From mboxrd@z Thu Jan  1 00:00:00 1970
From: Aneesh V <aneesh@ti.com>
Date: Thu, 16 Jun 2011 19:08:33 +0530
Subject: [U-Boot] SPL framework re-design
In-Reply-To: <20110616121540.196C519E5AC4@gemini.denx.de>
References: <4DF9B9E0.8020206@ti.com>
	<20110616104716.762DD19E5AC3@gemini.denx.de>
	<4DF9EE03.8010105@ti.com>
	<20110616121540.196C519E5AC4@gemini.denx.de>
Message-ID: <4DFA0759.2060606@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

On Thursday 16 June 2011 05:45 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4DF9EE03.8010105@ti.com>  you wrote:
>>
>>> 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.
>
> Correct, i. e. please add for example:
>
> 	spl/board/freescale/mx31pdk/
> 	spl/board/freescale/mx31pdk/Makefile
> 	...

I thought we were going to have cpu directory SoC directory etc in this
directory structure.

>
>>> ...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?
>
> I think we can implement the logic to decide which directories need to
> be entered and built into spl/Makefile, so we can keep this out of the
> top level Makefile.
>
> spl/common/Makefile is responsible for building the common code in the
> spl/common/ directory.
>
> Correct, I do not see need for any sources in spl/
>
>>> 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?
>
> We should use them in-place. Using --gc-sections and
> -ffunction-sections we have enough granularity to select only what we
> really need.
>
>> Whether you reuse the source code or the object files we still need
>> directories for all the levels for the respective Makefiles, right?
>
> Can we not use the objects that get normally built, with the existing
> Makefiles?

But where do you add the reference to SoC level and CPU level object
files? Which library do you make them part of? I thought the board
level Makefile was meant only to build the board specific library.

For example, let's say we have board 'a' and 'b' of same SoC(soc).
Unless we have a SoC directory we may have to do something like this.

spl/board/<vendor>/a/Makefile:
OBJS := soc_1.o
OBJS += soc_2.o
OBJS += a.o

spl/board/<vendor>/b/Makefile:
OBJS := soc_1.o
OBJS += soc_2.o
OBJS += b.o

Please note that soc_1.o and soc_2.o are duplicated in the two
Makefiles. We are back to square one, right? Or did you have
something else in mind?

>
>> Also, at least some files will have to be built separately for SPL
>> because they have conditional compilation with CONFIG_PRELOADER kind of
>> flags.
>
> Please let's check where this is needed, and how we can handle this.
> I'd really like to get rid of this symlinking.

One case is start.S. We need a simplified start.S for SPL(no
relocation, no interrupt handling etc).

There are places where CONFIG_PRELOADER is used today. But maybe, these
could be avoided it we try.

best regards,
Aneesh