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

[Daniel Golle <daniel@makrotopia.org>]

On Tue, Feb 17, 2026 at 03:04:09AM +0100, Marek Vasut wrote:
> On 2/17/26 2:18 AM, Daniel Golle wrote:
> > Hi Marek,
> > 
> > thanks for taking a look at the series!
> > 
> > Let me reply inline below:
> > 
> > On Mon, Feb 16, 2026 at 11:16:24PM +0100, Marek Vasut wrote:
> > > On 2/16/26 10:21 PM, Daniel Golle wrote:
> > > 
> > > Hi,
> > > 
> > > > 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.
> > > 
> > > [...]
> > > 
> > > > 4. On-demand loading: None of the existing methods support loading FIT
> > > >      subimages directly from storage. OpenWrt's FIT images typically
> > > >      contain a 5-20 MB squashfs that does NOT need to be copied to RAM —
> > > >      the kernel maps it directly from flash. The bootloader only needs
> > > >      to load the kernel and DTB (~5-10 MB), not the entire 20-50 MB
> > > >      container. This requires a new loading abstraction.
> > > 
> > > Isn't this partial loading exactly what SPL does when the fitImage is
> > > generated with external data (mkimage -E) ? SPL loads and traverses the
> > > tree, and then loads the remaining chunks (files) only when needed if I
> > > recall it right ?
> > 
> > Yes, the image_loader abstraction in this series is essentially the
> > main-U-Boot equivalent of SPL's spl_load_info.read(), adapted for the
> > richer set of storage backends, byte-addressed, providing an interface
> > for both "load this to where ever" and "load this to a specific target
> > address" (image_loader_map() vs. image_loader_map_to()), and the full
> > fit_image_load() verification pipeline. The integration point in
> > fit_image_load() (patch 09/20) is ~50 lines of new code gated by if
> > (images->loader && external_data) - it reuses all existing FIT property
> > parsing, load address negotiation, and hash verification unchanged.
> > 
> > That said, the image_loader abstraction itself is format-agnostic - it
> > only deals with byte offsets, lengths, and RAM destinations. The same
> > three storage backends could be wired into other executable formats with
> > minimal effort, such as ELF, legacy uImage or UEFI PE.
> > 
> > Likewise, adding a backend based on fs_read() would be trivial,
> > extending U-Boot's wget to support range requests and using it as
> > image_loader backend would not be hard either.
> > 
> > > Can that SPL code be reused instead ?
> > 
> > I considered factoring out a shared "FIT external data reader" between
> > SPL and U-Boot proper, but the two callers want fundamentally different
> > things: SPL wants minimal code size and populates spl_image_info; U-Boot
> > proper wants full verification and populates bootm_headers.
> 
> I suspect the feature set of each loading stage can be configured e.g. using
> "if (IS_ENABLED(...))" to keep the size under control ?
> 
> I would be very happy if we could have ONE consistent code base used for
> loading in all of TPL/SPL/U-Boot . Custom special loader in U-Boot and
> different special loader in SPL and so on, will only lead to inconsistency
> and increased maintenance burden. Worse, it will lead to obscure bugs which
> will differ between U-Boot and SPL, or bugs being fixed in one and not the
> other.

This implies changing the parameter "ulong sector" to a byte offset,
which means all existing readers and users will have to be changed as
well, and also code to deal with unaligned start offsets will have to be
added. Other than that it's mostly a matter of adding some #ifdef-ery,
conditionally extending struct spl_load_info with
 - a cleanup callback function pointer
 - alloc_ptr for bump allocator
 - the array of already mapped regions

None of that is used by the readers, so the low-level spl_mmc reader
could be reused and extended -- but it's already very messy with many
hacks and special cases, it's own device and partition hunters, ...
and would basically need adding almost all of the code which is currently
in image-loader-blk.c (to handle the unaligned start offset, ...)

The other SPL readers are even more unsuitable:

 - The SPI-NOR and NOR readers lack support for MTD partitions, instead
   they are using a downstream DT property to specify *one* static offset
   ('u-boot,spl-payload-offset')

 - The UBI reader deals only with static UBI volumes, and support for UBI
   in SPL is a light-weight minimal thing incompatible with the full UBI
   implementation in U-Boot proper.

 - The FIT reader in SPL uses a very different approach from the
   image_loader approach I suggested. It is basically a minimal
   implementation of a FIT parser, while I'm suggesting to glue
   support for the image_loader into boot/image-fit.c of U-Boot proper,
   hence keeping and reusing all of its features.
   See patch "boot: fit: support on-demand loading in fit_image_load()".

So there really isn't much overlap other than the fact that there is a
struct with a priv pointer and a .read callback, and even that uses a
different addressing parameter (sectors vs. bytes).

Imho, trying to unite the two "with a hammer" will do more harm than good.