Re: [SPL] ELF loader support - design discussion

Thank you, Tom, for the quick response.


Yes, I understand that SPL Falcon mode is intended to boot Linux, and that
actually aligns well with our requirements. Our plan is to use SPL as a
lightweight secure bootloader that loads a set of images and performs some
platform-specific initialization before handing off to Linux. At this time,
we are not planning to include U-Boot proper or any additional boot stage
in between.


Regarding FIT, I understand that it places image contents at their required
load addresses, but that is not really the problem we are trying to solve.
From our perspective, particularly from a secure boot standpoint, ELF is
deeply integrated into our platform architecture, tooling, signing process,
and secure boot model. Our entire ecosystem is built around ELF. Having
said that, Elf provides us many benefits that suit our secure boot model.

As we move toward U-Boot, we would like the transition to be gradual, since
we do not want to disrupt the existing ecosystem all at once. We are
therefore trying to take small, incremental steps.

Thanks,
Urvashi

On Wed, Aug 26, 2026 at 12:58 PM Tom Rini <[email protected]> wrote:

> 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
>