From: Masahiro Yamada <yamada.m@jp.panasonic.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] Two sets of experimental Kconfig patches
Date: Tue, 27 May 2014 16:32:50 +0900 [thread overview]
Message-ID: <20140527163250.4E51.AA925319@jp.panasonic.com> (raw)
Hi.
I've posted two sets of Kconfig RFC patches: "RFCv2a" and "RFCv2b"
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 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@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.
If you want to easily try and compare them, you can also
use my GitHub repository:
git clone git://github.com/masahir0y/u-boot-kbuild.git
There are some branches.
kconfig_rfc: RFC
kconfig_v1: Version1
kconfig_rfc2a: RFCv2a
kconfig_rfc2b: RFCv2b
Best Regards
Masahiro Yamada
next reply other threads:[~2014-05-27 7:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-27 7:32 Masahiro Yamada [this message]
2014-05-30 17:24 ` [U-Boot] [RFC] Two sets of experimental Kconfig patches Tom Rini
2014-06-24 10:24 ` Masahiro Yamada
2014-06-02 4:30 ` Simon Glass
2014-06-24 4:55 ` Masahiro Yamada
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140527163250.4E51.AA925319@jp.panasonic.com \
--to=yamada.m@jp.panasonic.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.