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@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
