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

[Tom Rini]

On Thu, Sep 22, 2011 at 1:52 AM, Marek Vasut <marek.vasut at gmail.com> wrote:
> On Wednesday, September 21, 2011 01:31:28 AM Scott Wood wrote:
>> 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?
>
> Yes it's a burden. It's a burden to add this to all boards but one. It makes no
> sense.

Looking at a pile of partially ported TI boards, I wonder if we don't need a few
common SPL include files, setting this-and-that and then letting boards opt-out
of these defaults (or just going it alone?) as needed.

-- 
Tom