Hi Simon,
> > For example, we can describe a board header file like this: > > > > #if defined(CONFIG_TPL_BUILD) > > # define CONFIG_FOO 100 > > #elif defined(CONFIG_SPL_BUILD) > > # define CONFIG_FOO 50 > > #else > > # define CONFIG_FOO 10 > > # define CONFIG_BAR > > #endif > > I wonder if we should drop this, and require that all have the same > options? That would involve requiring that board config files are not > permitted to use #ifdef CONFIG_SPL or #ifdef CONFIG_TPL. > > Does that seem like a bad restriction? The advantage is that we only > need one defconfig for each board. It seems to me that things are > going to get really painful if we have three different configs. > > Of course, this doesn't preclude #ifdefs in the Makefiles or actual > source code, but we already have SPL-specific feature options. > > I'm not 100% clear on the constraints here. It is true that 3 defconfigs per board are painful, but those constraints should not be required. Opposite. You are suggesting a better idea below. We should not treat SPL as a special case. In my opinion, CONFIG_SPL_* should be discontinued. For example, we can merge CONFIG_SPL_TEXT_BASE to CONFIG_SYS_TEXT_BASE. I mean, #ifdef CONFIG_SPL_BUILD # define CONFIG_SYS_TEXT_BASE 0x00000000 #else # define CONFIG_SYS_TEXT_BASE 0x10000000 #endif rather than #define CONFIG_SPL_TEXT_BASE 0x00000000 #define CONFIG_SYS_TEXT_BASE 0x10000000 Above will be transformed in Kconfig style. CONFIG_SYS_TEXT_BASE=0x00000000 (in foo_spl_defconfig) CONFIG_SYS_TEXT_BASE=0x10000000 (in foo_defconfig) > > How to change the setting? > > -------------------------- > > > > We can modify configuration as we do in Linux Kernel. > > Of cource "make config" works in U-Boot too. > > But I think most of you prefer GUI interface of "make menuconfig". > > (In Linux Kernel, with thousands of CONFIGs, "make config" is already > > useless.) > > > > The difference from Linux Kernel is that the configuration is done > > on three levels at most. > > One thought for the future - we should also think about dropping > spl/tpl as special cases, and just have a general ability to build > U-Boot multiple times with different options. So we could perhaps have > 5 different builds with different prefixes (none,spl,tpl,qpl, etc.) I like your idea very much!!! I believe this is the right way. Many makefiles are very dirty because of ifdef CONFIG_SPL_BUILD ... else ... endif. We should stop doing like this. SPL is just one of general images. I absolutely agree. But I think we need more efforts to go there. I want Kconfig on the main line soon (hopefully, in the MW in next month) and leave your idea to the next stage. 2014.04 : Kconfig along this series 2014.07 : Treat SPL and TPL as generic cases How about this time line? > Another little point - I think there is a mkdir missing somwhere: > > make O=b/snow snow_defconfig > /bin/sh: line 0: cd: b/snow: No such file or directory > Makefile:128: *** output directory "b/snow" does not exist. Stop. > > > (previously it would just create the directory with mkdir -p) Sorry. This feature was lost when switching to Kconfig. I've posted a patch to re-add it. Please check this: http://patchwork.ozlabs.org/patch/332955/ > > A mountain of work to do in front of us > > --------------------------------------- > > > > This series is the beginning of our long long journey too. > > We have thousands of CONFIG macros. > > Moving them needs much efforts but I believe it is worthwile. > > But I cannot do that task alone. > > Hey, board maintainers, I need your help! > > > > And, when you add a new CONFIG macro, please create an entry in Kconfig. > > Please do not add it into a header file any more. > > We should probably have a script in the build system which knows about > all the existing CONFIG items, and produces an error if it spots a new > one. That encourage force people to stop adding new CONFIGs. Possibly can it be included in scripts/checkpatch.pl ? I'm not sure.. > > [1] How board maintainers information should be handled? > > > > About half a year ago, commit 27af930e9a merged boards.cfg and MAINTAINERS. > > > > Since then, board maintainer information has been described in the > > rightest field of boards.cfg. > > > > But Kconfig uses defconfig files for board configuration. > > boards.cfg is no longer necessary. > > > > Where should board maintainer info be moved to? > > > > Revive MAINTAINERS file? > > > > Or create a new enrty in Kconfig? > > > > I chose the latter in this version. > > > > You will find something like this: > > CONFIG_BOARD_MAINTAINER="Tom Rini <tr...@ti.com>" > > in configs/*_defconfig. > > This seems OK to me, but I wonder if the maintainer is actually not > really a CONFIG option, but rather a built-in feature of the board, > something that cannot be changed. That would argue for putting it in > its own file. > > But this is fine with me. This item has been discussed in another thread: http://u-boot.10912.n7.nabble.com/RFC-PATCH-0-17-Version-0-of-Kconfig-for-U-Boot-td176113i20.html#a176247 I think Tom will post a patch to re-add MAINTAINERS file. > > Happy to help, although I'd like to figure out the final for boards > approach first. Thanks for offering your help. Agree, we should figure out our approach first. > > [3] How ARCH should be given? > > > > There is another difference from Linux Kernel. > > > > If we cross compile Linux Kernel, we always give ARCH from the command line: > > > > $ make ARCH=arm multi_v7_defconfig > > $ make ARCH=arm > > > > On the other hand, we set ARCH in the board configuration in U-Boot. > > I am following the convention in this series. > > I added architecture choice in Kconfig. > > > > But, if we try to be a mirror of Linux Kernel, that's an alternative method. > > > > Which do you think is better, ARCH from the command line or selecting it > > in Kconfig? > > Perhaps it should be a board feature (as I suggest for maintainer > above) since it can't be changed. Actually it seems pretty weird that > we have to specify the ARCH since if we get it wrong the board won't > build. > > But again, since Linux does it this way, I think we can live iwth it. OK, let's stick to the way in this series. Best Regards Masahiro Yamada _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
