Re: [PATCH 2/6] arm64: dts: qcom: sm6125-xiaomi-ginkgo: Correct reserved memory ranges

[barnabas.czeman@mainlining.org]

On 2026-01-13 09:53, Konrad Dybcio wrote:
> On 1/12/26 9:13 PM, Barnabás Czémán wrote:
>> The device was crashing on high memory load because the reserved 
>> memory
>> ranges was wrongly defined. Correct the ranges for avoid the crashes.
>> Change the ramoops memory range to match with the values from the 
>> recovery
>> to be able to get the results from the device.
>> 
>> Fixes: 9b1a6c925c88 ("arm64: dts: qcom: sm6125: Initial support for 
>> xiaomi-ginkgo")
>> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
>> ---
>>  arch/arm64/boot/dts/qcom/sm6125-xiaomi-ginkgo.dts | 44 
>> ++++++++++++++++-------
>>  1 file changed, 32 insertions(+), 12 deletions(-)
>> 
>> diff --git a/arch/arm64/boot/dts/qcom/sm6125-xiaomi-ginkgo.dts 
>> b/arch/arm64/boot/dts/qcom/sm6125-xiaomi-ginkgo.dts
>> index bf03226a6f85..4c548cb5f253 100644
>> --- a/arch/arm64/boot/dts/qcom/sm6125-xiaomi-ginkgo.dts
>> +++ b/arch/arm64/boot/dts/qcom/sm6125-xiaomi-ginkgo.dts
>> @@ -13,6 +13,12 @@
>>  #include "sm6125.dtsi"
>>  #include "pm6125.dtsi"
>> 
>> +/delete-node/ &adsp_pil_mem;
>> +/delete-node/ &cont_splash_mem;
>> +/delete-node/ &gpu_mem;
>> +/delete-node/ &ipa_fw_mem;
>> +/delete-node/ &ipa_gsi_mem;
>> +
>>  / {
>>  	model = "Xiaomi Redmi Note 8";
>>  	compatible = "xiaomi,ginkgo", "qcom,sm6125";
>> @@ -36,28 +42,42 @@ framebuffer0: framebuffer@5c000000 {
>>  	};
>> 
>>  	reserved-memory {
>> -		debug_mem: debug@ffb00000 {
>> -			reg = <0x0 0xffb00000 0x0 0xc0000>;
>> +		adsp_pil_mem: adsp_pil_mem@55300000 {
>> +			reg = <0x0 0x55300000 0x0 0x2200000>;
>>  			no-map;
>>  		};
>> 
>> -		last_log_mem: lastlog@ffbc0000 {
>> -			reg = <0x0 0xffbc0000 0x0 0x80000>;
>> +		ipa_fw_mem: ipa_fw_mem@57500000 {
>> +			reg = <0x0 0x57500000 0x0 0x10000>;
>>  			no-map;
>>  		};
>> 
>> -		pstore_mem: ramoops@ffc00000 {
>> -			compatible = "ramoops";
>> -			reg = <0x0 0xffc40000 0x0 0xc0000>;
>> -			record-size = <0x1000>;
>> -			console-size = <0x40000>;
>> -			pmsg-size = <0x20000>;
>> +		ipa_gsi_mem: ipa_gsi_mem@57510000 {
>> +			reg = <0x0 0x57510000 0x0 0x5000>;
>> +			no-map;
>>  		};
>> 
>> -		cmdline_mem: memory@ffd00000 {
>> -			reg = <0x0 0xffd40000 0x0 0x1000>;
>> +		gpu_mem: gpu_mem@57515000 {
>> +			reg = <0x0 0x57515000 0x0 0x2000>;
>>  			no-map;
>>  		};
>> +
>> +		framebuffer@5c000000 {
>> +			reg = <0x0 0x5c000000 0x0 (2340 * 1080 * 4)>;
>> +			no-map;
>> +		};
>> +
>> +		/*
>> +		 * Matching with recovery values
>> +		 * to be able to get the results.
>> +		 */
> 
> /* This is an unnecessarily
>  * squashed comment that could
>  * easily go into a single line
>  */
> 
> 
>> +		ramoops@61600000 {
>> +			compatible = "ramoops";
>> +			reg = <0x0 0x61600000 0x0 0x400000>;
>> +			record-size = <0x80000>;
>> +			pmsg-size = <0x200000>;
>> +			console-size = <0x100000>;
> 
> Does your recovery image not specify ecc-size?
No.
> 
> In my past experience, that led to much better results wrt the data
> being actually readable.. you might want to rebuild your recovery (or
> at least the dt and repack the boot.img) for that
I would not because i have got good results with this settings and
users could use already built recoveries to get the result.
> 
> Konrad