* [U-Boot] [RFC] Two sets of experimental Kconfig patches
@ 2014-05-27 7:32 Masahiro Yamada
2014-05-30 17:24 ` Tom Rini
2014-06-02 4:30 ` Simon Glass
0 siblings, 2 replies; 5+ messages in thread
From: Masahiro Yamada @ 2014-05-27 7:32 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] [RFC] Two sets of experimental Kconfig patches
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
1 sibling, 1 reply; 5+ messages in thread
From: Tom Rini @ 2014-05-30 17:24 UTC (permalink / raw)
To: u-boot
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.
> 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.
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>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] [RFC] Two sets of experimental Kconfig patches
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-02 4:30 ` Simon Glass
2014-06-24 4:55 ` Masahiro Yamada
1 sibling, 1 reply; 5+ messages in thread
From: Simon Glass @ 2014-06-02 4:30 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] [RFC] Two sets of experimental Kconfig patches
2014-06-02 4:30 ` Simon Glass
@ 2014-06-24 4:55 ` Masahiro Yamada
0 siblings, 0 replies; 5+ messages in thread
From: Masahiro Yamada @ 2014-06-24 4:55 UTC (permalink / raw)
To: u-boot
Hi Simon,
>
> 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.
I agree.
But I think, in some cases, it makes sense to build SPL only.
I want to drop Falcon boot as a special case.
In my rough view:
- <board>_defconfig : Normal boot sequence
- <board>_defconfig + <board>_spl_defconfig : SPL boot sequence
- <board>_spl_defconfig : Falcon boot
> 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
I have posted v3.
It is possible in v3.
make menuconfig --> edit .config
make spl:menuconfig --> edit spl/.config
make tpl:menuconfig --> edit tpl/.config
make qpl:menuconfig --> edit qpl/.config
etc.
Syntax is
make <output_dir>:<config_command>
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] [RFC] Two sets of experimental Kconfig patches
2014-05-30 17:24 ` Tom Rini
@ 2014-06-24 10:24 ` Masahiro Yamada
0 siblings, 0 replies; 5+ messages in thread
From: Masahiro Yamada @ 2014-06-24 10:24 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-06-24 10:24 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2014-06-24 4:55 ` Masahiro Yamada
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.