[U-Boot] SPL framework re-design

[Wolfgang Denk <wd@denx.de>]

Dear Scott Wood,

In message <20110616114556.7d3c2a78@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.

> 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?

> We could perhaps get rid of the symlinking and have the SPL makefile build
> directly from the source into a different object location, though whether
> we should depends on whether it actually makes things simpler.

Agreed.

> > 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.  If files which export the same funcktion
names get linked together we have an error somewhere that needs to be
fixed - but this is not a new issue, this situation is the same now
already.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I dislike companies that have a we-are-the-high-priests-of-hardware-
so-you'll-like-what-we-give-you attitude. I like commodity markets in
which iron-and-silicon hawkers know that they exist to  provide  fast
toys for software types like me to play with..."    - Eric S. Raymond