Re: [PATCH v9 11/11] arm64: dts: renesas: add support for solidrun rzg2ul som on hb-ripple

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dts: invalid physical memory addresses in reserved-memory nodes for 512MB RAM variant
--

commit 92cda0c205abe05e3b0184f1c8a5222e1d09b1d4
Author: Josua Mayer <josua@solid-run.com>

arm64: dts: renesas: add support for solidrun rzg2ul som on hb-ripple

This commit adds device tree support for the SolidRun RZ/G2UL SoM on the
HummingBoard Ripple baseboard. It introduces the new board dts, overlay
files for LEDs, and the shared SoM dtsi.

> diff --git a/arch/arm64/boot/dts/renesas/rzg2ul-sr-som.dtsi b/arch/arm64/boot/dts/renesas/rzg2ul-sr-som.dtsi
> new file mode 100644
> index 0000000000000..c629688189270
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/rzg2ul-sr-som.dtsi
> @@ -0,0 +1,437 @@
[ ... ]
> +	memory@48000000 {
> +		/*
> +		 * Physical RAM starts at 0x40000000, but Renesas RZ/G2 BSPs
> +		 * reserve and hide the first 128MB for TrustZone by default.
> +		 *
> +		 * Minimum size for this SoM is 512MB, and the bootloader patches
> +		 * the dtb according to the actual RAM size and reservations.
> +		 */
> +		reg = <0x0 0x48000000 0x0 0x18000000>;
> +		device_type = "memory";
> +	};
[ ... ]
> +	reserved-memory {
> +		ranges;
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +
> +		global_cma: linux,cma@58000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x0 0x58000000 0x0 0x10000000>;
> +			reusable;
> +			linux,cma-default;
> +		};
> +
> +		mmp_reserved: linux,multimedia@68000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x0 0x68000000 0x0 0x8000000>;
> +			reusable;
> +		};
> +	};

[Severity: High]
Will these reserved-memory regions cause boot failures on the 512MB SoM
variant?

The memory node defined above sets usable physical RAM starting at 0x48000000
with a size of 0x18000000 (384MB), meaning the physical RAM ends at 0x60000000.

However, the global_cma region extends up to 0x68000000 (exceeding RAM by
128MB), and mmp_reserved starts at 0x68000000, placing it entirely outside of
the defined physical memory bounds.

Additionally, the combined size of these regions (256MB + 128MB = 384MB)
would consume 100% of the usable memory on the 512MB variant. Could these
allocations be scaled or dynamically assigned based on the RAM size to avoid
memory initialization errors?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-rzg2-sr-boards-v9-0-5901e0fc9e44@solid-run.com?part=11