Re: [RFC PATCH 00/20] boot: add OpenWrt boot method and on-demand FIT loading

[Daniel Golle <daniel@makrotopia.org>]

On Tue, Feb 17, 2026 at 01:35:34PM -0600, Tom Rini wrote:
> 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.

Hm... The tricky part is kinda not the "load from somewhere" as that
just ends up calling the .read() op, which usually is more or less
identical to what some existing commands are already doing, hence easy
to use 'mmc read ...', 'mtd read ...', 'ubi read ...' for testing.
Seeing that all the steps in 'bootm' are working, sub-images are
correctly loaded (or skipped), verification steps (hashes, signature,
...) are all working was the more difficult part...

> 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?

In order to kinda do the same as was happening previously when first
loading the whole image from flash to $loadaddr, I've implemented a
trivial allocator for chunks with no defined load address in FIT.
In this case, image_loader_map() is called and loads to alloc_ptr,
which points to $loadaddr on init, and is then bumped by the
size loaded. I can use the lmb allocator instead, it's cleaner than
open-coding this.
In case of known load address (ie. specified for that sub-image in FIT)
and compression being IH_COMP_NONE, image_loader_map_to() is called
which directly loads that sub-image to the specified target address, no
allocation what-so-ever.

> 
> > > 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 :)

+1