[U-Boot] content in a defconfig file versus in a header file -- clarification?

[Chris Packham]

On Tue, 9 Apr 2019, 11:00 PM Robert P. J. Day, <rpjday at crashcourse.ca>
wrote:

>
>   i'm rewriting a bunch of u-boot tutorial pages (publicly available
> if anyone wants to read them), and i want to clarify the proper
> location to put configuration content -- a defconfig file versus a
> header file -- knowing that the trend lately has been to move content
> into defconfig files where appropriate, so some potentially trivial
> questions.
>
>   first, each defconfig file represents the configuration for a
> single, specific target board, so that, in an ideal world, any
> "CONFIG_" Kbuild settings for that board should be placed there,
> correct? the exception would be any content that is in some way common
> across a family of closely-related boards but, other than that,
> configuration "OPTIONS", as defined in the README file, belong in the
> board's defconfig file.
>
>   i ask since, unsurprisingly, there are exceptions. for example,
> CONFIG_ENV_SIZE is a popular config setting, defined in env/Kconfig
> (and other Kconfig files), so one would think that that setting should
> be set in the defconfig files. but for the most part, the majority of
> settings are in the include/configs/*.h header files.
>
>   as a specific example, consider the bubblegum 96 board. its
> defconfig file does not set that Kconfig variable; rather, it's set in
> include/configs/bubblegum_96.h. it still works fine, of course, but
> according to current U-Boot standards, would that properly be in the
> defconfig file? (i have no intention of trying to clean any of that
> up, just wanting to clarify best practices.)
>

Historically u-boot just had include/config/$BOARD.h. This lacked any
mechanism for enforcing consitency, finding existing options or expressing
dependent options, so the Kconfig/Kbuild mechanism used by Linux was
adopted on 2014.10.

Because the world doesn't stop turning it has been necessary to run both
mechanisms in parallel. Over the intervening years many options have been
moved to Kconfig, it truly has been a huge undertaking by the u-boot
community.

Of course the work is not done and we'll see many boards orphaned before
they get fully converted, but I think we're now closer to the end than the
beginning. Some day soon you'll see boards with just a defconfig and dts
file (the latter picking up items from $BOARD.h that describe the hardware).

The direction now is that if one is adding a new feature/driver it goes
into Kconfig. New boards should use things in Kconfig but often require a
$BOARD.h for things that don't have Kconfig support.

See http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.kconfig for a bit
more info.


>   thanks.
>
> rday
>
> p.s. of course settings like that would belong in any "common" header
> file covering multiple boards, such as tegra-common.h, zynq-common.h
> and so on.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>