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