[U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards

[Stephen Warren <swarren@wwwdotorg.org>]

On 03/18/2014 09:16 PM, Masahiro Yamada wrote:
> Hi Stephen,
> 
>>> diff --git a/configs/beaver_defconfig b/configs/beaver_defconfig
>>> new file mode 100644
>>> index 0000000..fbf00f3
>>> --- /dev/null
>>> +++ b/configs/beaver_defconfig
>>> @@ -0,0 +1,10 @@
>>> +CONFIG_SPL=y
>>> +CONFIG_ARM=y
>>> +CONFIG_SYS_CPU="armv7"
>>> +CONFIG_SOC_DIR=y
>>> +CONFIG_SYS_SOC="tegra30"
>>> +CONFIG_SYS_BOARD="beaver"
>>> +CONFIG_VENDOR_DIR=y
>>> +CONFIG_SYS_VENDOR="nvidia"
>>> +CONFIG_SYS_CONFIG_NAME="beaver"
>>> +CONFIG_BOARD_MAINTAINER="Tom Warren <twarren@nvidia.com>:Stephen Warren <swarren@nvidia.com>"
>>
>> This is odd; defconfig in the Linux kernel is for defining values for
>> user-editable configuration options. However, at least
>> CONFIG_BOARD_MAINTAINERS is a property of the board port, not something
>> the a user should be editing.
> 
> In U-Boot, each board and its maintainer are tightly coupled.
> So, Albert chose to merge boards.cfg and MAINTAINERS in commit 27af930e9a.

I think you're completely missing my point. None of the information
contained in the defconfig files you posted is even *remotely* related
to what a defconfig file is. defconfig is for user-configurable
configuration of the software, not for core values that must be set up
in a certain way for the code to compile or work.

> I am following that concept.
> That's why I added maintainers information to defconfig files
> rather than keeping it in a seperated file.
> 
> Anyway, this item is for open discussion.
> Do you have any idea instead of this?

I don't think there's any need at all for a "defconfig" file here.

Perhaps the solution is to simply name these files something other than
"defconfig", but rather something else that reflects what the content
really is.

>> Other values in this file feel very odd
>> too. For example, I would expect selecting SYS_SOC=tegra30 it
>> automatically select SYS_VENDOR, SYS_CPU, ARM, SPL, ...
> 
> This is really really Tegra-specific matter.

Absolutely not at all.

Any board contains a specific SoC. Each specific SoC is a particular CPU
architecture and type, etc.