Hi Stephen,
2015-02-20 6:13 GMT+09:00 Stephen Warren <swar...@wwwdotorg.org>: > 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. Right. This is the disadvantage of the single .config strategy. That's why I chose separate .config at first. > For example, how do we disabled MMC support in SPL? > We have to introduce separate CONFIG_MMC and CONFIG_SPL_MMC don't we? Yes, I expect this. We already have CONFIG_SPL_MTD_SUPPORT CONFIG_SPL_NAND_SUPPORT CONFIG_SPL_NET_SUPPORT CONFIG_SPL_USB_HOST_SUPPORT etc. > 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? What you are saying is right, but we are suffering from various problems that are ascribed to the multi .config way. I cannot suggest any solution but the single .config. -- Best Regards Masahiro Yamada _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
