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

[Masahiro Yamada]

Hi Simon,

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

I agree.
But I think, in some cases,  it makes sense to build SPL only.
I want to drop Falcon boot as a special case.

In my rough view:
 -  <board>_defconfig    :  Normal boot sequence
 -  <board>_defconfig + <board>_spl_defconfig  :   SPL boot sequence
 -  <board>_spl_defconfig : Falcon boot


> 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

I have posted v3.

It is possible in v3.

make menuconfig         -->  edit  .config
make spl:menuconfig    -->  edit  spl/.config
make tpl:menuconfig    -->  edit  tpl/.config
make qpl:menuconfig   -->   edit  qpl/.config
etc.

Syntax is 
make  <output_dir>:<config_command>




Best Regards
Masahiro Yamada