Hi Masahiro, On 20 February 2015 at 17:55, Masahiro YAMADA <yamad...@jp.panasonic.com> wrote: > Hi Simon, > > > 2015-02-21 4:20 GMT+09:00 Simon Glass <s...@chromium.org>: >> Hi Stephen, >> >> On 19 February 2015 at 14:13, Stephen Warren <swar...@wwwdotorg.org> wrote: >>> On 02/19/2015 12:55 AM, 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. >>>> >>>> [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. >>>> >>>> [3] Kconfig files are getting ugly and difficult to understand. >>>> Commit b724bd7d6349 (dm: Kconfig: Move CONFIG_SYS_MALLOC_F_LEN to >>>> Kconfig) has sprinkled "if !SPL_BUILD" over the Kconfig files. >>>> >>>> [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 admit my mistake with my apology and this commit switches to the >>>> single .config configuration. >>>> >>>> It is not so difficult to do that: >>>> >>>> - Remove unnecessary processings from scripts/multiconfig.sh >>>> This file will remain for a while to support the current defconfig >>>> format. It will be removed after more cleanups are done. >>>> >>>> - Adjust some makefiles and Kconfigs >>>> >>>> - Add some entries to include/config_uncmd_spl.h and the new file >>>> scripts/Makefile.uncmd_spl. Some CONFIG options that are not >>>> supported on SPL must be disabled because one .config is shared >>>> between SPL and U-Boot proper going forward. I know this is not >>>> a beautiful solution and I think we can do better, but let's see >>>> how much we will have to describe them. >>>> >>>> - update doc/README.kconfig >>>> >>>> More cleaning up patches will follow this. >>> >>> >>>> diff --git a/arch/arm/cpu/armv7/tegra-common/Kconfig >>>> b/arch/arm/cpu/armv7/tegra-common/Kconfig >>>> index 0de13ae..c9e8919 100644 >>>> --- a/arch/arm/cpu/armv7/tegra-common/Kconfig >>>> +++ b/arch/arm/cpu/armv7/tegra-common/Kconfig >>>> @@ -26,7 +26,7 @@ config SYS_MALLOC_F_LEN >>>> default 0x1800 if SYS_MALLOC_F >>>> >>>> config USE_PRIVATE_LIBGCC >>>> - default y if SPL_BUILD >>>> + default y >>>> >>>> config DM >>>> default y if !SPL_BUILD >>> >>> >>> I think the above patch demonstrates the problem very nicely; it changes the >>> semantics from having CONFIG_USE_PRIVATE_LIBGCC enabled only in SPL build to >>> having it enabled everywhere. While that particular change shouldn't be an >>> issue, I think that requiring that all config options to have the same value >>> in main/SPL/TPL will be. For example, how do we disabled MMC support in SPL? >>> We have to introduce separate CONFIG_MMC and CONFIG_SPL_MMC don't we? That >>> doesn't seem any better than having separate defconfig files for >>> SPL/non-SPL, or using ifdefs in a single defconfig file. What happened to >>> the ability of one defconfig file to include another, so options could be >>> shared between the two? >> >> We use separate options for normal and SPL now. Currently we have >> CONFIG_SPL_MMC_SUPPORT. So it already works this way. >> >> If we can move to a world where SPL and U-Boot are more similar that >> will be good. >> >> What I don't understand about this change is why we cannot have >> 'default y if SPL_BUILD' in a rule if we want to. It seems like that >> would be useful. > > > CONFIG_SPL_BUILD is not defined in Kconfig any more, > i.e. we can not use the "if SPL_BUILD" conditonal. > > It is given when descending into the spl directory, like the pre-kconfig > build. > > Here in scripts/Makefile.spl > > -include include/config/auto.conf > -include $(obj)/include/autoconf.mk > > KBUILD_CPPFLAGS += -DCONFIG_SPL_BUILD > ifeq ($(CONFIG_TPL_BUILD),y) > KBUILD_CPPFLAGS += -DCONFIG_TPL_BUILD > endif
Thanks for explaining this. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
