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

[Scott Wood <scottwood@freescale.com>]

On 09/20/2011 04:30 PM, Marek Vasut wrote:
> On Tuesday, September 20, 2011 11:23:01 PM Scott Wood wrote:
>> On 09/20/2011 04:16 PM, Marek Vasut wrote:
>>> On Tuesday, September 20, 2011 09:12:08 PM Scott Wood wrote:
>>>> On 09/19/2011 05:31 PM, Marek Vasut wrote:
>>>>> 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.
>>>
>>> That kind of granularity is there already too -- though on driver level.
>>> But so far it seem sufficient.
>>
>> What's wrong with using that model for arch code as well?
>>
>> Note that "so far" most of the existing SPL targets have not been
>> converted to the new spl/.
> 
> Right, so when you hit the problem, you fix it. No need to overengineer it right 
> away.

It seems you hit the problem already, and you're trying to add an ad hoc
workaround rather than apply the same concept to arch code that is to be
used with drivers.

Wanting to staying consistent and simple is not overengineering.

>> It's not about rarity (which is often misjudged, BTW).  It's about
>> whether the model for selecting code for the SPL is additive or
>> subtractive, and whether we have a consistent mechanism or ad hockery
>> from the start.
>>
>> In nand_spl/ it was fully additive.  I'd like to keep it that way.
> 
> I see your point and I disagree. I'd use the majority vote here -- most of the 
> boards need it and rare ones don't -- so why put additional burden on majority 
> in favor of minority ?

Is it really such a burden to put something like

#define CONFIG_SPL_ARCH_CPU

in your board config header?  If you end up with several things that 95%
of targets are including, factor them out into a common header, like
include/config_cmd_default.h.  Or have a single define that selects a
set of defaults.  Or integrate kconfig. :-)

I don't want to get into a situation where someone has to dig around to
find out which bits of code are included by default, and what the
special magic is to turn them off.

-Scott