[U-Boot] SPL framework re-design

[Scott Wood]

On Fri, 17 Jun 2011 00:09:00 +0200
Wolfgang Denk <wd at denx.de> wrote:

> Dear Scott Wood,
> 
> In message <20110616114556.7d3c2a78 at schlenkerla.am.freescale.net> you wrote:
> >
> > What is a "generic SPL library", or even a "generic NAND SPL library"?
> > 
> > There is no code that is shared by all NAND SPLs.  The files directly under
> > "nand_spl/" are alternatives that the board makefile can choose.
> 
> I think there is tons of duplicated code that could and should be
> extraced into common directories.

There's some, but really not that much that I can see.  A handful of lines
for putc/puts.  Some similar but not identical board init code within a
board family.

Extracting duplicated code into files in the common directories, which
can be picked up by the targets that want them, can be done without
significant changes to the makefile structure.

> > Counterproposal: keep the basic structure the same, but refactor the
> > makefiles so that they use a common template but supply their own policy.
> > 
> > That is, the board makefile would just set some variables to be lists of
> > objects it's interested in (and any other relevant tunables, or special
> > rules), and then include the common SPL makefile that will do all the
> > symlinking and building.
> 
> Or put this from the head on it's feet and use a board specific
> config.mk which gets included by the SPL makefile?

That's a little less flexible, but probably OK.

> > > That's no longer the case with the proposed scheme. Source
> > > files and Makefiles in the generic and CPU directory are shared by many
> > > boards. How do we allow customizability for individual boards. using
> > > CONFIG_ flags? This may be needed for the boards to make the right
> > > trade-offs based SRAM budget/requirements etc. Maybe, --gc-sections and
> > > -ffunction-sections help in dealing with this?
> > 
> > What about when code depends on #defines that are not present for a given
> > target, because that target isn't going to select that file?  What about
> > when alternative files have the same function names?
> 
> What do you mean?  When a target does not select (and thus build) a
> file, then it does not matter which #defines are in there or not -
> they don't get build anyway.

That's currently how it works, but it appeared that a suggestion was being
made to build certain code as a library before getting to what the target
wants.

-Scott