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

[Marek Vasut]

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.