[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Scott Wood <scottwood@freescale.com>]

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