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
signature.asc
Description: PGP signature
