On Sunday, July 19, 2020, Paul Boddie paul@boddie.org.uk wrote:
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.
if starting from a recent cubietruck dts, the interface (schematic) is exactly the same, so cut/paste is perfectly appropriate.
the 2 other USB ports are plain USB2 and go out on EOMA68 pins.
[...]
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.
ah, yes.
So, there would be the A20 DT itself, the EOMA68-A20 DT which exposes or enables various peripherals,
so, some peripherals like the otg, mmc0, hdmi and also interestingly the 2 USB ports despite being on the EOMA68 connector, these would all go in the same level as cubietruck i.e. machine level.
and then - at run-time - each housing's DT which activates the peripherals that were exposed but not enabled.
yes. the 2nd sdmmc (mmc3 i think), the i2c, uart, spi, rgbttl and eint, all those would go into "dynamic pointer default NULL" set.
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.
that's where the "shield" thing comes in.
For example, how would a VGA output port be defined?
that ie precisely what the dynamic thing does: it's specified in the dynamic fragment.
the dynamic fragment contains the names eoma68-pin1 to 68 and says that when eoma68-pin33 is connected it shall be given the purpose "RGBTTL HSYNC".
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>; }; };};
this definition would go in the *Housing* dtb fragment.
the vga_out is defined to contain *dynamic* connections which link HSYNC to eoma68-pin33 (whatever).
only when the "dynamic merge" kernel syscall is made will the substitutions occur, *including* the (now new) definition of vga0
events will then fire, the associated rgbttl.ko gets loaded, and (eventually) /dev/fb0 appears.
And I guess there could be a corresponding endpoint in the computer card DT that makes VGA output a possibility.
no: it really does go in the *Housing* dtb fragment.
There might also have to be some kind of ddc-i2c-bus attribute referencing a node elsewhere, too.
exactly. and one for mmc3, and one for SPI and uart. but all in the *fragment* not the main eoma68 board file.
all with pin definitions that are *only* connected up at runtime.
all of which reference the eoma68 pins.
note:
any developer that connects peripherals via external arduino circuits (breadboards) is on their own, here, although the process needs documenting.
a user connecting say an SPI Ethernet to the MicroDesktop header would need to start from the Microdesktop dts fragment, add the spi peripheral to it, the run the "dynamic dtb load" command.
i *hope* that they implemented "unload dynamic dtb" by now.
Sorry if this was discussed on the list or documented elsewhere!
a long time ago.
[...]
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
ta-daaa that's it. overlays.
give me a sec to review the links
l.