[U-Boot] SPL framework re-design
Scott Wood
scottwood at freescale.com
Mon Jun 27 20:42:05 CEST 2011
On Mon, 27 Jun 2011 11:36:33 +0200
Wolfgang Denk <wd at denx.de> wrote:
> Dear Aneesh,
>
> In message <4E080733.2030001 at 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
More information about the U-Boot
mailing list