On Sunday, July 19, 2020, Paul Boddie paul@boddie.org.uk wrote:
On Sunday, 19 July 2020 22:43:59 CEST Luke Kenneth Casson Leighton wrote:
On Sun, Jul 19, 2020 at 9:35 PM Paul Boddie paul@boddie.org.uk wrote:
It looks like the device tree (sun7i-a20-eoma68-a20.dts) is very
similar
to that from the Cubietruck 2.
that sounds about right. possibly the original cubieboard.
OK. From what I can see, there are strong similarities between the above file and both sun4i-a10-cubieboard.dts and sun7i-a20-cubieboard2.dts. (I got mixed up and wrote Cubietruck 2 above.)
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.
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
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
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.
Were the differences documented and are there any schematics to provide any necessary insight when updating the device
tree?
there's PDFs somewhere... http://hands.com/~lkcl/eoma/ such as this: http://hands.com/~lkcl/eoma/DS113-V2.7-2017-02-17.pdf
And, as usual, when I go to download it, I find that I already have it alongside a schematic for the Cubietruck!
:)
the thing is that it is critically important that the dts file *do not* include the peripherals associated with the "Boards" (Micro-Desktop, 15in laptop). the peripheral sets *MUST* go into a "dynamic include" file that is detected at boot time and "inserted" into the live device-tree.
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.
this functionality - dynamic runtime "insertion" of device-tree fragments - was an idea *in development* back in.... 2013 we have had to wait several years for this functionality to make its way into both u-boot and the linux kernel.
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.
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.
however all 68 pins are "shield" pins, *not* "machine" pins, and need to be dynamically connected just like for 96boards shields.
l.