[U-Boot] [PATCH v2 00/15] Add macros to ease our life with independent CONFIGs between U-Boot and SPL

[Masahiro Yamada]

2015-08-07 8:08 GMT+09:00 Scott Wood <scottwood at freescale.com>:
> On Mon, 2015-08-03 at 07:59 -0600, Simon Glass wrote:
>> Hi,
>>
>> On 1 August 2015 at 07:14, Masahiro Yamada
>> <yamada.masahiro at socionext.com> wrote:
>> >
>> > I hope this series will make our life easier.
>>
>> I agree. This seems like a clever solution to the problem.
>>
>> As you probably saw on the other thread, Scott Wood suggested that
>> separate configs for U-Boot proper and SPL are better. There are
>> definitely arguments either way.
>>
>> I feel that joining them up has a few advantages:
>> - Single configuration step (no multiple 'make menuconfig' steps)
>
> How often do people use menuconfig versus a board's defconfig?  Even when
> they do, do they need to modify the SPL's config or just the main U-Boot?

It often happened when I changed SoC-specific features.


>> - Supports the common case where there is no need for a separate SPL option
>
> With separate configs there would not be separate options.  With a unified
> config there are separate SPL options, even if it doesn't require a separate
> makefile line.
>
>> - Single configuration file to maintain / patch
>
> For defconfigs it was already merged.

Yes, with mysterious "+S:" prefixes.
Internally, it was divided into separate defconfigs by a shell script
before going into Kconfig.



>> - Avoids needing to create options that depend on SPL, or !SPL and
>> thus exist in SPL but not in U-Boot proper (I find this confusing)
>
> Instead you have special SPL symbols that exist but don't mean anything in U-
> Boot proper...


True, but on the contrary, CONFIG options without CONFIG_SPL_ is meaningful
for SPL.

For example,

common/spl/spl_nand.c is only linked into SPL,
but it references CONFIG_SYS_TEXT_BASE.


SPL needs CONFIG_SPL_TEXT_BASE to link itself,
and also wants to know CONFIG_SYS_TEXT_BASE
for loading the U-boot proper image.


The single .config is sometimes helpful for inter-action between U-boot proper
and SPL.



>> The $(SPL) syntax may be a little clumsy but it is pretty clear what
>> is going on. Also if we come up with something else in the future it
>> should be fairly easy to revisit the sits and change them.
>>
>> I believe the common case is that most board options are the same for
>> SPL and U-Boot proper.
>
> Most SPLs have a command shell and all the associated bells and whistles
> selected, plus a full set of drivers?


Simon did not go as far as saying that.

The command shell should be available on U-Boot proper, I think.

But, yeah, Freescale finally enabled the command shell on SPL.


commit ed39218238cf8ca312b0a14a83848af055394c68
(common: spl: Add interactive DDR debugger support for SPL image)



>>  By my count we have about 40
>> CONFIG_SPL_..._SUPPORT optoins at present.
>
> Those were added before we had split configs.  With split configs they could
> go away.
>
>>  Compared to the thousands
>> of options int the source this is fairly small. So we should optimise
>> for the common case.
>
> 40 versus zero?  What special thing would need to be done to the "thousands
> of options" with split configs?
>
> How is TPL supposed to be handled?  Are the various SPL options that are set
> one way #ifdef CONFIG_TPL_BUILD and differently if not doomed to stay in the
> board config file and never get kconfigized?


At some point, the order of SPL and TPL should be swapped.

TPL (Tiny Program Loader)  ->  SPL  ->  U-Boot

Then, TPL will become an ad-hoc loader, disabling most of CONFIGs.
Implementation is Do-It-Yourself things under you board directory or somewhere.




-- 
Best Regards
Masahiro Yamada