[Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions

Paul Boddie paul at boddie.org.uk
Sun Jul 19 23:56:19 BST 2020

On Monday, 20 July 2020 00:20:58 CEST Luke Kenneth Casson Leighton wrote:
> On Sunday, July 19, 2020, Paul Boddie <paul at 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


> > 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 &reg_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, 

vga0: connector at 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:


But there is also this:


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):


> 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.


More information about the arm-netbook mailing list