On 8/30/23 9:59 AM, Nishanth Menon wrote:
On 09:31-20230830, Andrew Davis wrote:
On 8/30/23 7:31 AM, Nishanth Menon wrote:
On 17:14-20230829, Andrew Davis wrote:
Add am62x_beagleplay_r5_defconfig for R5 SPL and
am62x_beagleplay_a53_defconfig for A53 SPL and U-Boot support.
These defconfigs are composite defconfigs built from the config fragment
board/ti/am62x/beagleplay_*.config applied onto the base
am62x_evm_*_defconfig.
Signed-off-by: Andrew Davis <a...@ti.com>
---
configs/am62x_beagleplay_a53_defconfig | 3 +++
configs/am62x_beagleplay_r5_defconfig | 3 +++
2 files changed, 6 insertions(+)
create mode 100644 configs/am62x_beagleplay_a53_defconfig
create mode 100644 configs/am62x_beagleplay_r5_defconfig
diff --git a/configs/am62x_beagleplay_a53_defconfig
b/configs/am62x_beagleplay_a53_defconfig
new file mode 100644
index 00000000000..ad708e15397
--- /dev/null
+++ b/configs/am62x_beagleplay_a53_defconfig
@@ -0,0 +1,3 @@
+// The BeaglePlay defconfig for A53 core
+#include "configs/am62x_evm_a53_defconfig"
+#include "board/ti/am62x/beagleplay_a53.config"
diff --git a/configs/am62x_beagleplay_r5_defconfig
b/configs/am62x_beagleplay_r5_defconfig
new file mode 100644
index 00000000000..276b1f81a3e
--- /dev/null
+++ b/configs/am62x_beagleplay_r5_defconfig
@@ -0,0 +1,3 @@
+// The BeaglePlay defconfig for R5 core
+#include "configs/am62x_evm_r5_defconfig"
+#include "board/ti/am62x/beagleplay_r5.config"
--
2.39.2
my only complaint is that if we add lets say
board/ti/am62x/dfu.config, Then:
R5:
1. am62x_evm_r5_defconfig = am62x_evm_r5_defconfig
2. am62x_beagleplay_r5_defconfig = am62x_evm_r5_defconfig + beagleplay_r5.config
3. am62x_evm_r5_dfu_defconfig = am62x_evm_r5_defconfig + dfu.config
4. am62x_beagleplay_r5_dfu_defconfig = am62x_evm_r5_defconfig +
beagleplay_r5.config + dfu.config
This information can be in a single txt file Rather than have a
defconfig file for each combination.
Having every combination in a text file vs in a directory of files doesn't
seem like much difference to me. `cat combinations.txt` vs `ls -l configs/`.
But using a file would mean extra tooling and non-standard usage.
The .config usage is a standard already in kernel - nothing new there.
What we are attempting to solve is CI build coverage and test aspect of
things.
Exactly, when I say "standard" I mean CI standard, which is to take all
the configs/* and build them. No parsing these new combination files needed.
Just add a new configs/xx_defconfig for a combination you want to be
CI tested and you are done.
Thinking aloud here:
some sort of board/<vendor>/<board>/ci.conf yaml could probably be a better
approach with description of build, automated test information,
potentially board revisions etc.
Let's simply try to avoid these combinatorial problems by avoiding adding
too many fragments that apply broadly. That adds testing burden. When features
The combinations will be valid since the intent is a supported
configuration.
In theory anything you do in menuconfig should result in a valid configuration
(if we have our kconfig symbol dependencies in order). And randomconfig testing
can handle that. The combinations we want always tested should be limited, and
making each have a dedicated configs/ file does that.
Andrew
