From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com>
Date: Thu, 16 Jun 2011 14:55:33 +0200
Subject: [U-Boot] SPL framework re-design
In-Reply-To: <20110616104716.762DD19E5AC3@gemini.denx.de>
References: <4DF9B9E0.8020206@ti.com>
	<20110616104716.762DD19E5AC3@gemini.denx.de>
Message-ID: <BANLkTim9AE2aszKLiDH53vd+Hjpz7GVoNA@mail.gmail.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

Hi all,

for my MIPS based boards I tested a approach similar to Wolfgang's one
in the last weeks.
My goal was to create a SPL image, that is able to boot from a SPI flash.

The basic idea is to have a spl directory that is used as remote build
directory for all object files
needed for the SPL image. It contains only the Makefile and nothing
else. This Makefile is
a strongly simplified version of the TOPDIR/Makefile, uses
TOPDIR/config.mk and creates
a u-boot-spl.bin. The SPL build can be enabled by defining
CONFIG_UBOOT_SPL in the board config file.

If the spl/Makefiles becomes active, an additional variable name
CONFIG_UBOOT_SPL_BUILD wiil be
exported in the make environment. Additionally
-DCONFIG_UBOOT_SPL_BUILD will be added
to the CFLAGS (similar to -DCONFIG_PRELOADER). This allows us to reuse
almost of the arch, SoC and
board code.

The board_init_f function could be implemented in
arch/ARCH/lib/board_spl.c to allow arch-specific code.
The relocate_code and board_init_r functions must not be compiled,
they are not needed anyway. This
can be simply controlled with -DCONFIG_UBOOT_SPL_BUILD.

With this approach I can create a SPL image, that reuses all of the
minimal needed MIPS CPU code,
mySoC code, my board lowlevel_init, my SPI driver and some parts of
the generic SPI flash driver.

Some further comments below

On Thu, Jun 16, 2011 at 12:47 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Aneesh,
[snip]
>
> 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.

By using something like CONFIG_UBOOT_SPL_BUILD in the make environment
and as CFLAG all code can be reused without symlinking or copying.
You need only a separate directory for putting the object files in.

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

To use the spl directory as remote build directory, the obj and src variables
must be tweaked a little. To keep this changes minimal, it is not possible to
have further source files and directories inside the spl directory. I suggest to
put common spl code in TOPDIR/lib/spl/common, TOPDIR/lib/spl/nand and so on.

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

Best regards
Daniel