[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e7478064-9b08-0eac-9c43-a235a0d45a90@linaro.org>
Date: Tue, 16 May 2023 03:02:50 +0200
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Kathiravan T <quic_kathirav@...cinc.com>, agross@...nel.org,
andersson@...nel.org, robh+dt@...nel.org,
krzysztof.kozlowski+dt@...aro.org, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] arm64: dts: qcom: ipq5332: add few more reserved
memory region
On 12.04.2023 18:49, Kathiravan T wrote:
> In IPQ SoCs, U-boot will collect the system RAM contents upon crash for
> the post morterm
s/post morterm/post-mortem ; s/the//
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
s/loose/loss
some of the
> data, sometimes we may miss out critical information.
So.. is it used to store crash data, or do you load u-boot there?
Or is there some software running at a higher exception level that
collects the dumps and stores it to this region?
Are these regions only used for some sort of crashdump colection?
If so, they could get some more specific names, e.g. uboot-crashdump
or so.
Konrad
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>
> Signed-off-by: Kathiravan T <quic_kathirav@...cinc.com>
> ---
> arch/arm64/boot/dts/qcom/ipq5332.dtsi | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/ipq5332.dtsi b/arch/arm64/boot/dts/qcom/ipq5332.dtsi
> index c32217530b41..aec60840a2f0 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 {
> + 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;
Powered by blists - more mailing lists