Hi Tom,
On Fri, 30 May 2014 13:24:08 -0400 Tom Rini trini@ti.com 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 sjg@chromium.org 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