The way to use Kconfig in U-Boot

[Tom Rini]

On Fri, May 22, 2020 at 06:20:39PM +0800, Bin Meng wrote:
> Hi,
> 
> Kconfig is a flexible language and there are different ways to set a
> value for a specific platform.
> 
> We can either:
> 
> - Use Kconfig overriding functionality
> - Use Kconfig conditional set syntax like "default xxx if FOO"
> 
> Based on current Kconfig files hierarchy, in the root directory we
> have the following come at the very beginning:
> 
> # Allow defaults in arch-specific code to override any given here
> source "arch/Kconfig"
> 
> Based on this I thought our original design was to use the overriding.
> 
> But it seems not everyone is consistent on doing such. For example, we
> have a bunch of unmaintainable (IMO) Kconfig options like this:
> 
> config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
> hex "Address on the MMC to load U-Boot from"
> depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
> default 0x50 if ARCH_SUNXI
> default 0x75 if ARCH_DAVINCI
> default 0x8a if ARCH_MX6 || ARCH_MX7
> default 0x100 if ARCH_UNIPHIER
> default 0x140 if ARCH_MVEBU
> default 0x200 if ARCH_SOCFPGA || ARCH_AT91
> default 0x300 if ARCH_ZYNQ || ARCH_KEYSTONE || OMAP34XX || OMAP44XX || \
>          OMAP54XX || AM33XX || AM43XX || ARCH_K3
> default 0x4000 if ARCH_ROCKCHIP
> help
>   Address on the MMC to load U-Boot from, when the MMC is being used
>   in raw mode. Units: MMC sectors (1 sector = 512 bytes).
> 
> The "default xxx if FOO" list is crazy!
> 
> I think we need to discuss and come up with a unified way of doing this.
> 
> I personally am in favor of the overriding mechanism, which is how
> current x86 architecture Kconfig is organized. In the x86 arch
> Kconfig, we have:
> 
> # board-specific options below
> source "board/advantech/Kconfig"
> ...
> 
> # platform-specific options below
> source "arch/x86/cpu/apollolake/Kconfig"
> ...
> 
> # architecture-specific options below
> 
> So that board behavior overrides platform/SoC behavior over
> architecture behavior, and over the U-Boot common Kconfig options.
> This to me is very clear.

The problem I believe with overrides is that causes such churn to the
defconfigs on re-sync as they're used.

Personally I think this shows one of the problems with Kconfig as a
language and the need for some tool to take these values from something
else and spit out defines.  Perhaps now that u-boot, is a defined DT
prefix we could something-something our way through storing these in
-u-boot.dtsi files and use dtoc to get a header we use everywhere ala
kconfig.h?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot-custodians/attachments/20200522/73cc2cd5/attachment.sig>