The way to use Kconfig in U-Boot
Tom Rini
trini at konsulko.com
Fri May 22 20:37:10 CEST 2020
On Sat, May 23, 2020 at 01:06:19AM +0900, Masahiro Yamada wrote:
> On Sat, May 23, 2020 at 12:39 AM Bin Meng <bmeng.cn at gmail.com> 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 do not see this kind of Kconfig problem in Linux.
> Not in Barebox, either.
It depends on which part of the problem you're talking about.
> So, this is a problem of U-Boot, not of Kconfig.
>
> U-Boot conventionally prefixed all sort of parameters
> with CONFIG_, and put them in header files.
>
> Since Kconfig was introduced,
> we have converted them to Kconfig verbatim
> by using moveconfig tool.
>
>
> We always discuss "how to do it in Kconfig?"
> while they should not be CONFIG options in the first place.
So, this is one of the problem. What do we do about magic
numbers/values. Long ago, U-Boot and Linux both defined things, kept
binaries small and had big re-use problems. While I don't want to
rehash the entirety of the "Hey, this device tree thing Macs use is
neat, lets use this more on not-Macs!" discussion, Linux went that way.
U-Boot is moving that way, but has (very clearly) not fully converted
and hit some of the problem Linux got to just ignore. Neither Barebox
nor Zephyr is able to ignore those problems so yes, taking a look over
there would be a good idea. No one says the way we're handling magic
values like MMC_RAW_... is the best way.
> As for CONFIG_BUILD_TARGET, it is not a CONFIG option.
> It should be done in Makefile somehow.
Yes, that example is about making "all" build what the user expects for
their platform and not stopping at the u-boot has linked stage. That
could / should be cleaned up to N CONFIG_BUILD_TARGET_xxx and since the
"what does the SoC want" choice isn't a user thing, it makes sense to
select the one or more that make sense for a given platform.
> As for CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR,
> we can make it into a platform hook because
> we have a board file for each platform anyway.
>
>
> A board file for arch/arm/mach-sunxi/:
>
> unsigned int mmcsd_raw_mode_u_boot_sector(void)
> {
> return 0x50;
> }
>
>
> A board file for arch/arm/mach-davinci/:
>
> unsigned int mmcsd_raw_mode_u_boot_sector(void)
> {
> return 0x75;
> }
>
>
> Default:
>
> unsigned int __weak mmcsd_raw_mode_u_boot_sector(void)
> {
> return 0;
>
> }
I am a fan of weak functions, Simon is not. But I'm not sure this is an
example where weak functions are better than something like dtoc
generating a file based on having these information be pulled out of DT
files.
What hasn't been mentioned yet but is the 3rd example of where we do
Kconfig entries differently is that we do a lot more "default y if ..."
or "select ..." / "imply ..." under higher level options and for things
that people may want to disable than Linux does. To that, while some
things should probably be "imply" and not "select" but I'm not sure it's
the wrong direction.
It also would be nice to be able to do a board with "some descriptive
file" and "some config file fragment(s)" and get a build, rather than
have to have a defconfig file for each platform. But that I feel needs
a lot more ground work done first just to make trying out something
easier.
--
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/721614a7/attachment-0001.sig>
More information about the U-Boot-Custodians
mailing list