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

[Tom Rini]

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.

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

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

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260217/6681b844/attachment.sig>