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

Wed Mar 19 13:37:16 CET 2014

2014-03-19 11:51 GMT+01:00 Masahiro Yamada <yamada.m at jp.panasonic.com>:
> Hi Wolfgang,
>
>
> On Wed, 19 Mar 2014 10:56:46 +0100
> Wolfgang Denk <wd at denx.de> wrote:
>
>> Dear Masahiro,
>>
>> In message <20140319135026.7A64.AA925319 at jp.panasonic.com> you wrote:
>> >
>> > > >>> +++ 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 at nvidia.com>:Stephen Warren <swarren at 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.

maybe we should import get_maintainers.pl from kernel and readd
MAINTAINERS in the according format. So we could easily maintain infos
about board maintainers, custodians, custodian trees and maintaining
status per arch, CPU, SOC, drivers and boards in one place. Currently
that is not possible because one has to look into different sources
(boards.cfg, README's, U-Boot Wiki, git history, source file) to get
those infos.

>> > >
>> > > 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.
>> >
>> > Right.
>> > None of settings in Kconfig in this series is not user-editable.
>> > "make randconfig" or "make allyesconfig" will not work at all.
>>
>> I'm not sure if I understand your double negation here correctly.
>> Avoiding the double negation, you state that ALL values in this
>> defconfig are user-editable.
>
> Oops, sorry.
> What I wanted to say is:
> None of settings in Kconfig in this series is user-editable.
>
>
>
>> I fully agree with Stephen that this should not be the case.
>>
>> I'm afraid we are approaching one of the areas where we run into
>> problems if we try to reuse Kconfig as done in Linux, without changes.
>>
>> As Stephen already explained, we have the situation that there are
>> certain settings that are not actually supported to be user-editable.
>
> If "prompt" is not specified, the entry will not appear on
> "make config", "make menuconfig", etc.
>
> Linux Kernel does this for user-uneditable CONFIG.
>
> The following is a snippet from arch/arm/Kconfig of Linux Kernel.
>
> <<<<<<<<<<<<<
> config STACKTRACE_SUPPORT
>         bool
>         default y
>
> config HAVE_LATENCYTOP_SUPPORT
>         bool
>         depends on !SMP
>         default y
>
> config LOCKDEP_SUPPORT
>         bool
>         default y
>
> config TRACE_IRQFLAGS_SUPPORT
>         bool
>         default y
>
> config RWSEM_GENERIC_SPINLOCK
>         bool
>         default y
>>>>>>>>>>>>>>
>
> Above are forced to the default value.
> We should do this in U-Boot too.

agree. But at first we should introduce Kconfig files in all arch,
CPU, SOC, SOC common, board vendor, board and driver directories where
we put all CONFIG_SYS_ symbols. We also need to convert the current
config options for CPU, SOC, vendor and board. For example:

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"

should be converted to something like this:

CONFIG_CPU_ARMV7=y
CONFIG_SOC_TEGRA30=y
CONFIG_VENDOR_NVIDIA=y
CONFIG_BOARD_BEAVER=y

Then we can use the Kconfig symbol dependencies to create a minimal
working board config. For example:

board/nvidia/beaver/Kconfig:
config BOARD_BEAVER
    bool "board description"
    select VENDOR_NVIDIA
    select SOC_TEGRA30
    select SPL
    ...

arch/arm/cpu/armv7/tegra30/Kconfig:
config SOC_TEGRA30
    bool
    select ARMV7
    ...

The beaver_defconfig file could reduced then to
"CONFIG_BOARD_BEAVER=y" and some default user-editable options.

ideally the current target "make beaver_config" could be implemented as

echo "CONFIG_BOARD_BEAVER=y" > .config
make oldconfig

>
>
>
>> This is OK - the question is, what should it contain.  In my opinion,
>> we should fiond here the user changable settings (i. e. CONFIG_
>> stuff), but not the "unchangable" things (like CONFIG_SYS_).
>>
>> Yes, I am aware that there is a lot of incorrectly chosen names, i. e.
>> cases where CONFIG_ resp. CONFIG_SYS_ are incorrectly assigned - this
>> adds to the complexity of converting to Kconfig.
>
> For example, CONFIG_SYS_PROMPT.
>
>
>> > I believe the right way to reuse the Linux's Kconfig with minimum
>> > modification.
>>
>> Whithout modification, we will probably have to restrict ourself to
>> the really simple, user-configurable options - i. e. the CONFIG_ set
>> of options (and even then we will either have to make a number of
>> exceptions, and/or rename a number of such names, and/or provide in
>> some cases quite complex dependencies).
>
> This is the outcome we have developed.
> What we should do it to fix them correctly,
> not to change Kconfig concept.
>
>
> Best Regards
> Masahiro Yamada
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

-- 
- Daniel