[U-Boot] [RFC] Multiple binaries per U-Boot target (was: Separately compile Master boot loader)

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

On Thu, 11 Jul 2013 10:35:07 +0200, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:

> [...] nor is there currently a way to build several U-Boots in one go.

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.

The simplest targets would have a single build (U-boot itself).

SPL-type targets would have two (SPL and U-Boot).

TPL-like ones would have three (SPL, TPL and U-boot).

Etc.

A developer could then choose to build the default binaries or a
specific set, e.g. only rebuild U-boot for targets whose SPL needs not
change.

For maximum reuse, U-boot would have to be a set of components (and
that's what it is right now, and would be all the more with Kconfig)
and each 'binary' would be a selection of which components. Examples of
components would be:

- startup (mandatory component which contains the entry point);

- setup (optional component which would set up the system incl. DDR);

- relocation (optional component which moves the code up in DDR);

- console (optional component which allows interactive commands);

- chainload (optional component which allows chainloading another
  binary);

Etc. Of course there would be components for architecture support
(PPC, ARM, MIPS, x86)..., for CPU [class] support, for driver support,
for function support).

The interest of this idea would be that SPL and U-Boot would not be
distinguished by #ifs across the code, but only by their respective
configurations. We'd have a clear view and control in a single place
(the configuration header file) of what goes in SPL and what goes in
U-Boot (and what goes in TPL).

To be clearer on configurations and header files: my idea would be to
put SPL configuration under a single '#if CONFIG_BUILDING_SPL'-like
conditional, and U-Boot configuration under #if CONFIG_BUILDING_UBOOT,
and that SPL related configuration options either be replaced by their
general equivalents (for instance, no need for CONFIG_SPL_I2C_SUPPORT
if the SPL configuration includes some CONFIG_I2C_somedriver) or turned
into a component option (e.g. CONFIG_SPL_MAX_FOOTPRINT becoming option
CONFIG_SIZECHECK_MAX_FOOTPRINT).

I don't think this would require overhauling the whole of U-Boot; nor
should all be done in one go. We could independently:

- make sure SPL, U-Boot and TPL are independent sub-targets which can
  be built separately from the command line if needed, with a sane
  default for existing targets;

- progressively replace CONFIG_SPL_xxx options with equivalent
  CONFIG_SYS_xxx ones or move them into new "components" such as
  "sizecheck" or "chainload".

I realize I'm drawing a very rough picture here...

Comments/Criticisms welcome.

Amicalement,
-- 
Albert.