On Tue, Feb 17, 2026 at 07:28:03PM +0000, Daniel Golle wrote: > 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?
I worry that if we add this to bootm upstream, it'll be another interface that can't ever go away. Building off of another bit of feedback I sent after this message here, I think the testing side of this support should be handled with CMD_something.._GENERIC, similar to CMD_FS_GENERIC. But perhaps not as one other part of this I wanted to ask about is, does this only support reading FIT images which set their load address? Or is there a call somewhere to lmb_alloc to grab an arbitrary hunk of memory somewhere? > > 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. To be clear, I just meant in terms of how to implement a bootmeth that is not just EFI or distro boot but instead something else also aimed at real world end user devices. Lots of people have a Steam Deck and a router built on top of OpenWrt :) -- Tom
signature.asc
Description: PGP signature
