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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot