Re: [SPL] ELF loader support - design discussion

On Wed, Aug 26, 2026 at 11:56:36AM -0700, Urvashi Sharma wrote:

> Hi Everyone,
> 
> Hope you all are doing well.
> 
> I'm working on a use case that requires booting via SPL in Falcon Mode,
> where SPL is the natural choice given its minimal footprint. Our board
> specifically needs to load an ELF image from storage (e.g., MMC/NAND/SPI)
> directly into memory as part of this boot flow.

Note that "Falcon Mode" is specifically SPL boots Linux. So please
explain your use case a bit more, so we can help.

> U-Boot already provides the bootelf shell command for working with ELF
> binaries: it parses an ELF image, maps each segment to its linked address,
> and jumps to the entry point. However, bootelf assumes the ELF is already
> resident in memory - it does not read from storage itself. This differs
> from the existing SPL image loading methods (MMC, NAND, SPI, etc.), which
> combine storage access with image parsing in a single step. Since the FIT
> and legacy image formats also don't meet our needs, there is currently no
> existing SPL loader path that can take an ELF image from storage into
> memory.
> 
> To close this gap, I'm planning to implement a new ELF loader within SPL,
> built on the existing spl_image_loader framework (registered via
> SPL_LOAD_IMAGE_METHOD) that already lets board/SoC vendors plug in their
> own storage-aware image-loading implementations.
> 
> Since this would be a significant effort, I wanted to check with the
> community before proceeding - has anyone worked on something similar, or
> have any suggestions/concerns I should consider?

The SPL frameworks, generally speaking, are around ${content} from
${location} and then executing it. So at the high level, you should just
be needing to add "validate and execute ELF". But the baseline
requirement is to explain why you have an ELF and aren't just reading /
executing something in say a FIT image already.

-- 
Tom

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQTzzqh0PWDgGS+bTHor4qD1Cr/kCgUCao9FcAAKCRAr4qD1Cr/k
CtuxAP0SAKfmJsQX4AuI3t7sGjEk2UflU0Yp/042plWGKH99yAD8DAJk1dLTXSIX
jwuhIgbUNG/MKG15RjRqTwruGx9NjAY=
=+7Bc
-----END PGP SIGNATURE-----