Dear Wolfgang,
This is in continuation of our discussion in the following threads:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/99795 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/99785
I think this discussion now needs a dedicated thread.
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.
Current Design: * Currently a single board level Makefile determines what gets built into SPL. * 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>/
New Design Proposed by Wolfgang: * Have a top-level Makefile in the SPL root-directory - for instance 'nand_spl/Makefile' * nand_spl/Makefile builds a generic library with the generic source files at this level. * It then descends into sub-directories(SoC, board etc) to make the respective libraries at those levels. * These libraries are finally linked together by nand_spl/Makefile to build the SPL image.
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.
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 available in media specific directories such as nand_spl/ and mmc_spl/. Symbolic links?
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?
4. How do we handle the case where a given SoC doesn't need any board level code for the SPL(This is the case with OMAP4). Is this handled by just not have any <board> directories?
5. If so, how does the top-level SPL Makefile handle this? By checking for the existence of <board> directory before descending into it? How does it handle the link step where the board level library is not available?
best regards, Aneesh