[U-Boot] SPL framework re-design

[Aneesh V]

Dear Wolfgang,

On Thursday 16 June 2011 04:17 PM, Wolfgang Denk wrote:
> Dear Aneesh,
>
> In message<4DF9B9E0.8020206 at 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/

Can you please extend this to show the SoC/board directories etc. I
guess they will go under spl/ and not under each media.

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

What's the distinction between spl/Makefile and spl/common/Makefile?
I guess we won't have any source files at spl/ level?

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

You mean you will re-use *.o files with normal u-boot? If so, do you
want to create symbolic links to them in the SPL directories or use
them in-place?

Whether you reuse the source code or the object files we still need
directories for all the levels for the respective Makefiles, right?

Also, at least some files will have to be built separately for SPL
because they have conditional compilation with CONFIG_PRELOADER kind of
flags.
>
>> 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/

I meant code that is media specific, such as MMC support, NAND support
etc. I think these should still go in spl/mmc, spl/nand etc right?

A multi-device SPL will have to use 2 or more such libraries.

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

So, is the logic like this: If there is a linker script in the board
directory use it, else look for a linker script in SoC directory?

BTW, my question was more about the contents of final image than the
memory map. But, I think this can be handled with appropriate use of
--gc-sections, -ffunction-sections, and -fdata-sections. The two main
entry points board_init_f() and board_init_r() are typically
implemented in the SoC layer or board layer of an SPL. This along with
the use of above compiler switches will help SoCs/boards to link in
only what they need, right?

best regards,
Aneesh