On Tue, Feb 17, 2026 at 12:13:58PM -0600, Tom Rini wrote: > On Mon, Feb 16, 2026 at 09:21:14PM +0000, Daniel Golle wrote: > > Hi all, > > > > This RFC series adds a new boot method for OpenWrt's "uImage.FIT with > > embedded rootfs" firmware model, along with the underlying infrastructure > > to load FIT images on-demand directly from storage devices without copying > > them entirely to RAM first. > > > > I would like to discuss the design with U-Boot maintainers and fellow > > OpenWrt developers before submitting a formal patch series. > [snip] > > Three storage backends: > > > > - Block device (eMMC, SD, SATA, NVMe, USB mass storage, virtio) > > - MTD (SPI-NOR, raw NOR, raw NAND with bad block skipping) > > - UBI volume (SPI-NAND, raw NAND) > > > > The "bootm" command is extended to accept a storage device specification > > instead of a RAM address: > > > > bootm mmc 0:4 # boot FIT from eMMC partition 4 > > bootm mtd recovery # boot FIT from MTD partition "recovery" > > bootm ubi recovery # boot FIT from UBI volume "recovery" > > > > This infrastructure is independently useful beyond the OpenWrt boot > > method. Any board that stores a FIT image directly in a partition > > (rather than as a file on a filesystem) can benefit from on-demand > > subimage loading. > > For the user interface portion of this, since this is implementing > bootmeths, this should all be handled under bootflow/bootdev/etc > commands, and not adding further options to bootm.
I thought it would be useful independently of bootmeth/bootflow/bootdev for `bootm` to have these options, as it will allow to gradually migrate a large number of our downstream boards. Many of them at this point still require scripts to handle things like extracting MAC addresses from flash (in ways the original vendor has decided to store them), updating U-Boot or TF-A blobs, ... and migrating all of that to use bootmeth/bootflow/... will take time. In the meantime, already getting rid of (duplicate) scripts "read firmware from mmc/ubi/mtd" would be feasible, is less of a burden and easy to test for people who got the respective board at hand. Also, testing loading (partial) images directly from storage outside of bootmeth has been very useful during development. Would it be an option to hide the new bootm cmdline features behind an additional Kconfig option maybe? > > Since you're also talking about an A/B mechanism, looking at the RAUC > support may also be helpful as that's another widely deployed > methodology we support now via standard boot. Yes, I've looked into RAUC and it has (more or less) recently gained support for UBI, which indeed brings it closer to being useful in the context of OpenWrt. Due to OpenWrt having a read/write overlayfs typically covering all raiming space on flash, using a symmetric A/B mechanism is not feasible in many cases, especially if space is limited (typical: 128 MB SPI-NAND), as both A and B would require independent r/w overlayfs, effectively halfing the space available for users. Configuration being synced across A and B (which may be different versions) is another non-trivial problem. Hence, OpenWrt has opted to implement a production vs. recovery dual-boot model when ever we have the choice to do so. The recovery system doesn't have any persistent state, hence elimintating the need for finding an arrangement regarding the read/write overlay filesystem, or keeping configuration in-sync across different versions of the firmware. RAUC also defines the firmware format, which for OpenWrt often isn't an option as we like to remain compatible with the vendor/stock firmware formats (in 90%+ of cases: uImage.FIT or legacy uImage, sometimes with appended metadata) Apart from that, the dependencies required for RAUC on the target (OpenSSL, libglib2, libdbus, expat, ...) are overkill for many smaller OpenWrt devices. We've made big efforts to avoid FreeDesktop-land and have created userspace tools which require only a fraction of the resources. We offer free choice of the TLS provider library (OpenSSL, mbedTLS and wolfSSL are 1st class citizens; there is some support gnuTLS as well), and having only one of them installed. A hard dependency on OpenSSL alone is already a show-stopper for anything to be considered becoming part of the core infrastructure. Requiring an XML parser would end the conversation. I consider it as extremely unlikely that this will ever change for OpenWrt, and we do consider that as one of our strengths. The total size of a fully usable OpenWrt installation currently starts at around 6 MiB on low-end targets (that does include the kernel and all drivers, as well as mbedTLS and everything else needed for a router or WiFi access point, including a Web UI). Random examples - ultra low-end device: NEC Aterm WR8750N https://downloads.openwrt.org/releases/24.10.5/targets/ath79/tiny/openwrt-24.10.5-ath79-tiny-nec_wr8750n-squashfs-sysupgrade.bin - aforementioned BananaPi R3 WiFi 6 DBDC router: https://downloads.openwrt.org/releases/24.10.5/targets/mediatek/filogic/openwrt-24.10.5-mediatek-filogic-bananapi_bpi-r3-sdcard.img.gz (SD card image which can be used directly, or to install to SPI-NAND, SPI-NOR or eMMC)
