[U-Boot] SPL framework re-design

[Scott Wood <scottwood@freescale.com>]

On Mon, 27 Jun 2011 11:36:33 +0200
Wolfgang Denk <wd@denx.de> wrote:

> Dear Aneesh,
> 
> In message <4E080733.2030001@ti.com> you wrote:
> > 
> > > I wonder why do we need this whole spl thing in the first place (well,
> > > surely I know what they are used for but why do we need a separate entity
> > > for this)? Isn't it just the same U-Boot in, well, very special configuration
> > > (minimal set of drivers, no shell, etc)? Why do we need a whole shadow tree
> > > at spl/ instead of just providing the _configuration_?
> > >
> > > Am I missing something?
> > 
> > The reason is that the regular U-Boot is not configurable enough to
> > build the extremely small images that should fit in internal RAM. The
> > last time I attempted, I ended up getting an ~60KB image for
> > OMAP4(that too without any of the hardware initialization I am adding
> > in my SPL work).
> 
> This statement does not make much sense to me.  If we can do it in the
> spl/ directory, we should be able to do it in any other directory as
> well.  The worst to happen is that we have to keep two setsof object
> files separated, but chosing a different suffix should be sufficient.

We do it in the spl/ directory by bypassing the normal makefile
config system, specifying a board-and-spl-specific list of objects instead.

It could of course be done with the standard config system, but it will
require that every bit of code in U-Boot be enabled only with a particular
config option -- no "always on" code.  This would be a good thing anyway,
but it will take some work to do it cleanly.  A first step would probably
be a global "finegrained/small" flag that configs use to opt into the
new system, but eventually all bits of functionality should have
appropriate individual config symbols.

-Scott