Wading in here later than I had wanted to, sorry.
On Mon, Apr 28, 2014 at 06:39:33PM +0900, Masahiro Yamada wrote:
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
[snip]
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.
To start with, I think we should try and keep things the way they are and not have to specify ARCH at least.
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?
While all of us kernel folks have well trained our fingers to add in ARCH= when building something other than x86 (unless of course we're doing native kernel compiles, which are a handy stress test of the system at least), that the kernel happily tries to build for x86 generally isn't the nicest thing ever. Which is why we've all trained ourselves to pass in ARCH. </end old guy rant>
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.
So, here's my question / hope. We can incrementally move from what this patch provides us today of strict but not as flexible set of Kconfig choices and options to something more flexible later. For example, this converts am335x_evm_uart[12345] directly but I would like to just drop them all and make CONS_INDEX (the only thing different between _uartN and am335x_evm itself) be a choice the user selects. That's not something I expect to be done at the start of the series of course.
[snip]
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.)
So this I believe answers what I was hoping which is that yes, down the line more things will be questions and less things selected, which means defconfig are more about providing config options.
And then yes, we need to re-evaluate what we do for SPL/TPL and see if really we can't just handle things with a user-selected CONFIG_SPL/TPL (for the just very different parts) and perhaps decouple these parts of the build.