[U-Boot] SPL framework re-design

[Wolfgang Denk]

Dear Aneesh V,

In message <4DF9EE03.8010105 at 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