[RFC PATCH 01/20] boot: add image_loader on-demand loading abstraction

[Simon Glass]

Hi Daniel,

On Mon, 16 Feb 2026 at 14:21, Daniel Golle <daniel at makrotopia.org> wrote:
>
> Introduce struct image_loader, a small generic layer that lets callers
> read arbitrary byte ranges from a storage device and keeps a translation
> table of the regions that have already been loaded into RAM.
>
> The API consists of four functions:
>
>   image_loader_lookup()   - check whether a range is already mapped
>   image_loader_map()      - return a mapped pointer, reading on demand
>   image_loader_map_to()   - read into a caller-supplied address
>   image_loader_cleanup()  - release all backend resources

This is somewhat similar to blkmap, but in this case the block is 1.

How about calling it imagemap instead of image_loader? We have lots of
load_image and image_load stuff in the code base so image_loader would
be confusing.

>
> A read-callback (image_loader_read_fn) plus an opaque *priv pointer
> abstract the actual I/O so that block, MTD, and UBI back-ends can be
> added in follow-up patches without touching the core.
>
> Each backend provides a .cleanup callback which is invoked by
> image_loader_cleanup() to release held device references and free
> allocated memory. This ensures safe resource teardown between
> consecutive boot attempts.
>
> The translation table (struct image_loader_region[]) avoids redundant
> reads when the same region is requested more than once, and allows
> extending an existing mapping when a larger size is needed at the same
> offset. The table size is controlled by CONFIG_IMAGE_LOADER_MAX_REGIONS
> (default 16).
>
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
>  boot/Kconfig           |  20 +++++
>  boot/Makefile          |   2 +
>  boot/image-loader.c    | 163 +++++++++++++++++++++++++++++++++++++++++
>  include/image-loader.h | 141 +++++++++++++++++++++++++++++++++++
>  4 files changed, 326 insertions(+)
>  create mode 100644 boot/image-loader.c
>  create mode 100644 include/image-loader.h
>

Having looked through some of the patches, this should be a new
uclass, with a driver for each of the parent devices (block, mtd) that
you support.

In other words it should be a child of the media device, similar to
how UCLASS_BOOTDEV works.

See my notes in patch 2 as well.

I wonder if your tests could be added here or perhaps in the next
patch after this one?

> diff --git a/boot/Kconfig b/boot/Kconfig
> index e5db165424a..f6908e04a51 100644
> --- a/boot/Kconfig
> +++ b/boot/Kconfig
> @@ -1167,6 +1167,26 @@ config SYS_BOOT_RAMDISK_HIGH
>
>  endmenu                # Boot images
>
> +config IMAGE_LOADER
> +       bool "On-demand image loading from storage"
> +       help
> +         Provides a generic abstraction for reading image data from
> +         storage on demand. A translation table maps already-loaded
> +         regions to their RAM addresses, avoiding redundant reads.
> +
> +         Used by bootm when a storage device is specified instead of a
> +         RAM address.
> +
> +config IMAGE_LOADER_MAX_REGIONS
> +       int "Maximum number of mapped regions in image loader"
> +       default 16 if IMAGE_LOADER
> +       default 0
> +       help
> +         Maximum number of distinct image regions that can be mapped
> +         into RAM simultaneously. 16 is sufficient for typical FIT
> +         images (FDT structure + kernel + device tree + ramdisk +
> +         a few loadable sub-images).

It doesn't seem worth having a limit and this would render some images
unloadable. How about using an alist so you can handle any number?

Regards,
Simon