Config fragments

[Simon Glass]

Hi,

On Mon, 25 Sept 2023 at 09:12, Svyatoslav Ryhel <clamor95 at gmail.com> wrote:
>
> пн, 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!

Re dealing with fragments, we have a proposal as above, but I have not
seen any other comments.

I believe this needs to be figured out soon.

Regards,
Simon