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:"... 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? 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. > [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". > [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. It seems like the root cause of this sprinkling is wanting to use default y to avoid touching a bunch of defconfig files, but not wanting to do the default y at the toplevel Kconfig. Maybe better tooling for bulk defconfig updates would help. In any case, couldn't you do CONFIG_SPL_DM currently, by making DM depend on "!SPL_BUILD || SPL_DM", without fundamentally changing the SPL kconfig infrastructure? Why do symbols like LOCALVERSION and CC_OPTIMIZE_FOR_SIZE depend on ! SPL_BUILD? > [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? > - 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. How is uncmd_spl better than "!SPL_BUILD"? -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
