[U-Boot] [PATCH v2 00/15] Add macros to ease our life with independent CONFIGs between U-Boot and SPL

[Simon Glass]

Hi,

On 1 August 2015 at 07:14, Masahiro Yamada
<yamada.masahiro at 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