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

[Tom Rini]

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
-------------- 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/ddd9a8cd/attachment.sig>