From mboxrd@z Thu Jan  1 00:00:00 1970
From: Wolfgang Denk <wd@denx.de>
Date: Thu, 16 Jun 2011 12:47:16 +0200
Subject: [U-Boot] SPL framework re-design
In-Reply-To: <4DF9B9E0.8020206@ti.com>
References: <4DF9B9E0.8020206@ti.com>
Message-ID: <20110616104716.762DD19E5AC3@gemini.denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Dear Aneesh,

In message <4DF9B9E0.8020206@ti.com> you wrote:
> 
> To make sure I understand your new proposals, let me consolidate them
> here. Please correct me if I am wrong. Also, in the end I have some
> questions about your new proposal. Some of the questions are getting
> into the details. But I need the details to re-work my patches
> according to the new proposal.

Thanks for going into this!

> Current Design:
> * Currently a single board level Makefile determines what gets built
> into SPL.

And as we have learned so far, these board level Makefiles contain a
large lot of duplicated code, especially when dealing with several
boards based on the same or similar Soc(s).

> * This Makefile chooses all the files to be built. Makes symbolic links
> to them in the board level SPL directory and builds and links them to
> create the SPL image.
> * This structure is duplicated for different types of SPLs, nand_spl,
> onenand_ipl, mmc_spl etc.
> * Directory structure is something like:
> nand_spl/board/<vendor>/<board>/

All correct so far.

> New Design Proposed by Wolfgang:
> * Have a top-level Makefile in the SPL root-directory - for instance
> 'nand_spl/Makefile'

The longer I think about this the more I feel we should even take this
one step further.  Looking at what we have so far:

	mmc_spl/
	nand_spl/
	onenand_ipl/

we are also duplicating the structure across different boot media. I
think we should re-organize this as follows:

	spl/
	spl/common/
	spl/mmc/
	spl/nand/
	spl/onenand/

This can probably done in an initial step which is more or less
plain renaming and without any functional changes.

We would then have

	spl/Makefile
	...
	spl/common/Makefile
	...
	spl/nand/Makefile
	...

> * nand_spl/Makefile builds a generic library with the generic source
> files at this level.

...this changes to: "spl/Makefile, spl/common/Makefile and
spl/<bootdevice>/Makefile build libraries with the generic object
files at their respective level (assuming these exist).

> * It then descends into sub-directories(SoC, board etc) to make the
> respective libraries at those levels.

...again with the addition that these may or may not exist - depending
if any board specific code is needed or not.

> * These libraries are finally linked together by nand_spl/Makefile to
> build the SPL image.

...together by spl/Makefile ...

> Open questions about the new proposal:
> 1. We may need more layers than just generic, SoC and board. For
> instance all SPLs typically use start.S from the CPU directory. Also,
> a lot of SoC code is typically SoC family generic. How about something
> like this for the directory structure:
> 
> nand_spl/<cpu>/
> 	      <soc-family>/
> 	      <soc1>/<board>/
> 	      <soc2>/<board>/
> Maybe, <arch> needs to be added too.

If this seems necessary, we may do this. But I would like to avoid to
copying basicly the whole source tree (either as verbatim copies or
as symlinks).

We should try to get rid of the need to create symbolic links. If we
use the same source files as for the "normal", then we should also
use the normal object files.

> 2. How do we handle the type of SPLs that handle different media. For
> instance omap3 spl will support mmc and NAND. Can we have a directory
> tree starting with 'spl/'? If so, how does this tree share generic code

Yes, this makes a lot of sense to me - see above.

> available in media specific directories such as nand_spl/ and mmc_spl/.
> Symbolic links?

No.  Let's put this stuff into  spl/common/

> 3. Customizability - In the existing scheme what gets built into the
> SPL for a given board was completely customizable by the board level
> Makefile. 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?

As far as building is concerned, the files to be built should always
(unless truly common) be selected based on CONFIG_ settings in the
Makefiles.

As far as linking is concerned, we can do the same for most cases
(keep in mind that all linker scripts are run through the C
preprocessor, so we can do a lot of things).  For those cases where
even more flexibility is needed, we can use custom linker scripts in
the board directories.

> 4. How do we handle the case where a given SoC doesn't need any board
> level code for the SPL(This is the case with OMAP4). Is this handled by
> just not have any <board> directories?

Right.  Or, if a board directory exists for other reasons, by just
building an empty board library.

> 5. If so, how does the top-level SPL Makefile handle this? By checking
> for the existence of <board> directory before descending into it? How

Yes.

> does it handle the link step where the board level library is not
> available?

In the same way: we test if the <board> directory exists, and only if
this is the case it gets added to the list of directories to descend
into for building, and to the list of libraries to be linked together.

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
"A fractal is by definition a set for which the Hausdorff Besicovitch
dimension strictly exceeds the topological dimension."
- Mandelbrot, _The Fractal Geometry of Nature_