[U-Boot] [RFC] Multiple binaries per U-Boot target

Simon Glass sjg at chromium.org
Fri Jul 19 18:53:33 CEST 2013


Hi,

On Fri, Jul 19, 2013 at 9:27 AM, Sascha Silbe <t-uboot at infra-silbe.de>wrote:

> Albert ARIBAUD <albert.u.boot at aribaud.net> writes:
>
> > Although, with recent proposals like the TPL one:
> >
> > http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/164432
> >
> > ... I am toying with the idea of a more generic build mechanism which
> > would allow a target to specify as many binaries as it needs, each with
> > its own configuration.
>
> FWIW, I like the idea. Apart from streamlining the current code, it
> would allow building custom chains of bootloaders. One thing I could use
> for development would be a minimal stage that can load one of two
> "normal" / full-blown U-Boot versions, similar to dual BIOS support on
> modern x86 PCs. All devices I work with can be un-bricked reasonably
> easily, but for most of them it either requires manual interaction
> (e.g. the push-button for UART boot on CuBox) or prevents "normal" boots
> (e.g. removing the SD card on Wandboard so that it boots via USB
> _instead_ of from SD card).
>
> In addition, it would allow customising SPL features without having to
> introduce more special code.
>

We actually use something like this in Chrome OS. Right now we are working
on a 'small' U-Boot which is not SPL but has no commands (they are compiled
out by a CONFIG option which I will post one day). This will involve two
complete runs of the U-Boot Makefile - one to create each version of
U-Boot. It would be great if this could be handled automatically in the
same build.

I wonder in fact if one day full U-Boot could be small enough then we
wouldn't need SPL for some SOCs.

Another idea I think Wolfgang suuggested was to implement modules, and
bring in code as needed, but that seems a bigger ask.

Regards,
Simon


More information about the U-Boot mailing list