On May 15, 2024 thus sayeth Andrew Davis:
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-gole@ti.com Signed-off-by: Bryan Brattlof bb@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.
Ah Okay, I'll take a stab at the buildman fix. Also noticed in the logs I didn't add the configs to a MAINTAINERS entry.
~Bryan