From mboxrd@z Thu Jan  1 00:00:00 1970
From: Wolfgang Denk <wd@denx.de>
Date: Thu, 16 Jun 2011 14:15:40 +0200
Subject: [U-Boot] SPL framework re-design
In-Reply-To: <4DF9EE03.8010105@ti.com>
References: <4DF9B9E0.8020206@ti.com>
	<20110616104716.762DD19E5AC3@gemini.denx.de>
	<4DF9EE03.8010105@ti.com>
Message-ID: <20110616121540.196C519E5AC4@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 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
	...

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

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

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

Right.

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

We should use the same logic as in config.mk, i. e.
CONFIG_SYS_LDSCRIPT has hioghest priority, then search in the standard
locations.

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

This is my understanding, too.

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
2000 pounds of chinese soup                               = 1 Won Ton