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.
+ */
+ ramoops@61600000 {
+ compatible = "ramoops";
+ reg = <0x0 0x61600000 0x0 0x400000>;
+ record-size = <0x80000>;
+ pmsg-size = <0x200000>;
+ console-size = <0x100000>;
+ };
};
extcon_usb: extcon-usb {
--
2.52.0
On 12/01/2026 21:13, 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;
> + };
Hello!
I suggest one more nice to have improvement:
you could label framebuffer cont_splash_mem since you already touching
the node and testing the series.
Then in additional commit, you can replace manually defined `reg` in
chosen > framebuffer node with
memory-region = <&cont_splash_mem>;
For example you can look at sdm845-oneplus-common.dtsi
Tell me what u think
David
> +
> + /*
> + * Matching with recovery values
> + * to be able to get the results.
> + */
> + ramoops@61600000 {
> + compatible = "ramoops";
> + reg = <0x0 0x61600000 0x0 0x400000>;
> + record-size = <0x80000>;
> + pmsg-size = <0x200000>;
> + console-size = <0x100000>;
> + };
> };
>
> extcon_usb: extcon-usb {
>
--
David Heidelberg
On 1/14/26 11:15 AM, David Heidelberg wrote:
> On 12/01/2026 21:13, 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>
>> ---
[...]
> Hello!
>
> I suggest one more nice to have improvement:
>
> you could label framebuffer cont_splash_mem since you already touching the node and testing the series.
>
> Then in additional commit, you can replace manually defined `reg` in chosen > framebuffer node with
>
> memory-region = <&cont_splash_mem>;
>
> For example you can look at sdm845-oneplus-common.dtsi
>
> Tell me what u think
If you wanna do that, please call it framebuffer_mem, "cont_splash" is a
Qualcomm-specific name for (roughly) flicker-free bootup
Konrad
On 14/01/2026 11:28, Konrad Dybcio wrote:
> On 1/14/26 11:15 AM, David Heidelberg wrote:
>> On 12/01/2026 21:13, 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>
>>> ---
>
> [...]
>
>> Hello!
>>
>> I suggest one more nice to have improvement:
>>
>> you could label framebuffer cont_splash_mem since you already touching the node and testing the series.
>>
>> Then in additional commit, you can replace manually defined `reg` in chosen > framebuffer node with
>>
>> memory-region = <&cont_splash_mem>;
>>
>> For example you can look at sdm845-oneplus-common.dtsi
>>
>> Tell me what u think
>
> If you wanna do that, please call it framebuffer_mem, "cont_splash" is a
> Qualcomm-specific name for (roughly) flicker-free bootup
I have feeling someone recommended me to stick with cont_splash_mem.
I think, since we'll be doing the mdss reset anyway in sdm845 (which I
used as an example), I can do the rename in our sdm845 too then without
any harm? (no it's not flicker-free takeover :D )
David
>
> Konrad
--
David Heidelberg
On 1/14/26 10:55 PM, David Heidelberg wrote:
> On 14/01/2026 11:28, Konrad Dybcio wrote:
>> On 1/14/26 11:15 AM, David Heidelberg wrote:
>>> On 12/01/2026 21:13, 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>
>>>> ---
>>
>> [...]
>>
>>> Hello!
>>>
>>> I suggest one more nice to have improvement:
>>>
>>> you could label framebuffer cont_splash_mem since you already touching the node and testing the series.
>>>
>>> Then in additional commit, you can replace manually defined `reg` in chosen > framebuffer node with
>>>
>>> memory-region = <&cont_splash_mem>;
>>>
>>> For example you can look at sdm845-oneplus-common.dtsi
>>>
>>> Tell me what u think
>>
>> If you wanna do that, please call it framebuffer_mem, "cont_splash" is a
>> Qualcomm-specific name for (roughly) flicker-free bootup
>
> I have feeling someone recommended me to stick with cont_splash_mem.
>
> I think, since we'll be doing the mdss reset anyway in sdm845 (which I used as an example), I can do the rename in our sdm845 too then without any harm? (no it's not flicker-free takeover :D )
It's not flicker-free because the OS must cooperate in that process,
whereas we currently reset and re-initialize the entire display subsystem
Konrad
On 16/01/2026 10:52, Konrad Dybcio wrote:
> On 1/14/26 10:55 PM, David Heidelberg wrote:
>> On 14/01/2026 11:28, Konrad Dybcio wrote:
>>> On 1/14/26 11:15 AM, David Heidelberg wrote:
>>>> On 12/01/2026 21:13, 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>
>>>>> ---
>>>
>>> [...]
>>>
>>>> Hello!
>>>>
>>>> I suggest one more nice to have improvement:
>>>>
>>>> you could label framebuffer cont_splash_mem since you already touching the node and testing the series.
>>>>
>>>> Then in additional commit, you can replace manually defined `reg` in chosen > framebuffer node with
>>>>
>>>> memory-region = <&cont_splash_mem>;
>>>>
>>>> For example you can look at sdm845-oneplus-common.dtsi
>>>>
>>>> Tell me what u think
>>>
>>> If you wanna do that, please call it framebuffer_mem, "cont_splash" is a
>>> Qualcomm-specific name for (roughly) flicker-free bootup
>>
>> I have feeling someone recommended me to stick with cont_splash_mem.
>>
>> I think, since we'll be doing the mdss reset anyway in sdm845 (which I used as an example), I can do the rename in our sdm845 too then without any harm? (no it's not flicker-free takeover :D )
>
> It's not flicker-free because the OS must cooperate in that process,
> whereas we currently reset and re-initialize the entire display subsystem
Sure.
Previously I was thinking, that after doing proper panel driver with
proper initialization sequences etc. etc., we could have device-tree
property such as "linux,takeover-from-bootloader", where we could skip
mdss reset, panel reset and just continue from the point what bootloader
set (for devices where bootloader does the right job).
David
>
> Konrad
--
David Heidelberg
On 1/16/26 12:21 PM, David Heidelberg wrote:
> On 16/01/2026 10:52, Konrad Dybcio wrote:
>> On 1/14/26 10:55 PM, David Heidelberg wrote:
>>> On 14/01/2026 11:28, Konrad Dybcio wrote:
>>>> On 1/14/26 11:15 AM, David Heidelberg wrote:
>>>>> On 12/01/2026 21:13, 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>
>>>>>> ---
>>>>
>>>> [...]
>>>>
>>>>> Hello!
>>>>>
>>>>> I suggest one more nice to have improvement:
>>>>>
>>>>> you could label framebuffer cont_splash_mem since you already touching the node and testing the series.
>>>>>
>>>>> Then in additional commit, you can replace manually defined `reg` in chosen > framebuffer node with
>>>>>
>>>>> memory-region = <&cont_splash_mem>;
>>>>>
>>>>> For example you can look at sdm845-oneplus-common.dtsi
>>>>>
>>>>> Tell me what u think
>>>>
>>>> If you wanna do that, please call it framebuffer_mem, "cont_splash" is a
>>>> Qualcomm-specific name for (roughly) flicker-free bootup
>>>
>>> I have feeling someone recommended me to stick with cont_splash_mem.
>>>
>>> I think, since we'll be doing the mdss reset anyway in sdm845 (which I used as an example), I can do the rename in our sdm845 too then without any harm? (no it's not flicker-free takeover :D )
>>
>> It's not flicker-free because the OS must cooperate in that process,
>> whereas we currently reset and re-initialize the entire display subsystem
>
> Sure.
>
> Previously I was thinking, that after doing proper panel driver with proper initialization sequences etc. etc., we could have device-tree property such as "linux,takeover-from-bootloader", where we could skip mdss reset, panel reset and just continue from the point what bootloader set (for devices where bootloader does the right job).
I don't think there's a need for a separate property. Once MDSS is
powered on, various registers could be read back and the state could be
largely inferred from there.
It just comes with an infinite amount of edge cases and it's not top
priority for now, I don't think
Konrad
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?
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
Konrad
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
On 1/13/26 10:14 AM, barnabas.czeman@mainlining.org wrote:
> 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.
Ok, no worries then
Konrad
© 2016 - 2026 Red Hat, Inc.