
Hi,
On 1 August 2015 at 07:14, Masahiro Yamada yamada.masahiro@socionext.com wrote:
Refer to Simon's question, too: http://lists.denx.de/pipermail/u-boot/2015-July/219598.html
Since U-boot introduced SPL (not since Kconfig), enabling features for U-boot and SPL independently is always a PITA.
- decide if each feature should be supported for SPL or not
- Add CONFIG_SPL_FRED_SUPPORT into Makefile.spl
- Add #undef include/config_uncmd_spl.h to disable features we do not want to support on SPL
- Add "ifdef CONFIG_SPL_BUILD ... endif" here and there to adjust things
- Add "#ifdef CONFIG_SPL_BUILD ... #endif" here and there to fix things up
Things are getting more and more crappy.
When U-boot switched to Kconfig, first I introduced separate .config (.config, spl/.config, tpl/.config) to clean up them. But it turned out to be a pain.
So, I believe the current single .config is much better. But I also admit we need something systematic to subdue our PITA.
One possibility is to support "spl-y" in makefiles. (This idea is cribbed from barebox.)
obj-$(CONFIG_FOO) += foo.o spl-$(CONFIG_SPL_FOO) += foo.o
is cleaner than
ifdef CONFIG_SPL_BUILD obj-$(CONFIG_SPL_FOO) += foo.o else obj-$(CONFIG_FOO) += foo.o endif
It is a nice improvement in makefile side. But we still need to do something with C files.
Another option is something like CONFIG_FOO=yyn (yes for U-boot, yes for SPL, no for TPL)
To achieve this, I think a big operation is needed in Kconfig core. I cannot do that. (Of course, Patches are welcome if someone else can do that.)
So, I was thinking of something different.
My idea was inspired by IS_ENABLED() macro in include/linux/kconfig.h.
Linux defines different macros for built-in and module, and it is possible to write #if IS_ENABLED(CONFIG_FOO) ... #endif
instead of
#if defined(CONFIG_FOO) || defined(CONFIG_FOO_MODULE) ... #endif
So, I'd like to propose new macros to write code like
#if CONFIG_IS_ENABLED(FOO) ... #endif
instead of
#if (!defined(CONFIG_SPL_BUILD) && defined(CONFIG_FOO)) || \ (defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_FOO)) ... #endif
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) - Supports the common case where there is no need for a separate SPL option - Single configuration file to maintain / patch - 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)
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. By my count we have about 40 CONFIG_SPL_..._SUPPORT optoins at present. Compared to the thousands of options int the source this is fairly small. So we should optimise for the common case.
There are definitely trade-offs and I'm sure people will continue to think about it.
But most important I think this solves the problem on the thread Masahiro references.
Regards, Simon