From: Simon Glass <sjg@chromium.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] Two sets of experimental Kconfig patches
Date: Sun, 1 Jun 2014 22:30:50 -0600 [thread overview]
Message-ID: <CAPnjgZ3oXLt1VRHjBAxRd7=z1W_kFDH7X9X1GA0QqSWUHO5KTA@mail.gmail.com> (raw)
In-Reply-To: <20140527163250.4E51.AA925319@jp.panasonic.com>
Hi Masahiro,
On 27 May 2014 01:32, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote:
> 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.
>
>
I have been thinking about this a lot, but it isn't 100% clear to me.
While I agree that duplicating the CONFIGs is bad, in fact the
opposite of what I was getting at, I do feel that things like
CONFIG_TEGRA20 need to be set in one place. We don't want the SPL/TPL
config to be changing things that make no sense given the board that
is selected. It doesn't make sense to have an SPL for Tegra and a TPL
for MX6.
Similar to what Tom was saying I feel that there will come a time when
the difference between U-Boot and SPL is just the options that are
enabled - the code paths will be the same. For example, I did a
CONFIG_CMD series which removed all commands from U-Boot and cut the
size to <50KB. OK that is not SPL size, but I can see a point where
they will merge. In that case we certainly don't want the option that
you list above - instead we want CONFIG_OF_CONTROL to mean the same
thing for U-Boot and SPL.
Perhaps it will help if we can have options like:
make menuconfig_main
make menuconfig_spl
make menuconfig_tpl
to avoid chaining between configs? That was my main concern with series 1.
[snip]
It would be great if we could make a decision on this and merge it
soon. To me the ARCH issue is minor but FWIW I think we should try to
avoid needing ARCH= on the command line.
So long as we get the general direction right we can make changes
later. To me the general direction is towards getting rid of the
special-case SPL code and SPL options.
Anyone else have comments?
Regards,
Simon
next prev parent reply other threads:[~2014-06-02 4:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-27 7:32 [U-Boot] [RFC] Two sets of experimental Kconfig patches Masahiro Yamada
2014-05-30 17:24 ` Tom Rini
2014-06-24 10:24 ` Masahiro Yamada
2014-06-02 4:30 ` Simon Glass [this message]
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='CAPnjgZ3oXLt1VRHjBAxRd7=z1W_kFDH7X9X1GA0QqSWUHO5KTA@mail.gmail.com' \
--to=sjg@chromium.org \
--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.