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

[Simon Glass]

Hi Stephen,

On 24 August 2016 at 12:16, Stephen Warren <swarren at wwwdotorg.org> wrote:
> 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.

It is possible to refactor this a bit to avoid the duplication by
defining a variable which is TPL or SPL. I didn't think it worth it
for 3 lines.

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

We has it that way originally and changed to separate options a few
releases later. While I understand that this can look bad in
Makefiles, it isn't that bad. It is *much* easier for a user to deal
with a single config that has a few extra CONFIG options, than 3
configs.

While we have about 8000 CONFIG options, we have <150 for SPL and with
this series 10 for TPL. It just doesn't make sense to treat everything
the same.

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

Never say never, but I can't imagine why we would introduce a new boot
element just to choose the device tree. SPL can easily do this itself
if needed - we would just need to support attaching multiple DTs to
SPL, which is easy enough.

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

Yes it would be nice to split out the build a little better.

Chrome OS is trying to solve the problem that boards that use the same
arch tend  to share options. We already handle that with Kconfig and
it seems easier to add 'default y' for an option under in the arch's
Kconfig definition than have multiple levels of defconfig files that
we join together. Although it does have drawbacks, such as that people
might unset a required option and break the board. We can use 'select'
it is really cannot be unset, but then someone comes along with a
special-case board..

In terms of munging binaries together to make an image, see my recent
binman series for some ideas as Tom says.

Regards,
Simon