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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <dd141d65b3ee1c9e1f3148bccee6e964@mainlining.org>
Date: Tue, 13 Jan 2026 10:14:06 +0100
From: barnabas.czeman@...nlining.org
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Bjorn Andersson <andersson@...nel.org>, Konrad Dybcio
 <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Gabriel Gonzales
 <semfault@...root.org>, Kees Cook <kees@...nel.org>, Tony Luck
 <tony.luck@...el.com>, "Guilherme G. Piccoli" <gpiccoli@...lia.com>,
 Biswapriyo Nath <nathbappai@...il.com>, linux-arm-msm@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-hardening@...r.kernel.org, phone-devel@...r.kernel.org,
 ~postmarketos/upstreaming@...ts.sr.ht, linux@...nlining.org
Subject: Re: [PATCH 2/6] arm64: dts: qcom: sm6125-xiaomi-ginkgo: Correct
 reserved memory ranges

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@...nlining.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@...00000 {
>>  	};
>> 
>>  	reserved-memory {
>> -		debug_mem: debug@...00000 {
>> -			reg = <0x0 0xffb00000 0x0 0xc0000>;
>> +		adsp_pil_mem: adsp_pil_mem@...00000 {
>> +			reg = <0x0 0x55300000 0x0 0x2200000>;
>>  			no-map;
>>  		};
>> 
>> -		last_log_mem: lastlog@...c0000 {
>> -			reg = <0x0 0xffbc0000 0x0 0x80000>;
>> +		ipa_fw_mem: ipa_fw_mem@...00000 {
>> +			reg = <0x0 0x57500000 0x0 0x10000>;
>>  			no-map;
>>  		};
>> 
>> -		pstore_mem: ramoops@...00000 {
>> -			compatible = "ramoops";
>> -			reg = <0x0 0xffc40000 0x0 0xc0000>;
>> -			record-size = <0x1000>;
>> -			console-size = <0x40000>;
>> -			pmsg-size = <0x20000>;
>> +		ipa_gsi_mem: ipa_gsi_mem@...10000 {
>> +			reg = <0x0 0x57510000 0x0 0x5000>;
>> +			no-map;
>>  		};
>> 
>> -		cmdline_mem: memory@...00000 {
>> -			reg = <0x0 0xffd40000 0x0 0x1000>;
>> +		gpu_mem: gpu_mem@...15000 {
>> +			reg = <0x0 0x57515000 0x0 0x2000>;
>>  			no-map;
>>  		};
>> +
>> +		framebuffer@...00000 {
>> +			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@...00000 {
>> +			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