[U-Boot] What is the correct way to configure SPL options?

[Tom Rini <trini@ti.com>]

On 05/17/2012 02:23 PM, Charles Manning wrote:
> On Friday 18 May 2012 08:58:06 Scott Wood wrote:
>> On 05/17/2012 03:47 PM, Tom Rini wrote:
>>> On 05/17/2012 01:22 PM, Scott Wood wrote:
>>>> We had problems with (B) regarding TEXT_BASE -- the makefile versions of
>>>> the config symbols will only be generated once.
>>>> CONFIG_SKIP_LOW_LEVEL_INIT doesn't seem to be used from makefiles.
>>>>
>>>> I still think (C) is the way to go.
>>>
>>> But since we have CONFIG_SYS_SPL_TEXT_BASE now, (B) is how we do it
>>> normally, yes?
>>
>> That was more of an instance of "OK, I give in, we'll do it the simple
>> but ugly way if it's just this one thing" than "the normal way".
>>
>
> To me it looks like the ugliness comes from an unclear policy resulting in SPL
> configs being handled in two different ways.
>
> IMHO, the policy can be simplified and rationalised in two ways:
>
>
> A) Recognise name each config option that might vary with an SPL and regular
> variant. That will just lead to hell in the Makefiles.
> - non inclusive or-
> C) Each binary has a different config and is built separately. Then there is
> no need for multiple CONFIGs for the same feature.
>
> I have found (C) to work fine for building multiple variants (using a much
> older version of u-boot). For example, I build two stripped u-boots to run a
> manufacturing loader process. I thus build at least 3 different u-boots for
> the same board. Each has a different config and is built separately.
>
> I guess common stuff can be rationalised:
> foo-common.h
> ....
>
> foo-uboot.h
> #include "foo-common.h"
> ...
>
> foo-spl.h
> #include "foo-common.h"
> ...
>
> But that really makes for config file proliferation. Still, that would seem
> more manageable.

My suggestion would be to walk a few boards to that conversion. 
foo-common.h will be 97% of what foo.h is.  A single file and making use 
of boards.cfg to set flags when we really need different builds and 
behaviors should do it.  Of course with the Kconfig wishlist item maybe 
we could revisit this problem :)

-- 
Tom

>
> -- CHarles
>