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

[Daniel Golle]

On Tue, Feb 17, 2026 at 03:18:53PM -0600, Tom Rini wrote:
> On Tue, Feb 17, 2026 at 09:07:31PM +0000, Daniel Golle wrote:
> > 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.
> 
> Yes, this part would be more of just an easier syntax, perhps "block
> read type ...".
> 
> > 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...
> 
> Presumably because of the partial read part? That does get back to
> Marek's earlier question about if you can't get that already with
> "mkimage -E" and I didn't see the answer, sorry.

For partial read to work, using "mkimage -E" is a requirement, everything
else wouldn't make sense. However, that still doesn't magically solve
loading (and validating) on the needed parts from storage to RAM, at this
point (ie. without this series) it is still expected that the whole image
has been loaded to RAM at the point `bootm` is called.

> 
> > > 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.
> 
> Oh yes, this cannot be open coded. The lmb framework is how we avoid
> some classes of security issues and just open coding that brings them
> all right back. But this is also something that's solved, today, for FIT
> images of KERNEL_NOLOAD so we shouldn't need anything new here, either.

+1

> 
> > 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.
> 
> Is that with the existing code, or did you write something new here as
> well?

As the existing code expects the whole image to reside in RAM and only
take care of validation, decompression and relocation, I had to extend
image-fit.c to use the image_loader to only load the parts *from
storage* which are actually needed, and if possible, load them directly
to where they are supposed to go. Imho, the code is simple enough to
just look at it:

https://patchwork.ozlabs.org/project/uboot/patch/ab7837536e4567b90d7cb662984dd7e637ef4361.1771275704.git.daniel@makrotopia.org/

At this stage (because I first wanted to discuss the general approach)
the patch still skips some parts of image-fit.c, which is obviously not
acceptable for upstream inclusion, but good enough to demonstrate the
idea and also try it in practise.

Ie. the 'goto storage_loaded' has to go away and all of image-fit.c has
to be changed to equally work on RAM-backed or storage-backed images.