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

Message-ID: <CAH=2Ntz2MxM1rNeTULTWAotXWouEOj+uNHaWCjzW+ZMNZiT2hg@mail.gmail.com>
Date:   Thu, 18 May 2023 16:55:00 +0530
From:   Bhupesh Sharma <bhupesh.sharma@...aro.org>
To:     Kathiravan T <quic_kathirav@...cinc.com>
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

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.

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.

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
>