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

[Tom Rini]

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.

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.

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