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

[Stephen Warren <swarren@wwwdotorg.org>]

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.

> 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?

> 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@nvidia.com>"
> +
> +config BOARD_STATUS
> +	string
> +	default "Active +4"
> +
> +endif

Maintainter information seems better in MAINTAINERS.

> 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?

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?