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

[Luke Kenneth Casson Leighton]

On Monday, July 20, 2020, Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

>
>
>
> i *hope* that they implemented "unload dynamic dtb" by now.
>

 Finally, if you need to remove all overlays in one-go, just call
of_overlay_remove_all() which will remove every single one in the correct
order.

it got implemented, thank goodness.

that means (hypothetically) that Cards can be powered from OTG, *unplugged
live*, put into a *new housing* and not require a reboot.

ultimately some Cards might actually have small internal batteries or
supercapacitors to keep running for long enough to transfer without
external power.

cat tsys01.dtbo > /sys/kernel/config/device-tree/overlays/tsys01/dtbo

that looks pretty straightforward.

the rest is probably because the dragonboard was quite early, and now the
docs are out of date


the rbpi doc looks pretty garbled.  phandles.  *that* was the name of the
pointer thing i mentioned.


it doesn't help the person writing that document that the rbpi foundation
actually changed the pinouts between versions of hardware, and of course
everyone expects the old overlays to "just work".

this kind of hell is precisely why eoma68 will not be "upgraded".  or if it
is, it'll be "faster sdmmc" or "faster usb3" both of which do dynamic
hardware-level runtime negotiation that has nothing to do with pinouts
themselves.

i.e. there will *never* be "abandonment" of pinout definitions.  a pin
defined now as i2c-clk *will remain defined as such*, forever.


one minor complication with eoma68 is that all pins (except usb) are
dual-purpose (GPIO) multiplexed however given that this is standard fare
for shield headers i do not anticipate problems in the overlay fragment
definitions.

l.



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