On 5/15/24 1:21 PM, Tom Rini wrote:
On Fri, May 03, 2024 at 11:44:29AM -0500, Bryan Brattlof wrote:
The am62x-lp-sk is a package and reference board spin of the am62x-sk to
showcase the low-power features of the am62x SoC family. Because it so
closely resembles the am62x-sk board, use the preprocessor to inherit
its configuration making the needed changes for this board where
necessary.
Reviewed-by: Dhruva Gole <d-g...@ti.com>
Signed-off-by: Bryan Brattlof <b...@ti.com>
---
configs/am62x_lp_sk_a53_defconfig | 3 +++
configs/am62x_lp_sk_r5_defconfig | 2 ++
2 files changed, 5 insertions(+)
diff --git a/configs/am62x_lp_sk_a53_defconfig
b/configs/am62x_lp_sk_a53_defconfig
new file mode 100644
index 0000000000000..904b2142b2f53
--- /dev/null
+++ b/configs/am62x_lp_sk_a53_defconfig
@@ -0,0 +1,3 @@
+#include <configs/am62x_evm_a53_defconfig>
+CONFIG_DEFAULT_DEVICE_TREE="ti/k3-am62-lp-sk"
+CONFIG_OF_UPSTREAM=y
So, there's a problem here. The #include trick for defconfig files isn't
working as intended, exactly. The example here doesn't work right.
First, it shows up as a variant of "sandbox" (as buildman will show and
leads to https://source.denx.de/u-boot/u-boot/-/jobs/835067#L119)
And this becomes clearer if you look at configs/am69_sk_r5_defconfig
which has to set some symbols already found in
configs/j784s4_evm_r5_defconfig in order to work. This is seemingly very
not equivalent to invoking "make foo_defconfig bar.config" to combine
things.
This is equivalent when running make. The issue is with buildman which
manually checks the content of the defconfig to find what ARCH it should
run the defconfig with. buildman doesn't understand the #include yet.
Until buildman can be fixed, you'll need to do what we did with
am69_sk_r5_defconfig and redefine the ARCH/SOC/TARGET info in the
defconfig file so buildman can find it without following the #include.
Andrew
