[U-Boot] [PATCH 03/11] kconfig: add board Kconfig and defconfig files

[Masahiro Yamada]

Hi Stephen,


On Thu, 24 Apr 2014 14:36:33 -0600
Stephen Warren <swarren at wwwdotorg.org> wrote:

> On 04/23/2014 11:04 PM, Masahiro Yamada wrote:
> > This commit adds
> >  - arch/*/Kconfig: provide a menu to select target boards
> >  - board/*/Kconfig: set CONFIG macros to the appropriate values
> >         for each board
> >  - configs/*_defconfig: default setting of each board
> > 
> > (This commit was automatically generated by a conversion script
> > based on boards.cfg)
> > 
> > In Linux Kernel, defconfig files are located under
> > arch/${ARCH}/configs/ directory.
> > It works in Linux Kernel because ARCH is always given from the
> > command line for cross compile.
> > 
> > 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.

I am afraid something like
 make ARCH=arm seaboard_defconfig
 make ARCH=arm  CROSS_COMPILE=arm-linux-gnueabi-
is annoying for some users.

This item was an open discussion in the RFC version, but
Simon was the only person who replyed this question.

See
https://www.mail-archive.com/u-boot@lists.denx.de/msg134502.html
"How ARCH should be given?"   section.


Of course, this part is changable if other people accept
Linux's ARCH=${ARCH} way.

Comments are still welcome.


> > Besides, we must configure boards for SPL and TPL too
> > if they are supported.
> > For those boards, defconfig files with the same name are placed
> > in configs/spl/, configs/tpl/ directories.
> 
> I really don't think we should have separate defconfig files for SPL/TPL/...
> 
> I don't think that the approach of a single huge Kconfig file (albeit
> split into multiple included files per architecture and board) is going
> to work; it requires a massive amount of irrelevant Kconfig to be
> parsed, whereas scanning boards.cfg is a much simpler
> scan-until-you-find-a-matching-line approach.
> 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> 
> > +config TARGET_SEABOARD
> > +	bool "Support seaboard"
> 
> If U-Boot is built like:
> 
> make seaboard_config
> make
> 
> ... then I'm not sure why there is a Kconfig option for TARGET_SEABAORD.
> Are you intending for the .config file to dictate that we're building
> for Seaboard? If so, then presumably the make commands above will no
> longer be valid, and if we can change that aspect, why couldn't we
> require the user to add the architecture to the build command-line, just
> like the kernel does?

TARGET_SEABOARD is used just for selecting hard-coded
CONFIG_SYS_CPU="armv7"    (CONFIG_SYS_CPU="arm720t" in spl/.config)
CONFIG_SYS_BOARD="seaboard"
CONFIG_SYS_VENDOR="nvidia"
etc.

You said adding non-user-editable CONFIG to defconfig is odd.
So, this patch selects a board with CONFIG_TARGET_*  and then
selects hard-coded macros.


> > diff --git a/board/nvidia/seaboard/Kconfig b/board/nvidia/seaboard/Kconfig
> > new file mode 100644
> > index 0000000..7d38a81
> > --- /dev/null
> > +++ b/board/nvidia/seaboard/Kconfig
> > @@ -0,0 +1,32 @@
> > +if TARGET_SEABOARD
> > +
> > +config SYS_CPU
> > +	string
> > +	default "arm720t" if SPL_BUILD
> > +	default "armv7" if !SPL_BUILD
> > +
> > +config SYS_BOARD
> > +	string
> > +	default "seaboard"
> > +
> > +config SYS_VENDOR
> > +	string
> > +	default "nvidia"
> > +
> > +config SYS_SOC
> > +	string
> > +	default "tegra20"
> > +
> > +config SYS_CONFIG_NAME
> > +	string
> > +	default "seaboard"
> > +
> > +config BOARD_MAINTAINER
> > +	string
> > +	default "Tom Warren <twarren at nvidia.com>"
> > +
> > +config BOARD_STATUS
> > +	string
> > +	default "Active +4"
> > +
> > +endif
> 
> Maintainter information seems better in MAINTAINERS.

Personally, I prefer MAINTAINERS file.
But Wolfgang really dislikes it.

I just wanted to show what will happen
if I add CONFIG_BOARD_MAINTAINER and CONFIG_BOARD_STATUS
as hard-coded settings into board-specific Kconfig file.



> > diff --git a/configs/seaboard_defconfig b/configs/seaboard_defconfig
> > new file mode 100644
> > index 0000000..88819b9
> > --- /dev/null
> > +++ b/configs/seaboard_defconfig
> > @@ -0,0 +1,3 @@
> > +CONFIG_SPL=y
> > +CONFIG_ARM=y
> > +CONFIG_TARGET_SEABOARD=y
> 
> > diff --git a/configs/spl/seaboard_defconfig b/configs/spl/seaboard_defconfig
> > new file mode 100644
> > index 0000000..bc3eab4
> > --- /dev/null
> > +++ b/configs/spl/seaboard_defconfig
> > @@ -0,0 +1,2 @@
> > +CONFIG_ARM=y
> > +CONFIG_TARGET_SEABOARD=y
> 
> This definitely feels wrong. We shouldn't need to repeat the content of
> these files twice with/without CONFIG_SPL=y.
> 
> Should SPL/non-SPL be two build targets that get built when you ask to
> build for Seaboard, not two entirely unrelated defconfig files?

This is another item worth discussion.

The idea in my mind is to not treat SPL and TPL as special cases.
(This is an idea proposed by Simon.)

I was thinking of handling Non-SPL, SPL, TPL as generic images.

Currently, C sources and Makefiles are really dirty because of
ifdef CONFIG_SPL_BUILD everywhere.

But, roughly, the difference among them is how many CONFIG_ macros
are enabled.

Non-SPL:  enable hush command line, many useful commands,
         many drivers, net work feature etc. But the image size is big.

SPL: disable hush command line & all commands
       enable only some drivers enough for loading another image.
       The image size is small.

So, in future, many user ediatable settings will be moved to Kconfig.
And then, 

config/seaboard_defconfig will include
CONFIG_SYS_HUSH_PARSER=y
CONFIG_CMD_FOO=y
CONFIG_CMD_BAR=y
...

but config/spl/seaboard_defconfig will disable most of them.


But, if people don't like this,
I can change this part as only one defconfig per board
in the next version.
(Instead, we may lose flexibility to some extent
because SPL and non-SPL will share the same defconfig.)


> I guess I'm having a hard time understanding how Kconfig applies to U-Boot.
> 
> It feels like we should have two levels of configuration:
> 
> 1) You pick to build for a specific board name. This defines certain
> parameters of the build, e.g.:
> 
> - Which SoC you're building for, which implies
> -- CPU arch
> -- SPL used or not
> -- ...
> - Other hard-coded board parameters
> 
> 2) User option configuration, e.g.:
> 
> - Disable USB support on this board if I don't want it
> - Enable some other feature not enabled by default
> 
> I'm not completely sure that using Kconfig for both of those is the
> correct approach?

I believe using Kconfig for both is the correct approach.



Best Regards
Masahiro Yamada