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

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

[Charles Manning]

Hi All

My understanding of the way SPL is intended to be configured is:

(a) You have one config file for both SPL and u-boot.
(b) SPL features are selected via SPL-specific options.

I have a need to build SPL with MMC/FAT support, but I don't want
u-boot to have MMC/FAT support.

I do however see that quite a few SPL feature selections don't use SPL
config definitions though which would seem to violate (b) above.

eg.drivers/mmc/Makefile contains
COBJS-$(CONFIG_GENERIC_MMC) += mmc.o

It seems to me there are three ways to address this:

A) Change all those Makefiles to something like:

ifdef CONFIG_SPL_BUILD
COBJS-$(CONFIG_SPL_MMC_SUPPORT) += mmc.o
else
COBJS-$(CONFIG_GENERIC_MMC) += mmc.o
endif


B) Modifying the config file with something like

#ifdef CONFIG_SPL_BUILD
#define CONFIG_GENERIC_MMC
...
#endif

C) Separate config files. One for SPL and the other for u-boot.

Which is the best way to do this?

Thanks

Charles

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

[Tom Rini]

On Thu, May 17, 2012 at 12:13:20PM +1200, Charles Manning wrote:
> Hi All
> 
> My understanding of the way SPL is intended to be configured is:
> 
> (a) You have one config file for both SPL and u-boot.

Yes.

> (b) SPL features are selected via SPL-specific options.

For some parts, yes.  Note that SPL does use
-ffunction-sections/-fdata-sections/--gc-sections.

> I have a need to build SPL with MMC/FAT support, but I don't want
> u-boot to have MMC/FAT support.

This is a new challenge, yes.

> I do however see that quite a few SPL feature selections don't use SPL
> config definitions though which would seem to violate (b) above.
> 
> eg.drivers/mmc/Makefile contains
> COBJS-$(CONFIG_GENERIC_MMC) += mmc.o
> 
> It seems to me there are three ways to address this:
> 
> A) Change all those Makefiles to something like:
> 
> ifdef CONFIG_SPL_BUILD
> COBJS-$(CONFIG_SPL_MMC_SUPPORT) += mmc.o
> else
> COBJS-$(CONFIG_GENERIC_MMC) += mmc.o
> endif
> 
> 
> B) Modifying the config file with something like
> 
> #ifdef CONFIG_SPL_BUILD
> #define CONFIG_GENERIC_MMC
> ...
> #endif
> 
> C) Separate config files. One for SPL and the other for u-boot.
> 
> Which is the best way to do this?

I think (B) is the method to go with.  We already do this with certain
things like CONFIG_SKIP_LOW_LEVEL_INIT.

-- 
Tom

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

[Scott Wood]

On 05/17/2012 01:48 PM, Tom Rini wrote:
> On Thu, May 17, 2012 at 12:13:20PM +1200, Charles Manning wrote:
>> Hi All
>>
>> My understanding of the way SPL is intended to be configured is:
>>
>> (a) You have one config file for both SPL and u-boot.
> 
> Yes.
> 
>> (b) SPL features are selected via SPL-specific options.
> 
> For some parts, yes.  Note that SPL does use
> -ffunction-sections/-fdata-sections/--gc-sections.
> 
>> I have a need to build SPL with MMC/FAT support, but I don't want
>> u-boot to have MMC/FAT support.
> 
> This is a new challenge, yes.
> 
>> I do however see that quite a few SPL feature selections don't use SPL
>> config definitions though which would seem to violate (b) above.
>>
>> eg.drivers/mmc/Makefile contains
>> COBJS-$(CONFIG_GENERIC_MMC) += mmc.o
>>
>> It seems to me there are three ways to address this:
>>
>> A) Change all those Makefiles to something like:
>>
>> ifdef CONFIG_SPL_BUILD
>> COBJS-$(CONFIG_SPL_MMC_SUPPORT) += mmc.o
>> else
>> COBJS-$(CONFIG_GENERIC_MMC) += mmc.o
>> endif
>>
>>
>> B) Modifying the config file with something like
>>
>> #ifdef CONFIG_SPL_BUILD
>> #define CONFIG_GENERIC_MMC
>> ...
>> #endif
>>
>> C) Separate config files. One for SPL and the other for u-boot.
>>
>> Which is the best way to do this?
> 
> I think (B) is the method to go with.  We already do this with certain
> things like CONFIG_SKIP_LOW_LEVEL_INIT.

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.

-Scott

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

[Tom Rini]

On 05/17/2012 01:22 PM, Scott Wood wrote:
> On 05/17/2012 01:48 PM, Tom Rini wrote:
>> On Thu, May 17, 2012 at 12:13:20PM +1200, Charles Manning wrote:
>>> Hi All
>>>
>>> My understanding of the way SPL is intended to be configured is:
>>>
>>> (a) You have one config file for both SPL and u-boot.
>>
>> Yes.
>>
>>> (b) SPL features are selected via SPL-specific options.
>>
>> For some parts, yes.  Note that SPL does use
>> -ffunction-sections/-fdata-sections/--gc-sections.
>>
>>> I have a need to build SPL with MMC/FAT support, but I don't want
>>> u-boot to have MMC/FAT support.
>>
>> This is a new challenge, yes.
>>
>>> I do however see that quite a few SPL feature selections don't use SPL
>>> config definitions though which would seem to violate (b) above.
>>>
>>> eg.drivers/mmc/Makefile contains
>>> COBJS-$(CONFIG_GENERIC_MMC) += mmc.o
>>>
>>> It seems to me there are three ways to address this:
>>>
>>> A) Change all those Makefiles to something like:
>>>
>>> ifdef CONFIG_SPL_BUILD
>>> COBJS-$(CONFIG_SPL_MMC_SUPPORT) += mmc.o
>>> else
>>> COBJS-$(CONFIG_GENERIC_MMC) += mmc.o
>>> endif
>>>
>>>
>>> B) Modifying the config file with something like
>>>
>>> #ifdef CONFIG_SPL_BUILD
>>> #define CONFIG_GENERIC_MMC
>>> ...
>>> #endif
>>>
>>> C) Separate config files. One for SPL and the other for u-boot.
>>>
>>> Which is the best way to do this?
>>
>> I think (B) is the method to go with.  We already do this with certain
>> things like CONFIG_SKIP_LOW_LEVEL_INIT.
>
> 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?  I really think it's a good thing that one build target 
gets one a bootable system now.  If we need to rework things further, 
lets figure that out but I think it's a good thing that 'make 
omap3_beagle' spits out both parts.

-- 
Tom

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

[Scott Wood]

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".

-Scott

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

[Charles Manning]

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.

-- CHarles

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

[Tom Rini]

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
>