On Monday, 20 July 2020 00:20:58 CEST Luke Kenneth Casson Leighton wrote:
On Sunday, July 19, 2020, Paul Boddie paul@boddie.org.uk wrote:
The principal differences appear to be as follows:
The EOMA68-A20 DT doesn't have HDMI nodes whereas the Cubieboard DTs have nodes for HDMI connectors and the usual peripheral nodes (&hdmi, &hdmi_out). Given the effort that went into putting micro-HDMI on the computer card, I guess there might be some definitions to add here.
yes.
OK, I'll add them.
The EOMA68-A20 DT has a special pinctrl node for mmc3_cd_pin (MMC3 card detect, I guess). There are also LED pin differences, but I think these are explained by pin definitions migrating to the sun7i-a20.dtsi file.
ah. the updates to the hardware it is now mmc0
OK.
Some I2C definitions seem to be different in the Cubieboard DTs, but that could also be due to pin definitions migrating to the sun7i-a20.dtsi file.
The Cubieboard DTs enable the display engine (&de) and power (&ac_power_supply).
There are some changes to the Ethernet node (&gmac). (I didn't think Ethernet was exposed by the computer cards when the specification was updated after the first round of cards being made.)
no it's gone
OK.
The Cubieboard DTs enable USB OTG (&usb_otg) whereas the EOMA68-A20 DT has a node ®_usb0_vbus that the other DTs do not have.
So, it seems possible that an updated DT file would be a minor variation on the Cubieboard 2 file.
pretty much.
I'll have to look at the OTG thing to figure out its significance.
[...]
Indeed. I guess the computer card device tree sits at a level between the chipset device tree and what would normally be the machine device tree.
if i understand you correctly: not quite.
the closest equivalent is 96boards and arduino shield dtbs.
here the 96boards dtb file *is* the machine level.
the pin header dtb locations however are NOT FILLED IN.
they instead have special references - pointers. each pointer is named (given the pin number) but is set to NULL by default.
at RUNTIME - not "device tree compile time" - at **RUNTIME** - a special command is run with a "shield dtb fragment" that directly and DYNAMICALLY replaces those named parameter pointers with the reference to the dtb fragment.
I understood the run-time aspect, but I thought that the specialisation would be a bit like the way something like the Cubieboard DT specialises the A20 DT.
So, there would be the A20 DT itself, the EOMA68-A20 DT which exposes or enables various peripherals, and then - at run-time - each housing's DT which activates the peripherals that were exposed but not enabled.
I guess the challenge is to describe the peripherals in a neutral way in the housing's DT so as not to taint them with the specifics of a particular computer card DT.
For example, how would a VGA output port be defined? Normally, there would be a connector node with an endpoint, so something like this in the housing DT, perhaps:
vga0: connector@0 { compatible = "vga-connector"; label = "vga";
port { vga_connector_in: endpoint { remote-endpoint = <&vga_out>; }; }; };
And I guess there could be a corresponding endpoint in the computer card DT that makes VGA output a possibility. There might also have to be some kind of ddc-i2c-bus attribute referencing a node elsewhere, too.
Sorry if this was discussed on the list or documented elsewhere!
[...]
I guess I should ask whether such support made it into either of them.
investigating 96boards and how their shields are supported should give some leads, there.
This was the first thing I found:
https://www.96boards.org/documentation/consumer/dragonboard/dragonboard410c/ guides/dt-overlays.md.html
But there is also this:
https://www.kernel.org/doc/html/latest/devicetree/overlay-notes.html
Oddly, the syntax in the above is far simpler than various other guides to overlays, making me wonder whether they are describing different kinds of overlays. For example (see part 2):
https://www.raspberrypi.org/documentation/configuration/device-tree.md
the absolute last thing needed however is hardcoded static compiled dtb, one for eoma68-a20-microdesktop, one for laptop, then one for eoma68-rk3288-microdesktop
it would be utterly disastrous for EOMA68 to consider the base dtb file to be a "chipset" level tree.
it has to be a *board* level (machine level) tree because of the standalone nature of EOMA68 Cards.
Yes, I think everyone understands this now, at least intuitively if not the precise mechanism. :-)
however all 68 pins are "shield" pins, *not* "machine" pins, and need to be dynamically connected just like for 96boards shields.
The mechanism, yes.
Paul