[U-Boot] [RFC PATCH 0/17] Version 0 of Kconfig for U-Boot

[Masahiro Yamada]

Hi Simon,



> > For example, we can describe a board header file like this:
> >
> >   #if defined(CONFIG_TPL_BUILD)
> >   # define CONFIG_FOO   100
> >   #elif defined(CONFIG_SPL_BUILD)
> >   # define CONFIG_FOO   50
> >   #else
> >   # define CONFIG_FOO   10
> >   # define CONFIG_BAR
> >   #endif
> 
> I wonder if we should drop this, and require that all have the same
> options? That would involve requiring that board config files are not
> permitted to use #ifdef CONFIG_SPL or #ifdef CONFIG_TPL.
> 
> Does that seem like a bad restriction? The advantage is that we only
> need one defconfig for each board. It seems to me that things are
> going to get really painful if we have three different configs.
> 
> Of course, this doesn't preclude #ifdefs in the Makefiles or actual
> source code, but we already have SPL-specific feature options.
> 
> I'm not 100% clear on the constraints here.

It is true that 3 defconfigs per board are painful,
but those constraints should not be required.
Opposite.

You are suggesting a better idea below.
We should not treat SPL as a special case.

In my opinion, CONFIG_SPL_*  should be discontinued.

For example, we can merge CONFIG_SPL_TEXT_BASE
to CONFIG_SYS_TEXT_BASE.


I mean,

#ifdef CONFIG_SPL_BUILD
#  define CONFIG_SYS_TEXT_BASE    0x00000000
#else
#  define CONFIG_SYS_TEXT_BASE    0x10000000
#endif

rather than
#define CONFIG_SPL_TEXT_BASE    0x00000000
#define CONFIG_SYS_TEXT_BASE    0x10000000


Above will be transformed in Kconfig style.

CONFIG_SYS_TEXT_BASE=0x00000000  (in  foo_spl_defconfig)
CONFIG_SYS_TEXT_BASE=0x10000000  (in  foo_defconfig)


> >  How to change the setting?
> >  --------------------------
> >
> > We can modify configuration as we do in Linux Kernel.
> > Of cource "make config" works in U-Boot too.
> > But I think most of you prefer GUI interface of "make menuconfig".
> > (In Linux Kernel, with thousands of CONFIGs, "make config" is already useless.)
> >
> > The difference from Linux Kernel is that the configuration is done
> > on three levels at most.
> 
> One thought for the future - we should also think about dropping
> spl/tpl as special cases, and just have a general ability to build
> U-Boot multiple times with different options. So we could perhaps have
> 5 different builds with different prefixes (none,spl,tpl,qpl, etc.)

I like your idea very much!!!
I believe this is the right way.

Many makefiles are very dirty because of
ifdef CONFIG_SPL_BUILD ... else ... endif.
We should stop doing like this.

SPL is just one of general images. I absolutely agree.
But I think we need more efforts to go there.

I want Kconfig on the main line soon
(hopefully, in the MW in next month)
and leave your idea to the next stage.

2014.04 : Kconfig along this series
2014.07 : Treat SPL and TPL as generic cases

How about this time line?



> Another little point - I think there is a mkdir missing somwhere:
> 
>  make O=b/snow snow_defconfig
> /bin/sh: line 0: cd: b/snow: No such file or directory
> Makefile:128: *** output directory "b/snow" does not exist.  Stop.
> 
> 
> (previously it would just create the directory with mkdir -p)


Sorry. This feature was lost when switching to Kconfig.
I've posted a patch to re-add it.
Please check this:
http://patchwork.ozlabs.org/patch/332955/



> >  A mountain of work to do in front of us
> >  ---------------------------------------
> >
> > This series is the beginning of our long long journey too.
> > We have thousands of CONFIG macros.
> > Moving them needs much efforts but I believe it is worthwile.
> > But I cannot do that task alone.
> > Hey, board maintainers, I need your help!
> >
> > And, when you add a new CONFIG macro, please create an entry in Kconfig.
> > Please do not add it into a header file any more.
> 
> We should probably have a script in the build system which knows about
> all the existing CONFIG items, and produces an error if it spots a new
> one. That encourage force people to stop adding new CONFIGs.

Possibly can it be included in scripts/checkpatch.pl ? I'm not sure..



> > [1] How board maintainers information should be handled?
> >
> > About half a year ago, commit 27af930e9a merged boards.cfg and MAINTAINERS.
> >
> > Since then, board maintainer information has been described in the
> > rightest field of boards.cfg.
> >
> > But Kconfig uses defconfig files for board configuration.
> > boards.cfg is no longer necessary.
> >
> > Where should board maintainer info be moved to?
> >
> > Revive MAINTAINERS file?
> >
> > Or create a new enrty in Kconfig?
> >
> > I chose the latter in this version.
> >
> > You will find something like this:
> > CONFIG_BOARD_MAINTAINER="Tom Rini <trini at ti.com>"
> > in configs/*_defconfig.
> 
> This seems OK to me, but I wonder if the maintainer is actually not
> really a CONFIG option, but rather a built-in feature of the board,
> something that cannot be changed. That would argue for putting it in
> its own file.
> 
> But this is fine with me.

This item has been discussed in another thread:
http://u-boot.10912.n7.nabble.com/RFC-PATCH-0-17-Version-0-of-Kconfig-for-U-Boot-td176113i20.html#a176247

I think Tom will post a patch to re-add MAINTAINERS file.


> 
> Happy to help, although I'd like to figure out the final for boards
> approach first.

Thanks for offering your help.
Agree, we should figure out our approach first.



> > [3] How ARCH should be given?
> >
> > There is another difference from Linux Kernel.
> >
> > If we cross compile Linux Kernel, we always give ARCH from the command line:
> >
> >   $ make ARCH=arm multi_v7_defconfig
> >   $ make ARCH=arm
> >
> > On the other hand, we set ARCH in the board configuration in U-Boot.
> > I am following the convention in this series.
> > I added architecture choice in Kconfig.
> >
> > But, if we try to be a mirror of Linux Kernel, that's an alternative method.
> >
> > Which do you think is better, ARCH from the command line or selecting it
> > in Kconfig?
> 
> Perhaps it should be a board feature (as I suggest for maintainer
> above) since it can't be changed. Actually it seems pretty weird that
> we have to specify the ARCH since if we get it wrong the board won't
> build.
> 
> But again, since Linux does it this way, I think we can live iwth it.

OK, let's stick to the way in this series.



Best Regards
Masahiro Yamada