Re: [PATCH v2 1/3] dts: qcs6490-rubikpi3: Add U-Boot dtsi

[Hongyang Zhao <hongyang.zhao@thundersoft.com>]

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 <hongyang.zhao@thundersoft.com>
> > Reviewed-by: Simon Glass <sjg@chromium.org>
> > ---
> >   .../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
> >