Hi,
On Thu, 18 May 2023 at 14:00, Kathiravan T <quic_kathirav@xxxxxxxxxxx> 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@xxxxxxxxxxx>
> ---
> 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
>
