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

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

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