Hi, On Mon, 25 Sept 2023 at 09:12, Svyatoslav Ryhel <clamo...@gmail.com> wrote: > > пн, 25 вер. 2023 р. о 18:05 Tom Rini <tr...@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 <tr...@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-gerl...@ti.com> > > > >> M: Tom Rini <tr...@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 <n...@ti.com> > > > >> M: Robert Nelson <robertcnel...@gmail.com> > > > >> M: Tom Rini <tr...@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