Config fragments

[Svyatoslav Ryhel]

пн, 25 вер. 2023 р. о 18:05 Tom Rini <trini at konsulko.com> пише:
>
> On Mon, Sep 25, 2023 at 04:18:45PM +0300, Svyatoslav Ryhel wrote:
> >
> >
> > 23 серпня 2023 р. 18:55:58 GMT+03:00, Tom Rini <trini at konsulko.com> написав(-ла):
> > >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 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.
> > >
> > >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
> > >files).
> > >
> > >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.
> > >
> >
> > Greetings! Are there any progress regards fragments move or this will
> > hang in mailing list indefinitely?
>
> I don't follow, sorry.  Yes, please send a patch on top of next to move
> the fragments for Tegra platforms to match how they're done for TI
> platforms now.
>
> --
> Tom

Oh, so it was merged already into next, sorry did not check the next branch.
Tegra fragments move patch was already sent a month ago alongside
other board improvements, waiting for Thierry now. Thanks!