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.
Let's simply try to avoid these combinatorial problems by avoiding adding
too many fragments that apply broadly. That adds testing burden. When features
need added/removed, folks can use menuconfig or similar. We shouldn't need a
defconfig fragment for DFU..
Andrew
