Config fragments

Svyatoslav Ryhel clamor95 at
Wed Aug 23 18:01:55 CEST 2023

23 серпня 2023 р. 18:55:58 GMT+03:00, Tom Rini <trini at> написав(-ла):
>On Wed, Aug 23, 2023 at 09:30:31AM -0600, 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.
>I'm adding Svyatoslav who is the person that brought in all of the
>config fragments that are going to be in v2023.07.
>> 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
>They aren't random.  They're, just for v2023.07, in configs/ and then
>moving forward, they're in the board directory.  I would like to see
>them in more places possibly, but that's not something I'm sure enough
>on right now.
>> board/ti/am62x/MAINTAINERS:
>> AM62x BOARD
>> M: Dave Gerlach <d-gerlach at>
>> M: Tom Rini <trini at>
>> S: Maintained
>> F: board/ti/am62x/
>> F: include/configs/am62x_evm.h
>> F: configs/am62x_evm_r5_defconfig
>> F: configs/am62x_evm_a53_defconfig
>> M:     Nishanth Menon <nm at>
>> M:     Robert Nelson <robertcnelson at>
>> M:     Tom Rini <trini at>
>> 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.
>Note that the "N" syntax has been in use, for defconfigs for a lot
>longer, and is why the CI check for unmaintained / orphaned boards
>stopped working.
>> *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?
>I'm not sure I like this direction honestly.  Do we want CI to cover
>these configurations?  Maybe.  But it's just for CI.  Using the TI
>examples, I don't know that you can use buildman today to generate a
>functional binary (and if you can, if --keep will retain the right
>Maybe we just need to make it clear that if you use config fragments
>then you're opting out of CI for that specific platform.  That should be
>fine for example for the TI ones that will be built in OE a bunch
>anyhow so accidental failure to builds will be caught.  I don't know
>about the Tegra platforms.

Thanks! Only 3 recently merged Tegra boards actually have config fragments (transformer, grouper and x3). ATM all common defconfigs are designed to be self sufficient and pass buildman even without fragment call.

More information about the U-Boot mailing list