From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Fri, 30 May 2014 13:24:08 -0400 Subject: [U-Boot] [RFC] Two sets of experimental Kconfig patches In-Reply-To: <20140527163250.4E51.AA925319@jp.panasonic.com> References: <20140527163250.4E51.AA925319@jp.panasonic.com> Message-ID: <20140530172408.GP5836@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, May 27, 2014 at 04:32:50PM +0900, Masahiro Yamada wrote: > Hi. > > I've posted two sets of Kconfig RFC patches: "RFCv2a" and "RFCv2b" These are all certainly some thought experiments worth pursuing, so thanks for taking the time. > > The difference from v1 is that > Full U-boot image, SPL and TPL share a single defconfig > and "make config" is done in one-shot. > > This approach dates back to Simon's following comments: > > On Thu, 20 Mar 2014 19:15:30 -0700 > Simon Glass wrote: > > > > But, our situation is a little more complicated. > > > We need to generate 3 images at most: main image, SPL and TPL. > > > And each of them can have a different set of CONFIGs. > > > > > > 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. > > > In my opition, this approach might work, but will be painful. > > Anyway I just wanted to see what would happen > if multiple binary images had a single defconfig in common. > > We will have to duplicate many configs with CONFIG_SPL_ > and CONFIG_TPL_ prefixes. > > For example, > - CONFIG_SYS_TEXT_BASE (text base for the full image) > - CONFIG_SPL_TEXT_BASE (text base for SPL) > - CONFIG_TPL_TEXT_BASE (text base for TPL) > > - CONFIG_OF_CONTROL (enables OF control for the full image) > - CONFIG_SPL_OF_CONTROL (enables OF control for SPL) > - CONFIG_TPL_OF_CONTROL (enables OF control for TPL) > > Probably I will not adopt this approach, but your comments > are welcome. The biggest pro I see with this approach is that we don't add more complication to the process. I often run into "why does make board_name not work?". However, this will also prevent us from doing some of the cleanup and restructuring that we need to do. There's too much duplicated code between SPL/TPL and "normal" U-Boot that we want to fix. And there are times where a much smaller but more "normal" U-Boot-as-SPL would be handy. I think in the long run we need to live with this "problem". Perhaps we can come up with a little Makefile-magic along the lines of a fullconfig_fooboard rule that would: mkdir fooboard if exists fooboard_spl_config, make O=fooboard/spl fooboard_spl_config if exists fooboard_tpl_config, make O=fooboard/tpl fooboard_tpl_config make O=fooboard/main fooboard_config And maybe throw an 'all' in after the config target, maybe not. > The difference between RFCv2a and RFCv2b is > how ARCH should be passed to the build system. > > In RFCv2a, ARCH is determined by Kconfig. > We don't have to give it from the command line. > All defconfig files are stored in configs/ directory. > > > In RFCv2b, ARCH should be given from the command line > as in Linux Kernel: > make ARCH= _defconfig > make ARCH= CROSS_COMPILE= > Defconfig files are stored in arch/${ARCH}/configs/ directory. > > > I just tried Linux's way implementation because Stephen mentioned so. > > On Thu, 24 Apr 2014 14:36:33 -0600 > Stephen Warren wrote: > > > > But in U-Boot, ARCH is not given from the command line. > > > Which means we cannot know ARCH before the board configuration. > > > That is why "*_defconfig" files over all architectures should be > > > gathered into one directory ./configs/. > > > (The problem is configs/ directory contains about 1200 files!) > > > > Perhaps we can change the command-line used to build U-Boot, rather than > > shoe-horning U-Boot's Kconfig usage to fit that current limitation. > > > But I am not sure if other users are comfortable with giving ARCH= > for every configuration and build. > Your comments are welcome. So, I know there's a certain number of users that pass ARCH= along assuming that it's required and just wouldn't notice this particular change. But as I said in that thread, I really think this is a case where we can be a little smarter about things, so, well, we ought to try. It's just a menu choice and I imagine most people won't start with a totally blank config, even so. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: