On 09. 04. 19 13:00, Robert P. J. Day wrote:

i'm rewriting a bunch of u-boot tutorial pages (publicly available if anyone wants to read them),

Would be easier to put link here that others can take a look and review.

Thanks, Michal

On Tue, 9 Apr 2019, 11:00 PM Robert P. J. Day, rpjday@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@lists.denx.de https://lists.denx.de/listinfo/u-boot