Hi Casey, Thanks for the review.
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 > I tested the qcom-next branch on RUBIK Pi 3 without this U-Boot dtsi patch. The board boots successfully with the generated u-boot.mbn, and Linux starts via U-Boot EFI. The memory map also looks correct; Linux reports the memory range from 0x80000000 to 0x27fffffff, matching the 8 GiB layout. So the SMEM-based dynamic memory map works fine on RUBIK Pi 3. I will drop this dtsi patch in v3, and also update the documentation to use the directly generated u-boot.mbn instead of qtestsign. Thanks, Hongyang > > > > > 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 > >
