[U-Boot] Quick guide to Kconfig

[U-Boot] Quick guide to Kconfig

[Masahiro Yamada]

Hi all,



The mainline has switched to Kconfig.

Please make sure to use "make <board>_defconfig"
instead of "make <board>_config".



[1] Board Configuration

     make  <board_name>_defconfig



[2] Modify configuration


 make config,  make menuconfig,  make nconfig, ... etc.


 For SPL,
   make spl/config,  make spl/menuconfig,  make spl/nconfig, ... etc.


 For TPL,
   make tpl/config,  make tpl/menuconfig,  make tpl/nconfig, ... etc.


  But there are no useful configurations in Kconfig for now.


[3] boards.cfg

We no longer have boards.cfg maintained in the git-repo.
But this file is necessary for MAKEALL and buildman.
Perhaps it may also be useful for browsing the list of the
supported boards.

You can generate an equivalent one by
running "tools/genboardscfg.py".



[4] MAKEALL and buildman

They depend on the boards.cfg file.

MAKEALL and buildman automatically generate boards.cfg
if it does not exist.










Best Regards
Masahiro Yamada

[U-Boot] Quick guide to Kconfig

[Frank Ihle]

Hi everyone,

can you please give me a hint how to run the menuconfig?
 
I just downloaded the latest U-Boot from ftp://ftp.denx.de/pub/u-boot/u-boot-latest.tar.bz2 (Version: 2014.07). When entering the /u-boot-2014.07/ directory and hitting "make menuconfig" then, it just tells me that there's no rule to make menuconfig - and so I can't run the configuration tool. Am I in the wrong directory or is it the wrong version?

Regards 

Frank

>>> Masahiro Yamada <yamada.m@jp.panasonic.com> 31.07.14 6.53 Uhr >>>
Hi all,



The mainline has switched to Kconfig.

Please make sure to use "make <board>_defconfig"
instead of "make <board>_config".



[1] Board Configuration

     make  <board_name>_defconfig



[2] Modify configuration


 make config,  make menuconfig,  make nconfig, ... etc.


 For SPL,
   make spl/config,  make spl/menuconfig,  make spl/nconfig, ... etc.


 For TPL,
   make tpl/config,  make tpl/menuconfig,  make tpl/nconfig, ... etc.


  But there are no useful configurations in Kconfig for now.


[3] boards.cfg

We no longer have boards.cfg maintained in the git-repo.
But this file is necessary for MAKEALL and buildman.
Perhaps it may also be useful for browsing the list of the
supported boards.

You can generate an equivalent one by
running "tools/genboardscfg.py".



[4] MAKEALL and buildman

They depend on the boards.cfg file.

MAKEALL and buildman automatically generate boards.cfg
if it does not exist.










Best Regards
Masahiro Yamada

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Quick guide to Kconfig

[Masahiro Yamada]

Hi Frank,


On Thu, 31 Jul 2014 08:29:07 +0200
"Frank Ihle" <frank.ihle@hs-offenburg.de> wrote:

> Hi everyone,
> 
> can you please give me a hint how to run the menuconfig?
>  
> I just downloaded the latest U-Boot from ftp://ftp.denx.de/pub/u-boot/u-boot-latest.tar.bz2 (Version: 2014.07). When entering the /u-boot-2014.07/ directory and hitting "make menuconfig" then, it just tells me that there's no rule to make menuconfig - and so I can't run the configuration tool. Am I in the wrong directory or is it the wrong version?



Kconfig is not included in u-boot-latest.tar.bz2 (Version: 2014.07);
Kconfig was merged into the mainline just ten hours ago!

If you want to try the newest source tree,
please do git-clone.

git clone git://git.denx.de/u-boot.git



Best Regards
Masahiro Yamada

[U-Boot] Quick guide to Kconfig

[Frank Ihle]

Hi Masahiro,

thanks! it's running nicely. I see you're running the GUI with lxdialog, and it's nice to see that more and more build systems come together to one "base", which makes it much easier for further developing. 

I've just started using it on our project too, but the integration is a pretty tenacious job, as you might know. I would much appreciate it, if you could share any information like tutorials or documentation for a better adaptation of the lxdialog, if that's alright. Because, if we are using U-Boots menuconfig, then we'd like to add extra rows with information on our own.

Kind Regards 

Frank

>>>> Masahiro Yamada <yamada.m@jp.panasonic.com> 31.07.14 8.39 Uhr >>>
>Hi Frank,
>
>
>On Thu, 31 Jul 2014 08:29:07 +0200
>"Frank Ihle" <frank.ihle@hs-offenburg.de> wrote:
>
>> Hi everyone,
>> 
>> can you please give me a hint how to run the menuconfig?
>>  
>> I just downloaded the latest U-Boot from ftp://ftp.denx.de/pub/u-boot/u-boot-latest.tar.bz2 (Version: 2014.07). When entering the /u-boot-2014.07/ directory and hitting "make menuconfig" then, it just tells me that there's no rule to make menuconfig - and so I can't run the configuration tool. Am I in the wrong directory or is it the wrong version?
>
>
>
>Kconfig is not included in u-boot-latest.tar.bz2 (Version: 2014.07);
>Kconfig was merged into the mainline just ten hours ago!
>
>If you want to try the newest source tree,
>please do git-clone.
>
>git clone git://git.denx.de/u-boot.git
>
>
>
>Best Regards
>Masahiro Yamada

[U-Boot] Quick guide to Kconfig

[Hans de Goede]

Hi,

On 07/31/2014 06:51 AM, Masahiro Yamada wrote:
> Hi all,
> 
> 
> 
> The mainline has switched to Kconfig.
> 
> Please make sure to use "make <board>_defconfig"
> instead of "make <board>_config".
> 
> 
> 
> [1] Board Configuration
> 
>      make  <board_name>_defconfig
> 
> 
> 
> [2] Modify configuration
> 
> 
>  make config,  make menuconfig,  make nconfig, ... etc.
> 
> 
>  For SPL,
>    make spl/config,  make spl/menuconfig,  make spl/nconfig, ... etc.

I'm a bit confused here, a single "make" will build both the SPL +
the regular u-boot binary, so why 2 separate menuconfig commands for them ?

To be a bit more specific, currently for sunxi for some boards
(the ones most used by devs) we have both Foo_defconfig and Foo_FEL_defconfig
with the latter one being identical to the first one, except that it not only
defines SPL (all our builds use SPL) but also SPL_FEL, this changes some
compile time settings as well as leads to using a different linker script
for the SPL. The end result is a SPL binary which can be loaded through the
"FEL" allwinner usb firmware loading / update mechanism, rather then written
to a sdcard as our regular builds.

Rather then doubling the amount of defconfigs we have to allow using FEL
on any sunxi board, I would like to remove the Foo_FEL_defconfig files
and make it possible to do a FEL build by doing something like this:

make Foo_defconfig
make menuconfig
<select FEL>
make

I was planning on taking a shot at this, but the different make menuconfig
and make spl/menuconfigs have me somewhat confused (I've a decent knowledge of
Kconfig from my kernel work).

Perhaps you can give me some hints on how I can best implement the above ?

Thanks & Regards,

Hans

[U-Boot] Quick guide to Kconfig

[Ian Campbell]

On Thu, 2014-07-31 at 16:38 +0200, Hans de Goede wrote:
> make Foo_defconfig
> make menuconfig
> <select FEL>
> make

I was hoping that I might eventually be able to do something like
	make Foo_defconfig CONFIG_SPL_FEL=y
or perhaps
	make Foo_defconfig S:CONFIG_SPL_FEL=y
and have it DTRT(tm).

> I was planning on taking a shot at this, but the different make menuconfig
> and make spl/menuconfigs have me somewhat confused (I've a decent knowledge of
> Kconfig from my kernel work).

I think part of the problem is that right now we are at "Phase I" of the
switch to Kconfig, which is where the board.cfg settings have moved as a
string into CONFIG_SYS_EXTRA_OPTIONS. I suppose "Phase II" is that the
various maintainers implement proper Kconfig options for their platforms
and transition the individual settings over to it. Eventually
CONFIG_SYS_EXTRA_OPTIONS goes away.

Eventually (sooner rather than later, I think) we will want to have a
first-class Kconfig setting for CONFIG_SPL_FEL and then things like
"make spl/menuconfig" would let you enable FEL, I think/hope.

Apologies if I've misunderstood something and am therefore talking
nonsense ;-)

Ian.

[U-Boot] Quick guide to Kconfig

[Masahiro Yamada]

Hi Hans,


On Thu, 31 Jul 2014 16:38:47 +0200
Hans de Goede <hdegoede@redhat.com> wrote:

> Hi,
> 
> On 07/31/2014 06:51 AM, Masahiro Yamada wrote:
> > Hi all,
> > 
> > 
> > 
> > The mainline has switched to Kconfig.
> > 
> > Please make sure to use "make <board>_defconfig"
> > instead of "make <board>_config".
> > 
> > 
> > 
> > [1] Board Configuration
> > 
> >      make  <board_name>_defconfig
> > 
> > 
> > 
> > [2] Modify configuration
> > 
> > 
> >  make config,  make menuconfig,  make nconfig, ... etc.
> > 
> > 
> >  For SPL,
> >    make spl/config,  make spl/menuconfig,  make spl/nconfig, ... etc.
> 
> I'm a bit confused here, a single "make" will build both the SPL +
> the regular u-boot binary, so why 2 separate menuconfig commands for them ?

A single "make <board>_defconfig" will configure both the Normal U-boot and SPL.
(It will create  .config and additionally spl/.config if SPL is supported )

Likewise a single "make" will build both.

This keeps the same build process as we had prior to Kconfig,
except the command name difference between  <board>_config and <board>_defconfig.

But "config", "menuconfig", "nconfig", etc. are interactive configuration
tools, which can not be run for Normal and SPL at one time.

So I think it is reasonable to allow users to invoke menuconfig and spl/menuconfig
separately.




> To be a bit more specific, currently for sunxi for some boards
> (the ones most used by devs) we have both Foo_defconfig and Foo_FEL_defconfig
> with the latter one being identical to the first one, except that it not only
> defines SPL (all our builds use SPL) but also SPL_FEL, this changes some
> compile time settings as well as leads to using a different linker script
> for the SPL. The end result is a SPL binary which can be loaded through the
> "FEL" allwinner usb firmware loading / update mechanism, rather then written
> to a sdcard as our regular builds.
> 
> Rather then doubling the amount of defconfigs we have to allow using FEL
> on any sunxi board, I would like to remove the Foo_FEL_defconfig files
> and make it possible to do a FEL build by doing something like this:
> 
> make Foo_defconfig
> make menuconfig
> <select FEL>
> make

Yes, this is exactly what I expect board maintainers.

We had multiple entries in boards.cfg per board
(with some differences in the options field)
and I generated the correspoing defconfig files.

But I guess it would be painful to maintain lots of defconfigs.

I expect board maintainers will consolidate defconfigs like you are trying to do,
and eventually, we will have one defconfig per board in the future.


> I was planning on taking a shot at this, but the different make menuconfig
> and make spl/menuconfigs have me somewhat confused (I've a decent knowledge of
> Kconfig from my kernel work).
> 
> Perhaps you can give me some hints on how I can best implement the above ?


Sounds good!


I think it is good to add

config FEL
     bool

or something allowing users to enable/disable it.


If it is a sunxi-specifi option, please add it to
arch/arm/cpu/armv7/sunxi/Kconfig or board/sunxi/Kconfig.



Best Regards
Masahiro Yamada

[U-Boot] Quick guide to Kconfig

[Masahiro Yamada]

Hi Ian,




On Thu, 31 Jul 2014 16:07:54 +0100
Ian Campbell <ijc@hellion.org.uk> wrote:

> On Thu, 2014-07-31 at 16:38 +0200, Hans de Goede wrote:
> > make Foo_defconfig
> > make menuconfig
> > <select FEL>
> > make
> 
> I was hoping that I might eventually be able to do something like
> 	make Foo_defconfig CONFIG_SPL_FEL=y
> or perhaps
> 	make Foo_defconfig S:CONFIG_SPL_FEL=y
> and have it DTRT(tm).


Sorry, we cannot override CONFIG macros from the command line;
We have to run "make menuconfig" (or "make spl/menuconfig")
and toggle the option.


> > I was planning on taking a shot at this, but the different make menuconfig
> > and make spl/menuconfigs have me somewhat confused (I've a decent knowledge of
> > Kconfig from my kernel work).
> 
> I think part of the problem is that right now we are at "Phase I" of the
> switch to Kconfig, which is where the board.cfg settings have moved as a
> string into CONFIG_SYS_EXTRA_OPTIONS. I suppose "Phase II" is that the
> various maintainers implement proper Kconfig options for their platforms
> and transition the individual settings over to it. Eventually
> CONFIG_SYS_EXTRA_OPTIONS goes away.

Exactly.

CONFIG_SYS_EXTRA_OPTIONS is a temporary gimmick
to migrate to Kconfig.


Please note this option is marked as "DEPRECATED".


config SYS_EXTRA_OPTIONS
        string "Extra Options (DEPRECATED)"
        depends on !SPL_BUILD
        help
          The old configuration infrastructure (= mkconfig + boards.cfg)
          provided the extra options field. If you have something like
          "HAS_BAR,BAZ=64", the optional options
            #define CONFIG_HAS
            #define CONFIG_BAZ  64
          will be defined in include/config.h.
          This option was prepared for the smooth migration from the old
          configuration to Kconfig. Since this option will be removed sometime,
          new boards should not use this option.



I do not recommend to use this option for new boards.



> Eventually (sooner rather than later, I think) we will want to have a
> first-class Kconfig setting for CONFIG_SPL_FEL and then things like
> "make spl/menuconfig" would let you enable FEL, I think/hope.
> 
> Apologies if I've misunderstood something and am therefore talking
> nonsense ;-)


Sounds nice, thanks!



Best Regards
Masahiro Yamada

[U-Boot] Quick guide to Kconfig

[Yan, Miao]

Hi,

> -----Original Message-----
> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
> On Behalf Of Masahiro Yamada
> Sent: Thursday, July 31, 2014 12:51 PM
> To: u-boot at lists.denx.de
> Subject: [U-Boot] Quick guide to Kconfig
> 
> Hi all,
> 
> 
> 
> The mainline has switched to Kconfig.
> 
> Please make sure to use "make <board>_defconfig"
> instead of "make <board>_config".
> 
> 
> 
> [1] Board Configuration
> 
>      make  <board_name>_defconfig


Do we have a minimal python version requirement ? Because I can
no longer build U-Boot on our build server which still uses python-2.4.x.
There are some 2.6+ only syntax in genboardscfg.py and multiconfig.py. 

Thanks,
Miao


> 
> 
> 
> [2] Modify configuration
> 
> 
>  make config,  make menuconfig,  make nconfig, ... etc.
> 
> 
>  For SPL,
>    make spl/config,  make spl/menuconfig,  make spl/nconfig, ... etc.
> 
> 
>  For TPL,
>    make tpl/config,  make tpl/menuconfig,  make tpl/nconfig, ... etc.
> 
> 
>   But there are no useful configurations in Kconfig for now.
> 
> 
> [3] boards.cfg
> 
> We no longer have boards.cfg maintained in the git-repo.
> But this file is necessary for MAKEALL and buildman.
> Perhaps it may also be useful for browsing the list of the supported boards.
> 
> You can generate an equivalent one by
> running "tools/genboardscfg.py".
> 
> 
> 
> [4] MAKEALL and buildman
> 
> They depend on the boards.cfg file.
> 
> MAKEALL and buildman automatically generate boards.cfg if it does not exist.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Best Regards
> Masahiro Yamada
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Quick guide to Kconfig

[Masahiro Yamada]

Hi.



On Mon, 4 Aug 2014 07:12:01 +0000
"Yan, Miao" <Miao.Yan@windriver.com> wrote:

> Hi,
> 
> > -----Original Message-----
> > From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
> > On Behalf Of Masahiro Yamada
> > Sent: Thursday, July 31, 2014 12:51 PM
> > To: u-boot at lists.denx.de
> > Subject: [U-Boot] Quick guide to Kconfig
> > 
> > Hi all,
> > 
> > 
> > 
> > The mainline has switched to Kconfig.
> > 
> > Please make sure to use "make <board>_defconfig"
> > instead of "make <board>_config".
> > 
> > 
> > 
> > [1] Board Configuration
> > 
> >      make  <board_name>_defconfig
> 
> 
> Do we have a minimal python version requirement ? Because I can
> no longer build U-Boot on our build server which still uses python-2.4.x.
> There are some 2.6+ only syntax in genboardscfg.py and multiconfig.py. 


I have no idea about the python version requirement in U-Boot.

It seams not so difficult to rewrite them without "with ... as" and "except ... as"
and here are the patches:
http://patchwork.ozlabs.org/patch/376215/
http://patchwork.ozlabs.org/patch/376214/

Sorry, tools/genboardscfg.py is not working on Python 2.4
I have to make more effort for that, but I am not sure it is worthwhile.

Is is difficult to install newer Python on your machine?


Best Regards
Masahiro Yamada

[U-Boot] Quick guide to Kconfig

[Yan, Miao]

Hi,

> > Do we have a minimal python version requirement ? Because I can no
> > longer build U-Boot on our build server which still uses python-2.4.x.
> > There are some 2.6+ only syntax in genboardscfg.py and multiconfig.py.
> 
> 
> I have no idea about the python version requirement in U-Boot.
> 
> It seams not so difficult to rewrite them without "with ... as" and "except ...
> as"
> and here are the patches:
> http://patchwork.ozlabs.org/patch/376215/
> http://patchwork.ozlabs.org/patch/376214/
> 
> Sorry, tools/genboardscfg.py is not working on Python 2.4 I have to make
> more effort for that, but I am not sure it is worthwhile.
> 
> Is is difficult to install newer Python on your machine?

I can work-around it by installing a newer Python in my home directory and
fixing $PATH.  I am OK if you think it not necessary to support older 
versions, I just want to be sure about that.

Thanks,
Miao



> 
> 
> Best Regards
> Masahiro Yamada

[U-Boot] Quick guide to Kconfig

[Simon Glass]

Hi Masahiro,

On 30 July 2014 22:51, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote:
> Hi all,
>
>
>
> The mainline has switched to Kconfig.
>
> Please make sure to use "make <board>_defconfig"
> instead of "make <board>_config".

Once this thread is complete, do you think you could send a patch to
add some docs to the source tree?

Regards,
Simon

[U-Boot] Quick guide to Kconfig

[Tom Rini]

On Fri, Aug 01, 2014 at 01:37:54PM +0900, Masahiro Yamada wrote:

[snip]
> We had multiple entries in boards.cfg per board
> (with some differences in the options field)
> and I generated the correspoing defconfig files.
> 
> But I guess it would be painful to maintain lots of defconfigs.
> 
> I expect board maintainers will consolidate defconfigs like you are
> trying to do, and eventually, we will have one defconfig per board in
> the future.

So I was thinking about this a bit this morning since I have lots of
defconfigs I want to merge together as well (see am335x_evm*).  I
suspect the answer is board maintainers will want a README in their
directory.  But today we're inconsistent in a few places.  First, it's
most often board/.../README but we have a few README.somethings (I'm
guilty there too.  And despite 702e601 we have some board-level (I'd
consider at least) details in docs/ still.

Would board/sunxi/README work for the sunxi cases?  Or is that going to
get too unwieldy?

-- 
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/20140804/911a6e8a/attachment.pgp>

[U-Boot] Quick guide to Kconfig

[Hans de Goede]

Hi,

On 08/04/2014 04:27 PM, Tom Rini wrote:
> On Fri, Aug 01, 2014 at 01:37:54PM +0900, Masahiro Yamada wrote:
> 
> [snip]
>> We had multiple entries in boards.cfg per board
>> (with some differences in the options field)
>> and I generated the correspoing defconfig files.
>>
>> But I guess it would be painful to maintain lots of defconfigs.
>>
>> I expect board maintainers will consolidate defconfigs like you are
>> trying to do, and eventually, we will have one defconfig per board in
>> the future.
> 
> So I was thinking about this a bit this morning since I have lots of
> defconfigs I want to merge together as well (see am335x_evm*).  I
> suspect the answer is board maintainers will want a README in their
> directory.  But today we're inconsistent in a few places.  First, it's
> most often board/.../README but we have a few README.somethings (I'm
> guilty there too.  And despite 702e601 we have some board-level (I'd
> consider at least) details in docs/ still.
> 
> Would board/sunxi/README work for the sunxi cases?  Or is that going to
> get too unwieldy?

board/sunxi/README will work fine for sunxi documentation as far as I
can see right now.

Regards,

Hans

[U-Boot] Quick guide to Kconfig

[Tom Rini]

On Fri, Aug 01, 2014 at 01:42:15PM +0900, Masahiro Yamada wrote:
> Hi Ian,
> 
> 
> 
> 
> On Thu, 31 Jul 2014 16:07:54 +0100
> Ian Campbell <ijc@hellion.org.uk> wrote:
> 
> > On Thu, 2014-07-31 at 16:38 +0200, Hans de Goede wrote:
> > > make Foo_defconfig
> > > make menuconfig
> > > <select FEL>
> > > make
> > 
> > I was hoping that I might eventually be able to do something like
> > 	make Foo_defconfig CONFIG_SPL_FEL=y
> > or perhaps
> > 	make Foo_defconfig S:CONFIG_SPL_FEL=y
> > and have it DTRT(tm).
> 
> 
> Sorry, we cannot override CONFIG macros from the command line;

But this is an upstream limitation ;)

-- 
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/20140804/79657003/attachment.pgp>

[U-Boot] Quick guide to Kconfig

[Tom Rini]

On Mon, Aug 04, 2014 at 05:15:21AM -0600, Simon Glass wrote:
> Hi Masahiro,
> 
> On 30 July 2014 22:51, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote:
> > Hi all,
> >
> >
> >
> > The mainline has switched to Kconfig.
> >
> > Please make sure to use "make <board>_defconfig"
> > instead of "make <board>_config".
> 
> Once this thread is complete, do you think you could send a patch to
> add some docs to the source tree?

I plan to grab the patch already posted to fixup existing docs in place,
btw.

-- 
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/20140804/7cd879aa/attachment.pgp>

[U-Boot] Quick guide to Kconfig

[Ian Campbell]

On Mon, 2014-08-04 at 11:49 -0400, Tom Rini wrote:
> On Fri, Aug 01, 2014 at 01:42:15PM +0900, Masahiro Yamada wrote:
> > Hi Ian,
> > 
> > 
> > 
> > 
> > On Thu, 31 Jul 2014 16:07:54 +0100
> > Ian Campbell <ijc@hellion.org.uk> wrote:
> > 
> > > On Thu, 2014-07-31 at 16:38 +0200, Hans de Goede wrote:
> > > > make Foo_defconfig
> > > > make menuconfig
> > > > <select FEL>
> > > > make
> > > 
> > > I was hoping that I might eventually be able to do something like
> > > 	make Foo_defconfig CONFIG_SPL_FEL=y
> > > or perhaps
> > > 	make Foo_defconfig S:CONFIG_SPL_FEL=y
> > > and have it DTRT(tm).
> > 
> > 
> > Sorry, we cannot override CONFIG macros from the command line;
> 
> But this is an upstream limitation ;)

Right, I think it must have been just my wishful thinking that I
remembered doing this...

Ian.

[U-Boot] Quick guide to Kconfig

[Masahiro Yamada]

Hi Tom,

On Mon, 4 Aug 2014 10:27:42 -0400
Tom Rini <trini@ti.com> wrote:

> On Fri, Aug 01, 2014 at 01:37:54PM +0900, Masahiro Yamada wrote:
> 
> [snip]
> > We had multiple entries in boards.cfg per board
> > (with some differences in the options field)
> > and I generated the correspoing defconfig files.
> > 
> > But I guess it would be painful to maintain lots of defconfigs.
> > 
> > I expect board maintainers will consolidate defconfigs like you are
> > trying to do, and eventually, we will have one defconfig per board in
> > the future.
> 
> So I was thinking about this a bit this morning since I have lots of
> defconfigs I want to merge together as well (see am335x_evm*). 


I think we don't have to be too strict to "one defconfig per board".
Maybe we can have two or three where it is reasonable.
Anyway it is a good thing to merge "am335x_evm_uart*"  :-)


Best Regards
Masahiro Yamada

[U-Boot] Quick guide to Kconfig

[Ian Campbell]

On Mon, 2014-08-04 at 17:35 +0200, Hans de Goede wrote:
> Hi,
> 
> On 08/04/2014 04:27 PM, Tom Rini wrote:
> > On Fri, Aug 01, 2014 at 01:37:54PM +0900, Masahiro Yamada wrote:
> > 
> > [snip]
> >> We had multiple entries in boards.cfg per board
> >> (with some differences in the options field)
> >> and I generated the correspoing defconfig files.
> >>
> >> But I guess it would be painful to maintain lots of defconfigs.
> >>
> >> I expect board maintainers will consolidate defconfigs like you are
> >> trying to do, and eventually, we will have one defconfig per board in
> >> the future.
> > 
> > So I was thinking about this a bit this morning since I have lots of
> > defconfigs I want to merge together as well (see am335x_evm*).  I
> > suspect the answer is board maintainers will want a README in their
> > directory.  But today we're inconsistent in a few places.  First, it's
> > most often board/.../README but we have a few README.somethings (I'm
> > guilty there too.  And despite 702e601 we have some board-level (I'd
> > consider at least) details in docs/ still.
> > 
> > Would board/sunxi/README work for the sunxi cases?  Or is that going to
> > get too unwieldy?
> 
> board/sunxi/README will work fine for sunxi documentation as far as I
> can see right now.

A bunch of the sort of thing I imaging would be there probably ought
instead to go into Kconfig help sections for the symbols which they are
documenting.

Ian.