Hi, On 24 February 2015 at 23:14, Masahiro Yamada <yamad...@jp.panasonic.com> wrote: > Hi Scott, > > > On Tue, 24 Feb 2015 18:17:59 -0600 > Scott Wood <scottw...@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 <scottw...@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] > #endif > > I 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
