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.
