Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230518082934.24129-1-quic_kathirav@quicinc.com> <20230518082934.24129-4-quic_kathirav@quicinc.com>
In-Reply-To: <20230518082934.24129-4-quic_kathirav@quicinc.com>
From:   Bhupesh Sharma <bhupesh.sharma@linaro.org>
Date:   Thu, 18 May 2023 16:55:00 +0530
Message-ID: <CAH=2Ntz2MxM1rNeTULTWAotXWouEOj+uNHaWCjzW+ZMNZiT2hg@mail.gmail.com>
Subject: Re: [PATCH V2 3/3] arm64: dts: qcom: ipq5332: add few more reserved
 memory region
To:     Kathiravan T <quic_kathirav@quicinc.com>
Cc:     agross@kernel.org, andersson@kernel.org, konrad.dybcio@linaro.org,
        robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
        conor+dt@kernel.org, linux-arm-msm@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi,

On Thu, 18 May 2023 at 14:00, Kathiravan T <quic_kathirav@quicinc.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@quicinc.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@4a100000 {

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@4a500000 {
> +                       reg = <0x0 0x4a500000 0x0 0x100000>;
> +                       no-map;
> +               };
> +
>                 tz_mem: tz@4a600000 {
>                         reg = <0x0 0x4a600000 0x0 0x200000>;
>                         no-map;
> @@ -121,7 +131,7 @@
>
>                 smem@4a800000 {
>                         compatible = "qcom,smem";
> -                       reg = <0x0 0x4a800000 0x0 0x00100000>;
> +                       reg = <0x0 0x4a800000 0x0 0x100000>;
>                         no-map;
>
>                         hwlocks = <&tcsr_mutex 0>;
> --
> 2.17.1
>