From mboxrd@z Thu Jan  1 00:00:00 1970
From: Aneesh V <aneesh@ti.com>
Date: Thu, 16 Jun 2011 13:38:00 +0530
Subject: [U-Boot] SPL framework re-design
Message-ID: <4DF9B9E0.8020206@ti.com>
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 Wolfgang,

This is in continuation of our discussion in the following threads:

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/99795
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/99785

I think this discussion now needs a dedicated thread.

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.

Current Design:
* Currently a single board level Makefile determines what gets built
into SPL.
* 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>/


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.
* It then descends into sub-directories(SoC, board etc) to make the
respective libraries at those levels.
* These libraries are finally linked together by nand_spl/Makefile to
build the SPL image.


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.

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
available in media specific directories such as nand_spl/ and mmc_spl/.
Symbolic links?

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?

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?

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
does it handle the link step where the board level library is not
available?

best regards,
Aneesh