Rename the MI01.2 DTS after Reference Design Platform(RDP) number to align
with ipq5332-rdp468.dts, add UART1 node and reserve memory for U-boot
and SBL to avoid losing the RAM contents which will be used in post
morterm analysis.
Kathiravan T (3):
arm64: dts: qcom: ipq5332: rename mi01.2 dts to rdp441
arm64: dts: qcom: ipq5332: define UART1
arm64: dts: qcom: ipq5332: add few more reserved memory region
arch/arm64/boot/dts/qcom/Makefile | 2 +-
...{ipq5332-mi01.2.dts => ipq5332-rdp441.dts} | 0
arch/arm64/boot/dts/qcom/ipq5332.dtsi | 24 ++++++++++++++++++-
3 files changed, 24 insertions(+), 2 deletions(-)
rename arch/arm64/boot/dts/qcom/{ipq5332-mi01.2.dts => ipq5332-rdp441.dts} (100%)
--
2.17.1
Add the definition for the UART1 found on IPQ5332 SoC.
Signed-off-by: Kathiravan T <[email protected]>
---
Changes in V2:
- Added the dma and dma-names property
- Didn't pick up the R-b tag due to above change
arch/arm64/boot/dts/qcom/ipq5332.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/ipq5332.dtsi b/arch/arm64/boot/dts/qcom/ipq5332.dtsi
index 12e0e179e139..753581e60604 100644
--- a/arch/arm64/boot/dts/qcom/ipq5332.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq5332.dtsi
@@ -218,6 +218,18 @@
status = "disabled";
};
+ blsp1_uart1: serial@78b0000 {
+ compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+ reg = <0x078b0000 0x200>;
+ interrupts = <GIC_SPI 291 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gcc GCC_BLSP1_UART2_APPS_CLK>,
+ <&gcc GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+ dmas = <&blsp_dma 2>, <&blsp_dma 3>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
blsp1_spi0: spi@78b5000 {
compatible = "qcom,spi-qup-v2.2.1";
reg = <0x078b5000 0x600>;
--
2.17.1
To align with ipq5332-rdp468.dts, lets rename the mi01.2 dts as well to
ipq5332-rdp441.dts.
Reviewed-by: Konrad Dybcio <[email protected]>
Signed-off-by: Kathiravan T <[email protected]>
---
Changes in V2:
- Pick up R-b tag
arch/arm64/boot/dts/qcom/Makefile | 2 +-
.../boot/dts/qcom/{ipq5332-mi01.2.dts => ipq5332-rdp441.dts} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename arch/arm64/boot/dts/qcom/{ipq5332-mi01.2.dts => ipq5332-rdp441.dts} (100%)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index e311ba675f35..bd09e2029df7 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -3,7 +3,7 @@ dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc.dtb
dtb-$(CONFIG_ARCH_QCOM) += apq8094-sony-xperia-kitakami-karin_windy.dtb
dtb-$(CONFIG_ARCH_QCOM) += apq8096-db820c.dtb
dtb-$(CONFIG_ARCH_QCOM) += apq8096-ifc6640.dtb
-dtb-$(CONFIG_ARCH_QCOM) += ipq5332-mi01.2.dtb
+dtb-$(CONFIG_ARCH_QCOM) += ipq5332-rdp441.dtb
dtb-$(CONFIG_ARCH_QCOM) += ipq5332-rdp468.dtb
dtb-$(CONFIG_ARCH_QCOM) += ipq6018-cp01-c1.dtb
dtb-$(CONFIG_ARCH_QCOM) += ipq8074-hk01.dtb
diff --git a/arch/arm64/boot/dts/qcom/ipq5332-mi01.2.dts b/arch/arm64/boot/dts/qcom/ipq5332-rdp441.dts
similarity index 100%
rename from arch/arm64/boot/dts/qcom/ipq5332-mi01.2.dts
rename to arch/arm64/boot/dts/qcom/ipq5332-rdp441.dts
--
2.17.1
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 <[email protected]>
---
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 {
+ 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
On Thu, 18 May 2023 at 14:00, Kathiravan T <[email protected]> wrote:
>
> Add the definition for the UART1 found on IPQ5332 SoC.
>
> Signed-off-by: Kathiravan T <[email protected]>
> ---
> Changes in V2:
> - Added the dma and dma-names property
> - Didn't pick up the R-b tag due to above change
>
> arch/arm64/boot/dts/qcom/ipq5332.dtsi | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/ipq5332.dtsi b/arch/arm64/boot/dts/qcom/ipq5332.dtsi
> index 12e0e179e139..753581e60604 100644
> --- a/arch/arm64/boot/dts/qcom/ipq5332.dtsi
> +++ b/arch/arm64/boot/dts/qcom/ipq5332.dtsi
> @@ -218,6 +218,18 @@
> status = "disabled";
> };
>
> + blsp1_uart1: serial@78b0000 {
> + compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
> + reg = <0x078b0000 0x200>;
> + interrupts = <GIC_SPI 291 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&gcc GCC_BLSP1_UART2_APPS_CLK>,
> + <&gcc GCC_BLSP1_AHB_CLK>;
> + clock-names = "core", "iface";
> + dmas = <&blsp_dma 2>, <&blsp_dma 3>;
> + dma-names = "tx", "rx";
> + status = "disabled";
> + };
> +
> blsp1_spi0: spi@78b5000 {
> compatible = "qcom,spi-qup-v2.2.1";
> reg = <0x078b5000 0x600>;
> --
> 2.17.1
Reviewed-by: Bhupesh Sharma <[email protected]>
Thanks.
Hi,
On Thu, 18 May 2023 at 14:00, Kathiravan T <[email protected]> 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 <[email protected]>
> ---
> 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
>
On 5/18/2023 4:55 PM, Bhupesh Sharma wrote:
> Hi,
>
> On Thu, 18 May 2023 at 14:00, Kathiravan T <[email protected]> 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 <[email protected]>
>> ---
>> 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.
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@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
>>