Hiya,
Thanks for respinning this!
On 6/24/26 14:45, Hongyang Zhao wrote:
Add the board-specific U-Boot device tree overrides for the
Thundercomm RUBIK Pi 3.
When U-Boot is loaded as the primary bootloader, no previous stage
provides the memory layout. Describe the 8 GiB LPDDR4x layout locally
so U-Boot can use the available DRAM.
I'm hoping we can skip this patch, since we now support retrieving the
memory map dynamically from SMEM. I'd appreciate it if you could do a
clean build of the qcom-next branch here and see if it works without this.
https://source.denx.de/u-boot/custodians/u-boot-snapdragon
You also shouldn't need to use qtestsign as MBN support was also just
picked so u-boot.mbn should be built directly.
I used the Rubik Pi for testing both series locally so crossing my
fingers you don't run into any issues.
Thanks,
// Casey
Signed-off-by: Hongyang Zhao <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
---
.../arm/dts/qcs6490-thundercomm-rubikpi3-u-boot.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/dts/qcs6490-thundercomm-rubikpi3-u-boot.dtsi
b/arch/arm/dts/qcs6490-thundercomm-rubikpi3-u-boot.dtsi
new file mode 100644
index 00000000000..8518cd402d0
--- /dev/null
+++ b/arch/arm/dts/qcs6490-thundercomm-rubikpi3-u-boot.dtsi
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/ {
+ /*
+ * When running as the primary bootloader there is no prior stage to
+ * populate the memory layout for us. We should have multiple nodes
+ * here, but ABL does not like that.
+ */
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0 0x80000000 0 0x39700000>,
+ <0 0xc0000000 0 0x01800000>,
+ <0 0xc3400000 0 0xbcc00000>,
+ <1 0x80000000 1 0x00000000>;
+ };
+};
+
+// RAM Entry 0 : Base 0x0080000000 Size 0x0039700000
+// RAM Entry 1 : Base 0x00C0000000 Size 0x0001800000
+// RAM Entry 2 : Base 0x00C3400000 Size 0x00BCC00000
+// RAM Entry 3 : Base 0x0180000000 Size 0x0100000000
