[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library
Scott Wood
scottwood at freescale.com
Tue Sep 20 21:12:08 CEST 2011
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
More information about the U-Boot
mailing list