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

[Tom Rini]

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.

> 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=<arch>   <board_name>_defconfig
>    make ARCH=<arch>    CROSS_COMPILE=<gcc_prefix>
> 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 <swarren at wwwdotorg.org> 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=<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: <http://lists.denx.de/pipermail/u-boot/attachments/20140530/344d507b/attachment.pgp>