Hi Daniel, On Mon, 16 Feb 2026 at 14:21, Daniel Golle <[email protected]> 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 <[email protected]> > --- > 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
