[U-Boot] [RFC] Two sets of experimental Kconfig patches

[Simon Glass]

Hi Masahiro,

On 27 May 2014 01:32, Masahiro Yamada <yamada.m at jp.panasonic.com> wrote:
> Hi.
>
> I've posted two sets of Kconfig RFC patches: "RFCv2a" and "RFCv2b"
>
> The difference from v1  is that
> Full U-boot image, SPL and TPL share a single defconfig
> and "make config" is done in one-shot.
>
> This approach dates back to Simon's following comments:
>
> On Thu, 20 Mar 2014 19:15:30 -0700
> Simon Glass <sjg at chromium.org> wrote:
>
>> > But, our situation is a little more complicated.
>> > We need to generate 3 images at most: main image, SPL and TPL.
>> > And each of them can have a different set of CONFIGs.
>> >
>> > For example, we can describe a board header file like this:
>> >
>> >   #if defined(CONFIG_TPL_BUILD)
>> >   # define CONFIG_FOO   100
>> >   #elif defined(CONFIG_SPL_BUILD)
>> >   # define CONFIG_FOO   50
>> >   #else
>> >   # define CONFIG_FOO   10
>> >   # define CONFIG_BAR
>> >   #endif
>>
>> I wonder if we should drop this, and require that all have the same
>> options? That would involve requiring that board config files are not
>> permitted to use #ifdef CONFIG_SPL or #ifdef CONFIG_TPL.
>>
>> Does that seem like a bad restriction? The advantage is that we only
>> need one defconfig for each board. It seems to me that things are
>> going to get really painful if we have three different configs.
>>
>> Of course, this doesn't preclude #ifdefs in the Makefiles or actual
>> source code, but we already have SPL-specific feature options.
>>
>> I'm not 100% clear on the constraints here.
>
>
> In my opition, this approach might work, but will be painful.
>
> Anyway I just wanted to see what would happen
> if multiple binary images had a single defconfig in common.
>
> We will have to duplicate many configs with CONFIG_SPL_
> and CONFIG_TPL_ prefixes.
>
> For example,
>  - CONFIG_SYS_TEXT_BASE  (text base for the full image)
>  - CONFIG_SPL_TEXT_BASE  (text base for SPL)
>  - CONFIG_TPL_TEXT_BASE  (text base for TPL)
>
>  - CONFIG_OF_CONTROL         (enables OF control for the full image)
>  - CONFIG_SPL_OF_CONTROL  (enables OF control for SPL)
>  - CONFIG_TPL_OF_CONTROL  (enables OF control for TPL)
>
> Probably I will not adopt this approach, but your comments
> are welcome.
>
>

I have been thinking about this a lot, but it isn't 100% clear to me.

While I agree that duplicating the CONFIGs is bad, in fact the
opposite of what I was getting at, I do feel that things like
CONFIG_TEGRA20 need to be set in one place. We don't want the SPL/TPL
config to be changing things that make no sense given the board that
is selected. It doesn't make sense to have an SPL for Tegra and a TPL
for MX6.

Similar to what Tom was saying I feel that there will come a time when
the difference between U-Boot and SPL is just the options that are
enabled - the code paths will be the same. For example, I did a
CONFIG_CMD series which removed all commands from U-Boot and cut the
size to <50KB. OK that is not SPL size, but I can see a point where
they will merge. In that case we certainly don't want the option that
you list above - instead we want CONFIG_OF_CONTROL to mean the same
thing for U-Boot and SPL.

Perhaps it will help if we can have options like:

make menuconfig_main
make menuconfig_spl
make menuconfig_tpl

to avoid chaining between configs? That was my main concern with series 1.

[snip]

It would be great if we could make a decision on this and merge it
soon. To me the ARCH issue is minor but FWIW I think we should try to
avoid needing ARCH= on the command line.

So long as we get the general direction right we can make changes
later. To me the general direction is towards getting rid of the
special-case SPL code and SPL options.

Anyone else have comments?

Regards,
Simon