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

[Paul Boddie]

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

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 &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, 
perhaps:

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:

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