Hi Masahiro,
On 17 March 2014 01:52, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Several weeks have passed since Kbuild series was merged to the code base at 2014.01-rc1.
I think now is a good time to start to discuss the next stage. Yes, our promised land, Kconfig.
Great! I have a few general comments below and have not reviewed the code on this version.
Besides Linux Kernel, Kconfig is being used in some projects, for example, BusyBox, Buildroot.
But, our situation is a little more complicated. We need to generate 3 images at most: main image, SPL and TPL. And each of them can have a different set of CONFIGs.
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.
All defined macros prefixed with CONFIG_ are extracted into
- include/autoconf.mk (for main U-Boot)
- include/spl-autoconf.mk (for SPL)
- include/tpl-autoconf.mk (for TPL)
for the use in makefiles.
In order to keep this scheme in Kconfig, I had to modify some files. But I tried to minimize the modification.
How does Kconfig in U-Boot work?
For boards without SPL support, it works like Linux Kernel. That is, a list of CONFIGs is saved into ".config" file. When we run "make", if necessary, "make silentoldconfig" is automatically invoked, which creates/updates include/config/auto.conf and include/generated/autoconf.h.
For boards supporting SPL, a list of CONFIG macros defined for SPL_BUILD is saved into "spl/.config". include/config/auto.conf and include/generated/autoconf.h are generated under spl/ directory.
CONFIG macros for TPL are also handled in the same way.
To sum up,
[1] Main U-boot - .config (saved CONFIG list) - include/config/auto.conf (for use in makefiles) - include/generated/autoconf.h (for use in C sources) - include/config/* (for if_changed_dep)
[2] SPL - spl/.config (saved CONFIG list) - spl/include/config/auto.conf (for use in makefiles) - spl/include/generated/autoconf.h (for use in C sources) - spl/include/config/* (for if_changed_dep)
[3] TPL - tpl/.config (saved CONFIG list) - tpl/include/config/auto.conf (for use in makefiles) - tpl/include/generated/autoconf.h (for use in C sources) - tpl/include/config/* (for if_changed_dep)
How to configure and build?
Prior to this series, we did board configuration like this:
$ make vexpress_aemv8a_config Configuring for vexpress_aemv8a - Board: vexpress_aemv8a, Options: ARM64
Going forward, we should configure like this:
$ make vexpress_aemv8a_defconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf # # configuration written to .config #
Please note we should use suffix "_defconfig" instead of "_config".
And then build the same as before.
$ make CROSS_COMPILE=<your_gcc_prefix>
Or you can configure and build in one time:
$ make CROSS_COMPILE=<your_gcc_prefix> vexpress_aemv8a_defconfig all
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.)
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)
Just try
$ make menuconfig
A menu with a blue background will be displayed for the configuration of the main U-boot image.
Please descend into "General setup" and notice SPL/TPL build setting.
[*] Build SPL image [ ] Build TPL image () Cross-compiler tool prefix
After going around the menu, choose <Exit>. Your configuration will be saved into ".config".
If you have enabled "Build SPL image", the second menu will come up. This is for the SPL configuration. Please note the background color is black for identifiability. SPL configuration will be written into "spl/.config".
If you have checked "Build TPL image" also, the third menu will be shown. This is for the configuration of TPL image, although there are only a few boards supporting TPL.
While I agree this will get us going, and I suppose this approach in the interim, I wonder if we can simply it so there is one defconfig per board.
Coexistence of Kconfig and board header
For a long time, we have used C header files to define the set of CONFIGs. They are placed under include/configs/ directory.
It would take really long term (one year? two year? I don't know) to move existing CONFIG macros to Kconfig.
So, two different infractructure must coexist in the interim.
The conventional include/autoconf.mk, include/spl-autoconf.mk, include/tpl-autoconf.mk are merged into include/config/auto.conf, spl/include/config/auto.conf, tpl/include/config/auto.conf, respectively.
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.
Build Test
I built all boards excepts some already broken ones. I also checked MD5SUM of output binaries for all of them.
I believe this series should not break any boards. But if you notice something got broken, please let me know.
Besides, I confirmed out-of-tree build, parallel build (-j make option) work correctly.
How to apply this series
This series use the following as a prerequisite.
[1] sparc: consolidate CONFIG_{LEON, LEON2, LEON3} http://patchwork.ozlabs.org/patch/330103/
Please apply it first.
Or you can try my local branch: git clone git://github.com/masahir0y/u-boot-kbuild.git cd u-boot-kbuild.git git checkout kconfig_v0
Known Problems and Open Discussion
This is RFC version. Your comments are welcome. Let's discuss!
[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@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.
I think MAINTAINERS file is another way good enough.
Your comments are welcome.
[2] MAKEALL and buildman have not been not adjusted yet
As I mentioned above, boards.cfg is not necessary for Kconfig. I want to delete it.
But before that, we must rework MAKEALL and buildman to search defconfig files instead of boards.cfg.
I think maybe I can do that, but if Simon could give me a hand, it would be highly appreciated.
Happy to help, although I'd like to figure out the final for boards 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.
If requested, I think I can send both implementation for comparison.
[4] Should we keep different configurations for the same board?
If you see boards.cfg, some boards have multiple configurations with the difference only in options in the 8th field.
"m54455evb" has many configurations: M54455EVB, M54455EVB_a66, M54455EVB_i66, M54455EVB_intel, ...
This series is keeping all of them. But I am not sure if it is right to duplicate the almost same defconfig files for one board.
It seems OK to me.
Regard, Simon