[PATCH 1/6] kernel: import dt-overlay configfs patches for 5.10

[Daniel Golle]

On Sat, Nov 27, 2021 at 02:24:52PM +0200, Oskari Lemmelä wrote:
> Hi,
> 
> On 27.11.2021 13.55, Daniel Golle wrote:
> > On Sat, Nov 27, 2021 at 11:28:05AM +0200, Oskari Lemmelä wrote:
> >> Hi,
> >>
> >> On 25.11.2021 3.06, Daniel Golle wrote:
> >>> Import patchset allowing loading and applying device tree overlays at
> >>> run-time via configfs.
> >>>
> >>> This will allow for packaging DTOs for hardware add-ons such as the
> >>> various HATs (Hardware Attached on Top) common for SBCs.
> >>> A new kernel config option CONFIG_OF_CONFIGFS is introduced and some
> >>> additional sysfs attributes are added in case CONFIG_OF_OVERLAY is
> >>> enabled.
> >>
> >> Is this something that did not get accepted by upstream linux?
> >> Those patches seem to be almost 8 years old.
> > 
> > I didn't investigate the full history of that patchset, I just found
> > it to be the default and only way available to modify DT from
> > user-space (and hence useful for SBC targets).
> > 
> 
> If I remember correctly dynamic runtime DT loading was rejected by linux
> community. Many SBC distros used them, but when it did not make to
> mainline they have changed strategy.

Oh, ok, sad. Thanks for the background.

> 
> U-boot dynamic device tree loading have been implemented after that to
> do same thing before Linux kernel is loaded.
> 

I know and we are using that to embed DT overlay into uImage.FIT images
for BPi-R64, and for this (SATA vs. PCIe) case it's the best solution
because it's a single choice and may need to be decided before extroot
is mounted (because extroot could be sitting on the SATA disk only
available after DTO is applied).

For a lot of less fundamental user modifications, such as adding an
RTC, enabling a user-added USB port or hooking LoRaWAN to an additional
bit-banged SPI bus, it seems much easier (and sufficient) to load the
DTO early in user-space.


Letting Linux apply DT overlays got two main advantages:

 * works equally well on all DT targets (not all of them even have
   a DT-aware bootloader, most of them come with bootloader which
   doesn't support DTO, think of ramips or ath79...)

 * easy to generate .ipk packages for DTOs (just placing dto in the
   right folder results in having it applied on reboot, it can even be
   loaded right away by post-install script)


Letting U-Boot handle DT overlays has one main disadvantage:

Embedding all possible DTOs into uImage.FIT could result in a huge
number of boot configurations as usually most DTOs can be combined with
other DTOs and we should cover all combinations using boot configs in
FIT then...
If we want U-Boot to load DTOs from filesystem (instead of FIT), that
filesystem needs to exist, first of all. Somethings needs to take care
of creating it, handling potential corruption (fsck), ...
Also FDT itself doesn't ensure integrity (afaik), we would have to wrap
DTOs as FIT or provide some sort of integrity protection mechanism (ie.
hashes we can check somehow)

While none of the above is that tragic if what you are having in mind
is a RaspberryPi sitting on your desk, it does become more tricky for
devices which do not boot off a removable SD card (think: soldered-on
SPI-connected flash typically found inside routers)

However, if this whole approach is a dead-end and will just burden us
with additional maintainance in the long run, we have to find a better
way.


> Oskari
> 
> > Quite a few trees on git.kernel.org come with that patch on top and
> > when looking for DT overlay documentation, the docs assume you got that
> > patch applied [1], [2]...
> > 
> > [1]: https://elinux.org/R-Car/DT-Overlays
> > [2]: https://www.96boards.org/documentation/consumer/dragonboard/dragonboard410c/guides/dt-overlays.md.html#3-load-overlays-dynamically
> > 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel