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.
