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

[Stephen Warren <swarren@wwwdotorg.org>]

On 04/28/2014 03:39 AM, Masahiro Yamada wrote:
> On Thu, 24 Apr 2014 14:36:33 -0600
> Stephen Warren <swarren@wwwdotorg.org> wrote:

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

I guess the main issue I see here is that all the HW-configuration needs
to be repeated in seaboard_defconfig and spl/seaboard_defconfig.

(As an aside, if there's nothing special about SPL-vs-not and they're
just different builds of U-Boot, why put the SPL configurations into a
special-case sub-directory, why not name them seaboard_spl_defconfig and
seaboard_defconfig, and put them in the same configs directory).

Can we allow one defconfig to include or inherit from another? I know
that ChromeOS stores kernel defconfigs in "split configs" that build
upon each-other. Probably, this feature comes from elsewhere, and we
could just crib the config split/combine script for U-Boot's use. To
make this work, we'd probably need the user to run something like:

./build-u-boot seaboard
or:
./build-u-boot seaboard_spl

... rather than running make directly, so that script could generate the
.config from a set of defconfigs, and then invoke make.

(as an aside, having the user run a script to build rather than make
directly gives us a huge amount more flexibility to add run arbitrary
code to set up the build process before invoking make. I've found this
kind of thing extremely useful in the past on other projects).

This would allow us to create something like:

file: tegra20_soc_config
System is ARM
...

file: seaboard_board_config:
include tegra20_soc_config
Main UART is UARTD # some boards use UART A, etc.
Enable UART support
DT filename is tegra20-seaboard.dtb
...

file: seaboard_defconfig
include seaboard_board_config
Enable a whole slew of options like shell, commands, MMC drivers, USB, ...

file: seaboard_spl_defconfig
include seaboard_board_config
Enable a few SPL-specific options, if any