From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Thu, 19 Feb 2015 14:13:15 -0700 Subject: [U-Boot] [PATCH v2 3/4] kconfig: switch to single .config configuration In-Reply-To: <1424332525-21314-4-git-send-email-yamada.m@jp.panasonic.com> References: <1424332525-21314-1-git-send-email-yamada.m@jp.panasonic.com> <1424332525-21314-4-git-send-email-yamada.m@jp.panasonic.com> Message-ID: <54E651EB.4000804@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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?