[U-Boot] [PATCH 03/11] Kconfig: add CONFIG_SYS_BOOTM_LEN

[Hans de Goede]

Hi,

On 28-09-15 23:12, Tom Rini wrote:
> On Mon, Sep 28, 2015 at 09:22:35PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 28-09-15 17:10, Tom Rini wrote:
>>> On Wed, Sep 23, 2015 at 10:25:35AM -0700, Ryan Harkin wrote:
>>>
>>>> As config migrates from board config files to Kconfig, when adding
>>>> CONFIG_SYS_BOOTM_LEN to a platform, I decided to add
>>>> Kconfig support for CONFIG_SYS_BOOTM_LEN.
>>>>
>>>> Signed-off-by: Ryan Harkin <ryan.harkin at linaro.org>
>>>> Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
>>>> CC: Masahiro Yamada <yamada.m at jp.panasonic.com>
>>>> CC: Simon Glass <sjg at chromium.org>
>>>> CC: Linus Walleij <linus.walleij at linaro.org>
>>>
>>> Thanks for trying to do this.  The problem however is that you need to
>>> use tools/moveconfig.py so that all of the other boards (which is a lot)
>>> get updated too, otherwise they fail to build.
>>
>> No, just no, not more polluting of defconfig files with things which really
>> belong in a per SoC file not a per board file.
>
> Well, we should be putting SoC/arch-specific stuff into the defaults

Agreed, but where, do we add a long list of:

	default FOO if ARCH_BAR

To the Kconfig file where the actual CONFIG_SOMETHING gets defined, or
do we add it to board/bar/Kconfig ? Currently we've a bit of a mix,
I personally prefer the board/bar/Kconfig version as that puts everything for
one SoC(-family) in one place and it helps avoiding merge conflicts.

> and
> also using this as a chance to look at places where defaults differ
> pointlessly.
>
> But, I also hear your concern.  I see Masahiro has been working with
> merge_config.sh from the kernel in the kernel.   How crazy would it be
> to re-work things (in some cases..) to have a merge in the config
> process so that there could be a sunxi-common config fragment.

Either we then ask the user to take an extra step during building
(not a good idea IMHO), or we somehow need to automate this, which is
hard because figuring out which foo_common_config fragment belongs
to which board_defconfig file is going to be hard and / or will
involve a long list of hardcoded values in a Makefile or some such.

> Or
> can/should we really just use default foo if Y in more places.

I believe that this is the better option, currently board/sunxi/Kconfig
already has:

config SYS_CLK_FREQ
         default 912000000 if MACH_SUN7I
         default 1008000000 if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I || MACH_SUN8I

config SYS_CONFIG_NAME
         default "sun4i" if MACH_SUN4I
         default "sun5i" if MACH_SUN5I
         default "sun6i" if MACH_SUN6I
         default "sun7i" if MACH_SUN7I
         default "sun8i" if MACH_SUN8I
         default "sun9i" if MACH_SUN9I

Apparently these are not a problem for the script which is used to rewrite all
the defconfig-s, where as in the past having:

config CMD_FOO
	default y

in board/sunxi/Kconfig was a problem (it caused the script to emit
a ton of warnings IIRC) so I guess that doing something like:

config FOO
	default bar if ARCH_SUNXI

Will workaround the script issuing all kind of warnings, and then we
can keep per SoC(-family) defaults in board/foo/Kconfig.

Regards,

Hans