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

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


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



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