From mboxrd@z Thu Jan 1 00:00:00 1970 From: Masahiro Yamada Date: Tue, 24 Jun 2014 19:24:26 +0900 Subject: [U-Boot] [RFC] Two sets of experimental Kconfig patches In-Reply-To: <20140530172408.GP5836@bill-the-cat> References: <20140527163250.4E51.AA925319@jp.panasonic.com> <20140530172408.GP5836@bill-the-cat> Message-ID: <20140624192425.9368.AA925319@jp.panasonic.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Tom, On Fri, 30 May 2014 13:24:08 -0400 Tom Rini wrote: > 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. I have posted v3. In v3, I added CONFIG_SUBIMAGES for "generic" sub-image framework. It takes the form of: CONFIG_SUBIMAGES="img1_output_dir:img1_defconfig,img2_output_dir:img2_defconfig" If it is defined the "main" U-Boot, it also does "make defconfig" based on img1_defconfig and create img1_output/.config etc. For instance, configs/C29XPCIE_NAND_defconfig has CONFIG_SUBIMAGES="spl:C29XPCIE_NAND_spl_defconfig,tpl:C29XPCIE_NAND_tpl_defconfig" We are still depending on the SPL/TPL framework ( = CONFIG_SPL, CONFIG_TPL, CONFIG_SPL_BUILD, CONFIG_TPL_BUILD). But I think it worth refactoring code to rip off them sometime. Best Regards Masahiro Yamada