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

[Tom Rini]

On Wed, Aug 24, 2016 at 12:16:23PM -0600, Stephen Warren 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.
> 
> 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.

It's a bit of a mess, yes.  And it doesn't help matters that there's now
a growing number of boards that would like to / could go in the
direction of dropping SPL as they have sufficient initial memory to have
real U-Boot there to start with.  But I think the additional tooling
required to make the end user experience be at least as good as it is
now means we need to revisit this topic once things are largely in
Kconfig. I think the binary manager Simon showed a while ago will be
part this too, so that we can continue to have a functional output at
the end.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160824/cf74017a/attachment.sig>