[U-Boot] [RFC] Two sets of experimental Kconfig patches

[Masahiro Yamada]

Hi Tom,


On Fri, 30 May 2014 13:24:08 -0400
Tom Rini <trini at 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 at 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