Hi,
On 24 February 2015 at 23:14, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Hi Scott,
On Tue, 24 Feb 2015 18:17:59 -0600 Scott Wood scottwood@freescale.com wrote:
On Tue, 2015-02-24 at 16:20 +0900, Masahiro Yamada wrote:
Hi Scott,
On Mon, 23 Feb 2015 19:22:51 -0600 Scott Wood scottwood@freescale.com wrote:
On Fri, 2015-02-20 at 14:24 +0900, Masahiro Yamada wrote:
When Kconfig for U-boot was examined, one of the biggest issues was how to support multiple images (Normal, SPL, TPL). There were actually two options, "single .config" and "multiple .config". After some discussions and thought experiments, I chose the latter, i.e. to create ".config", "spl/.config", "tpl/.config" for Normal, SPL, TPL, respectively.
It is true that the "multiple .config" strategy provided us the maximum flexibility and helped to avoid duplicating CONFIGs among Normal, SPL, TPL, but I have noticed some fatal problems:
[1] It is impossible to share CONFIG options across the images. If you change the configuration of Main image, you often have to adjust some SPL configurations correspondingly. Currently, we cannot handle the dependencies between them. It means one of the biggest advantages of Kconfig is lost.
Sharing can happen in the defconfig with "+S:"...
Yes, it can as for "make *_defconfig".
If we modify some options in .config for example by "make menuconfig", we also modify some in spl/.config correspondingly.
Users are responsible for configure .config and spl/.config in sync in the sane combination.
What sort of dependencies are people wanting? Would it be possible to modify kconfig to import SPL .config into the main config (or vice versa?) with a name prefix so that dependencies could happen, without sacrificing the ability to set symbols independently?
To have independent symboles coexist in a single .config, I can only suggest to duplicate options like CONFIG_FOO=0x100 CONFIG_SPL_FOO=0x200 CONFIG_TPL_FOO=0x300
What I meant was a way to keep the configs separate, but automatically import the CONFIG_FOO from the SPL .config as CONFIG_SPL_FOO (or some other prefix that doesn't conflict with SPL-specific options).
What is the benefit of doing this?
Or as Ian suggested, have only the main config be user-editable, but still let select/depends turn certain things on/off for the auto-generated SPL config.
I guess it is possible for boolean options, but impossible to set hex/int options independently.
How many hex/int options are there, that need to be different in SPL versus the main U-Boot? Having a few CONFIG_SPL_xxx for those is better than having a bunch.
OK. But, I do not think we need to tweak the Kconfig just for saving boolean options.
BTW, Ian's idea had been already achieved by include/config_uncmd_spl.h
So, the answer is to avoid kconfig and go back to using the preprocessor for configuration? :-(
I am not saying I prefer the preprocessor.
Indeed, include/config_uncmd_spl.h is ugly, so I'd like to propose a better solution.
If we introduce CONFIG_SPL_DM, for example, the ifdef conditional in source files will be like this:
#if (!defined(CONFIG_SPL_BUILD) && defined(CONFIG_DM)) || \ (defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_DM))
[Driver Model Code]#else [Non Driver Model Code] #endif
This is too ugly to be written in each conditional.
So, I want to describe like this:
#if IS_ENABLED_CONFIG(DM) [Driver Model Code] #else [Non Driver Model Code] #endifI will post some patches later on.
BTW it would be nice if we could compile the code even if it is not included (e.g with the compile-time IS_ENABLED(CONFIG_...)). Also for driver model I would like it to be supported the same in both SPL and U-Boot proper, to avoid this sort of thing. We are very close to merging the driver model SPL support.
[snip]
Regards, Simon