On 09/19/2011 05:31 PM, Marek Vasut wrote:
On Monday, September 19, 2011 08:13:45 PM Scott Wood wrote:
On 09/16/2011 05:48 PM, Marek Vasut wrote:
The stuff in arch/arm/cpu should be exactly what you need, nothing more !
This is "spl/", not "arch/arm/spl/", so let's not reason from one architecture, much less the subset of that architecture that has already been made to work with spl/ -- there are 14 different instances of arch/arm/cpu/$(CPU).
I don't think I follow you on this one really -- are we still discussing the inclusion/non-inclusion of the cpu-specific library in the SPL, right ?
We're discussing CONFIG_SPL_NO_CPU_SUPPORT_CODE and its use in spl/Makefile.
We will not want everything we normally pull from arch/powerpc/cpu/mpc85xx to go into an 85xx NAND SPL, for example. But we will want some small portion of it.
Then you adjust the makefile there by ifdef CONFIG_SPL_BUILD
It's not quite that simple, since different SPLs will have different requirements. Board config headers will need to define symbols like CONFIG_SPL_FEATURE and the makefiles will use both CONFIG_SPL_BUILD and CONFIG_SPL_FEATURE to determine which object files to include.
Board config headers should set appropriate symbols indicating what parts of arch/$(ARCH)/cpu/$(CPU) they want during an SPL build (at whatever granularity is appropriate). If that's an empty set, then so be it, no need to avoid the directory altogether.
Whether it's file or directory based, everything should be off by default. Boards should ask for what they want, not what they want to exclude.
Actually, this being a rare case where you want it excluded, it's better the way it is.
I disagree, especially in the early stages where we're setting an example for how other components will be handled.
-Scott