[U-Boot] [PATCH v2 3/4] kconfig: switch to single .config configuration

Simon Glass sjg at chromium.org
Sat Feb 21 03:29:46 CET 2015


Hi Masahiro,

On 20 February 2015 at 17:55, Masahiro YAMADA <yamada.m at jp.panasonic.com> wrote:
> Hi Simon,
>
>
> 2015-02-21 4:20 GMT+09:00 Simon Glass <sjg at chromium.org>:
>> Hi Stephen,
>>
>> On 19 February 2015 at 14:13, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>> On 02/19/2015 12:55 AM, Masahiro Yamada wrote:
>>>>
>>>> When Kconfig for U-boot was examined, one of the biggest issues was
>>>> how to support multiple images (Normal, SPL, TPL).  There were
>>>> actually two options, "single .config" and "multiple .config".
>>>> After some discussions and thought experiments, I chose the latter,
>>>> i.e. to create ".config", "spl/.config", "tpl/.config" for Normal,
>>>> SPL, TPL, respectively.
>>>>
>>>> It is true that the "multiple .config" strategy provided us the
>>>> maximum flexibility and helped to avoid duplicating CONFIGs among
>>>> Normal, SPL, TPL, but I have noticed some fatal problems:
>>>>
>>>> [1] It is impossible to share CONFIG options across the images.
>>>>    If you change the configuration of Main image, you often have to
>>>>    adjust some SPL configurations correspondingly.  Currently, we
>>>>    cannot handle the dependencies between them.  It means one of the
>>>>    biggest advantages of Kconfig is lost.
>>>>
>>>> [2] It is too painful to change both ".config" and "spl/.config".
>>>>    Sunxi guys started to work around this problem by creating a new
>>>>    configuration target.  Commit cbdd9a9737cc (sunxi: kconfig: Add
>>>>    %_felconfig rule to enable FEL build of sunxi platforms.) added
>>>>    "make *_felconfig" to enable CONFIG_SPL_FEL on both images.
>>>>    Changing the configuration of multiple images in one command is a
>>>>    generic demand.  The current implementation cannot propose any
>>>>    good solution about this.
>>>>
>>>> [3] Kconfig files are getting ugly and difficult to understand.
>>>>    Commit b724bd7d6349 (dm: Kconfig: Move CONFIG_SYS_MALLOC_F_LEN to
>>>>    Kconfig) has sprinkled "if !SPL_BUILD" over the Kconfig files.
>>>>
>>>> [4] The build system got more complicated than it should be.
>>>>    To adjust Linux-originated Kconfig to U-Boot, the helper script
>>>>    "scripts/multiconfig.sh" was introduced.  Writing a complicated
>>>>    text processor is a shell script sometimes caused problems.
>>>>
>>>> Now I believe the "single .config" will serve us better.  With it,
>>>> all the problems above would go away.  Instead, we will have to add
>>>> some CONFIG_SPL_* (and CONFIG_TPL_*) options such as CONFIG_SPL_DM,
>>>> but we will not have much.  Anyway, this is what we do now in
>>>> scripts/Makefile.spl.
>>>>
>>>> I admit my mistake with my apology and this commit switches to the
>>>> single .config configuration.
>>>>
>>>> It is not so difficult to do that:
>>>>
>>>>   - Remove unnecessary processings from scripts/multiconfig.sh
>>>>    This file will remain for a while to support the current defconfig
>>>>    format.  It will be removed after more cleanups are done.
>>>>
>>>>   - Adjust some makefiles and Kconfigs
>>>>
>>>>   - Add some entries to include/config_uncmd_spl.h and the new file
>>>>     scripts/Makefile.uncmd_spl.  Some CONFIG options that are not
>>>>     supported on SPL must be disabled because one .config is shared
>>>>     between SPL and U-Boot proper going forward.  I know this is not
>>>>     a beautiful solution and I think we can do better, but let's see
>>>>     how much we will have to describe them.
>>>>
>>>>   - update doc/README.kconfig
>>>>
>>>> More cleaning up patches will follow this.
>>>
>>>
>>>> diff --git a/arch/arm/cpu/armv7/tegra-common/Kconfig
>>>> b/arch/arm/cpu/armv7/tegra-common/Kconfig
>>>> index 0de13ae..c9e8919 100644
>>>> --- a/arch/arm/cpu/armv7/tegra-common/Kconfig
>>>> +++ b/arch/arm/cpu/armv7/tegra-common/Kconfig
>>>> @@ -26,7 +26,7 @@ config SYS_MALLOC_F_LEN
>>>>         default 0x1800 if SYS_MALLOC_F
>>>>
>>>>   config USE_PRIVATE_LIBGCC
>>>> -       default y if SPL_BUILD
>>>> +       default y
>>>>
>>>>   config DM
>>>>         default y if !SPL_BUILD
>>>
>>>
>>> I think the above patch demonstrates the problem very nicely; it changes the
>>> semantics from having CONFIG_USE_PRIVATE_LIBGCC enabled only in SPL build to
>>> having it enabled everywhere. While that particular change shouldn't be an
>>> issue, I think that requiring that all config options to have the same value
>>> in main/SPL/TPL will be. For example, how do we disabled MMC support in SPL?
>>> We have to introduce separate CONFIG_MMC and CONFIG_SPL_MMC don't we? That
>>> doesn't seem any better than having separate defconfig files for
>>> SPL/non-SPL, or using ifdefs in a single defconfig file. What happened to
>>> the ability of one defconfig file to include another, so options could be
>>> shared between the two?
>>
>> We use separate options for normal and SPL now. Currently we have
>> CONFIG_SPL_MMC_SUPPORT. So it already works this way.
>>
>> If we can move to a world where SPL and U-Boot are more similar that
>> will be good.
>>
>> What I don't understand about this change is why we cannot have
>> 'default y if SPL_BUILD' in a rule if we want to. It seems like that
>> would be useful.
>
>
> CONFIG_SPL_BUILD is not defined in Kconfig any more,
> i.e. we can not use the "if SPL_BUILD" conditonal.
>
> It is given when descending into the spl directory, like the pre-kconfig build.
>
> Here in scripts/Makefile.spl
>
> -include include/config/auto.conf
> -include $(obj)/include/autoconf.mk
>
> KBUILD_CPPFLAGS += -DCONFIG_SPL_BUILD
> ifeq ($(CONFIG_TPL_BUILD),y)
> KBUILD_CPPFLAGS += -DCONFIG_TPL_BUILD
> endif

Thanks for explaining this.

Regards,
Simon


More information about the U-Boot mailing list