[U-Boot] [PATCH 06/42] Use separate options for TPL support

[Stephen Warren]

On 08/24/2016 10:51 AM, Simon Glass wrote:
> At present TPL uses the same options as SPL support. In a few cases the board
> config enables or disables the SPL options depending on whether
> CONFIG_TPL_BUILD is defined.
>
> With the move to Kconfig, options are determined for the whole build and
> (without a hack like an #undef in a header file) cannot be controlled in this
> way.
>
> Create new TPL options for these and update users. This will allow Kconfig
> conversion to proceed for these boards.

> diff --git a/common/Makefile b/common/Makefile

>  # environment
> -ifdef CONFIG_SPL_ENV_SUPPORT
> +ifdef CONFIG_TPL_BUILD
> +obj-$(CONFIG_TPL_ENV_SUPPORT) += env_attr.o
> +obj-$(CONFIG_TPL_ENV_SUPPORT) += env_flags.o
> +obj-$(CONFIG_TPL_ENV_SUPPORT) += env_callback.o
> +else
>  obj-$(CONFIG_SPL_ENV_SUPPORT) += env_attr.o
>  obj-$(CONFIG_SPL_ENV_SUPPORT) += env_flags.o
>  obj-$(CONFIG_SPL_ENV_SUPPORT) += env_callback.o
> +endif

This feels like it will become an unbounded mess as the set of Kconfig 
options for SPL and TPL grow.

Rather, I think we should have a separate U-Boot build/binary, separate 
defconfig, etc. for main U-Boot, SPL (if a board uses it), TPL (if a 
board uses it), etc., plug perhaps some top-level definition to bind 
them all back together.

That way, we'll just have CONFIG_ENV_SUPPPORT, and never have any 
CONFIG_$(xxx)_ENV_SUPPORT. We completely avoid the proliferation of 
duplicated Kconfig symbols.

I vaguely recall mention of SPL choosing the DT for the main U-Boot. 
What if SPL needs different DTs? We'd need to use TPL to choose the DT. 
What if TPL needs different DT to? We'd need to introduce a new binary 
(QPL?) to do the selection. That might then need CONFIG_QPL_*. If we 
just use the same Kconfig symbols everywhere, and just configure which 
options are enabled via a separate defconfig for main, SPL, TPL, QPL, 
we'll have a much more manageable system.

Of course, that would probably require some Kconfig work to allow the 
defconfigs for ${board}_spl_defconfig, ${board}_tpl_defconfig, 
${board}_qpl_defconfig, and ${board}_defconfig to all include 
${board}_common_defconfig (or whatever set common files are appropriate) 
to avoid duplication. ChromeOS already solved that for the kernel IIRC. 
Also, we'd likely need some kind of top-level ${board}_xxx file to 
indicate that plain "make" should separately build spl, tpl, main for 
the boad, and how to munge them together.