[Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Mon Jul 20 00:56:34 BST 2020
On Monday, July 20, 2020, Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> 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
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
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
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
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
More information about the arm-netbook