[U-Boot] SPL framework re-design

[Scott Wood]

On Thu, 16 Jun 2011 13:38:00 +0530
Aneesh V <aneesh at ti.com> wrote:

> New Design Proposed by Wolfgang:
> * Have a top-level Makefile in the SPL root-directory - for instance
> 'nand_spl/Makefile'
> * nand_spl/Makefile builds a generic library with the generic source
> files at this level.

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.

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.

And no, I don't think we can get rid of building the objects separately,
and I don't want a situation where #ifdef NAND_SPL is honored in some files
but not others.

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.

> 3. Customizability - In the existing scheme what gets built into the
> SPL for a given board was completely customizable by the board level
> Makefile.

This is a critical feature for a situation where we need to fit in a tiny
space and target a variety of different hardware.

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

-Scott