The way to use Kconfig in U-Boot

Tom Rini trini at konsulko.com
Fri May 22 15:45:31 CEST 2020


On Fri, May 22, 2020 at 07:38:21AM -0600, Simon Glass wrote:
> Hi,
> 
> On Fri, 22 May 2020 at 06:32, Tom Rini <trini at konsulko.com> wrote:
> >
> > 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?
> 
> I think for the case Bin mentions yes we could do that. Certainly not
> nice to put this sort of thing in Kconfig. Perhaps a DT 'config/' node
> a bit like the existing 'chosen', that dtoc emits?

We should take a look at where Zephyr does it I think as I believe
they've done a lot of "put data in DT file, then build based on that" as
while there are valid use cases for us for figuring out what we have at
run time, we have very strong use cases for "we know everything at build
time".

-- 
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/c4959b8b/attachment.sig>


More information about the U-Boot-Custodians mailing list