Re: [PATCH 2/6] arm64: dts: qcom: sm6125-xiaomi-ginkgo: Correct reserved memory ranges
From: Konrad Dybcio
Date: Tue Jan 13 2026 - 04:21:36 EST
On 1/13/26 10:14 AM, barnabas.czeman@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxx>
>>> ---
>>> 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