Hi Stephen,
On Thu, 24 Apr 2014 14:36:33 -0600 Stephen Warren swarren@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@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:
- 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
- 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