Re: [SPL] ELF loader support - design discussion

On Wed, Aug 26, 2026 at 05:16:44PM -0700, Urvashi Sharma wrote:

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

That's interesting. Well, as I said, things should already be
designed such that you just need to add ELF support as the existing load
mechanisms should handle getting the contents loaded. If that's not
quite the case, it would be among the enhancements I look forward to
seeing posted from you and your team. Thanks!

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

-- 
Tom

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

iHUEABYKAB0WIQTzzqh0PWDgGS+bTHor4qD1Cr/kCgUCapCu3gAKCRAr4qD1Cr/k
CjPiAQDs8/klOtWv4DtVMVrE+4CdiIyJaoD/ZykahZ7WPYi1EwEA7wNfhGJA6TYF
6FyBO4lzcY8A5MghdDkdSMudCMqg8AU=
=qp2q
-----END PGP SIGNATURE-----