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@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-...
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