The way to use Kconfig in U-Boot
Tom Rini
trini at konsulko.com
Fri May 22 19:58:54 CEST 2020
On Fri, May 22, 2020 at 11:38:58PM +0800, Bin Meng wrote:
> Hi Simon,
>
> On Fri, May 22, 2020 at 10:10 PM Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi Bin,
> >
> > On Fri, 22 May 2020 at 08:00, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Fri, May 22, 2020 at 09:53:07PM +0800, Bin Meng wrote:
> > > > Hi Simon,
> > > >
> > > > On Fri, May 22, 2020 at 9:38 PM Simon Glass <sjg at chromium.org> 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?
> > > > >
> > > >
> > > > Yes, for the example I gave, we can certainly put such information
> > > > into DT config/ node. But this example may not be a good one because
> > > > we cannot just put every Kconfig option into DT.
> >
> > Bin can you suggest an example with lots of variability, that is not
> > suitable for DT?
>
> How about this one?
>
> config BUILD_TARGET
> string "Build target special images"
> default "u-boot-with-spl.sfp" if TARGET_SOCFPGA_ARRIA10
> default "u-boot-with-spl.sfp" if TARGET_SOCFPGA_GEN5
> default "u-boot-spl.kwb" if ARCH_MVEBU && SPL
> default "u-boot-elf.srec" if RCAR_GEN3
> default "u-boot.itb" if SPL_LOAD_FIT && (ARCH_ROCKCHIP || \
> ARCH_SUNXI || RISCV || ARCH_ZYNQMP)
> default "u-boot.kwb" if ARCH_KIRKWOOD
> default "u-boot-with-spl.bin" if ARCH_AT91 && SPL_NAND_SUPPORT
> default "u-boot-with-spl.imx" if ARCH_MX6 && SPL
> help
> Some SoCs need special image types (e.g. U-Boot binary
> with a special header) as build targets. By defining
> CONFIG_BUILD_TARGET in the SoC / board header, this
> special image will be automatically built upon calling
> make / buildman.
>
> It might not be a good example neither :)
>
> But what I really wanted to get some agreement among custodians about
> the style. Which style do we want to go?
I've been encouraging the "put defaults together" style as that I hope
makes the problem scope for "now make handling this cleaner" easier to
see. When something is scattered in N files it's easier to miss what
everyone looks like. As you note, that too might fit well enough into a
/config node or similar type thing instead. It didn't really belong in
include/config/${board}.h (or more often one of the common include files
there) and doesn't quite fit in with Kconfig well either.
--
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/90583437/attachment.sig>
More information about the U-Boot-Custodians
mailing list