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

[Luke Kenneth Casson Leighton]

On Sunday, July 19, 2020, Paul Boddie <paul at boddie.org.uk> wrote:

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


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



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68