Config fragments

[Andrew Davis]

On 8/23/23 10:30 AM, Simon Glass wrote:
> Hi,
> 
> Up until 2023.04 it has been possible to build all the defconfigs but
> with 2023.07 that changed. Tom mentioned this to me recently.
> 
> Up until 2023.04 we can enumerate all the board configs that can be
> built. We can build any of them using a single name and a single
> defconfig. The boards.cfg file which buildman creates contains a full
> list of things that can be built.
> 
>  From 2023.07 this changes and we now have random .config files
> sprinkled about the place. I say random because they are not connected
> to anything. For example, here is
> board/ti/am62x/MAINTAINERS:
> 
> AM62x BOARD
> M: Dave Gerlach <d-gerlach at ti.com>
> M: Tom Rini <trini at konsulko.com>
> S: Maintained
> F: board/ti/am62x/
> F: include/configs/am62x_evm.h
> F: configs/am62x_evm_r5_defconfig
> F: configs/am62x_evm_a53_defconfig
> 
> BEAGLEPLAY BOARD
> M:     Nishanth Menon <nm at ti.com>
> M:     Robert Nelson <robertcnelson at gmail.com>
> M:     Tom Rini <trini at konsulko.com>
> S:     Maintained
> N:     beagleplay
> 
> In most cases the MAINTAINERS file tells us about each board and until
> [1] I had assumed that was the case. With that patch reverted, these
> are the only 'orphaned' MAINTAINERS entries (buildman
> --maintainer-check):
> 
> WARNING: orphaned defconfig in board/armltd/vexpress64/MAINTAINERS
> ending at line 8
> WARNING: orphaned defconfig in board/google/veyron/MAINTAINERS ending at line 44
> WARNING: orphaned defconfig in
> board/mikrotik/crs3xx-98dx3236/MAINTAINERS ending at line 7
> WARNING: orphaned defconfig in board/st/common/MAINTAINERS ending at line 6
> WARNING: orphaned defconfig in board/ti/am62x/MAINTAINERS ending at line 15
> 
> But Tom advised me that MAINTAINERS is not intended for this purpose,
> so the check has been dropped. I am not suggesting we bring it back,
> necessarily, but if we did, we could use it to specify the .config and
> defconfig files which are used by each board.
> 
> *Failing that*, I suggest a new 'name.brd' file in the board directory
> to contain this information, e.g.
> 
> # Contents of board/ti/am62x/beagleplay.brd:
> beagleplay-r5: am62x_evm_r5_defconfig beagleplay_r5.config
> beagleplay-a53: am62x_evm_a53_defconfig beagleplay_a53.config
> 
> This could be parsed by buildman and other tools, to produce a list of
> available boards and to build each using a single name (e.g. make
> beagleplay-r5_defconfig)
> 
> What do people think?
> 

How about instead of needing this new 'name.brd' files, we look into
"include" directives inside these configs? So we could have a file:

beagleplay_r5_defconfig

in the normal configs/ directory, but with the contents:

#include "configs/am62x_evm_r5_defconfig"

CONFIG_DEFAULT_DEVICE_TREE="k3-am625-beagleplay"
CONFIG_OF_LIST="k3-am625-beagleplay"
...

The # is already a comment line so these should be safe
for existing tools, and then we have in our Makefile
an automatic pass through the C preprocessor.

Some boards have can build with and without the fragments,
so to have complete CI coverage, we have dummy defconfigs
that have both the base and a fragment include:

#include "configs/am62x_evm_r5_defconfig"
#include "board/ti/am62x/high_security.config"

Something like that, then as Heinrich mentioned, simply
enumerating configs/*defconfig should yield all valid
combinations for building/testing.

Andrew

> Regards,
> Simon
> 
> [1] https://patchwork.ozlabs.org/project/uboot/patch/20230803185144.1760729-2-sjg@chromium.org/