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

[Scott Wood <scottwood@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@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?

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

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

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

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

-Scott