On Wed, 2015-02-25 at 15:14 +0900, Masahiro Yamada 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?
So that you can express dependencies in the main U-Boot on SPL symbols, which you said was one of the problems that motivated this change. > > > > 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. Most options are boolean (especially if you ignore hardware description that isn't going to differ between SPL and non-SPL). I think it makes a lot of sense to not want to duplicate them, and especially to not complicate each place that ifdefs on the symbol by having to check for SPL. > > > 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. That's not what I was suggesting. I was suggesting something like: config DM bool "Enable Driver Model" depends on !SPL_BUILD || SPL_DM ... Then the ifdef would just be #ifdef CONFIG_DM [Driver Model Code] #else [Non Driver Model Code] #endif > > > > > [2] It is too painful to change both ".config" and "spl/.config". > > > > > Sunxi guys started to work around this problem by creating a new > > > > > configuration target. Commit cbdd9a9737cc (sunxi: kconfig: Add > > > > > %_felconfig rule to enable FEL build of sunxi platforms.) added > > > > > "make *_felconfig" to enable CONFIG_SPL_FEL on both images. > > > > > Changing the configuration of multiple images in one command is a > > > > > generic demand. The current implementation cannot propose any > > > > > good solution about this. > > > > > > > > How about defconfig fragments? Instead of having script infrastructure > > > > specifically for CONFIG_SPL_FEL, merge a fragment containing > > > > "+S:CONFIG_SPL_FEL". > > > > > > Do you mean something like this? > > > U-boot proper : common/.config + .config > > > SPL : common/.config + spl/.config > > > TPL : common/.config + tpl/.config > > > > No, I meant having a fragment containing only "+S:CONFIG_SPL_FEL" that > > could be merged into any other config. > > So, the fragment is something like the _common_ .config, right? The fragment would be part of a library of common config tweaks that users can apply -- providing similar convenience as _felconfig but with generic infrastructure. > > > > > [4] The build system got more complicated than it should be. > > > > > To adjust Linux-originated Kconfig to U-Boot, the helper script > > > > > "scripts/multiconfig.sh" was introduced. Writing a complicated > > > > > text processor is a shell script sometimes caused problems. > > > > > > > > > > Now I believe the "single .config" will serve us better. With it, > > > > > all the problems above would go away. Instead, we will have to add > > > > > some CONFIG_SPL_* (and CONFIG_TPL_*) options such as CONFIG_SPL_DM, > > > > > but we will not have much. Anyway, this is what we do now in > > > > > scripts/Makefile.spl. > > > > > > > > I had been hoping that the split configs would let us get rid of many of > > > > the CONFIG_SPL_* options that we already have. > > > > > > > > How will TPL be handled? Are you going to duplicate all the SPL > > > > symbols? Or just avoid ever kconfigizing them? > > > > > > Not all, but I expect some duplicated CONFIG_TPL_* such as > > > CONFIG_TPL_TEXT_BASE. > > > > I'm not talking about TEXT_BASE. I'm talking about stuff like this: > > We have to add some CONFIG_TPL_*, but we will just have 20. Just? And how much makefile crud to check for those options when building? To achieve what? > > If you redefine TPL to mean SPL that doesn't use certain code, you'll > > end up with targets that have TPL but no SPL. Are you sure this is > > simplifying anything? > > Sorry, I can't get it. > What I expect is like follows: > > CONFIG_TPL still depends on CONFIG_SPL. > > We have three options for the boot procedure: > > [1] U-Boot-proper (CONFIG_SPL is not defined) > > [2] SPL + U-Boot-proper (CONFIG_SPL is defined) > > [3] TPL + SPL + U-Boot-proper (CONFIG_SPL and CONFIG_TPL are defined) > > > The image size: TPL < SPL < U-Boot-proper > > Driver Model and some other features are available on SPL if CONFIG_SPL_* is > defined. > > Almost no systematic infrastructure is available on TPL, so we will have > very small number of CONFIG_TPL_*. So instead of CONFIG_TPL_* we'd have more hardcoded makefile hackery to disable things in TPL -- and we'd have to duplicate that hackery for SPLs that are just as small as what you're now calling TPL, if you're not going to allow TPL without SPL. -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot