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

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.

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 ;)

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

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

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

Hi.

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

Hi,

...

-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Masahiro Yamada Sent: Thursday, July 31, 2014 12:51 PM To: u-boot@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