linux-kernel - Re: [PATCH V2 3/3] arm64: dts: qcom: ipq5332: add few more reserved memory region

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] [day] [month] [year] [list]

Date:   Thu, 18 May 2023 18:04:09 +0530
From:   Kathiravan T <quic_kathirav@...cinc.com>
To:     Bhupesh Sharma <bhupesh.sharma@...aro.org>
CC:     <agross@...nel.org>, <andersson@...nel.org>,
        <konrad.dybcio@...aro.org>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
        <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V2 3/3] arm64: dts: qcom: ipq5332: add few more reserved
 memory region


On 5/18/2023 4:55 PM, Bhupesh Sharma wrote:
> Hi,
>
> On Thu, 18 May 2023 at 14:00, Kathiravan T <quic_kathirav@...cinc.com> wrote:
>> In IPQ SoCs, U-boot will collect the system RAM contents upon crash for
>> the post morterm analysis. If we don't reserve the memory region used by
>> U-boot, obviously linux will consume it and upon next boot on crash, uboot
>> will be loaded in the same region, which will lead to loose some of the
>> data, sometimes we may miss out critical information. So lets reserve the
>> region used by the U-boot.
>>
>> Similarly SBL copies some data into the reserved region and it will be
>> used in the crash scenario. So reserve 1MB for SBL as well.
>>
>> While at it, drop the size padding in the smem memory region.
>>
>> Signed-off-by: Kathiravan T <quic_kathirav@...cinc.com>
>> ---
>> Changes in V2:
>>          - Dropped the size padding in smem memory region
>>
>>   arch/arm64/boot/dts/qcom/ipq5332.dtsi | 12 +++++++++++-
>>   1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/ipq5332.dtsi b/arch/arm64/boot/dts/qcom/ipq5332.dtsi
>> index 753581e60604..7e0a2a674f09 100644
>> --- a/arch/arm64/boot/dts/qcom/ipq5332.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/ipq5332.dtsi
>> @@ -114,6 +114,16 @@
>>                  #size-cells = <2>;
>>                  ranges;
>>
>> +               uboot@...00000 {
> Shouldn't this be bootloader agnostic? AFAIK any bootloader ported on
> IPQ SoCs and booting linux can access the system RAM.
>
> I mean s/uboot/bootloader here and in the commit log.


Ack.


>
> Also which entity collects the post-crash data, is it some linux driver?
> If yes, can you add more details about it in the commit log.


Bootloader is the one which collects the post-crash data. Below is the flow

System crash -> TZ -> Reset the system -> PBL -> SBL -> Bootloader,

During system boot, crashdump magic is set. Upon system reboot cases, 
these magic values will be cleared. In the system crash scenarios like 
panic,

the crashdump magic will not be cleared. Bootloader checks this value 
and collects the data and then reset the system.


Thanks,

Kathiravan T.


>
> Thanks,
> Bhupesh
>
>> +                       reg = <0x0 0x4a100000 0x0 0x400000>;
>> +                       no-map;
>> +               };
>> +
>> +               sbl@...00000 {
>> +                       reg = <0x0 0x4a500000 0x0 0x100000>;
>> +                       no-map;
>> +               };
>> +
>>                  tz_mem: tz@...00000 {
>>                          reg = <0x0 0x4a600000 0x0 0x200000>;
>>                          no-map;
>> @@ -121,7 +131,7 @@
>>
>>                  smem@...00000 {
>>                          compatible = "qcom,smem";
>> -                       reg = <0x0 0x4a800000 0x0 0x00100000>;
>> +                       reg = <0x0 0x4a800000 0x0 0x100000>;
>>                          no-map;
>>
>>                          hwlocks = <&tcsr_mutex 0>;
>> --
>> 2.17.1
>>