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@ti.com M: Tom Rini trini@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@ti.com M: Robert Nelson robertcnelson@gmail.com M: Tom Rini trini@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?
Regards, Simon
[1] https://patchwork.ozlabs.org/project/uboot/patch/20230803185144.1760729-2-sj...
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@ti.com M: Tom Rini trini@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@ti.com M: Robert Nelson robertcnelson@gmail.com M: Tom Rini trini@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.
23 серпня 2023 р. 18:55:58 GMT+03:00, Tom Rini trini@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@ti.com M: Tom Rini trini@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@ti.com M: Robert Nelson robertcnelson@gmail.com M: Tom Rini trini@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.
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.
On Wed, Aug 23, 2023 at 11:55:58AM -0400, Tom Rini wrote:
[snip]
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).
This specific point is wrong (export BINMAN_INDIRS/BL31/TEE, buildman is fine) but instead has me down a side-track of what the heck we're doing/not doing without --keep-outputs right now.
23 серпня 2023 р. 18:55:58 GMT+03:00, Tom Rini trini@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@ti.com M: Tom Rini trini@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@ti.com M: Robert Nelson robertcnelson@gmail.com M: Tom Rini trini@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?
Best regards, Svyatoslav R.
On Mon, Sep 25, 2023 at 04:18:45PM +0300, Svyatoslav Ryhel wrote:
23 серпня 2023 р. 18:55:58 GMT+03:00, Tom Rini trini@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@ti.com M: Tom Rini trini@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@ti.com M: Robert Nelson robertcnelson@gmail.com M: Tom Rini trini@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.
пн, 25 вер. 2023 р. о 18:05 Tom Rini trini@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@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@ti.com M: Tom Rini trini@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@ti.com M: Robert Nelson robertcnelson@gmail.com M: Tom Rini trini@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!
Hi,
On Mon, 25 Sept 2023 at 09:12, Svyatoslav Ryhel clamor95@gmail.com wrote:
пн, 25 вер. 2023 р. о 18:05 Tom Rini trini@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@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@ti.com M: Tom Rini trini@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@ti.com M: Robert Nelson robertcnelson@gmail.com M: Tom Rini trini@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
On 23.08.23 17:30, 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.
Could you, please, explain why there are defconfig that can't be built. The CI should have thrown an error in this case.
Why don't we delete defconfigs that don't build?
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@ti.com M: Tom Rini trini@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@ti.com M: Robert Nelson robertcnelson@gmail.com M: Tom Rini trini@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
Why should we care about the maintainer status when building a defconfig?
But Tom advised me that MAINTAINERS is not intended for this purpose,
Enumerating configs/*defconfig would make more sense to me.
Best regards
Heinrich
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?
Regards, Simon
[1] https://patchwork.ozlabs.org/project/uboot/patch/20230803185144.1760729-2-sj...
On Wed, Aug 23, 2023 at 05:57:13PM +0200, Heinrich Schuchardt wrote:
On 23.08.23 17:30, 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.
Could you, please, explain why there are defconfig that can't be built. The CI should have thrown an error in this case.
Why don't we delete defconfigs that don't build?
What Simon is noting is that all of the defconfigs in configs/ are a subset of all of the valid configurations of boards.
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@ti.com M: Tom Rini trini@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@ti.com M: Robert Nelson robertcnelson@gmail.com M: Tom Rini trini@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
Why should we care about the maintainer status when building a defconfig?
We care, for the currently disabled CI check, that all boards have a listed maintainer. This is disabled as it was broken by commit e8da1da82f1e ("buildman: Handle the MAINTAINERS 'N' tag") but only recently noticed.
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@ti.com M: Tom Rini trini@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@ti.com M: Robert Nelson robertcnelson@gmail.com M: Tom Rini trini@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-sj...
Hi Andrew,
On Wed, 23 Aug 2023 at 10:44, Andrew Davis afd@ti.com wrote:
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@ti.com M: Tom Rini trini@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@ti.com M: Robert Nelson robertcnelson@gmail.com M: Tom Rini trini@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.
I do agree it would be nice to have this information in the file it relates to. But wouldn't that involve changing kconf and other tools? What tools will parse those files? We really want 'make xxx_defconfig' to work for these new 'combined config' boards and my understanding is that kconf is used here.
Your proposal certainly allows each 'combined config' to have a name - it is just the filename of the defconfig file.
Any ideas?
Regards, Simon
On 8/29/23 11:47 AM, Simon Glass wrote:
Hi Andrew,
On Wed, 23 Aug 2023 at 10:44, Andrew Davis afd@ti.com wrote:
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@ti.com M: Tom Rini trini@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@ti.com M: Robert Nelson robertcnelson@gmail.com M: Tom Rini trini@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.
I do agree it would be nice to have this information in the file it relates to. But wouldn't that involve changing kconf and other tools? What tools will parse those files? We really want 'make xxx_defconfig' to work for these new 'combined config' boards and my understanding is that kconf is used here.
The U-Boot Makefile passes the provided xxx_defconfig into the kconfig scripts. All I'm suggesting is to have that Makefile run the passed in defconfig through the C preprocessor before handing it off to kconfig.
For existing defconfigs the preprocessor will make no changes to the file. For the config fragments, the `#include` lines will be substituted with the contents, the result will be a normal defconfig file that can then also be passed into kconfig.
No changes to kconfig scripts, or anything other than the Makefile, are needed.
Your proposal certainly allows each 'combined config' to have a name - it is just the filename of the defconfig file.
Exactly, this keeps all current CI tooling/flows the exact same.
Andrew
Any ideas?
Regards, Simon
Hi Andrew,
On Tue, 29 Aug 2023 at 11:05, Andrew Davis afd@ti.com wrote:
On 8/29/23 11:47 AM, Simon Glass wrote:
Hi Andrew,
On Wed, 23 Aug 2023 at 10:44, Andrew Davis afd@ti.com wrote:
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@ti.com M: Tom Rini trini@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@ti.com M: Robert Nelson robertcnelson@gmail.com M: Tom Rini trini@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.
I do agree it would be nice to have this information in the file it relates to. But wouldn't that involve changing kconf and other tools? What tools will parse those files? We really want 'make xxx_defconfig' to work for these new 'combined config' boards and my understanding is that kconf is used here.
The U-Boot Makefile passes the provided xxx_defconfig into the kconfig scripts. All I'm suggesting is to have that Makefile run the passed in defconfig through the C preprocessor before handing it off to kconfig.
Could you take a look to see how hard that would be?
For existing defconfigs the preprocessor will make no changes to the file. For the config fragments, the `#include` lines will be substituted with the contents, the result will be a normal defconfig file that can then also be passed into kconfig.
OK
No changes to kconfig scripts, or anything other than the Makefile, are needed.
Your proposal certainly allows each 'combined config' to have a name - it is just the filename of the defconfig file.
Exactly, this keeps all current CI tooling/flows the exact same.
Indeed.
Regards, SImon
participants (5)
-
Andrew Davis -
Heinrich Schuchardt -
Simon Glass -
Svyatoslav Ryhel -
Tom Rini