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

[Daniel Golle]

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. The shared
part wouldn't be much more than just the two fdt_getprop_u32() calls to
read data-offset and data-size, which didn't seem worth an abstraction
layer.

- SPL doesn't track what's already in RAM. If it needs the same data
  twice (e.g. re-reading the FDT after discovering its full size), it
  reads from storage again.

- No caching - no equivalent of image_loader_lookup() that returns a
  previously-loaded region.

- No allocation tracking - no alloc_ptr bump allocator. SPL code
  manually manages destination addresses.

- No map() / map_to() distinction - SPL always provides an explicit
  destination buffer. There's no "load this somewhere, I don't care where"
  semantic.

- No cleanup - no resource lifetime management, no refcounting of
  underlying devices.

Anyway, I'm happy to reconsider if there's a specific shared interface
you have in mind, or if you believe it's worth (or even possible due
to size constraints) to extend SPL's loader code.