[PATCH v6 00/11] Add R5F and C7xv device nodes

[PATCH v6 00/11] Add R5F and C7xv device nodes

[Judith Mendez]

For am62x and am62ax devices, this patch series adds device nodes
for the R5F subsystem and C7xv DSP subsystem found in their
respective voltage domain, based on the device TRMs [0][1].

This patch series also includes patches for enabling IPC for am62x SK,
am62ax SK, and am62px SK by reserving memory and binding the mailbox
assignments for each remote core.

Also reserve timers used by C7x DSP for am62ax SK board and timers used
by MCU FW for AM642 SK and EVM boards as per firmware requirements.

Changes since v5:
- Include patch 1/11
- Reduce size of memory carveouts used as external memory to 15MB as per: [2]
- Reorder DT properties for cores so that standard DT properties come first [3]

Links
v5: https://lore.kernel.org/linux-devicetree/20250210221530.1234009-1-jm@ti.com/
v4: https://lore.kernel.org/linux-devicetree/20250206235200.3128163-1-jm@ti.com/
v3: https://lore.kernel.org/linux-devicetree/20250204011641.1523561-1-jm@ti.com/
v2: https://lore.kernel.org/linux-devicetree/20250131214611.3288742-1-jm@ti.com/
v1: https://lore.kernel.org/linux-devicetree/20250127221631.3974583-1-jm@ti.com/

[0] https://www.ti.com/lit/pdf/spruj16
[1] https://www.ti.com/lit/pdf/spruiv7
[2] https://lore.kernel.org/linux-devicetree/04e77daf-e775-44fa-82bf-8b6ebf73bcef@ti.com/
[3] https://lore.kernel.org/linux-devicetree/4740c3f8-5051-4e25-af91-b45735ffef31@ti.com/

Devarsh Thakkar (3):
  arm64: dts: ti: k3-am62a-wakeup: Add R5F device node
  arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors
  arm64: dts: ti: k3-am62p5-sk: Enable IPC with remote processors

Hari Nagalla (6):
  arm64: dts: ti: k3-am62-wakeup: Add wakeup R5F node
  arm64: dts: ti: k3-am62a-mcu: Add R5F remote proc node
  arm64: dts: ti: k3-am62x-sk-common: Enable IPC with remote processors
  arm64: dts: ti: k3-am62a7-sk: Reserve main_timer2 for C7x DSP
  arm64: dts: ti: k3-am62a7-sk: Reserve main_rti4 for C7x DSP
  arm64: dts: ti: k3-am64: Reserve timers used by MCU FW

Jai Luthra (1):
  arm64: dts: ti: k3-am62a-main: Add C7xv device node

Judith Mendez (1):
  arm64: dts: ti: k3-am62: Add ATCM and BTCM cbass ranges

 arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi    |  25 +++++
 arch/arm64/boot/dts/ti/k3-am62.dtsi           |   8 +-
 arch/arm64/boot/dts/ti/k3-am62a-main.dtsi     |  12 ++
 arch/arm64/boot/dts/ti/k3-am62a-mcu.dtsi      |  25 +++++
 arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi   |  25 +++++
 arch/arm64/boot/dts/ti/k3-am62a7-sk.dts       | 106 +++++++++++++++++-
 arch/arm64/boot/dts/ti/k3-am62p5-sk.dts       |  50 ++++++++-
 .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi |  34 +++++-
 arch/arm64/boot/dts/ti/k3-am642-evm.dts       |  17 +++
 arch/arm64/boot/dts/ti/k3-am642-sk.dts        |  17 +++
 10 files changed, 300 insertions(+), 19 deletions(-)

-- 
2.49.0

[PATCH v6 01/11] arm64: dts: ti: k3-am62: Add ATCM and BTCM cbass ranges

[Judith Mendez]

Add cbass ranges for ATCM and BTCM on am62x device, without
these, remoteproc driver fails to probe and attach to the DM
r5 core and IPC communication is broken.

Signed-off-by: Judith Mendez <jm@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am62.dtsi | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am62.dtsi b/arch/arm64/boot/dts/ti/k3-am62.dtsi
index bfb55ca113239..59f6dff552ed4 100644
--- a/arch/arm64/boot/dts/ti/k3-am62.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62.dtsi
@@ -86,7 +86,9 @@ cbass_main: bus@f0000 {
 			 /* Wakeup Domain Range */
 			 <0x00 0x00b00000 0x00 0x00b00000 0x00 0x00002400>, /* VTM */
 			 <0x00 0x2b000000 0x00 0x2b000000 0x00 0x00300400>,
-			 <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>;
+			 <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>,
+			 <0x00 0x78000000 0x00 0x78000000 0x00 0x00008000>, /* DM R5 ATCM*/
+			 <0x00 0x78100000 0x00 0x78100000 0x00 0x00008000>; /* DM R5 BTCM*/
 
 		cbass_mcu: bus@4000000 {
 			bootph-all;
@@ -103,7 +105,9 @@ cbass_wakeup: bus@b00000 {
 			#size-cells = <2>;
 			ranges = <0x00 0x00b00000 0x00 0x00b00000 0x00 0x00002400>, /* VTM */
 				 <0x00 0x2b000000 0x00 0x2b000000 0x00 0x00300400>, /* Peripheral Window */
-				 <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>;
+				 <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>,
+				 <0x00 0x78000000 0x00 0x78000000 0x00 0x00008000>, /* DM R5 ATCM*/
+				 <0x00 0x78100000 0x00 0x78100000 0x00 0x00008000>; /* DM R5 BTCM*/
 		};
 	};
 
-- 
2.49.0

[PATCH v6 02/11] arm64: dts: ti: k3-am62-wakeup: Add wakeup R5F node

[Judith Mendez]

From: Hari Nagalla <hnagalla@ti.com>

AM62 SoC devices have a single core R5F processor in wakeup domain.
The R5F processor in wakeup domain is used as a device manager
for the SoC.

Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi | 25 ++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
index 9b8a1f85aa15c..6549b7efa6561 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
@@ -106,6 +106,31 @@ wkup_rti0: watchdog@2b000000 {
 		status = "reserved";
 	};
 
+	wkup_r5fss0: r5fss@78000000 {
+		compatible = "ti,am62-r5fss";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x78000000 0x00 0x78000000 0x8000>,
+			 <0x78100000 0x00 0x78100000 0x8000>;
+		power-domains = <&k3_pds 119 TI_SCI_PD_EXCLUSIVE>;
+		status = "disabled";
+
+		wkup_r5fss0_core0: r5f@78000000 {
+			compatible = "ti,am62-r5f";
+			reg = <0x78000000 0x00008000>,
+			      <0x78100000 0x00008000>;
+			reg-names = "atcm", "btcm";
+			resets = <&k3_reset 121 1>;
+			firmware-name = "am62-wkup-r5f0_0-fw";
+			ti,atcm-enable = <1>;
+			ti,btcm-enable = <1>;
+			ti,loczrama = <1>;
+			ti,sci = <&dmsc>;
+			ti,sci-dev-id = <121>;
+			ti,sci-proc-ids = <0x01 0xff>;
+		};
+	};
+
 	wkup_vtm0: temperature-sensor@b00000 {
 		compatible = "ti,j7200-vtm";
 		reg = <0x00 0xb00000 0x00 0x400>,
-- 
2.49.0

[PATCH v6 03/11] arm64: dts: ti: k3-am62a-mcu: Add R5F remote proc node

[Judith Mendez]

From: Hari Nagalla <hnagalla@ti.com>

AM62A SoCs have a single R5F core in the MCU voltage domain.
Add the R5FSS node with the child node for core0 in MCU voltage
domain .dtsi file.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am62a-mcu.dtsi | 25 ++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62a-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am62a-mcu.dtsi
index 9ed9d703ff24d..ee961ced7208f 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a-mcu.dtsi
@@ -174,4 +174,29 @@ mcu_mcan1: can@4e18000 {
 		bosch,mram-cfg = <0x0 128 64 64 64 64 32 32>;
 		status = "disabled";
 	};
+
+	mcu_r5fss0: r5fss@79000000 {
+		compatible = "ti,am62-r5fss";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x79000000 0x00 0x79000000 0x8000>,
+			 <0x79020000 0x00 0x79020000 0x8000>;
+		power-domains = <&k3_pds 7 TI_SCI_PD_EXCLUSIVE>;
+		status = "disabled";
+
+		mcu_r5fss0_core0: r5f@79000000 {
+			compatible = "ti,am62-r5f";
+			reg = <0x79000000 0x00008000>,
+			      <0x79020000 0x00008000>;
+			reg-names = "atcm", "btcm";
+			resets = <&k3_reset 9 1>;
+			firmware-name = "am62a-mcu-r5f0_0-fw";
+			ti,atcm-enable = <0>;
+			ti,btcm-enable = <1>;
+			ti,loczrama = <0>;
+			ti,sci = <&dmsc>;
+			ti,sci-dev-id = <9>;
+			ti,sci-proc-ids = <0x03 0xff>;
+		};
+	};
 };
-- 
2.49.0

[PATCH v6 04/11] arm64: dts: ti: k3-am62a-wakeup: Add R5F device node

[Judith Mendez]

From: Devarsh Thakkar <devarsht@ti.com>

AM62A SoCs have a single R5F core in wakeup domain. This core is
also used as a device manager for the SoC.

Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi | 25 +++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
index b2c8f53517438..259ae6ebbfb5a 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
@@ -103,6 +103,31 @@ wkup_rti0: watchdog@2b000000 {
 		status = "reserved";
 	};
 
+	wkup_r5fss0: r5fss@78000000 {
+		compatible = "ti,am62-r5fss";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x78000000 0x00 0x78000000 0x8000>,
+			 <0x78100000 0x00 0x78100000 0x8000>;
+		power-domains = <&k3_pds 119 TI_SCI_PD_EXCLUSIVE>;
+		status = "disabled";
+
+		wkup_r5fss0_core0: r5f@78000000 {
+			compatible = "ti,am62-r5f";
+			reg = <0x78000000 0x00008000>,
+			      <0x78100000 0x00008000>;
+			reg-names = "atcm", "btcm";
+			resets = <&k3_reset 121 1>;
+			firmware-name = "am62a-wkup-r5f0_0-fw";
+			ti,atcm-enable = <1>;
+			ti,btcm-enable = <1>;
+			ti,loczrama = <1>;
+			ti,sci = <&dmsc>;
+			ti,sci-dev-id = <121>;
+			ti,sci-proc-ids = <0x01 0xff>;
+		};
+	};
+
 	wkup_vtm0: temperature-sensor@b00000 {
 		compatible = "ti,j7200-vtm";
 		reg = <0x00 0xb00000 0x00 0x400>,
-- 
2.49.0

[PATCH v6 05/11] arm64: dts: ti: k3-am62a-main: Add C7xv device node

[Judith Mendez]

From: Jai Luthra <j-luthra@ti.com>

AM62A SoCs have a C7xv DSP subsystem with Analytics engine capability.
This subsystem is intended for deep learning purposes. Define the
device node for C7xv DSP.

Signed-off-by: Jai Luthra <j-luthra@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
index a1daba7b1fad5..d296e9e179738 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
@@ -1123,6 +1123,18 @@ vpu: video-codec@30210000 {
 		power-domains = <&k3_pds 204 TI_SCI_PD_EXCLUSIVE>;
 	};
 
+	c7x_0: dsp@7e000000 {
+		compatible = "ti,am62a-c7xv-dsp";
+		reg = <0x00 0x7e000000 0x00 0x00100000>;
+		reg-names = "l2sram";
+		resets = <&k3_reset 208 1>;
+		firmware-name = "am62a-c71_0-fw";
+		ti,sci = <&dmsc>;
+		ti,sci-dev-id = <208>;
+		ti,sci-proc-ids = <0x04 0xff>;
+		status = "disabled";
+	};
+
 	e5010: jpeg-encoder@fd20000 {
 		compatible = "ti,am62a-jpeg-enc", "img,e5010-jpeg-enc";
 		reg = <0x00 0xfd20000 0x00 0x100>,
-- 
2.49.0

[PATCH v6 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Judith Mendez]

From: Devarsh Thakkar <devarsht@ti.com>

For each remote proc, reserve memory for IPC and bind the mailbox
assignments. Two memory regions are reserved for each remote processor.
The first region of 1MB of memory is used for Vring shared buffers
and the second region is used as external memory to the remote processor
for the resource table and for tracebuffer allocations.

Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 96 +++++++++++++++++++++++--
 1 file changed, 90 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
index 1c9d95696c839..7d817b447c1d0 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
@@ -52,6 +52,42 @@ linux,cma {
 			linux,cma-default;
 		};
 
+		c7x_0_dma_memory_region: c7x-dma-memory@99800000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x99800000 0x00 0x100000>;
+			no-map;
+		};
+
+		c7x_0_memory_region: c7x-memory@99900000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x99900000 0x00 0xf00000>;
+			no-map;
+		};
+
+		mcu_r5fss0_core0_dma_memory_region: r5f-dma-memory@9b800000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9b800000 0x00 0x100000>;
+			no-map;
+		};
+
+		mcu_r5fss0_core0_memory_region: r5f-dma-memory@9b900000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9b900000 0x00 0xf00000>;
+			no-map;
+		};
+
+		wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9c800000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9c800000 0x00 0x100000>;
+			no-map;
+		};
+
+		wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9c900000 0x00 0xf00000>;
+			no-map;
+		};
+
 		secure_tfa_ddr: tfa@9e780000 {
 			reg = <0x00 0x9e780000 0x00 0x80000>;
 			alignment = <0x1000>;
@@ -63,12 +99,6 @@ secure_ddr: optee@9e800000 {
 			alignment = <0x1000>;
 			no-map;
 		};
-
-		wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
-			compatible = "shared-dma-pool";
-			reg = <0x00 0x9c900000 0x00 0x01e00000>;
-			no-map;
-		};
 	};
 
 	opp-table {
@@ -741,3 +771,57 @@ dpi1_out: endpoint {
 		};
 	};
 };
+
+&mailbox0_cluster0 {
+	status = "okay";
+
+	mbox_r5_0: mbox-r5-0 {
+		ti,mbox-rx = <0 0 0>;
+		ti,mbox-tx = <1 0 0>;
+	};
+};
+
+&mailbox0_cluster1 {
+	status = "okay";
+
+	mbox_c7x_0: mbox-c7x-0 {
+		ti,mbox-rx = <0 0 0>;
+		ti,mbox-tx = <1 0 0>;
+	};
+};
+
+&mailbox0_cluster2 {
+	status = "okay";
+
+	mbox_mcu_r5_0: mbox-mcu-r5-0 {
+		ti,mbox-rx = <0 0 0>;
+		ti,mbox-tx = <1 0 0>;
+	};
+};
+
+&wkup_r5fss0 {
+	status = "okay";
+};
+
+&wkup_r5fss0_core0 {
+	mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
+	memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
+			<&wkup_r5fss0_core0_memory_region>;
+};
+
+&mcu_r5fss0 {
+	status = "okay";
+};
+
+&mcu_r5fss0_core0 {
+	mboxes = <&mailbox0_cluster2>, <&mbox_mcu_r5_0>;
+	memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
+			<&mcu_r5fss0_core0_memory_region>;
+};
+
+&c7x_0 {
+	mboxes = <&mailbox0_cluster1>, <&mbox_c7x_0>;
+	memory-region = <&c7x_0_dma_memory_region>,
+			<&c7x_0_memory_region>;
+	status = "okay";
+};
-- 
2.49.0

[PATCH v6 07/11] arm64: dts: ti: k3-am62p5-sk: Enable IPC with remote processors

[Judith Mendez]

From: Devarsh Thakkar <devarsht@ti.com>

For each remote proc, reserve memory for IPC and bind the mailbox
assignments. Two memory regions are reserved for each remote processor.
The first region of 1MB of memory is used for Vring shared buffers
and the second region is used as external memory to the remote processor
for the resource table and for tracebuffer allocations.

Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am62p5-sk.dts | 50 ++++++++++++++++++++++---
 1 file changed, 44 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts b/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
index d29f524600af0..05760507da4ed 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
@@ -49,6 +49,30 @@ reserved-memory {
 		#size-cells = <2>;
 		ranges;
 
+		mcu_r5fss0_core0_dma_memory_region: mcu-r5fss-dma-memory-region@9b800000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9b800000 0x00 0x100000>;
+			no-map;
+		};
+
+		mcu_r5fss0_core0_memory_region: mcu-r5fss-memory-region@9b900000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9b900000 0x00 0xf00000>;
+			no-map;
+		};
+
+		wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9c800000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9c800000 0x00 0x100000>;
+			no-map;
+		};
+
+		wkup_r5fss0_core0_memory_region: r5f-memory@9c900000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9c900000 0x00 0xf00000>;
+			no-map;
+		};
+
 		secure_tfa_ddr: tfa@9e780000 {
 			reg = <0x00 0x9e780000 0x00 0x80000>;
 			no-map;
@@ -58,12 +82,6 @@ secure_ddr: optee@9e800000 {
 			reg = <0x00 0x9e800000 0x00 0x01800000>; /* for OP-TEE */
 			no-map;
 		};
-
-		wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
-			compatible = "shared-dma-pool";
-			reg = <0x00 0x9c900000 0x00 0x01e00000>;
-			no-map;
-		};
 	};
 
 	vmain_pd: regulator-0 {
@@ -640,6 +658,26 @@ mbox_mcu_r5_0: mbox-mcu-r5-0 {
 	};
 };
 
+&wkup_r5fss0 {
+	status = "okay";
+};
+
+&wkup_r5fss0_core0 {
+	mboxes = <&mailbox0_cluster0 &mbox_r5_0>;
+	memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
+			<&wkup_r5fss0_core0_memory_region>;
+};
+
+&mcu_r5fss0 {
+	status = "okay";
+};
+
+&mcu_r5fss0_core0 {
+	mboxes = <&mailbox0_cluster1 &mbox_mcu_r5_0>;
+	memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
+			<&mcu_r5fss0_core0_memory_region>;
+};
+
 &main_uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&main_uart0_pins_default>;
-- 
2.49.0

[PATCH v6 08/11] arm64: dts: ti: k3-am62x-sk-common: Enable IPC with remote processors

[Judith Mendez]

From: Hari Nagalla <hnagalla@ti.com>

For each remote proc, reserve memory for IPC and bind the mailbox
assignments. Two memory regions are reserved for each remote processor.
The first region of 1MB of memory is used for Vring shared buffers
and the second region is used as external memory to the remote processor
for the resource table and for tracebuffer allocations.

Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
---
 .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 34 ++++++++++++++++---
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
index d52cb2a5a589a..364b2ba6af958 100644
--- a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
@@ -70,6 +70,18 @@ mcu_m4fss_memory_region: m4f-memory@9cc00000 {
 			no-map;
 		};
 
+		wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9da00000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9da00000 0x00 0x100000>;
+			no-map;
+		};
+
+		wkup_r5fss0_core0_memory_region: r5f-memory@9db00000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9db00000 0x00 0xc00000>;
+			no-map;
+		};
+
 		secure_tfa_ddr: tfa@9e780000 {
 			reg = <0x00 0x9e780000 0x00 0x80000>;
 			alignment = <0x1000>;
@@ -82,11 +94,6 @@ secure_ddr: optee@9e800000 {
 			no-map;
 		};
 
-		wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9db00000 {
-			compatible = "shared-dma-pool";
-			reg = <0x00 0x9db00000 0x00 0xc00000>;
-			no-map;
-		};
 	};
 
 	leds {
@@ -476,10 +483,17 @@ cpsw3g_phy0: ethernet-phy@0 {
 };
 
 &mailbox0_cluster0 {
+	status = "okay";
+
 	mbox_m4_0: mbox-m4-0 {
 		ti,mbox-rx = <0 0 0>;
 		ti,mbox-tx = <1 0 0>;
 	};
+
+	mbox_r5_0: mbox-r5-0 {
+		ti,mbox-rx = <2 0 0>;
+		ti,mbox-tx = <3 0 0>;
+	};
 };
 
 &mcu_m4fss {
@@ -489,6 +503,16 @@ &mcu_m4fss {
 	status = "okay";
 };
 
+&wkup_r5fss0 {
+	status = "okay";
+};
+
+&wkup_r5fss0_core0 {
+	mboxes = <&mailbox0_cluster0 &mbox_r5_0>;
+	memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
+			<&wkup_r5fss0_core0_memory_region>;
+};
+
 &usbss0 {
 	bootph-all;
 	status = "okay";
-- 
2.49.0

[PATCH v6 09/11] arm64: dts: ti: k3-am62a7-sk: Reserve main_timer2 for C7x DSP

[Judith Mendez]

From: Hari Nagalla <hnagalla@ti.com>

C7x DSP uses main_timer2, so mark it as reserved in linux DT.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
index 7d817b447c1d0..8d7645bb90337 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
@@ -682,6 +682,11 @@ &main_uart1 {
 	status = "reserved";
 };
 
+/* main_timer2 is used by C7x DSP */
+&main_timer2 {
+	status = "reserved";
+};
+
 &usbss0 {
 	status = "okay";
 	ti,vbus-divider;
-- 
2.49.0

[PATCH v6 10/11] arm64: dts: ti: k3-am62a7-sk: Reserve main_rti4 for C7x DSP

[Judith Mendez]

From: Hari Nagalla <hnagalla@ti.com>

The main rti4 watchdog timer is used by the C7x DSP, so reserve the
timer in the linux device tree.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
index 8d7645bb90337..032f1f18d184e 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
@@ -830,3 +830,8 @@ &c7x_0 {
 			<&c7x_0_memory_region>;
 	status = "okay";
 };
+
+/* main_rti4 is used by C7x DSP */
+&main_rti4 {
+	status = "reserved";
+};
-- 
2.49.0

[PATCH v6 11/11] arm64: dts: ti: k3-am64: Reserve timers used by MCU FW

[Judith Mendez]

From: Hari Nagalla <hnagalla@ti.com>

AM64x device has 4 R5F cores in the main domain. TI MCU firmware uses
main domain timers as tick timers in these firmwares. Hence keep them
as reserved in the Linux device tree.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am642-evm.dts | 17 +++++++++++++++++
 arch/arm64/boot/dts/ti/k3-am642-sk.dts  | 17 +++++++++++++++++
 2 files changed, 34 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index f8ec40523254b..68bd6b806f8f0 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -796,6 +796,23 @@ &mcu_m4fss {
 	status = "okay";
 };
 
+/* main_timers 8-11 are used by TI MCU FW */
+&main_timer8 {
+	status = "reserved";
+};
+
+&main_timer9 {
+	status = "reserved";
+};
+
+&main_timer10 {
+	status = "reserved";
+};
+
+&main_timer11 {
+	status = "reserved";
+};
+
 &serdes_ln_ctrl {
 	idle-states = <AM64_SERDES0_LANE0_PCIE0>;
 };
diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
index 33e421ec18abb..07fbdf2400d23 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
@@ -710,6 +710,23 @@ &mcu_m4fss {
 	status = "okay";
 };
 
+/* main_timers 8-11 are used by TI MCU FW */
+&main_timer8 {
+	status = "reserved";
+};
+
+&main_timer9 {
+	status = "reserved";
+};
+
+&main_timer10 {
+	status = "reserved";
+};
+
+&main_timer11 {
+	status = "reserved";
+};
+
 &ecap0 {
 	status = "okay";
 	/* PWM is available on Pin 1 of header J3 */
-- 
2.49.0

Re: [PATCH v6 11/11] arm64: dts: ti: k3-am64: Reserve timers used by MCU FW

[Andrew Davis]

On 4/4/25 7:15 PM, Judith Mendez wrote:
> From: Hari Nagalla <hnagalla@ti.com>
> 
> AM64x device has 4 R5F cores in the main domain. TI MCU firmware uses
> main domain timers as tick timers in these firmwares. Hence keep them
> as reserved in the Linux device tree.
> 
> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
> Signed-off-by: Judith Mendez <jm@ti.com>
> ---
>   arch/arm64/boot/dts/ti/k3-am642-evm.dts | 17 +++++++++++++++++
>   arch/arm64/boot/dts/ti/k3-am642-sk.dts  | 17 +++++++++++++++++
>   2 files changed, 34 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> index f8ec40523254b..68bd6b806f8f0 100644
> --- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> @@ -796,6 +796,23 @@ &mcu_m4fss {
>   	status = "okay";
>   };
>   
> +/* main_timers 8-11 are used by TI MCU FW */

Can you make this comment per-core and explain which core
each timer is reserved for? Makes it easier on me in Zephyr
to point out why we use the timers that we do, something
like:

/* main_timer8 is reserved for mcu_r5fss0_core0 */

Andrew

> +&main_timer8 {
> +	status = "reserved";
> +};
> +
> +&main_timer9 {
> +	status = "reserved";
> +};
> +
> +&main_timer10 {
> +	status = "reserved";
> +};
> +
> +&main_timer11 {
> +	status = "reserved";
> +};
> +
>   &serdes_ln_ctrl {
>   	idle-states = <AM64_SERDES0_LANE0_PCIE0>;
>   };
> diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
> index 33e421ec18abb..07fbdf2400d23 100644
> --- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
> @@ -710,6 +710,23 @@ &mcu_m4fss {
>   	status = "okay";
>   };
>   
> +/* main_timers 8-11 are used by TI MCU FW */
> +&main_timer8 {
> +	status = "reserved";
> +};
> +
> +&main_timer9 {
> +	status = "reserved";
> +};
> +
> +&main_timer10 {
> +	status = "reserved";
> +};
> +
> +&main_timer11 {
> +	status = "reserved";
> +};
> +
>   &ecap0 {
>   	status = "okay";
>   	/* PWM is available on Pin 1 of header J3 */

Re: [PATCH v6 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Judith Mendez]

Hi Devarsh,

On 4/7/25 8:54 AM, Devarsh Thakkar wrote:
> Hi Judith,
> 
> On 05/04/25 05:45, Judith Mendez wrote:
>  > From: Devarsh Thakkar <devarsht@ti.com>
>>
> 
> Thanks for the patch.
> 
>> For each remote proc, reserve memory for IPC and bind the mailbox
>> assignments. Two memory regions are reserved for each remote processor.
>> The first region of 1MB of memory is used for Vring shared buffers
>> and the second region is used as external memory to the remote processor
>> for the resource table and for tracebuffer allocations.
>>
>> Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
>> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
>> Signed-off-by: Judith Mendez <jm@ti.com>
>> ---
>>   arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 96 +++++++++++++++++++++++--
>>   1 file changed, 90 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts 
>> b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>> index 1c9d95696c839..7d817b447c1d0 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>> @@ -52,6 +52,42 @@ linux,cma {
>>               linux,cma-default;
>>           };
>> +        c7x_0_dma_memory_region: c7x-dma-memory@99800000 {
>> +            compatible = "shared-dma-pool";
>> +            reg = <0x00 0x99800000 0x00 0x100000>;
>> +            no-map;
>> +        };
>> +
>> +        c7x_0_memory_region: c7x-memory@99900000 {
>> +            compatible = "shared-dma-pool";
>> +            reg = <0x00 0x99900000 0x00 0xf00000>;
>> +            no-map;
>> +        };
>> +
>> +        mcu_r5fss0_core0_dma_memory_region: r5f-dma-memory@9b800000 {
>> +            compatible = "shared-dma-pool";
>> +            reg = <0x00 0x9b800000 0x00 0x100000>;
>> +            no-map;
>> +        };
>> +
>> +        mcu_r5fss0_core0_memory_region: r5f-dma-memory@9b900000 {
>> +            compatible = "shared-dma-pool";
>> +            reg = <0x00 0x9b900000 0x00 0xf00000>;
>> +            no-map;
>> +        };
>> +
>> +        wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9c800000 {
>> +            compatible = "shared-dma-pool";
>> +            reg = <0x00 0x9c800000 0x00 0x100000>;
>> +            no-map;
>> +        };
>> +
>> +        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
>> +            compatible = "shared-dma-pool";
>> +            reg = <0x00 0x9c900000 0x00 0xf00000>;
>> +            no-map;
>> +        };
>> +
>>           secure_tfa_ddr: tfa@9e780000 {
>>               reg = <0x00 0x9e780000 0x00 0x80000>;
>>               alignment = <0x1000>;
>> @@ -63,12 +99,6 @@ secure_ddr: optee@9e800000 {
>>               alignment = <0x1000>;
>>               no-map;
>>           };
>> -
>> -        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
>> -            compatible = "shared-dma-pool";
>> -            reg = <0x00 0x9c900000 0x00 0x01e00000>;
>> -            no-map;
>> -        };
>>       };
> 
> This is missing the edgeAI specific remote-core carveouts and 
> RTOS-to-RTOS IPC memory regions [1] being used by edgeAI firmwares which 
> come as pre-packaged in the official SDK release for AM62A.
> 
> There is only one official SDK release for AM62A (which is edgeAI based) 
> [2] which packages these edgeAI remoteproc firmwares and in my view it 
> is a fair expectation that remote core careveouts in device-tree should 
> align with firmwares released in SDK.
> 
> This is because most developers (including me) and vendors download this 
> official SDK release and use it with latest upstream kernel and modules 
> (right now we are applying required patches locally) and this patch 
> won't suffice for this, in-fact it won't work since the remoteproc 
> firmwares are already using regions beyond the reserved-regions from 
> this patch.

I understand your point, currently with this patch remoteproc loading
will not work for some cores. However, the goal here is to standardize
as much as possible the memory carveout sizes, push the "demo firmware"
to request resources the correct way from resource table, and move away
from this dependency and limitations that we have with our firmware. We
should soon be able to generate our own firmware using Zephyr,  which
Andrew is pioneering, so with this firmware we should move to the
correct direction upstream. Downstream we are still using the memory
carveout sizes that the firmware folk want so desperately to keep, for
now..

~ Judith

> 
> [1]: 
> https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts?h=ti-linux-6.6.y-cicd#n103
> [2]: https://www.ti.com/tool/PROCESSOR-SDK-AM62A
> 
> Regards
> Devarsh
> 
>>       opp-table {
>> @@ -741,3 +771,57 @@ dpi1_out: endpoint {
>>           };
>>       };
>>   };
>> +
>> +&mailbox0_cluster0 {
>> +    status = "okay";
>> +
>> +    mbox_r5_0: mbox-r5-0 {
>> +        ti,mbox-rx = <0 0 0>;
>> +        ti,mbox-tx = <1 0 0>;
>> +    };
>> +};
>> +
>> +&mailbox0_cluster1 {
>> +    status = "okay";
>> +
>> +    mbox_c7x_0: mbox-c7x-0 {
>> +        ti,mbox-rx = <0 0 0>;
>> +        ti,mbox-tx = <1 0 0>;
>> +    };
>> +};
>> +
>> +&mailbox0_cluster2 {
>> +    status = "okay";
>> +
>> +    mbox_mcu_r5_0: mbox-mcu-r5-0 {
>> +        ti,mbox-rx = <0 0 0>;
>> +        ti,mbox-tx = <1 0 0>;
>> +    };
>> +};
>> +
>> +&wkup_r5fss0 {
>> +    status = "okay";
>> +};
>> +
>> +&wkup_r5fss0_core0 {
>> +    mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
>> +    memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
>> +            <&wkup_r5fss0_core0_memory_region>;
>> +};
>> +
>> +&mcu_r5fss0 {
>> +    status = "okay";
>> +};
>> +
>> +&mcu_r5fss0_core0 {
>> +    mboxes = <&mailbox0_cluster2>, <&mbox_mcu_r5_0>;
>> +    memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
>> +            <&mcu_r5fss0_core0_memory_region>;
>> +};
>> +
>> +&c7x_0 {
>> +    mboxes = <&mailbox0_cluster1>, <&mbox_c7x_0>;
>> +    memory-region = <&c7x_0_dma_memory_region>,
>> +            <&c7x_0_memory_region>;
>> +    status = "okay";
>> +};
> 

Re: [PATCH v6 11/11] arm64: dts: ti: k3-am64: Reserve timers used by MCU FW

[Judith Mendez]

Hi Andrew,

On 4/7/25 7:35 AM, Andrew Davis wrote:
> On 4/4/25 7:15 PM, Judith Mendez wrote:
>> From: Hari Nagalla <hnagalla@ti.com>
>>
>> AM64x device has 4 R5F cores in the main domain. TI MCU firmware uses
>> main domain timers as tick timers in these firmwares. Hence keep them
>> as reserved in the Linux device tree.
>>
>> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
>> Signed-off-by: Judith Mendez <jm@ti.com>
>> ---
>>   arch/arm64/boot/dts/ti/k3-am642-evm.dts | 17 +++++++++++++++++
>>   arch/arm64/boot/dts/ti/k3-am642-sk.dts  | 17 +++++++++++++++++
>>   2 files changed, 34 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts 
>> b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
>> index f8ec40523254b..68bd6b806f8f0 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
>> @@ -796,6 +796,23 @@ &mcu_m4fss {
>>       status = "okay";
>>   };
>> +/* main_timers 8-11 are used by TI MCU FW */
> 
> Can you make this comment per-core and explain which core
> each timer is reserved for? Makes it easier on me in Zephyr
> to point out why we use the timers that we do, something
> like:
> 
> /* main_timer8 is reserved for mcu_r5fss0_core0 */

Sure, I can do that. Will wait for [0] conversation to close and then
respin the series with this change

[0] 
https://lore.kernel.org/linux-devicetree/f42607f5-e39d-48a1-89c0-11d4982a2426@ti.com/

~ Judith

> 
> Andrew
> 
>> +&main_timer8 {
>> +    status = "reserved";
>> +};
>> +
>> +&main_timer9 {
>> +    status = "reserved";
>> +};
>> +
>> +&main_timer10 {
>> +    status = "reserved";
>> +};
>> +
>> +&main_timer11 {
>> +    status = "reserved";
>> +};
>> +
>>   &serdes_ln_ctrl {
>>       idle-states = <AM64_SERDES0_LANE0_PCIE0>;
>>   };
>> diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts 
>> b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
>> index 33e421ec18abb..07fbdf2400d23 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
>> @@ -710,6 +710,23 @@ &mcu_m4fss {
>>       status = "okay";
>>   };
>> +/* main_timers 8-11 are used by TI MCU FW */
>> +&main_timer8 {
>> +    status = "reserved";
>> +};
>> +
>> +&main_timer9 {
>> +    status = "reserved";
>> +};
>> +
>> +&main_timer10 {
>> +    status = "reserved";
>> +};
>> +
>> +&main_timer11 {
>> +    status = "reserved";
>> +};
>> +
>>   &ecap0 {
>>       status = "okay";
>>       /* PWM is available on Pin 1 of header J3 */

Re: [PATCH v6 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Andrew Davis]

On 4/7/25 9:13 AM, Judith Mendez wrote:
> Hi Devarsh,
> 
> On 4/7/25 8:54 AM, Devarsh Thakkar wrote:
>> Hi Judith,
>>
>> On 05/04/25 05:45, Judith Mendez wrote:
>>  > From: Devarsh Thakkar <devarsht@ti.com>
>>>
>>
>> Thanks for the patch.
>>
>>> For each remote proc, reserve memory for IPC and bind the mailbox
>>> assignments. Two memory regions are reserved for each remote processor.
>>> The first region of 1MB of memory is used for Vring shared buffers
>>> and the second region is used as external memory to the remote processor
>>> for the resource table and for tracebuffer allocations.
>>>
>>> Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
>>> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
>>> Signed-off-by: Judith Mendez <jm@ti.com>
>>> ---
>>>   arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 96 +++++++++++++++++++++++--
>>>   1 file changed, 90 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>> index 1c9d95696c839..7d817b447c1d0 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>> @@ -52,6 +52,42 @@ linux,cma {
>>>               linux,cma-default;
>>>           };
>>> +        c7x_0_dma_memory_region: c7x-dma-memory@99800000 {
>>> +            compatible = "shared-dma-pool";
>>> +            reg = <0x00 0x99800000 0x00 0x100000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        c7x_0_memory_region: c7x-memory@99900000 {
>>> +            compatible = "shared-dma-pool";
>>> +            reg = <0x00 0x99900000 0x00 0xf00000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        mcu_r5fss0_core0_dma_memory_region: r5f-dma-memory@9b800000 {
>>> +            compatible = "shared-dma-pool";
>>> +            reg = <0x00 0x9b800000 0x00 0x100000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        mcu_r5fss0_core0_memory_region: r5f-dma-memory@9b900000 {
>>> +            compatible = "shared-dma-pool";
>>> +            reg = <0x00 0x9b900000 0x00 0xf00000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9c800000 {
>>> +            compatible = "shared-dma-pool";
>>> +            reg = <0x00 0x9c800000 0x00 0x100000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
>>> +            compatible = "shared-dma-pool";
>>> +            reg = <0x00 0x9c900000 0x00 0xf00000>;
>>> +            no-map;
>>> +        };
>>> +
>>>           secure_tfa_ddr: tfa@9e780000 {
>>>               reg = <0x00 0x9e780000 0x00 0x80000>;
>>>               alignment = <0x1000>;
>>> @@ -63,12 +99,6 @@ secure_ddr: optee@9e800000 {
>>>               alignment = <0x1000>;
>>>               no-map;
>>>           };
>>> -
>>> -        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
>>> -            compatible = "shared-dma-pool";
>>> -            reg = <0x00 0x9c900000 0x00 0x01e00000>;
>>> -            no-map;
>>> -        };
>>>       };
>>
>> This is missing the edgeAI specific remote-core carveouts and RTOS-to-RTOS IPC memory regions [1] being used by edgeAI firmwares which come as pre-packaged in the official SDK release for AM62A.
>>
>> There is only one official SDK release for AM62A (which is edgeAI based) [2] which packages these edgeAI remoteproc firmwares and in my view it is a fair expectation that remote core careveouts in device-tree should align with firmwares released in SDK.
>>

Why should Linux upstream care about what we do in our current evil vendor SDKs?
We change things around every cycle, and do all kinds of hacky things to just
"make it work" for the current SDK release.

>> This is because most developers (including me) and vendors download this official SDK release and use it with latest upstream kernel and modules (right now we are applying required patches locally) and this patch won't suffice for this, in-fact it won't work since the remoteproc firmwares are already using regions beyond the reserved-regions from this patch.

Then that firmware team should fix their firmware, Linux should not
do things just because some builds of a firmware did the wrong thing.

Just a random example from the top of my mind here, a while back
someone on the codec firmware team decided to take the standard RPMSG
name service structure and modify it to suit some specific usecase
they had, suddenly all the firmware we made for AM57x devices stopped
working on upstream kernels. Instead of fixing the firmware we just
carried a hack for the same in our vendor kernel trees. Now customers
have no path to use this old firmware on newer kernels as adding the
hack to upstream Linux (rightly) failed [0].

Let's not do that again, if we have firmware that doesn't follow
upstream, then let's fix the firmware, not hack around it upstream.

The edgeAI firmware folks have no issue ignoring existing upstream
IPC carveouts and simply replacing them all with their own custom
ones in their SDK[1], I see no reason they cannot continue doing that
if they don't want to fix their firmware.

> 
> I understand your point, currently with this patch remoteproc loading
> will not work for some cores. However, the goal here is to standardize
> as much as possible the memory carveout sizes, push the "demo firmware"
> to request resources the correct way from resource table, and move away
> from this dependency and limitations that we have with our firmware. We
> should soon be able to generate our own firmware using Zephyr,  which
> Andrew is pioneering, so with this firmware we should move to the
> correct direction upstream. Downstream we are still using the memory
> carveout sizes that the firmware folk want so desperately to keep, for
> now..
> 

+1

I have this Zephyr based firmware for AM62A working and it uses the
standard IPC regions as specified in this patch. I'll be posting the PR
for it in Zephyr upstream by the end of week.

For this patch as it is:

Acked-by: Andrew Davis <afd@ti.com>

Andrew

[0] https://lore.kernel.org/lkml/20241011123922.23135-1-richard@nod.at/
[1] https://git.ti.com/cgit/edgeai/meta-edgeai/tree/recipes-kernel/linux/linux-ti-staging/j721e-evm/0001-arm64-dts-ti-Add-DTB-overlays-for-vision-apps-and-ed.patch?h=kirkstone

> ~ Judith
> 
>>
>> [1]: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts?h=ti-linux-6.6.y-cicd#n103
>> [2]: https://www.ti.com/tool/PROCESSOR-SDK-AM62A
>>
>> Regards
>> Devarsh
>>
>>>       opp-table {
>>> @@ -741,3 +771,57 @@ dpi1_out: endpoint {
>>>           };
>>>       };
>>>   };
>>> +
>>> +&mailbox0_cluster0 {
>>> +    status = "okay";
>>> +
>>> +    mbox_r5_0: mbox-r5-0 {
>>> +        ti,mbox-rx = <0 0 0>;
>>> +        ti,mbox-tx = <1 0 0>;
>>> +    };
>>> +};
>>> +
>>> +&mailbox0_cluster1 {
>>> +    status = "okay";
>>> +
>>> +    mbox_c7x_0: mbox-c7x-0 {
>>> +        ti,mbox-rx = <0 0 0>;
>>> +        ti,mbox-tx = <1 0 0>;
>>> +    };
>>> +};
>>> +
>>> +&mailbox0_cluster2 {
>>> +    status = "okay";
>>> +
>>> +    mbox_mcu_r5_0: mbox-mcu-r5-0 {
>>> +        ti,mbox-rx = <0 0 0>;
>>> +        ti,mbox-tx = <1 0 0>;
>>> +    };
>>> +};
>>> +
>>> +&wkup_r5fss0 {
>>> +    status = "okay";
>>> +};
>>> +
>>> +&wkup_r5fss0_core0 {
>>> +    mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
>>> +    memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
>>> +            <&wkup_r5fss0_core0_memory_region>;
>>> +};
>>> +
>>> +&mcu_r5fss0 {
>>> +    status = "okay";
>>> +};
>>> +
>>> +&mcu_r5fss0_core0 {
>>> +    mboxes = <&mailbox0_cluster2>, <&mbox_mcu_r5_0>;
>>> +    memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
>>> +            <&mcu_r5fss0_core0_memory_region>;
>>> +};
>>> +
>>> +&c7x_0 {
>>> +    mboxes = <&mailbox0_cluster1>, <&mbox_c7x_0>;
>>> +    memory-region = <&c7x_0_dma_memory_region>,
>>> +            <&c7x_0_memory_region>;
>>> +    status = "okay";
>>> +};
>>
> 

Re: [PATCH v6 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Beleswar Prasad Padhi]

Hi Judith, Andrew,

On 07/04/25 19:43, Judith Mendez wrote:
> Hi Devarsh,
>
> On 4/7/25 8:54 AM, Devarsh Thakkar wrote:
>> Hi Judith,
>>
>> On 05/04/25 05:45, Judith Mendez wrote:
>>  > From: Devarsh Thakkar <devarsht@ti.com>
>>>
>>
>> Thanks for the patch.
>>
>>> For each remote proc, reserve memory for IPC and bind the mailbox
>>> assignments. Two memory regions are reserved for each remote processor.
>>> The first region of 1MB of memory is used for Vring shared buffers
>>> and the second region is used as external memory to the remote 
>>> processor
>>> for the resource table and for tracebuffer allocations.
>>>
>>> Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
>>> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
>>> Signed-off-by: Judith Mendez <jm@ti.com>
>>> ---
>>>   arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 96 
>>> +++++++++++++++++++++++--
>>>   1 file changed, 90 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts 
>>> b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>> index 1c9d95696c839..7d817b447c1d0 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>> @@ -52,6 +52,42 @@ linux,cma {
>>>               linux,cma-default;
>>>           };
>>> +        c7x_0_dma_memory_region: c7x-dma-memory@99800000 {
>>> +            compatible = "shared-dma-pool";
>>> +            reg = <0x00 0x99800000 0x00 0x100000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        c7x_0_memory_region: c7x-memory@99900000 {
>>> +            compatible = "shared-dma-pool";
>>> +            reg = <0x00 0x99900000 0x00 0xf00000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        mcu_r5fss0_core0_dma_memory_region: r5f-dma-memory@9b800000 {
>>> +            compatible = "shared-dma-pool";
>>> +            reg = <0x00 0x9b800000 0x00 0x100000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        mcu_r5fss0_core0_memory_region: r5f-dma-memory@9b900000 {
>>> +            compatible = "shared-dma-pool";
>>> +            reg = <0x00 0x9b900000 0x00 0xf00000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9c800000 {
>>> +            compatible = "shared-dma-pool";
>>> +            reg = <0x00 0x9c800000 0x00 0x100000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
>>> +            compatible = "shared-dma-pool";
>>> +            reg = <0x00 0x9c900000 0x00 0xf00000>;
>>> +            no-map;
>>> +        };
>>> +
>>>           secure_tfa_ddr: tfa@9e780000 {
>>>               reg = <0x00 0x9e780000 0x00 0x80000>;
>>>               alignment = <0x1000>;
>>> @@ -63,12 +99,6 @@ secure_ddr: optee@9e800000 {
>>>               alignment = <0x1000>;
>>>               no-map;
>>>           };
>>> -
>>> -        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
>>> -            compatible = "shared-dma-pool";
>>> -            reg = <0x00 0x9c900000 0x00 0x01e00000>;
>>> -            no-map;
>>> -        };
>>>       };
>>
>> This is missing the edgeAI specific remote-core carveouts and 
>> RTOS-to-RTOS IPC memory regions [1] being used by edgeAI firmwares 
>> which come as pre-packaged in the official SDK release for AM62A.
>>
>> There is only one official SDK release for AM62A (which is edgeAI 
>> based) [2] which packages these edgeAI remoteproc firmwares and in my 
>> view it is a fair expectation that remote core careveouts in 
>> device-tree should align with firmwares released in SDK.
>>
>> This is because most developers (including me) and vendors download 
>> this official SDK release and use it with latest upstream kernel and 
>> modules (right now we are applying required patches locally) and this 
>> patch won't suffice for this, in-fact it won't work since the 
>> remoteproc firmwares are already using regions beyond the 
>> reserved-regions from this patch.
>
> I understand your point, currently with this patch remoteproc loading
> will not work for some cores. However, the goal here is to standardize
> as much as possible the memory carveout sizes, push the "demo firmware"
> to request resources the correct way from resource table, 


It is indeed more suitable if the memory carveouts are called out in the 
resource table of the firmware. But you will still need to reserve that 
memory sections in the Device Tree so that Kernel does not map that 
memory for anything else. So I am thinking how moving to resource table 
will help solve this problem?

Thanks,
Beleswar

> and move away
> from this dependency and limitations that we have with our firmware. We
> should soon be able to generate our own firmware using Zephyr, which
> Andrew is pioneering, so with this firmware we should move to the
> correct direction upstream. Downstream we are still using the memory
> carveout sizes that the firmware folk want so desperately to keep, for
> now..
>
> ~ Judith
>
>>
>> [1]: 
>> https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts?h=ti-linux-6.6.y-cicd#n103
>> [2]: https://www.ti.com/tool/PROCESSOR-SDK-AM62A
>>
>> Regards
>> Devarsh
>>
>>>       opp-table {
>>> @@ -741,3 +771,57 @@ dpi1_out: endpoint {
>>>           };
>>>       };
>>>   };
>>> +
>>> +&mailbox0_cluster0 {
>>> +    status = "okay";
>>> +
>>> +    mbox_r5_0: mbox-r5-0 {
>>> +        ti,mbox-rx = <0 0 0>;
>>> +        ti,mbox-tx = <1 0 0>;
>>> +    };
>>> +};
>>> +
>>> +&mailbox0_cluster1 {
>>> +    status = "okay";
>>> +
>>> +    mbox_c7x_0: mbox-c7x-0 {
>>> +        ti,mbox-rx = <0 0 0>;
>>> +        ti,mbox-tx = <1 0 0>;
>>> +    };
>>> +};
>>> +
>>> +&mailbox0_cluster2 {
>>> +    status = "okay";
>>> +
>>> +    mbox_mcu_r5_0: mbox-mcu-r5-0 {
>>> +        ti,mbox-rx = <0 0 0>;
>>> +        ti,mbox-tx = <1 0 0>;
>>> +    };
>>> +};
>>> +
>>> +&wkup_r5fss0 {
>>> +    status = "okay";
>>> +};
>>> +
>>> +&wkup_r5fss0_core0 {
>>> +    mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
>>> +    memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
>>> +            <&wkup_r5fss0_core0_memory_region>;
>>> +};
>>> +
>>> +&mcu_r5fss0 {
>>> +    status = "okay";
>>> +};
>>> +
>>> +&mcu_r5fss0_core0 {
>>> +    mboxes = <&mailbox0_cluster2>, <&mbox_mcu_r5_0>;
>>> +    memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
>>> +            <&mcu_r5fss0_core0_memory_region>;
>>> +};
>>> +
>>> +&c7x_0 {
>>> +    mboxes = <&mailbox0_cluster1>, <&mbox_c7x_0>;
>>> +    memory-region = <&c7x_0_dma_memory_region>,
>>> +            <&c7x_0_memory_region>;
>>> +    status = "okay";
>>> +};
>>
>

Re: [PATCH v6 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Judith Mendez]

Hi Beleswar,

On 4/7/25 11:00 PM, Beleswar Prasad Padhi wrote:
> Hi Judith, Andrew,
> 
> On 07/04/25 19:43, Judith Mendez wrote:
>> Hi Devarsh,
>>
>> On 4/7/25 8:54 AM, Devarsh Thakkar wrote:
>>> Hi Judith,
>>>
>>> On 05/04/25 05:45, Judith Mendez wrote:
>>>  > From: Devarsh Thakkar <devarsht@ti.com>
>>>>
>>>
>>> Thanks for the patch.
>>>
>>>> For each remote proc, reserve memory for IPC and bind the mailbox
>>>> assignments. Two memory regions are reserved for each remote processor.
>>>> The first region of 1MB of memory is used for Vring shared buffers
>>>> and the second region is used as external memory to the remote 
>>>> processor
>>>> for the resource table and for tracebuffer allocations.
>>>>
>>>> Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
>>>> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
>>>> Signed-off-by: Judith Mendez <jm@ti.com>
>>>> ---
>>>>   arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 96 
>>>> +++++++++++++++++++++++--
>>>>   1 file changed, 90 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts 
>>>> b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>> index 1c9d95696c839..7d817b447c1d0 100644
>>>> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>> @@ -52,6 +52,42 @@ linux,cma {
>>>>               linux,cma-default;
>>>>           };
>>>> +        c7x_0_dma_memory_region: c7x-dma-memory@99800000 {
>>>> +            compatible = "shared-dma-pool";
>>>> +            reg = <0x00 0x99800000 0x00 0x100000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        c7x_0_memory_region: c7x-memory@99900000 {
>>>> +            compatible = "shared-dma-pool";
>>>> +            reg = <0x00 0x99900000 0x00 0xf00000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        mcu_r5fss0_core0_dma_memory_region: r5f-dma-memory@9b800000 {
>>>> +            compatible = "shared-dma-pool";
>>>> +            reg = <0x00 0x9b800000 0x00 0x100000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        mcu_r5fss0_core0_memory_region: r5f-dma-memory@9b900000 {
>>>> +            compatible = "shared-dma-pool";
>>>> +            reg = <0x00 0x9b900000 0x00 0xf00000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9c800000 {
>>>> +            compatible = "shared-dma-pool";
>>>> +            reg = <0x00 0x9c800000 0x00 0x100000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
>>>> +            compatible = "shared-dma-pool";
>>>> +            reg = <0x00 0x9c900000 0x00 0xf00000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>>           secure_tfa_ddr: tfa@9e780000 {
>>>>               reg = <0x00 0x9e780000 0x00 0x80000>;
>>>>               alignment = <0x1000>;
>>>> @@ -63,12 +99,6 @@ secure_ddr: optee@9e800000 {
>>>>               alignment = <0x1000>;
>>>>               no-map;
>>>>           };
>>>> -
>>>> -        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
>>>> -            compatible = "shared-dma-pool";
>>>> -            reg = <0x00 0x9c900000 0x00 0x01e00000>;
>>>> -            no-map;
>>>> -        };
>>>>       };
>>>
>>> This is missing the edgeAI specific remote-core carveouts and 
>>> RTOS-to-RTOS IPC memory regions [1] being used by edgeAI firmwares 
>>> which come as pre-packaged in the official SDK release for AM62A.
>>>
>>> There is only one official SDK release for AM62A (which is edgeAI 
>>> based) [2] which packages these edgeAI remoteproc firmwares and in my 
>>> view it is a fair expectation that remote core careveouts in 
>>> device-tree should align with firmwares released in SDK.
>>>
>>> This is because most developers (including me) and vendors download 
>>> this official SDK release and use it with latest upstream kernel and 
>>> modules (right now we are applying required patches locally) and this 
>>> patch won't suffice for this, in-fact it won't work since the 
>>> remoteproc firmwares are already using regions beyond the 
>>> reserved-regions from this patch.
>>
>> I understand your point, currently with this patch remoteproc loading
>> will not work for some cores. However, the goal here is to standardize
>> as much as possible the memory carveout sizes, push the "demo firmware"
>> to request resources the correct way from resource table, 
> 
> 
> It is indeed more suitable if the memory carveouts are called out in the 
> resource table of the firmware. But you will still need to reserve that 
> memory sections in the Device Tree so that Kernel does not map that 
> memory for anything else. So I am thinking how moving to resource table 
> will help solve this problem?

The point is that our default FW is doing things incorrectly. We want to
push the existing FW to
1. Request resources via resource table.
2. Fix their memory requirements (recent offline discussion proved that
FW is requesting more than it needs)
3. FW should adapt to Linux not Linux adapt to FW

If not, then then we should try to move to Zephyr firmware or other/
better options.

Hope I am able to explain myself better this time around.

~ Judith

> 
> Thanks,
> Beleswar
> 
>> and move away
>> from this dependency and limitations that we have with our firmware. We
>> should soon be able to generate our own firmware using Zephyr, which
>> Andrew is pioneering, so with this firmware we should move to the
>> correct direction upstream. Downstream we are still using the memory
>> carveout sizes that the firmware folk want so desperately to keep, for
>> now..
>>
>> ~ Judith
>>
>>>
>>> [1]: 
>>> https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts?h=ti-linux-6.6.y-cicd#n103
>>> [2]: https://www.ti.com/tool/PROCESSOR-SDK-AM62A
>>>
>>> Regards
>>> Devarsh
>>>
>>>>       opp-table {
>>>> @@ -741,3 +771,57 @@ dpi1_out: endpoint {
>>>>           };
>>>>       };
>>>>   };
>>>> +
>>>> +&mailbox0_cluster0 {
>>>> +    status = "okay";
>>>> +
>>>> +    mbox_r5_0: mbox-r5-0 {
>>>> +        ti,mbox-rx = <0 0 0>;
>>>> +        ti,mbox-tx = <1 0 0>;
>>>> +    };
>>>> +};
>>>> +
>>>> +&mailbox0_cluster1 {
>>>> +    status = "okay";
>>>> +
>>>> +    mbox_c7x_0: mbox-c7x-0 {
>>>> +        ti,mbox-rx = <0 0 0>;
>>>> +        ti,mbox-tx = <1 0 0>;
>>>> +    };
>>>> +};
>>>> +
>>>> +&mailbox0_cluster2 {
>>>> +    status = "okay";
>>>> +
>>>> +    mbox_mcu_r5_0: mbox-mcu-r5-0 {
>>>> +        ti,mbox-rx = <0 0 0>;
>>>> +        ti,mbox-tx = <1 0 0>;
>>>> +    };
>>>> +};
>>>> +
>>>> +&wkup_r5fss0 {
>>>> +    status = "okay";
>>>> +};
>>>> +
>>>> +&wkup_r5fss0_core0 {
>>>> +    mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
>>>> +    memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
>>>> +            <&wkup_r5fss0_core0_memory_region>;
>>>> +};
>>>> +
>>>> +&mcu_r5fss0 {
>>>> +    status = "okay";
>>>> +};
>>>> +
>>>> +&mcu_r5fss0_core0 {
>>>> +    mboxes = <&mailbox0_cluster2>, <&mbox_mcu_r5_0>;
>>>> +    memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
>>>> +            <&mcu_r5fss0_core0_memory_region>;
>>>> +};
>>>> +
>>>> +&c7x_0 {
>>>> +    mboxes = <&mailbox0_cluster1>, <&mbox_c7x_0>;
>>>> +    memory-region = <&c7x_0_dma_memory_region>,
>>>> +            <&c7x_0_memory_region>;
>>>> +    status = "okay";
>>>> +};
>>>
>>

Re: [PATCH v6 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Beleswar Prasad Padhi]

Hi Judith,

On 10/04/25 04:02, Judith Mendez wrote:
> Hi Beleswar,
>
> On 4/7/25 11:00 PM, Beleswar Prasad Padhi wrote:
>> Hi Judith, Andrew,
>>
>> On 07/04/25 19:43, Judith Mendez wrote:
>>> Hi Devarsh,
>>>
>>> On 4/7/25 8:54 AM, Devarsh Thakkar wrote:
>>>> Hi Judith,
>>>>
>>>> On 05/04/25 05:45, Judith Mendez wrote:
>>>>  > From: Devarsh Thakkar <devarsht@ti.com>
>>>>>
>>>>
>>>> Thanks for the patch.
>>>>
>>>>> For each remote proc, reserve memory for IPC and bind the mailbox
>>>>> assignments. Two memory regions are reserved for each remote 
>>>>> processor.
>>>>> The first region of 1MB of memory is used for Vring shared buffers
>>>>> and the second region is used as external memory to the remote 
>>>>> processor
>>>>> for the resource table and for tracebuffer allocations.
>>>>>
>>>>> Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
>>>>> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
>>>>> Signed-off-by: Judith Mendez <jm@ti.com>
>>>>> ---
>>>>>   arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 96 
>>>>> +++++++++++++++++++++++--
>>>>>   1 file changed, 90 insertions(+), 6 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts 
>>>>> b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>>> index 1c9d95696c839..7d817b447c1d0 100644
>>>>> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>>> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>>> @@ -52,6 +52,42 @@ linux,cma {
>>>>>               linux,cma-default;
>>>>>           };
>>>>> +        c7x_0_dma_memory_region: c7x-dma-memory@99800000 {
>>>>> +            compatible = "shared-dma-pool";
>>>>> +            reg = <0x00 0x99800000 0x00 0x100000>;
>>>>> +            no-map;
>>>>> +        };
>>>>> +
>>>>> +        c7x_0_memory_region: c7x-memory@99900000 {
>>>>> +            compatible = "shared-dma-pool";
>>>>> +            reg = <0x00 0x99900000 0x00 0xf00000>;
>>>>> +            no-map;
>>>>> +        };
>>>>> +
>>>>> +        mcu_r5fss0_core0_dma_memory_region: 
>>>>> r5f-dma-memory@9b800000 {
>>>>> +            compatible = "shared-dma-pool";
>>>>> +            reg = <0x00 0x9b800000 0x00 0x100000>;
>>>>> +            no-map;
>>>>> +        };
>>>>> +
>>>>> +        mcu_r5fss0_core0_memory_region: r5f-dma-memory@9b900000 {
>>>>> +            compatible = "shared-dma-pool";
>>>>> +            reg = <0x00 0x9b900000 0x00 0xf00000>;
>>>>> +            no-map;
>>>>> +        };
>>>>> +
>>>>> +        wkup_r5fss0_core0_dma_memory_region: 
>>>>> r5f-dma-memory@9c800000 {
>>>>> +            compatible = "shared-dma-pool";
>>>>> +            reg = <0x00 0x9c800000 0x00 0x100000>;
>>>>> +            no-map;
>>>>> +        };
>>>>> +
>>>>> +        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
>>>>> +            compatible = "shared-dma-pool";
>>>>> +            reg = <0x00 0x9c900000 0x00 0xf00000>;
>>>>> +            no-map;
>>>>> +        };
>>>>> +
>>>>>           secure_tfa_ddr: tfa@9e780000 {
>>>>>               reg = <0x00 0x9e780000 0x00 0x80000>;
>>>>>               alignment = <0x1000>;
>>>>> @@ -63,12 +99,6 @@ secure_ddr: optee@9e800000 {
>>>>>               alignment = <0x1000>;
>>>>>               no-map;
>>>>>           };
>>>>> -
>>>>> -        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
>>>>> -            compatible = "shared-dma-pool";
>>>>> -            reg = <0x00 0x9c900000 0x00 0x01e00000>;
>>>>> -            no-map;
>>>>> -        };
>>>>>       };
>>>>
>>>> This is missing the edgeAI specific remote-core carveouts and 
>>>> RTOS-to-RTOS IPC memory regions [1] being used by edgeAI firmwares 
>>>> which come as pre-packaged in the official SDK release for AM62A.
>>>>
>>>> There is only one official SDK release for AM62A (which is edgeAI 
>>>> based) [2] which packages these edgeAI remoteproc firmwares and in 
>>>> my view it is a fair expectation that remote core careveouts in 
>>>> device-tree should align with firmwares released in SDK.
>>>>
>>>> This is because most developers (including me) and vendors download 
>>>> this official SDK release and use it with latest upstream kernel 
>>>> and modules (right now we are applying required patches locally) 
>>>> and this patch won't suffice for this, in-fact it won't work since 
>>>> the remoteproc firmwares are already using regions beyond the 
>>>> reserved-regions from this patch.
>>>
>>> I understand your point, currently with this patch remoteproc loading
>>> will not work for some cores. However, the goal here is to standardize
>>> as much as possible the memory carveout sizes, push the "demo firmware"
>>> to request resources the correct way from resource table, 
>>
>>
>> It is indeed more suitable if the memory carveouts are called out in 
>> the resource table of the firmware. But you will still need to 
>> reserve that memory sections in the Device Tree so that Kernel does 
>> not map that memory for anything else. So I am thinking how moving to 
>> resource table will help solve this problem?
>
> The point is that our default FW is doing things incorrectly. We want to
> push the existing FW to
> 1. Request resources via resource table.
> 2. Fix their memory requirements (recent offline discussion proved that
> FW is requesting more than it needs)
> 3. FW should adapt to Linux not Linux adapt to FW


Thanks. I also agree with you on all of the above points for a standard 
firmware.

However, I was referring to this problem:
Can we get rid of static reserved memory carveouts in DT?
People using a custom firmware will have to patch the Device Tree to 
reserve larger/different memory regions. Is there some way where the 
firmware can dictate the "reserved" memory carveouts at runtime? Memory 
carveouts can be announced through Resource Table, but there is no 
guarantee we will be able to allocate it (it could be mapped by the 
Kernel for some other alloc), unless its pre-reserved in DT.

Thanks,
Beleswar

>
> If not, then then we should try to move to Zephyr firmware or other/
> better options.
>
> Hope I am able to explain myself better this time around.
>
> ~ Judith
>
>>
>> Thanks,
>> Beleswar
>>
>>> and move away
>>> from this dependency and limitations that we have with our firmware. We
>>> should soon be able to generate our own firmware using Zephyr, which
>>> Andrew is pioneering, so with this firmware we should move to the
>>> correct direction upstream. Downstream we are still using the memory
>>> carveout sizes that the firmware folk want so desperately to keep, for
>>> now..
>>>
>>> ~ Judith
>>>
>>>>
>>>> [1]: 
>>>> https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts?h=ti-linux-6.6.y-cicd#n103
>>>> [2]: https://www.ti.com/tool/PROCESSOR-SDK-AM62A
>>>>
>>>> Regards
>>>> Devarsh
>>>>
>>>>>       opp-table {
>>>>> @@ -741,3 +771,57 @@ dpi1_out: endpoint {
>>>>>           };
>>>>>       };
>>>>>   };
>>>>> +
>>>>> +&mailbox0_cluster0 {
>>>>> +    status = "okay";
>>>>> +
>>>>> +    mbox_r5_0: mbox-r5-0 {
>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>> +    };
>>>>> +};
>>>>> +
>>>>> +&mailbox0_cluster1 {
>>>>> +    status = "okay";
>>>>> +
>>>>> +    mbox_c7x_0: mbox-c7x-0 {
>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>> +    };
>>>>> +};
>>>>> +
>>>>> +&mailbox0_cluster2 {
>>>>> +    status = "okay";
>>>>> +
>>>>> +    mbox_mcu_r5_0: mbox-mcu-r5-0 {
>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>> +    };
>>>>> +};
>>>>> +
>>>>> +&wkup_r5fss0 {
>>>>> +    status = "okay";
>>>>> +};
>>>>> +
>>>>> +&wkup_r5fss0_core0 {
>>>>> +    mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
>>>>> +    memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
>>>>> +            <&wkup_r5fss0_core0_memory_region>;
>>>>> +};
>>>>> +
>>>>> +&mcu_r5fss0 {
>>>>> +    status = "okay";
>>>>> +};
>>>>> +
>>>>> +&mcu_r5fss0_core0 {
>>>>> +    mboxes = <&mailbox0_cluster2>, <&mbox_mcu_r5_0>;
>>>>> +    memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
>>>>> +            <&mcu_r5fss0_core0_memory_region>;
>>>>> +};
>>>>> +
>>>>> +&c7x_0 {
>>>>> +    mboxes = <&mailbox0_cluster1>, <&mbox_c7x_0>;
>>>>> +    memory-region = <&c7x_0_dma_memory_region>,
>>>>> +            <&c7x_0_memory_region>;
>>>>> +    status = "okay";
>>>>> +};
>>>>
>>>
>

Re: [PATCH v6 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Devarsh Thakkar]

Hi Andrew, Judith,

Thanks for the quick revert.

On 07/04/25 21:28, Andrew Davis wrote:
> On 4/7/25 9:13 AM, Judith Mendez wrote:
>> Hi Devarsh,
>>
>> On 4/7/25 8:54 AM, Devarsh Thakkar wrote:
>>> Hi Judith,
>>>
>>> On 05/04/25 05:45, Judith Mendez wrote:
>>>  > From: Devarsh Thakkar <devarsht@ti.com>
>>>>
>>>
>>> Thanks for the patch.
>>>
>>>> For each remote proc, reserve memory for IPC and bind the mailbox
>>>> assignments. Two memory regions are reserved for each remote processor.
>>>> The first region of 1MB of memory is used for Vring shared buffers
>>>> and the second region is used as external memory to the remote 
>>>> processor
>>>> for the resource table and for tracebuffer allocations.
>>>>
>>>> Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
>>>> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
>>>> Signed-off-by: Judith Mendez <jm@ti.com>
>>>> ---
>>>>   arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 96 +++++++++++++++++++++ 
>>>> ++--
>>>>   1 file changed, 90 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/ 
>>>> boot/dts/ti/k3-am62a7-sk.dts
>>>> index 1c9d95696c839..7d817b447c1d0 100644
>>>> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>> @@ -52,6 +52,42 @@ linux,cma {
>>>>               linux,cma-default;
>>>>           };
>>>> +        c7x_0_dma_memory_region: c7x-dma-memory@99800000 {
>>>> +            compatible = "shared-dma-pool";
>>>> +            reg = <0x00 0x99800000 0x00 0x100000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        c7x_0_memory_region: c7x-memory@99900000 {
>>>> +            compatible = "shared-dma-pool";
>>>> +            reg = <0x00 0x99900000 0x00 0xf00000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        mcu_r5fss0_core0_dma_memory_region: r5f-dma-memory@9b800000 {
>>>> +            compatible = "shared-dma-pool";
>>>> +            reg = <0x00 0x9b800000 0x00 0x100000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        mcu_r5fss0_core0_memory_region: r5f-dma-memory@9b900000 {
>>>> +            compatible = "shared-dma-pool";
>>>> +            reg = <0x00 0x9b900000 0x00 0xf00000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9c800000 {
>>>> +            compatible = "shared-dma-pool";
>>>> +            reg = <0x00 0x9c800000 0x00 0x100000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
>>>> +            compatible = "shared-dma-pool";
>>>> +            reg = <0x00 0x9c900000 0x00 0xf00000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>>           secure_tfa_ddr: tfa@9e780000 {
>>>>               reg = <0x00 0x9e780000 0x00 0x80000>;
>>>>               alignment = <0x1000>;
>>>> @@ -63,12 +99,6 @@ secure_ddr: optee@9e800000 {
>>>>               alignment = <0x1000>;
>>>>               no-map;
>>>>           };
>>>> -
>>>> -        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
>>>> -            compatible = "shared-dma-pool";
>>>> -            reg = <0x00 0x9c900000 0x00 0x01e00000>;
>>>> -            no-map;
>>>> -        };
>>>>       };
>>>
>>> This is missing the edgeAI specific remote-core carveouts and RTOS- 
>>> to-RTOS IPC memory regions [1] being used by edgeAI firmwares which 
>>> come as pre-packaged in the official SDK release for AM62A.
>>>
>>> There is only one official SDK release for AM62A (which is edgeAI 
>>> based) [2] which packages these edgeAI remoteproc firmwares and in my 
>>> view it is a fair expectation that remote core careveouts in device- 
>>> tree should align with firmwares released in SDK.
>>>
> 
> Why should Linux upstream care about what we do in our current evil 
> vendor SDKs?

These carveouts are specific to remote-cores and so have to match with 
firmwares running in these remote-cores. The debate is on which 
firmwares it should match to. The firmwares being packaged in SDK are 
the most used-ones and so in my view it is safe to account them as the 
official ones, unless of-course there is a major overhaul and 
re-architecture planned and accepted for these firmwares in which case 
we should wait for it.

> We change things around every cycle, and do all kinds of hacky things to 
> just
> "make it work" for the current SDK release.
> 

I don't see any changes done in memory map for last set of releases, but 
agreed if there is big architecture change planned for these firmwares 
then we should rather wait for updated firmwares then adding bloated 
carve-outs.

>>> This is because most developers (including me) and vendors download 
>>> this official SDK release and use it with latest upstream kernel and 
>>> modules (right now we are applying required patches locally) and this 
>>> patch won't suffice for this, in-fact it won't work since the 
>>> remoteproc firmwares are already using regions beyond the reserved- 
>>> regions from this patch.
> 
> Then that firmware team should fix their firmware, Linux should not
> do things just because some builds of a firmware did the wrong thing.

Maybe some optimizations would be missing, but carve-outs for lot of 
things which these firm-wares do out-of-box (and not even related fully 
to AI) are missing. For e.g. there is RTOS-to-RTOS IPC test which runs 
on startup and there is no reserved region for same, this would lead to 
tricky failures. The DM R5 remote core also controls ISP, but all 
required regions for same are also not present either.

> 
> Just a random example from the top of my mind here, a while back
> someone on the codec firmware team decided to take the standard RPMSG
> name service structure and modify it to suit some specific usecase
> they had, suddenly all the firmware we made for AM57x devices stopped
> working on upstream kernels. Instead of fixing the firmware we just
> carried a hack for the same in our vendor kernel trees. Now customers
> have no path to use this old firmware on newer kernels as adding the
> hack to upstream Linux (rightly) failed [0].
> 
> Let's not do that again, if we have firmware that doesn't follow
> upstream, then let's fix the firmware, not hack around it upstream.
> 
> The edgeAI firmware folks have no issue ignoring existing upstream
> IPC carveouts and simply replacing them all with their own custom
> ones in their SDK[1], I see no reason they cannot continue doing that
> if they don't want to fix their firmware.
> 

There is no apples-to-apples comparison with TDA4VM, unlike AM62A7 it 
offers SDK for both edgeAI and generic Linux [1], so if someone just 
uses latest upstream kernel and device-tree with this generic linux SDK, 
that would still work without any overlays applied or carveouts added. 
Same is not true for AM62A, as AM62A offers only edgeAI SDK with 
firmwares packaged for AI use-cases. So if someone, just replaces latest 
upstream kernel and device-tree with the patches from this series in 
edgeAI wic image, it won't work cleanly due to missing carve-outs.

Also even if we keep aside edgeAI, basic camera+ISP use-case won't work 
without the carveouts and we would prefer not to clone another layer to 
grab the overlay and apply it every-time we want to test run camera+ISP 
(and even the edgeAI use-case) on AM62A which would be a pain.

>>
>> I understand your point, currently with this patch remoteproc loading
>> will not work for some cores. However, the goal here is to standardize
>> as much as possible the memory carveout sizes, push the "demo firmware"
>> to request resources the correct way from resource table, and move away
>> from this dependency and limitations that we have with our firmware.

I understand this, but my view is that w.r.t firmware only goal should 
not just be tp demonstrate correct way of requesting resources from 
resource-tables, optimize the carve-outs etc but also to demonstrate the 
primary use-cases (camera+ISP+edgeAI) which the device is capable of.

>> should soon be able to generate our own firmware using Zephyr,  which
>> Andrew is pioneering, so with this firmware we should move to the
>> correct direction upstream. Downstream we are still using the memory
>> carveout sizes that the firmware folk want so desperately to keep, for
>> now..
>>
> 
> +1
> 
> I have this Zephyr based firmware for AM62A working and it uses the
> standard IPC regions as specified in this patch. I'll be posting the PR
> for it in Zephyr upstream by the end of week.
> 

I understand this, but will this zephyr based firmware support vision + 
edgeAI analytics ? Does it demonstrate all the unique capabilities of 
AM62A SoC ? If not, then what would be utility of such firmware on AM62A 
where these are the primary use-cases w.r.t AM62A ?

Why should upstream device-tree use carve-outs which match to this demo 
zephyr based firmware (which apparently not many are using and is not 
going into any official SDK release) instead of official firmwares going 
into SDK ? SDK released firmwares are being used by so many customers 
and SDK documentation maps to it, but zephyr firmware that is being 
pitched here, who would be the potential users and what would be it's 
utility ?

[1]: https://www.ti.com/tool/PROCESSOR-SDK-J721E

Regards
Devarsh

> For this patch as it is:
> 
> Acked-by: Andrew Davis <afd@ti.com>
> 


> Andrew
> 
> [0] https://lore.kernel.org/lkml/20241011123922.23135-1-richard@nod.at/
> [1] https://git.ti.com/cgit/edgeai/meta-edgeai/tree/recipes-kernel/ 
> linux/linux-ti-staging/j721e-evm/0001-arm64-dts-ti-Add-DTB-overlays-for- 
> vision-apps-and-ed.patch?h=kirkstone
> 
>> ~ Judith
>>
>>>
>>> [1]: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/ 
>>> arch/arm64/boot/dts/ti/k3-am62a7-sk.dts?h=ti-linux-6.6.y-cicd#n103
>>> [2]: https://www.ti.com/tool/PROCESSOR-SDK-AM62A
>>>
>>> Regards
>>> Devarsh
>>>
>>>>       opp-table {
>>>> @@ -741,3 +771,57 @@ dpi1_out: endpoint {
>>>>           };
>>>>       };
>>>>   };
>>>> +
>>>> +&mailbox0_cluster0 {
>>>> +    status = "okay";
>>>> +
>>>> +    mbox_r5_0: mbox-r5-0 {
>>>> +        ti,mbox-rx = <0 0 0>;
>>>> +        ti,mbox-tx = <1 0 0>;
>>>> +    };
>>>> +};
>>>> +
>>>> +&mailbox0_cluster1 {
>>>> +    status = "okay";
>>>> +
>>>> +    mbox_c7x_0: mbox-c7x-0 {
>>>> +        ti,mbox-rx = <0 0 0>;
>>>> +        ti,mbox-tx = <1 0 0>;
>>>> +    };
>>>> +};
>>>> +
>>>> +&mailbox0_cluster2 {
>>>> +    status = "okay";
>>>> +
>>>> +    mbox_mcu_r5_0: mbox-mcu-r5-0 {
>>>> +        ti,mbox-rx = <0 0 0>;
>>>> +        ti,mbox-tx = <1 0 0>;
>>>> +    };
>>>> +};
>>>> +
>>>> +&wkup_r5fss0 {
>>>> +    status = "okay";
>>>> +};
>>>> +
>>>> +&wkup_r5fss0_core0 {
>>>> +    mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
>>>> +    memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
>>>> +            <&wkup_r5fss0_core0_memory_region>;
>>>> +};
>>>> +
>>>> +&mcu_r5fss0 {
>>>> +    status = "okay";
>>>> +};
>>>> +
>>>> +&mcu_r5fss0_core0 {
>>>> +    mboxes = <&mailbox0_cluster2>, <&mbox_mcu_r5_0>;
>>>> +    memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
>>>> +            <&mcu_r5fss0_core0_memory_region>;
>>>> +};
>>>> +
>>>> +&c7x_0 {
>>>> +    mboxes = <&mailbox0_cluster1>, <&mbox_c7x_0>;
>>>> +    memory-region = <&c7x_0_dma_memory_region>,
>>>> +            <&c7x_0_memory_region>;
>>>> +    status = "okay";
>>>> +};
>>>
>>
> 

Re: [PATCH v6 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Jai Luthra]

[-- Attachment #1: Type: text/plain, Size: 14369 bytes --]

Hi Devarsh,

Thanks for the cc here.

On Apr 10, 2025 at 14:30:59 +0530, Devarsh Thakkar wrote:
> Hi Andrew, Judith,
> 
> Thanks for the quick revert.
> 
> On 07/04/25 21:28, Andrew Davis wrote:
> > On 4/7/25 9:13 AM, Judith Mendez wrote:
> > > Hi Devarsh,
> > > 
> > > On 4/7/25 8:54 AM, Devarsh Thakkar wrote:
> > > > Hi Judith,
> > > > 
> > > > On 05/04/25 05:45, Judith Mendez wrote:
> > > >  > From: Devarsh Thakkar <devarsht@ti.com>
> > > > > 
> > > > 
> > > > Thanks for the patch.
> > > > 
> > > > > For each remote proc, reserve memory for IPC and bind the mailbox
> > > > > assignments. Two memory regions are reserved for each remote processor.
> > > > > The first region of 1MB of memory is used for Vring shared buffers
> > > > > and the second region is used as external memory to the
> > > > > remote processor
> > > > > for the resource table and for tracebuffer allocations.
> > > > > 
> > > > > Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
> > > > > Signed-off-by: Hari Nagalla <hnagalla@ti.com>
> > > > > Signed-off-by: Judith Mendez <jm@ti.com>
> > > > > ---
> > > > >   arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 96
> > > > > +++++++++++++++++++++ ++--
> > > > >   1 file changed, 90 insertions(+), 6 deletions(-)
> > > > > 
> > > > > diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> > > > > b/arch/arm64/ boot/dts/ti/k3-am62a7-sk.dts
> > > > > index 1c9d95696c839..7d817b447c1d0 100644
> > > > > --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> > > > > +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> > > > > @@ -52,6 +52,42 @@ linux,cma {
> > > > >               linux,cma-default;
> > > > >           };
> > > > > +        c7x_0_dma_memory_region: c7x-dma-memory@99800000 {
> > > > > +            compatible = "shared-dma-pool";
> > > > > +            reg = <0x00 0x99800000 0x00 0x100000>;
> > > > > +            no-map;
> > > > > +        };
> > > > > +
> > > > > +        c7x_0_memory_region: c7x-memory@99900000 {
> > > > > +            compatible = "shared-dma-pool";
> > > > > +            reg = <0x00 0x99900000 0x00 0xf00000>;
> > > > > +            no-map;
> > > > > +        };
> > > > > +
> > > > > +        mcu_r5fss0_core0_dma_memory_region: r5f-dma-memory@9b800000 {
> > > > > +            compatible = "shared-dma-pool";
> > > > > +            reg = <0x00 0x9b800000 0x00 0x100000>;
> > > > > +            no-map;
> > > > > +        };
> > > > > +
> > > > > +        mcu_r5fss0_core0_memory_region: r5f-dma-memory@9b900000 {
> > > > > +            compatible = "shared-dma-pool";
> > > > > +            reg = <0x00 0x9b900000 0x00 0xf00000>;
> > > > > +            no-map;
> > > > > +        };
> > > > > +
> > > > > +        wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9c800000 {
> > > > > +            compatible = "shared-dma-pool";
> > > > > +            reg = <0x00 0x9c800000 0x00 0x100000>;
> > > > > +            no-map;
> > > > > +        };
> > > > > +
> > > > > +        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
> > > > > +            compatible = "shared-dma-pool";
> > > > > +            reg = <0x00 0x9c900000 0x00 0xf00000>;
> > > > > +            no-map;
> > > > > +        };
> > > > > +
> > > > >           secure_tfa_ddr: tfa@9e780000 {
> > > > >               reg = <0x00 0x9e780000 0x00 0x80000>;
> > > > >               alignment = <0x1000>;
> > > > > @@ -63,12 +99,6 @@ secure_ddr: optee@9e800000 {
> > > > >               alignment = <0x1000>;
> > > > >               no-map;
> > > > >           };
> > > > > -
> > > > > -        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
> > > > > -            compatible = "shared-dma-pool";
> > > > > -            reg = <0x00 0x9c900000 0x00 0x01e00000>;
> > > > > -            no-map;
> > > > > -        };
> > > > >       };
> > > > 
> > > > This is missing the edgeAI specific remote-core carveouts and
> > > > RTOS- to-RTOS IPC memory regions [1] being used by edgeAI
> > > > firmwares which come as pre-packaged in the official SDK release
> > > > for AM62A.
> > > > 
> > > > There is only one official SDK release for AM62A (which is
> > > > edgeAI based) [2] which packages these edgeAI remoteproc
> > > > firmwares and in my view it is a fair expectation that remote
> > > > core careveouts in device- tree should align with firmwares
> > > > released in SDK.
> > > > 
> > 
> > Why should Linux upstream care about what we do in our current evil
> > vendor SDKs?
> 
> These carveouts are specific to remote-cores and so have to match with
> firmwares running in these remote-cores. The debate is on which firmwares it
> should match to. The firmwares being packaged in SDK are the most used-ones
> and so in my view it is safe to account them as the official ones, unless
> of-course there is a major overhaul and re-architecture planned and accepted
> for these firmwares in which case we should wait for it.
> 
> > We change things around every cycle, and do all kinds of hacky things to
> > just
> > "make it work" for the current SDK release.
> > 
> 
> I don't see any changes done in memory map for last set of releases, but
> agreed if there is big architecture change planned for these firmwares then
> we should rather wait for updated firmwares then adding bloated carve-outs.
> 
> > > > This is because most developers (including me) and vendors
> > > > download this official SDK release and use it with latest
> > > > upstream kernel and modules (right now we are applying required
> > > > patches locally) and this patch won't suffice for this, in-fact
> > > > it won't work since the remoteproc firmwares are already using
> > > > regions beyond the reserved- regions from this patch.
> > 
> > Then that firmware team should fix their firmware, Linux should not
> > do things just because some builds of a firmware did the wrong thing.
> 
> Maybe some optimizations would be missing, but carve-outs for lot of things
> which these firm-wares do out-of-box (and not even related fully to AI) are
> missing. For e.g. there is RTOS-to-RTOS IPC test which runs on startup and
> there is no reserved region for same, this would lead to tricky failures.
> The DM R5 remote core also controls ISP, but all required regions for same
> are also not present either.
> 
> > 
> > Just a random example from the top of my mind here, a while back
> > someone on the codec firmware team decided to take the standard RPMSG
> > name service structure and modify it to suit some specific usecase
> > they had, suddenly all the firmware we made for AM57x devices stopped
> > working on upstream kernels. Instead of fixing the firmware we just
> > carried a hack for the same in our vendor kernel trees. Now customers
> > have no path to use this old firmware on newer kernels as adding the
> > hack to upstream Linux (rightly) failed [0].
> > 
> > Let's not do that again, if we have firmware that doesn't follow
> > upstream, then let's fix the firmware, not hack around it upstream.
> > 
> > The edgeAI firmware folks have no issue ignoring existing upstream
> > IPC carveouts and simply replacing them all with their own custom
> > ones in their SDK[1], I see no reason they cannot continue doing that
> > if they don't want to fix their firmware.
> > 
> 
> There is no apples-to-apples comparison with TDA4VM, unlike AM62A7 it offers
> SDK for both edgeAI and generic Linux [1], so if someone just uses latest
> upstream kernel and device-tree with this generic linux SDK, that would
> still work without any overlays applied or carveouts added. Same is not true
> for AM62A, as AM62A offers only edgeAI SDK with firmwares packaged for AI
> use-cases. So if someone, just replaces latest upstream kernel and
> device-tree with the patches from this series in edgeAI wic image, it won't
> work cleanly due to missing carve-outs.
> 
> Also even if we keep aside edgeAI, basic camera+ISP use-case won't work
> without the carveouts and we would prefer not to clone another layer to grab
> the overlay and apply it every-time we want to test run camera+ISP (and even
> the edgeAI use-case) on AM62A which would be a pain.
> 

On the basic camera + ISP usecase, afaiu the downstream edgeAI SDK uses 
custom gstreamer elements that make calls to the aforementioned R5 core 
that controls the ISP. On top of that there are additional gstreamer 
patches that are not yet posted upstream for review from the community, 
so the userspace design isn't really set in stone, or upstream-friendly 
yet. 

IMO if that architecture is still under discussion, it might be better 
to keep the edgeAI specific carveouts out of the upstream DTs.. just in 
case the carevouts have to go away, or change significantly.

If you are sure that the regions and firmware architecture is set in 
stone and won't be updated even if there is a complete redesign of the 
userspace/application level stack for accessing the ISP (let's say using 
libcamera), only then it makes sense to add the carveouts right now.

> > > 
> > > I understand your point, currently with this patch remoteproc loading
> > > will not work for some cores. However, the goal here is to standardize
> > > as much as possible the memory carveout sizes, push the "demo firmware"
> > > to request resources the correct way from resource table, and move away
> > > from this dependency and limitations that we have with our firmware.
> 
> I understand this, but my view is that w.r.t firmware only goal should not
> just be tp demonstrate correct way of requesting resources from
> resource-tables, optimize the carve-outs etc but also to demonstrate the
> primary use-cases (camera+ISP+edgeAI) which the device is capable of.
> 
> > > should soon be able to generate our own firmware using Zephyr,  which
> > > Andrew is pioneering, so with this firmware we should move to the
> > > correct direction upstream. Downstream we are still using the memory
> > > carveout sizes that the firmware folk want so desperately to keep, for
> > > now..
> > > 
> > 
> > +1
> > 
> > I have this Zephyr based firmware for AM62A working and it uses the
> > standard IPC regions as specified in this patch. I'll be posting the PR
> > for it in Zephyr upstream by the end of week.
> > 
> 
> I understand this, but will this zephyr based firmware support vision +
> edgeAI analytics ? Does it demonstrate all the unique capabilities of AM62A
> SoC ? If not, then what would be utility of such firmware on AM62A where
> these are the primary use-cases w.r.t AM62A ?
> 
> Why should upstream device-tree use carve-outs which match to this demo
> zephyr based firmware (which apparently not many are using and is not going
> into any official SDK release) instead of official firmwares going into SDK
> ? SDK released firmwares are being used by so many customers and SDK
> documentation maps to it, but zephyr firmware that is being pitched here,
> who would be the potential users and what would be it's utility ?
> 
> [1]: https://www.ti.com/tool/PROCESSOR-SDK-J721E
> 
> Regards
> Devarsh
> 
> > For this patch as it is:
> > 
> > Acked-by: Andrew Davis <afd@ti.com>
> > 
> 
> 
> > Andrew
> > 
> > [0] https://lore.kernel.org/lkml/20241011123922.23135-1-richard@nod.at/
> > [1] https://git.ti.com/cgit/edgeai/meta-edgeai/tree/recipes-kernel/
> > linux/linux-ti-staging/j721e-evm/0001-arm64-dts-ti-Add-DTB-overlays-for-
> > vision-apps-and-ed.patch?h=kirkstone
> > 
> > > ~ Judith
> > > 
> > > > 
> > > > [1]:
> > > > https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/
> > > > arch/arm64/boot/dts/ti/k3-am62a7-sk.dts?h=ti-linux-6.6.y-cicd#n103
> > > > [2]: https://www.ti.com/tool/PROCESSOR-SDK-AM62A
> > > > 
> > > > Regards
> > > > Devarsh
> > > > 
> > > > >       opp-table {
> > > > > @@ -741,3 +771,57 @@ dpi1_out: endpoint {
> > > > >           };
> > > > >       };
> > > > >   };
> > > > > +
> > > > > +&mailbox0_cluster0 {
> > > > > +    status = "okay";
> > > > > +
> > > > > +    mbox_r5_0: mbox-r5-0 {
> > > > > +        ti,mbox-rx = <0 0 0>;
> > > > > +        ti,mbox-tx = <1 0 0>;
> > > > > +    };
> > > > > +};
> > > > > +
> > > > > +&mailbox0_cluster1 {
> > > > > +    status = "okay";
> > > > > +
> > > > > +    mbox_c7x_0: mbox-c7x-0 {
> > > > > +        ti,mbox-rx = <0 0 0>;
> > > > > +        ti,mbox-tx = <1 0 0>;
> > > > > +    };
> > > > > +};
> > > > > +
> > > > > +&mailbox0_cluster2 {
> > > > > +    status = "okay";
> > > > > +
> > > > > +    mbox_mcu_r5_0: mbox-mcu-r5-0 {
> > > > > +        ti,mbox-rx = <0 0 0>;
> > > > > +        ti,mbox-tx = <1 0 0>;
> > > > > +    };
> > > > > +};
> > > > > +
> > > > > +&wkup_r5fss0 {
> > > > > +    status = "okay";
> > > > > +};
> > > > > +
> > > > > +&wkup_r5fss0_core0 {
> > > > > +    mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
> > > > > +    memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
> > > > > +            <&wkup_r5fss0_core0_memory_region>;
> > > > > +};
> > > > > +
> > > > > +&mcu_r5fss0 {
> > > > > +    status = "okay";
> > > > > +};
> > > > > +
> > > > > +&mcu_r5fss0_core0 {
> > > > > +    mboxes = <&mailbox0_cluster2>, <&mbox_mcu_r5_0>;
> > > > > +    memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
> > > > > +            <&mcu_r5fss0_core0_memory_region>;
> > > > > +};
> > > > > +
> > > > > +&c7x_0 {
> > > > > +    mboxes = <&mailbox0_cluster1>, <&mbox_c7x_0>;
> > > > > +    memory-region = <&c7x_0_dma_memory_region>,
> > > > > +            <&c7x_0_memory_region>;
> > > > > +    status = "okay";
> > > > > +};
> > > > 
> > > 
> > 
> 
> 

-- 
Thanks,
Jai

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v6 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Devarsh Thakkar]

Hi Jai,

On 10/04/25 15:48, Jai Luthra wrote:
> Hi Devarsh,
> 
> Thanks for the cc here.

Thanks for the quick comments.

> 
<snip>

> On the basic camera + ISP usecase, afaiu the downstream edgeAI SDK uses
> custom gstreamer elements that make calls to the aforementioned R5 core
> that controls the ISP. On top of that there are additional gstreamer
> patches that are not yet posted upstream for review from the community,
> so the userspace design isn't really set in stone, or upstream-friendly
> yet.
> 

I don't see much relation of carve-outs with Gstreamer or it's pending 
downstream patches. The memory is mainly managed from firmwares (mainly 
openvx layer being used underneath) and there are even non-gstreamer 
pure openvx based use-cases/tests which use these carveouts. At the end 
of the day, the firmwares from the only SDK which is released publicly 
for AM62A uses all these carveouts.


> IMO if that architecture is still under discussion, it might be better
> to keep the edgeAI specific carveouts out of the upstream DTs.. just in
> case the carevouts have to go away, or change significantly.
> 
> If you are sure that the regions and firmware architecture is set in
> stone and won't be updated even if there is a complete redesign of the
> userspace/application level stack for accessing the ISP (let's say u
sing> libcamera), only then it makes sense to add the carveouts right now.


Yes as I said if whole firmware arch is getting updated then better to 
wait. I think probably the firmware team marked in cc can comment on 
that. Moreover I don't see any point of adding only half the regions as 
that would anyway not work with SDK supplied firmwares, for e.g. 
RTOS-to-RTOS ipc test run by firmwares on bootup would fail, along with 
other camera+ISP and AI use-cases.

Regards
Devarsh

>>>>
>>>> I understand your point, currently with this patch remoteproc loading
>>>> will not work for some cores. However, the goal here is to standardize
>>>> as much as possible the memory carveout sizes, push the "demo firmware"
>>>> to request resources the correct way from resource table, and move away
>>>> from this dependency and limitations that we have with our firmware.
>>
>> I understand this, but my view is that w.r.t firmware only goal should not
>> just be tp demonstrate correct way of requesting resources from
>> resource-tables, optimize the carve-outs etc but also to demonstrate the
>> primary use-cases (camera+ISP+edgeAI) which the device is capable of.
>>
>>>> should soon be able to generate our own firmware using Zephyr,  which
>>>> Andrew is pioneering, so with this firmware we should move to the
>>>> correct direction upstream. Downstream we are still using the memory
>>>> carveout sizes that the firmware folk want so desperately to keep, for
>>>> now..
>>>>
>>>
>>> +1
>>>
>>> I have this Zephyr based firmware for AM62A working and it uses the
>>> standard IPC regions as specified in this patch. I'll be posting the PR
>>> for it in Zephyr upstream by the end of week.
>>>
>>
>> I understand this, but will this zephyr based firmware support vision +
>> edgeAI analytics ? Does it demonstrate all the unique capabilities of AM62A
>> SoC ? If not, then what would be utility of such firmware on AM62A where
>> these are the primary use-cases w.r.t AM62A ?
>>
>> Why should upstream device-tree use carve-outs which match to this demo
>> zephyr based firmware (which apparently not many are using and is not going
>> into any official SDK release) instead of official firmwares going into SDK
>> ? SDK released firmwares are being used by so many customers and SDK
>> documentation maps to it, but zephyr firmware that is being pitched here,
>> who would be the potential users and what would be it's utility ?
>>
>> [1]: https://www.ti.com/tool/PROCESSOR-SDK-J721E
>>
>> Regards
>> Devarsh
>>
>>> For this patch as it is:
>>>
>>> Acked-by: Andrew Davis <afd@ti.com>
>>>
>>
>>
>>> Andrew
>>>
>>> [0] https://lore.kernel.org/lkml/20241011123922.23135-1-richard@nod.at/
>>> [1] https://git.ti.com/cgit/edgeai/meta-edgeai/tree/recipes-kernel/
>>> linux/linux-ti-staging/j721e-evm/0001-arm64-dts-ti-Add-DTB-overlays-for-
>>> vision-apps-and-ed.patch?h=kirkstone
>>>
>>>> ~ Judith
>>>>
>>>>>
>>>>> [1]:
>>>>> https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/
>>>>> arch/arm64/boot/dts/ti/k3-am62a7-sk.dts?h=ti-linux-6.6.y-cicd#n103
>>>>> [2]: https://www.ti.com/tool/PROCESSOR-SDK-AM62A
>>>>>
>>>>> Regards
>>>>> Devarsh
>>>>>
>>>>>>        opp-table {
>>>>>> @@ -741,3 +771,57 @@ dpi1_out: endpoint {
>>>>>>            };
>>>>>>        };
>>>>>>    };
>>>>>> +
>>>>>> +&mailbox0_cluster0 {
>>>>>> +    status = "okay";
>>>>>> +
>>>>>> +    mbox_r5_0: mbox-r5-0 {
>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>> +    };
>>>>>> +};
>>>>>> +
>>>>>> +&mailbox0_cluster1 {
>>>>>> +    status = "okay";
>>>>>> +
>>>>>> +    mbox_c7x_0: mbox-c7x-0 {
>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>> +    };
>>>>>> +};
>>>>>> +
>>>>>> +&mailbox0_cluster2 {
>>>>>> +    status = "okay";
>>>>>> +
>>>>>> +    mbox_mcu_r5_0: mbox-mcu-r5-0 {
>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>> +    };
>>>>>> +};
>>>>>> +
>>>>>> +&wkup_r5fss0 {
>>>>>> +    status = "okay";
>>>>>> +};
>>>>>> +
>>>>>> +&wkup_r5fss0_core0 {
>>>>>> +    mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
>>>>>> +    memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
>>>>>> +            <&wkup_r5fss0_core0_memory_region>;
>>>>>> +};
>>>>>> +
>>>>>> +&mcu_r5fss0 {
>>>>>> +    status = "okay";
>>>>>> +};
>>>>>> +
>>>>>> +&mcu_r5fss0_core0 {
>>>>>> +    mboxes = <&mailbox0_cluster2>, <&mbox_mcu_r5_0>;
>>>>>> +    memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
>>>>>> +            <&mcu_r5fss0_core0_memory_region>;
>>>>>> +};
>>>>>> +
>>>>>> +&c7x_0 {
>>>>>> +    mboxes = <&mailbox0_cluster1>, <&mbox_c7x_0>;
>>>>>> +    memory-region = <&c7x_0_dma_memory_region>,
>>>>>> +            <&c7x_0_memory_region>;
>>>>>> +    status = "okay";
>>>>>> +};
>>>>>
>>>>
>>>
>>
>>
> 

Re: [PATCH v6 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Judith Mendez]

Hi Beleswar,

On 4/10/25 3:55 AM, Beleswar Prasad Padhi wrote:
> Hi Judith,
> 
> On 10/04/25 04:02, Judith Mendez wrote:
>> Hi Beleswar,
>>
>> On 4/7/25 11:00 PM, Beleswar Prasad Padhi wrote:
>>> Hi Judith, Andrew,
>>>
>>> On 07/04/25 19:43, Judith Mendez wrote:
>>>> Hi Devarsh,
>>>>
>>>> On 4/7/25 8:54 AM, Devarsh Thakkar wrote:
>>>>> Hi Judith,
>>>>>
>>>>> On 05/04/25 05:45, Judith Mendez wrote:
>>>>>  > From: Devarsh Thakkar <devarsht@ti.com>
>>>>>>
>>>>>
>>>>> Thanks for the patch.
>>>>>
>>>>>> For each remote proc, reserve memory for IPC and bind the mailbox
>>>>>> assignments. Two memory regions are reserved for each remote 
>>>>>> processor.
>>>>>> The first region of 1MB of memory is used for Vring shared buffers
>>>>>> and the second region is used as external memory to the remote 
>>>>>> processor
>>>>>> for the resource table and for tracebuffer allocations.
>>>>>>
>>>>>> Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
>>>>>> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
>>>>>> Signed-off-by: Judith Mendez <jm@ti.com>
>>>>>> ---
>>>>>>   arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 96 
>>>>>> +++++++++++++++++++++++--
>>>>>>   1 file changed, 90 insertions(+), 6 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts 
>>>>>> b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>>>> index 1c9d95696c839..7d817b447c1d0 100644
>>>>>> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>>>> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>>>> @@ -52,6 +52,42 @@ linux,cma {
>>>>>>               linux,cma-default;
>>>>>>           };
>>>>>> +        c7x_0_dma_memory_region: c7x-dma-memory@99800000 {
>>>>>> +            compatible = "shared-dma-pool";
>>>>>> +            reg = <0x00 0x99800000 0x00 0x100000>;
>>>>>> +            no-map;
>>>>>> +        };
>>>>>> +
>>>>>> +        c7x_0_memory_region: c7x-memory@99900000 {
>>>>>> +            compatible = "shared-dma-pool";
>>>>>> +            reg = <0x00 0x99900000 0x00 0xf00000>;
>>>>>> +            no-map;
>>>>>> +        };
>>>>>> +
>>>>>> +        mcu_r5fss0_core0_dma_memory_region: 
>>>>>> r5f-dma-memory@9b800000 {
>>>>>> +            compatible = "shared-dma-pool";
>>>>>> +            reg = <0x00 0x9b800000 0x00 0x100000>;
>>>>>> +            no-map;
>>>>>> +        };
>>>>>> +
>>>>>> +        mcu_r5fss0_core0_memory_region: r5f-dma-memory@9b900000 {
>>>>>> +            compatible = "shared-dma-pool";
>>>>>> +            reg = <0x00 0x9b900000 0x00 0xf00000>;
>>>>>> +            no-map;
>>>>>> +        };
>>>>>> +
>>>>>> +        wkup_r5fss0_core0_dma_memory_region: 
>>>>>> r5f-dma-memory@9c800000 {
>>>>>> +            compatible = "shared-dma-pool";
>>>>>> +            reg = <0x00 0x9c800000 0x00 0x100000>;
>>>>>> +            no-map;
>>>>>> +        };
>>>>>> +
>>>>>> +        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
>>>>>> +            compatible = "shared-dma-pool";
>>>>>> +            reg = <0x00 0x9c900000 0x00 0xf00000>;
>>>>>> +            no-map;
>>>>>> +        };
>>>>>> +
>>>>>>           secure_tfa_ddr: tfa@9e780000 {
>>>>>>               reg = <0x00 0x9e780000 0x00 0x80000>;
>>>>>>               alignment = <0x1000>;
>>>>>> @@ -63,12 +99,6 @@ secure_ddr: optee@9e800000 {
>>>>>>               alignment = <0x1000>;
>>>>>>               no-map;
>>>>>>           };
>>>>>> -
>>>>>> -        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
>>>>>> -            compatible = "shared-dma-pool";
>>>>>> -            reg = <0x00 0x9c900000 0x00 0x01e00000>;
>>>>>> -            no-map;
>>>>>> -        };
>>>>>>       };
>>>>>
>>>>> This is missing the edgeAI specific remote-core carveouts and 
>>>>> RTOS-to-RTOS IPC memory regions [1] being used by edgeAI firmwares 
>>>>> which come as pre-packaged in the official SDK release for AM62A.
>>>>>
>>>>> There is only one official SDK release for AM62A (which is edgeAI 
>>>>> based) [2] which packages these edgeAI remoteproc firmwares and in 
>>>>> my view it is a fair expectation that remote core careveouts in 
>>>>> device-tree should align with firmwares released in SDK.
>>>>>
>>>>> This is because most developers (including me) and vendors download 
>>>>> this official SDK release and use it with latest upstream kernel 
>>>>> and modules (right now we are applying required patches locally) 
>>>>> and this patch won't suffice for this, in-fact it won't work since 
>>>>> the remoteproc firmwares are already using regions beyond the 
>>>>> reserved-regions from this patch.
>>>>
>>>> I understand your point, currently with this patch remoteproc loading
>>>> will not work for some cores. However, the goal here is to standardize
>>>> as much as possible the memory carveout sizes, push the "demo firmware"
>>>> to request resources the correct way from resource table, 
>>>
>>>
>>> It is indeed more suitable if the memory carveouts are called out in 
>>> the resource table of the firmware. But you will still need to 
>>> reserve that memory sections in the Device Tree so that Kernel does 
>>> not map that memory for anything else. So I am thinking how moving to 
>>> resource table will help solve this problem?
>>
>> The point is that our default FW is doing things incorrectly. We want to
>> push the existing FW to
>> 1. Request resources via resource table.
>> 2. Fix their memory requirements (recent offline discussion proved that
>> FW is requesting more than it needs)
>> 3. FW should adapt to Linux not Linux adapt to FW
> 
> 
> Thanks. I also agree with you on all of the above points for a standard 
> firmware.
> 
> However, I was referring to this problem:
> Can we get rid of static reserved memory carveouts in DT?
> People using a custom firmware will have to patch the Device Tree to 
> reserve larger/different memory regions. Is there some way where the 
> firmware can dictate the "reserved" memory carveouts at runtime? Memory 
> carveouts can be announced through Resource Table, but there is no 
> guarantee we will be able to allocate it (it could be mapped by the 
> Kernel for some other alloc), unless its pre-reserved in DT.
> 

Since we do not have an IOMMU for remote cores in K3, we cannot get rid
of the static reserved memory carveouts, is my understanding. The linux
driver would have programmed the IOMMU virtual and physical addresses
and it would have been able to do the virtual to physical address
translation on its own with only the requirement size from the FW
resource table. Since we do not have this flexibility provided with
IOMMU, we must have static reserved carveouts so that Linux will not
touch these memory regions. The firmware virtual address to physical
adress is atm a one to one mapping. So in summary, we must have these
static reserved memory carveouts, but we should fix the default FW
to use the "standardized" sizes and request SRAM via resource table.

~ Judith


> Thanks,
> Beleswar
> 
>>
>> If not, then then we should try to move to Zephyr firmware or other/
>> better options.
>>
>> Hope I am able to explain myself better this time around.
>>
>> ~ Judith
>>
>>>
>>> Thanks,
>>> Beleswar
>>>
>>>> and move away
>>>> from this dependency and limitations that we have with our firmware. We
>>>> should soon be able to generate our own firmware using Zephyr, which
>>>> Andrew is pioneering, so with this firmware we should move to the
>>>> correct direction upstream. Downstream we are still using the memory
>>>> carveout sizes that the firmware folk want so desperately to keep, for
>>>> now..
>>>>
>>>> ~ Judith
>>>>
>>>>>
>>>>> [1]: 
>>>>> https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts?h=ti-linux-6.6.y-cicd#n103
>>>>> [2]: https://www.ti.com/tool/PROCESSOR-SDK-AM62A
>>>>>
>>>>> Regards
>>>>> Devarsh
>>>>>
>>>>>>       opp-table {
>>>>>> @@ -741,3 +771,57 @@ dpi1_out: endpoint {
>>>>>>           };
>>>>>>       };
>>>>>>   };
>>>>>> +
>>>>>> +&mailbox0_cluster0 {
>>>>>> +    status = "okay";
>>>>>> +
>>>>>> +    mbox_r5_0: mbox-r5-0 {
>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>> +    };
>>>>>> +};
>>>>>> +
>>>>>> +&mailbox0_cluster1 {
>>>>>> +    status = "okay";
>>>>>> +
>>>>>> +    mbox_c7x_0: mbox-c7x-0 {
>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>> +    };
>>>>>> +};
>>>>>> +
>>>>>> +&mailbox0_cluster2 {
>>>>>> +    status = "okay";
>>>>>> +
>>>>>> +    mbox_mcu_r5_0: mbox-mcu-r5-0 {
>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>> +    };
>>>>>> +};
>>>>>> +
>>>>>> +&wkup_r5fss0 {
>>>>>> +    status = "okay";
>>>>>> +};
>>>>>> +
>>>>>> +&wkup_r5fss0_core0 {
>>>>>> +    mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
>>>>>> +    memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
>>>>>> +            <&wkup_r5fss0_core0_memory_region>;
>>>>>> +};
>>>>>> +
>>>>>> +&mcu_r5fss0 {
>>>>>> +    status = "okay";
>>>>>> +};
>>>>>> +
>>>>>> +&mcu_r5fss0_core0 {
>>>>>> +    mboxes = <&mailbox0_cluster2>, <&mbox_mcu_r5_0>;
>>>>>> +    memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
>>>>>> +            <&mcu_r5fss0_core0_memory_region>;
>>>>>> +};
>>>>>> +
>>>>>> +&c7x_0 {
>>>>>> +    mboxes = <&mailbox0_cluster1>, <&mbox_c7x_0>;
>>>>>> +    memory-region = <&c7x_0_dma_memory_region>,
>>>>>> +            <&c7x_0_memory_region>;
>>>>>> +    status = "okay";
>>>>>> +};
>>>>>
>>>>
>>

Re: [PATCH v6 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Andrew Davis]

On 4/10/25 3:55 AM, Beleswar Prasad Padhi wrote:
> Hi Judith,
> 
> On 10/04/25 04:02, Judith Mendez wrote:
>> Hi Beleswar,
>>
>> On 4/7/25 11:00 PM, Beleswar Prasad Padhi wrote:
>>> Hi Judith, Andrew,
>>>
>>> On 07/04/25 19:43, Judith Mendez wrote:
>>>> Hi Devarsh,
>>>>
>>>> On 4/7/25 8:54 AM, Devarsh Thakkar wrote:
>>>>> Hi Judith,
>>>>>
>>>>> On 05/04/25 05:45, Judith Mendez wrote:
>>>>>  > From: Devarsh Thakkar <devarsht@ti.com>
>>>>>>
>>>>>
>>>>> Thanks for the patch.
>>>>>
>>>>>> For each remote proc, reserve memory for IPC and bind the mailbox
>>>>>> assignments. Two memory regions are reserved for each remote processor.
>>>>>> The first region of 1MB of memory is used for Vring shared buffers
>>>>>> and the second region is used as external memory to the remote processor
>>>>>> for the resource table and for tracebuffer allocations.
>>>>>>
>>>>>> Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
>>>>>> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
>>>>>> Signed-off-by: Judith Mendez <jm@ti.com>
>>>>>> ---
>>>>>>   arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 96 +++++++++++++++++++++++--
>>>>>>   1 file changed, 90 insertions(+), 6 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>>>> index 1c9d95696c839..7d817b447c1d0 100644
>>>>>> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>>>> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>>>> @@ -52,6 +52,42 @@ linux,cma {
>>>>>>               linux,cma-default;
>>>>>>           };
>>>>>> +        c7x_0_dma_memory_region: c7x-dma-memory@99800000 {
>>>>>> +            compatible = "shared-dma-pool";
>>>>>> +            reg = <0x00 0x99800000 0x00 0x100000>;
>>>>>> +            no-map;
>>>>>> +        };
>>>>>> +
>>>>>> +        c7x_0_memory_region: c7x-memory@99900000 {
>>>>>> +            compatible = "shared-dma-pool";
>>>>>> +            reg = <0x00 0x99900000 0x00 0xf00000>;
>>>>>> +            no-map;
>>>>>> +        };
>>>>>> +
>>>>>> +        mcu_r5fss0_core0_dma_memory_region: r5f-dma-memory@9b800000 {
>>>>>> +            compatible = "shared-dma-pool";
>>>>>> +            reg = <0x00 0x9b800000 0x00 0x100000>;
>>>>>> +            no-map;
>>>>>> +        };
>>>>>> +
>>>>>> +        mcu_r5fss0_core0_memory_region: r5f-dma-memory@9b900000 {
>>>>>> +            compatible = "shared-dma-pool";
>>>>>> +            reg = <0x00 0x9b900000 0x00 0xf00000>;
>>>>>> +            no-map;
>>>>>> +        };
>>>>>> +
>>>>>> +        wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9c800000 {
>>>>>> +            compatible = "shared-dma-pool";
>>>>>> +            reg = <0x00 0x9c800000 0x00 0x100000>;
>>>>>> +            no-map;
>>>>>> +        };
>>>>>> +
>>>>>> +        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
>>>>>> +            compatible = "shared-dma-pool";
>>>>>> +            reg = <0x00 0x9c900000 0x00 0xf00000>;
>>>>>> +            no-map;
>>>>>> +        };
>>>>>> +
>>>>>>           secure_tfa_ddr: tfa@9e780000 {
>>>>>>               reg = <0x00 0x9e780000 0x00 0x80000>;
>>>>>>               alignment = <0x1000>;
>>>>>> @@ -63,12 +99,6 @@ secure_ddr: optee@9e800000 {
>>>>>>               alignment = <0x1000>;
>>>>>>               no-map;
>>>>>>           };
>>>>>> -
>>>>>> -        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
>>>>>> -            compatible = "shared-dma-pool";
>>>>>> -            reg = <0x00 0x9c900000 0x00 0x01e00000>;
>>>>>> -            no-map;
>>>>>> -        };
>>>>>>       };
>>>>>
>>>>> This is missing the edgeAI specific remote-core carveouts and RTOS-to-RTOS IPC memory regions [1] being used by edgeAI firmwares which come as pre-packaged in the official SDK release for AM62A.
>>>>>
>>>>> There is only one official SDK release for AM62A (which is edgeAI based) [2] which packages these edgeAI remoteproc firmwares and in my view it is a fair expectation that remote core careveouts in device-tree should align with firmwares released in SDK.
>>>>>
>>>>> This is because most developers (including me) and vendors download this official SDK release and use it with latest upstream kernel and modules (right now we are applying required patches locally) and this patch won't suffice for this, in-fact it won't work since the remoteproc firmwares are already using regions beyond the reserved-regions from this patch.
>>>>
>>>> I understand your point, currently with this patch remoteproc loading
>>>> will not work for some cores. However, the goal here is to standardize
>>>> as much as possible the memory carveout sizes, push the "demo firmware"
>>>> to request resources the correct way from resource table, 
>>>
>>>
>>> It is indeed more suitable if the memory carveouts are called out in the resource table of the firmware. But you will still need to reserve that memory sections in the Device Tree so that Kernel does not map that memory for anything else. So I am thinking how moving to resource table will help solve this problem?
>>
>> The point is that our default FW is doing things incorrectly. We want to
>> push the existing FW to
>> 1. Request resources via resource table.
>> 2. Fix their memory requirements (recent offline discussion proved that
>> FW is requesting more than it needs)
>> 3. FW should adapt to Linux not Linux adapt to FW
> 
> 
> Thanks. I also agree with you on all of the above points for a standard firmware.
> 
> However, I was referring to this problem:
> Can we get rid of static reserved memory carveouts in DT?
> People using a custom firmware will have to patch the Device Tree to reserve larger/different memory regions. Is there some way where the firmware can dictate the "reserved" memory carveouts at runtime? Memory carveouts can be announced through Resource Table, but there is no guarantee we will be able to allocate it (it could be mapped by the Kernel for some other alloc), unless its pre-reserved in DT.

That's the neat thing about the RSC_CARVEOUT item in the resource table,
it works both ways. The firmware can request a static address, or it can
use FW_RSC_ADDR_ANY for the address and Linux will go and dynamically
allocate it a region. Then it passes this info back to the firmware by
updating the resource table in memory. Firmware can then simply read this
carveout address from its resource table and start using it.

The only time we need a static addresses would be for code sections as
they are not relocatable (yet). And that is the reason we have the
minimal carveouts we are adding in this patch. Code goes here. And
these carveouts are 15MB! No firmware I know of has 15MB of *code*
section.

As we found in the offline discussion, even our largest firmware
doesn't use near that much space. What that firmware is doing is picking
some spots in DRAM for its heap and buffer areas, and without coordinating
with Linux, just starts using that memory. We have to then go into DT and
carveout all these ranges to avoid stepping on the firmware heaps from
Linux.

With these firmware heap/buffer memory static carveouts we have to account
for the worst case and statically carve out enough memory for the largest
possible amount of memory a firmware could ever use. In some firmware
we ship today this is +2GB! So why should every user of this board lose
all this memory when they might happen to be using a more sane firmware
that doesn't use so much (like my Zephyr firmware), or if their firmware
doesn't need any heap at all (like some other firmware we have).

Andrew

> 
> Thanks,
> Beleswar
> 
>>
>> If not, then then we should try to move to Zephyr firmware or other/
>> better options.
>>
>> Hope I am able to explain myself better this time around.
>>
>> ~ Judith
>>
>>>
>>> Thanks,
>>> Beleswar
>>>
>>>> and move away
>>>> from this dependency and limitations that we have with our firmware. We
>>>> should soon be able to generate our own firmware using Zephyr, which
>>>> Andrew is pioneering, so with this firmware we should move to the
>>>> correct direction upstream. Downstream we are still using the memory
>>>> carveout sizes that the firmware folk want so desperately to keep, for
>>>> now..
>>>>
>>>> ~ Judith
>>>>
>>>>>
>>>>> [1]: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts?h=ti-linux-6.6.y-cicd#n103
>>>>> [2]: https://www.ti.com/tool/PROCESSOR-SDK-AM62A
>>>>>
>>>>> Regards
>>>>> Devarsh
>>>>>
>>>>>>       opp-table {
>>>>>> @@ -741,3 +771,57 @@ dpi1_out: endpoint {
>>>>>>           };
>>>>>>       };
>>>>>>   };
>>>>>> +
>>>>>> +&mailbox0_cluster0 {
>>>>>> +    status = "okay";
>>>>>> +
>>>>>> +    mbox_r5_0: mbox-r5-0 {
>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>> +    };
>>>>>> +};
>>>>>> +
>>>>>> +&mailbox0_cluster1 {
>>>>>> +    status = "okay";
>>>>>> +
>>>>>> +    mbox_c7x_0: mbox-c7x-0 {
>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>> +    };
>>>>>> +};
>>>>>> +
>>>>>> +&mailbox0_cluster2 {
>>>>>> +    status = "okay";
>>>>>> +
>>>>>> +    mbox_mcu_r5_0: mbox-mcu-r5-0 {
>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>> +    };
>>>>>> +};
>>>>>> +
>>>>>> +&wkup_r5fss0 {
>>>>>> +    status = "okay";
>>>>>> +};
>>>>>> +
>>>>>> +&wkup_r5fss0_core0 {
>>>>>> +    mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
>>>>>> +    memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
>>>>>> +            <&wkup_r5fss0_core0_memory_region>;
>>>>>> +};
>>>>>> +
>>>>>> +&mcu_r5fss0 {
>>>>>> +    status = "okay";
>>>>>> +};
>>>>>> +
>>>>>> +&mcu_r5fss0_core0 {
>>>>>> +    mboxes = <&mailbox0_cluster2>, <&mbox_mcu_r5_0>;
>>>>>> +    memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
>>>>>> +            <&mcu_r5fss0_core0_memory_region>;
>>>>>> +};
>>>>>> +
>>>>>> +&c7x_0 {
>>>>>> +    mboxes = <&mailbox0_cluster1>, <&mbox_c7x_0>;
>>>>>> +    memory-region = <&c7x_0_dma_memory_region>,
>>>>>> +            <&c7x_0_memory_region>;
>>>>>> +    status = "okay";
>>>>>> +};
>>>>>
>>>>
>>

Re: [PATCH v6 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Andrew Davis]

On 4/10/25 6:38 AM, Devarsh Thakkar wrote:
> Hi Jai,
> 
> On 10/04/25 15:48, Jai Luthra wrote:
>> Hi Devarsh,
>>
>> Thanks for the cc here.
> 
> Thanks for the quick comments.
> 
>>
> <snip>
> 
>> On the basic camera + ISP usecase, afaiu the downstream edgeAI SDK uses
>> custom gstreamer elements that make calls to the aforementioned R5 core
>> that controls the ISP. On top of that there are additional gstreamer
>> patches that are not yet posted upstream for review from the community,
>> so the userspace design isn't really set in stone, or upstream-friendly
>> yet.
>>
> 
> I don't see much relation of carve-outs with Gstreamer or it's pending downstream patches. The memory is mainly managed from firmwares (mainly openvx layer being used underneath) and there are even non-gstreamer pure openvx based use-cases/tests which use these carveouts. At the end of the day, the firmwares from the only SDK which is released publicly for AM62A uses all these carveouts.
> 

These are programmable cores, you can run whatever you want on them. You can
make your own firmware if you like, we have support for them in our MCU+(FreeRTOS)
offering today[0](look at all these firmware you can build/run!).

In a week or so I'll start pushing support for these cores into Zephyr,
bringing in even more firmware options for these cores.

I simply do not see why one firmware, shipped with one of our SDKs*, doing
things wrong should force us to hack up our DT here in upstream Linux.

*Speaking of the "only" SDK's firmware, if you take our Yocto meta-ti layer and
build an SDK yourself, you get firmware by default that *doesn't need extra
carveouts*! [1][2]

Andrew

[0] https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/makefile.am62ax
[1] https://git.yoctoproject.org/meta-ti/tree/meta-ti-bsp/recipes-bsp/ti-rtos-fw/ti-rtos-echo-test-fw.bb
[2] https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tree/ti-ipc/am62axx?h=ti-linux-firmware

> 
>> IMO if that architecture is still under discussion, it might be better
>> to keep the edgeAI specific carveouts out of the upstream DTs.. just in
>> case the carevouts have to go away, or change significantly.
>>
>> If you are sure that the regions and firmware architecture is set in
>> stone and won't be updated even if there is a complete redesign of the
>> userspace/application level stack for accessing the ISP (let's say u
> sing> libcamera), only then it makes sense to add the carveouts right now.
> 
> 
> Yes as I said if whole firmware arch is getting updated then better to wait. I think probably the firmware team marked in cc can comment on that. Moreover I don't see any point of adding only half the regions as that would anyway not work with SDK supplied firmwares, for e.g. RTOS-to-RTOS ipc test run by firmwares on bootup would fail, along with other camera+ISP and AI use-cases.
> 
> Regards
> Devarsh
> 
>>>>>
>>>>> I understand your point, currently with this patch remoteproc loading
>>>>> will not work for some cores. However, the goal here is to standardize
>>>>> as much as possible the memory carveout sizes, push the "demo firmware"
>>>>> to request resources the correct way from resource table, and move away
>>>>> from this dependency and limitations that we have with our firmware.
>>>
>>> I understand this, but my view is that w.r.t firmware only goal should not
>>> just be tp demonstrate correct way of requesting resources from
>>> resource-tables, optimize the carve-outs etc but also to demonstrate the
>>> primary use-cases (camera+ISP+edgeAI) which the device is capable of.
>>>
>>>>> should soon be able to generate our own firmware using Zephyr,  which
>>>>> Andrew is pioneering, so with this firmware we should move to the
>>>>> correct direction upstream. Downstream we are still using the memory
>>>>> carveout sizes that the firmware folk want so desperately to keep, for
>>>>> now..
>>>>>
>>>>
>>>> +1
>>>>
>>>> I have this Zephyr based firmware for AM62A working and it uses the
>>>> standard IPC regions as specified in this patch. I'll be posting the PR
>>>> for it in Zephyr upstream by the end of week.
>>>>
>>>
>>> I understand this, but will this zephyr based firmware support vision +
>>> edgeAI analytics ? Does it demonstrate all the unique capabilities of AM62A
>>> SoC ? If not, then what would be utility of such firmware on AM62A where
>>> these are the primary use-cases w.r.t AM62A ?
>>>
>>> Why should upstream device-tree use carve-outs which match to this demo
>>> zephyr based firmware (which apparently not many are using and is not going
>>> into any official SDK release) instead of official firmwares going into SDK
>>> ? SDK released firmwares are being used by so many customers and SDK
>>> documentation maps to it, but zephyr firmware that is being pitched here,
>>> who would be the potential users and what would be it's utility ?
>>>
>>> [1]: https://www.ti.com/tool/PROCESSOR-SDK-J721E
>>>
>>> Regards
>>> Devarsh
>>>
>>>> For this patch as it is:
>>>>
>>>> Acked-by: Andrew Davis <afd@ti.com>
>>>>
>>>
>>>
>>>> Andrew
>>>>
>>>> [0] https://lore.kernel.org/lkml/20241011123922.23135-1-richard@nod.at/
>>>> [1] https://git.ti.com/cgit/edgeai/meta-edgeai/tree/recipes-kernel/
>>>> linux/linux-ti-staging/j721e-evm/0001-arm64-dts-ti-Add-DTB-overlays-for-
>>>> vision-apps-and-ed.patch?h=kirkstone
>>>>
>>>>> ~ Judith
>>>>>
>>>>>>
>>>>>> [1]:
>>>>>> https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/
>>>>>> arch/arm64/boot/dts/ti/k3-am62a7-sk.dts?h=ti-linux-6.6.y-cicd#n103
>>>>>> [2]: https://www.ti.com/tool/PROCESSOR-SDK-AM62A
>>>>>>
>>>>>> Regards
>>>>>> Devarsh
>>>>>>
>>>>>>>        opp-table {
>>>>>>> @@ -741,3 +771,57 @@ dpi1_out: endpoint {
>>>>>>>            };
>>>>>>>        };
>>>>>>>    };
>>>>>>> +
>>>>>>> +&mailbox0_cluster0 {
>>>>>>> +    status = "okay";
>>>>>>> +
>>>>>>> +    mbox_r5_0: mbox-r5-0 {
>>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>>> +    };
>>>>>>> +};
>>>>>>> +
>>>>>>> +&mailbox0_cluster1 {
>>>>>>> +    status = "okay";
>>>>>>> +
>>>>>>> +    mbox_c7x_0: mbox-c7x-0 {
>>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>>> +    };
>>>>>>> +};
>>>>>>> +
>>>>>>> +&mailbox0_cluster2 {
>>>>>>> +    status = "okay";
>>>>>>> +
>>>>>>> +    mbox_mcu_r5_0: mbox-mcu-r5-0 {
>>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>>> +    };
>>>>>>> +};
>>>>>>> +
>>>>>>> +&wkup_r5fss0 {
>>>>>>> +    status = "okay";
>>>>>>> +};
>>>>>>> +
>>>>>>> +&wkup_r5fss0_core0 {
>>>>>>> +    mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
>>>>>>> +    memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
>>>>>>> +            <&wkup_r5fss0_core0_memory_region>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&mcu_r5fss0 {
>>>>>>> +    status = "okay";
>>>>>>> +};
>>>>>>> +
>>>>>>> +&mcu_r5fss0_core0 {
>>>>>>> +    mboxes = <&mailbox0_cluster2>, <&mbox_mcu_r5_0>;
>>>>>>> +    memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
>>>>>>> +            <&mcu_r5fss0_core0_memory_region>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&c7x_0 {
>>>>>>> +    mboxes = <&mailbox0_cluster1>, <&mbox_c7x_0>;
>>>>>>> +    memory-region = <&c7x_0_dma_memory_region>,
>>>>>>> +            <&c7x_0_memory_region>;
>>>>>>> +    status = "okay";
>>>>>>> +};
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
> 

Re: [PATCH v6 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Beleswar Prasad Padhi]

Hi Andrew,

On 10/04/25 23:20, Andrew Davis wrote:
> On 4/10/25 3:55 AM, Beleswar Prasad Padhi wrote:
>> Hi Judith,
>>
>> On 10/04/25 04:02, Judith Mendez wrote:
>>> Hi Beleswar,
>>>
>>> On 4/7/25 11:00 PM, Beleswar Prasad Padhi wrote:
>>>> Hi Judith, Andrew,
>>>>
>>>> On 07/04/25 19:43, Judith Mendez wrote:
>>>>> Hi Devarsh,
>>>>>
>>>>> On 4/7/25 8:54 AM, Devarsh Thakkar wrote:
>>>>>> Hi Judith,
>>>>>>
>>>>>> On 05/04/25 05:45, Judith Mendez wrote:
>>>>>>  > From: Devarsh Thakkar <devarsht@ti.com>
>>>>>>>
>>>>>>
>>>>>> Thanks for the patch.
>>>>>>
>>>>>>> For each remote proc, reserve memory for IPC and bind the mailbox
>>>>>>> assignments. Two memory regions are reserved for each remote 
>>>>>>> processor.
>>>>>>> The first region of 1MB of memory is used for Vring shared buffers
>>>>>>> and the second region is used as external memory to the remote 
>>>>>>> processor
>>>>>>> for the resource table and for tracebuffer allocations.
>>>>>>>
>>>>>>> Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
>>>>>>> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
>>>>>>> Signed-off-by: Judith Mendez <jm@ti.com>
>>>>>>> ---
>>>>>>>   arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 96 
>>>>>>> +++++++++++++++++++++++--
>>>>>>>   1 file changed, 90 insertions(+), 6 deletions(-)
>>>>>>>
>>>>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts 
>>>>>>> b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>>>>> index 1c9d95696c839..7d817b447c1d0 100644
>>>>>>> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>>>>> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>>>>> @@ -52,6 +52,42 @@ linux,cma {
>>>>>>>               linux,cma-default;
>>>>>>>           };
>>>>>>> +        c7x_0_dma_memory_region: c7x-dma-memory@99800000 {
>>>>>>> +            compatible = "shared-dma-pool";
>>>>>>> +            reg = <0x00 0x99800000 0x00 0x100000>;
>>>>>>> +            no-map;
>>>>>>> +        };
>>>>>>> +
>>>>>>> +        c7x_0_memory_region: c7x-memory@99900000 {
>>>>>>> +            compatible = "shared-dma-pool";
>>>>>>> +            reg = <0x00 0x99900000 0x00 0xf00000>;
>>>>>>> +            no-map;
>>>>>>> +        };
>>>>>>> +
>>>>>>> +        mcu_r5fss0_core0_dma_memory_region: 
>>>>>>> r5f-dma-memory@9b800000 {
>>>>>>> +            compatible = "shared-dma-pool";
>>>>>>> +            reg = <0x00 0x9b800000 0x00 0x100000>;
>>>>>>> +            no-map;
>>>>>>> +        };
>>>>>>> +
>>>>>>> +        mcu_r5fss0_core0_memory_region: r5f-dma-memory@9b900000 {
>>>>>>> +            compatible = "shared-dma-pool";
>>>>>>> +            reg = <0x00 0x9b900000 0x00 0xf00000>;
>>>>>>> +            no-map;
>>>>>>> +        };
>>>>>>> +
>>>>>>> +        wkup_r5fss0_core0_dma_memory_region: 
>>>>>>> r5f-dma-memory@9c800000 {
>>>>>>> +            compatible = "shared-dma-pool";
>>>>>>> +            reg = <0x00 0x9c800000 0x00 0x100000>;
>>>>>>> +            no-map;
>>>>>>> +        };
>>>>>>> +
>>>>>>> +        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
>>>>>>> +            compatible = "shared-dma-pool";
>>>>>>> +            reg = <0x00 0x9c900000 0x00 0xf00000>;
>>>>>>> +            no-map;
>>>>>>> +        };
>>>>>>> +
>>>>>>>           secure_tfa_ddr: tfa@9e780000 {
>>>>>>>               reg = <0x00 0x9e780000 0x00 0x80000>;
>>>>>>>               alignment = <0x1000>;
>>>>>>> @@ -63,12 +99,6 @@ secure_ddr: optee@9e800000 {
>>>>>>>               alignment = <0x1000>;
>>>>>>>               no-map;
>>>>>>>           };
>>>>>>> -
>>>>>>> -        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
>>>>>>> -            compatible = "shared-dma-pool";
>>>>>>> -            reg = <0x00 0x9c900000 0x00 0x01e00000>;
>>>>>>> -            no-map;
>>>>>>> -        };
>>>>>>>       };
>>>>>>
>>>>>> This is missing the edgeAI specific remote-core carveouts and 
>>>>>> RTOS-to-RTOS IPC memory regions [1] being used by edgeAI 
>>>>>> firmwares which come as pre-packaged in the official SDK release 
>>>>>> for AM62A.
>>>>>>
>>>>>> There is only one official SDK release for AM62A (which is edgeAI 
>>>>>> based) [2] which packages these edgeAI remoteproc firmwares and 
>>>>>> in my view it is a fair expectation that remote core careveouts 
>>>>>> in device-tree should align with firmwares released in SDK.
>>>>>>
>>>>>> This is because most developers (including me) and vendors 
>>>>>> download this official SDK release and use it with latest 
>>>>>> upstream kernel and modules (right now we are applying required 
>>>>>> patches locally) and this patch won't suffice for this, in-fact 
>>>>>> it won't work since the remoteproc firmwares are already using 
>>>>>> regions beyond the reserved-regions from this patch.
>>>>>
>>>>> I understand your point, currently with this patch remoteproc loading
>>>>> will not work for some cores. However, the goal here is to 
>>>>> standardize
>>>>> as much as possible the memory carveout sizes, push the "demo 
>>>>> firmware"
>>>>> to request resources the correct way from resource table, 
>>>>
>>>>
>>>> It is indeed more suitable if the memory carveouts are called out 
>>>> in the resource table of the firmware. But you will still need to 
>>>> reserve that memory sections in the Device Tree so that Kernel does 
>>>> not map that memory for anything else. So I am thinking how moving 
>>>> to resource table will help solve this problem?
>>>
>>> The point is that our default FW is doing things incorrectly. We 
>>> want to
>>> push the existing FW to
>>> 1. Request resources via resource table.
>>> 2. Fix their memory requirements (recent offline discussion proved that
>>> FW is requesting more than it needs)
>>> 3. FW should adapt to Linux not Linux adapt to FW
>>
>>
>> Thanks. I also agree with you on all of the above points for a 
>> standard firmware.
>>
>> However, I was referring to this problem:
>> Can we get rid of static reserved memory carveouts in DT?
>> People using a custom firmware will have to patch the Device Tree to 
>> reserve larger/different memory regions. Is there some way where the 
>> firmware can dictate the "reserved" memory carveouts at runtime? 
>> Memory carveouts can be announced through Resource Table, but there 
>> is no guarantee we will be able to allocate it (it could be mapped by 
>> the Kernel for some other alloc), unless its pre-reserved in DT.
>
> That's the neat thing about the RSC_CARVEOUT item in the resource table,
> it works both ways. The firmware can request a static address, or it can
> use FW_RSC_ADDR_ANY for the address and Linux will go and dynamically
> allocate it a region. Then it passes this info back to the firmware by
> updating the resource table in memory. Firmware can then simply read this
> carveout address from its resource table and start using it.


Ah yes, I forgot about that. We already use FW_RSC_ADDR_ANY for VRING
allocations. We can scale it to memory carveouts in the similar way. Thanks.

>
> The only time we need a static addresses would be for code sections as
> they are not relocatable (yet). And that is the reason we have the
> minimal carveouts we are adding in this patch. Code goes here. And
> these carveouts are 15MB! No firmware I know of has 15MB of *code*
> section.
>
> As we found in the offline discussion, even our largest firmware
> doesn't use near that much space. What that firmware is doing is picking
> some spots in DRAM for its heap and buffer areas, and without 
> coordinating
> with Linux, just starts using that memory. We have to then go into DT and
> carveout all these ranges to avoid stepping on the firmware heaps from
> Linux.


Yeah I have found this as well. All of those heap/buffer areas should be 
moved
to the resource table now.

>
> With these firmware heap/buffer memory static carveouts we have to 
> account
> for the worst case and statically carve out enough memory for the largest
> possible amount of memory a firmware could ever use. In some firmware
> we ship today this is +2GB! So why should every user of this board lose
> all this memory when they might happen to be using a more sane firmware
> that doesn't use so much (like my Zephyr firmware), or if their firmware
> doesn't need any heap at all (like some other firmware we have).


Agreed on your point.

Thanks,
Beleswar

>
> Andrew
>
>>
>> Thanks,
>> Beleswar
>>
>>>
>>> If not, then then we should try to move to Zephyr firmware or other/
>>> better options.
>>>
>>> Hope I am able to explain myself better this time around.
>>>
>>> ~ Judith
>>>
>>>>
>>>> Thanks,
>>>> Beleswar
>>>>
>>>>> and move away
>>>>> from this dependency and limitations that we have with our 
>>>>> firmware. We
>>>>> should soon be able to generate our own firmware using Zephyr, which
>>>>> Andrew is pioneering, so with this firmware we should move to the
>>>>> correct direction upstream. Downstream we are still using the memory
>>>>> carveout sizes that the firmware folk want so desperately to keep, 
>>>>> for
>>>>> now..
>>>>>
>>>>> ~ Judith
>>>>>
>>>>>>
>>>>>> [1]: 
>>>>>> https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts?h=ti-linux-6.6.y-cicd#n103
>>>>>> [2]: https://www.ti.com/tool/PROCESSOR-SDK-AM62A
>>>>>>
>>>>>> Regards
>>>>>> Devarsh
>>>>>>
>>>>>>>       opp-table {
>>>>>>> @@ -741,3 +771,57 @@ dpi1_out: endpoint {
>>>>>>>           };
>>>>>>>       };
>>>>>>>   };
>>>>>>> +
>>>>>>> +&mailbox0_cluster0 {
>>>>>>> +    status = "okay";
>>>>>>> +
>>>>>>> +    mbox_r5_0: mbox-r5-0 {
>>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>>> +    };
>>>>>>> +};
>>>>>>> +
>>>>>>> +&mailbox0_cluster1 {
>>>>>>> +    status = "okay";
>>>>>>> +
>>>>>>> +    mbox_c7x_0: mbox-c7x-0 {
>>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>>> +    };
>>>>>>> +};
>>>>>>> +
>>>>>>> +&mailbox0_cluster2 {
>>>>>>> +    status = "okay";
>>>>>>> +
>>>>>>> +    mbox_mcu_r5_0: mbox-mcu-r5-0 {
>>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>>> +    };
>>>>>>> +};
>>>>>>> +
>>>>>>> +&wkup_r5fss0 {
>>>>>>> +    status = "okay";
>>>>>>> +};
>>>>>>> +
>>>>>>> +&wkup_r5fss0_core0 {
>>>>>>> +    mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
>>>>>>> +    memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
>>>>>>> + <&wkup_r5fss0_core0_memory_region>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&mcu_r5fss0 {
>>>>>>> +    status = "okay";
>>>>>>> +};
>>>>>>> +
>>>>>>> +&mcu_r5fss0_core0 {
>>>>>>> +    mboxes = <&mailbox0_cluster2>, <&mbox_mcu_r5_0>;
>>>>>>> +    memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
>>>>>>> + <&mcu_r5fss0_core0_memory_region>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&c7x_0 {
>>>>>>> +    mboxes = <&mailbox0_cluster1>, <&mbox_c7x_0>;
>>>>>>> +    memory-region = <&c7x_0_dma_memory_region>,
>>>>>>> +            <&c7x_0_memory_region>;
>>>>>>> +    status = "okay";
>>>>>>> +};
>>>>>>
>>>>>
>>>

Re: [PATCH v6 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Beleswar Prasad Padhi]

Hi Judith,

On 10/04/25 23:14, Judith Mendez wrote:
> Hi Beleswar,
>
> On 4/10/25 3:55 AM, Beleswar Prasad Padhi wrote:
>> Hi Judith,
>>
>> On 10/04/25 04:02, Judith Mendez wrote:
>>> Hi Beleswar,
>>>
>>> On 4/7/25 11:00 PM, Beleswar Prasad Padhi wrote:
>>>> Hi Judith, Andrew,
>>>>
>>>> On 07/04/25 19:43, Judith Mendez wrote:
>>>>> Hi Devarsh,
>>>>>
>>>>> On 4/7/25 8:54 AM, Devarsh Thakkar wrote:
>>>>>> Hi Judith,
>>>>>>
>>>>>> On 05/04/25 05:45, Judith Mendez wrote:
>>>>>>  > From: Devarsh Thakkar <devarsht@ti.com>
>>>>>>>
>>>>>>
>>>>>> Thanks for the patch.
>>>>>>
>>>>>>> For each remote proc, reserve memory for IPC and bind the mailbox
>>>>>>> assignments. Two memory regions are reserved for each remote 
>>>>>>> processor.
>>>>>>> The first region of 1MB of memory is used for Vring shared buffers
>>>>>>> and the second region is used as external memory to the remote 
>>>>>>> processor
>>>>>>> for the resource table and for tracebuffer allocations.
>>>>>>>
>>>>>>> Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
>>>>>>> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
>>>>>>> Signed-off-by: Judith Mendez <jm@ti.com>
>>>>>>> ---
>>>>>>>   arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 96 
>>>>>>> +++++++++++++++++++++++--
>>>>>>>   1 file changed, 90 insertions(+), 6 deletions(-)
>>>>>>>
>>>>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts 
>>>>>>> b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>>>>> index 1c9d95696c839..7d817b447c1d0 100644
>>>>>>> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>>>>> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>>>>> @@ -52,6 +52,42 @@ linux,cma {
>>>>>>>               linux,cma-default;
>>>>>>>           };
>>>>>>> +        c7x_0_dma_memory_region: c7x-dma-memory@99800000 {
>>>>>>> +            compatible = "shared-dma-pool";
>>>>>>> +            reg = <0x00 0x99800000 0x00 0x100000>;
>>>>>>> +            no-map;
>>>>>>> +        };
>>>>>>> +
>>>>>>> +        c7x_0_memory_region: c7x-memory@99900000 {
>>>>>>> +            compatible = "shared-dma-pool";
>>>>>>> +            reg = <0x00 0x99900000 0x00 0xf00000>;
>>>>>>> +            no-map;
>>>>>>> +        };
>>>>>>> +
>>>>>>> +        mcu_r5fss0_core0_dma_memory_region: 
>>>>>>> r5f-dma-memory@9b800000 {
>>>>>>> +            compatible = "shared-dma-pool";
>>>>>>> +            reg = <0x00 0x9b800000 0x00 0x100000>;
>>>>>>> +            no-map;
>>>>>>> +        };
>>>>>>> +
>>>>>>> +        mcu_r5fss0_core0_memory_region: r5f-dma-memory@9b900000 {
>>>>>>> +            compatible = "shared-dma-pool";
>>>>>>> +            reg = <0x00 0x9b900000 0x00 0xf00000>;
>>>>>>> +            no-map;
>>>>>>> +        };
>>>>>>> +
>>>>>>> +        wkup_r5fss0_core0_dma_memory_region: 
>>>>>>> r5f-dma-memory@9c800000 {
>>>>>>> +            compatible = "shared-dma-pool";
>>>>>>> +            reg = <0x00 0x9c800000 0x00 0x100000>;
>>>>>>> +            no-map;
>>>>>>> +        };
>>>>>>> +
>>>>>>> +        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
>>>>>>> +            compatible = "shared-dma-pool";
>>>>>>> +            reg = <0x00 0x9c900000 0x00 0xf00000>;
>>>>>>> +            no-map;
>>>>>>> +        };
>>>>>>> +
>>>>>>>           secure_tfa_ddr: tfa@9e780000 {
>>>>>>>               reg = <0x00 0x9e780000 0x00 0x80000>;
>>>>>>>               alignment = <0x1000>;
>>>>>>> @@ -63,12 +99,6 @@ secure_ddr: optee@9e800000 {
>>>>>>>               alignment = <0x1000>;
>>>>>>>               no-map;
>>>>>>>           };
>>>>>>> -
>>>>>>> -        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
>>>>>>> -            compatible = "shared-dma-pool";
>>>>>>> -            reg = <0x00 0x9c900000 0x00 0x01e00000>;
>>>>>>> -            no-map;
>>>>>>> -        };
>>>>>>>       };
>>>>>>
>>>>>> This is missing the edgeAI specific remote-core carveouts and 
>>>>>> RTOS-to-RTOS IPC memory regions [1] being used by edgeAI 
>>>>>> firmwares which come as pre-packaged in the official SDK release 
>>>>>> for AM62A.
>>>>>>
>>>>>> There is only one official SDK release for AM62A (which is edgeAI 
>>>>>> based) [2] which packages these edgeAI remoteproc firmwares and 
>>>>>> in my view it is a fair expectation that remote core careveouts 
>>>>>> in device-tree should align with firmwares released in SDK.
>>>>>>
>>>>>> This is because most developers (including me) and vendors 
>>>>>> download this official SDK release and use it with latest 
>>>>>> upstream kernel and modules (right now we are applying required 
>>>>>> patches locally) and this patch won't suffice for this, in-fact 
>>>>>> it won't work since the remoteproc firmwares are already using 
>>>>>> regions beyond the reserved-regions from this patch.
>>>>>
>>>>> I understand your point, currently with this patch remoteproc loading
>>>>> will not work for some cores. However, the goal here is to 
>>>>> standardize
>>>>> as much as possible the memory carveout sizes, push the "demo 
>>>>> firmware"
>>>>> to request resources the correct way from resource table, 
>>>>
>>>>
>>>> It is indeed more suitable if the memory carveouts are called out 
>>>> in the resource table of the firmware. But you will still need to 
>>>> reserve that memory sections in the Device Tree so that Kernel does 
>>>> not map that memory for anything else. So I am thinking how moving 
>>>> to resource table will help solve this problem?
>>>
>>> The point is that our default FW is doing things incorrectly. We 
>>> want to
>>> push the existing FW to
>>> 1. Request resources via resource table.
>>> 2. Fix their memory requirements (recent offline discussion proved that
>>> FW is requesting more than it needs)
>>> 3. FW should adapt to Linux not Linux adapt to FW
>>
>>
>> Thanks. I also agree with you on all of the above points for a 
>> standard firmware.
>>
>> However, I was referring to this problem:
>> Can we get rid of static reserved memory carveouts in DT?
>> People using a custom firmware will have to patch the Device Tree to 
>> reserve larger/different memory regions. Is there some way where the 
>> firmware can dictate the "reserved" memory carveouts at runtime? 
>> Memory carveouts can be announced through Resource Table, but there 
>> is no guarantee we will be able to allocate it (it could be mapped by 
>> the Kernel for some other alloc), unless its pre-reserved in DT.
>>
>
> Since we do not have an IOMMU for remote cores in K3, we cannot get rid
> of the static reserved memory carveouts, is my understanding. The linux
> driver would have programmed the IOMMU virtual and physical addresses
> and it would have been able to do the virtual to physical address
> translation on its own with only the requirement size from the FW
> resource table. 


We can still do that for K3 remote cores with just requesting carveout size.
The remoteproc core framework will assign the dynamically allocated
Physical Address (PA) as Device Address (DA) for the rproc[0]. Incase the PA
collides with some existing DA for the rproc, we can configure the rproc's
RAT (Region Address Translation Unit) to map the PA to some other DA from
rproc's view. As Andrew pointed, we can use FW_RSC_ADDR_ANY for all of
these carveouts.

Thanks,
Beleswar

[0]: 
https://github.com/torvalds/linux/blob/master/drivers/remoteproc/remoteproc_core.c#L768

> Since we do not have this flexibility provided with
> IOMMU, we must have static reserved carveouts so that Linux will not
> touch these memory regions. The firmware virtual address to physical
> adress is atm a one to one mapping. So in summary, we must have these
> static reserved memory carveouts, but we should fix the default FW
> to use the "standardized" sizes and request SRAM via resource table.
>
> ~ Judith
>
>
>> Thanks,
>> Beleswar
>>
>>>
>>> If not, then then we should try to move to Zephyr firmware or other/
>>> better options.
>>>
>>> Hope I am able to explain myself better this time around.
>>>
>>> ~ Judith
>>>
>>>>
>>>> Thanks,
>>>> Beleswar
>>>>
>>>>> and move away
>>>>> from this dependency and limitations that we have with our 
>>>>> firmware. We
>>>>> should soon be able to generate our own firmware using Zephyr, which
>>>>> Andrew is pioneering, so with this firmware we should move to the
>>>>> correct direction upstream. Downstream we are still using the memory
>>>>> carveout sizes that the firmware folk want so desperately to keep, 
>>>>> for
>>>>> now..
>>>>>
>>>>> ~ Judith
>>>>>
>>>>>>
>>>>>> [1]: 
>>>>>> https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts?h=ti-linux-6.6.y-cicd#n103
>>>>>> [2]: https://www.ti.com/tool/PROCESSOR-SDK-AM62A
>>>>>>
>>>>>> Regards
>>>>>> Devarsh
>>>>>>
>>>>>>>       opp-table {
>>>>>>> @@ -741,3 +771,57 @@ dpi1_out: endpoint {
>>>>>>>           };
>>>>>>>       };
>>>>>>>   };
>>>>>>> +
>>>>>>> +&mailbox0_cluster0 {
>>>>>>> +    status = "okay";
>>>>>>> +
>>>>>>> +    mbox_r5_0: mbox-r5-0 {
>>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>>> +    };
>>>>>>> +};
>>>>>>> +
>>>>>>> +&mailbox0_cluster1 {
>>>>>>> +    status = "okay";
>>>>>>> +
>>>>>>> +    mbox_c7x_0: mbox-c7x-0 {
>>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>>> +    };
>>>>>>> +};
>>>>>>> +
>>>>>>> +&mailbox0_cluster2 {
>>>>>>> +    status = "okay";
>>>>>>> +
>>>>>>> +    mbox_mcu_r5_0: mbox-mcu-r5-0 {
>>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>>> +    };
>>>>>>> +};
>>>>>>> +
>>>>>>> +&wkup_r5fss0 {
>>>>>>> +    status = "okay";
>>>>>>> +};
>>>>>>> +
>>>>>>> +&wkup_r5fss0_core0 {
>>>>>>> +    mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
>>>>>>> +    memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
>>>>>>> + <&wkup_r5fss0_core0_memory_region>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&mcu_r5fss0 {
>>>>>>> +    status = "okay";
>>>>>>> +};
>>>>>>> +
>>>>>>> +&mcu_r5fss0_core0 {
>>>>>>> +    mboxes = <&mailbox0_cluster2>, <&mbox_mcu_r5_0>;
>>>>>>> +    memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
>>>>>>> + <&mcu_r5fss0_core0_memory_region>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&c7x_0 {
>>>>>>> +    mboxes = <&mailbox0_cluster1>, <&mbox_c7x_0>;
>>>>>>> +    memory-region = <&c7x_0_dma_memory_region>,
>>>>>>> +            <&c7x_0_memory_region>;
>>>>>>> +    status = "okay";
>>>>>>> +};
>>>>>>
>>>>>
>>>
>

Re: [PATCH v6 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Beleswar Prasad Padhi]

On 10/04/25 23:52, Andrew Davis wrote:
> On 4/10/25 6:38 AM, Devarsh Thakkar wrote:
>> Hi Jai,
>>
>> On 10/04/25 15:48, Jai Luthra wrote:
>>> Hi Devarsh,
>>>
>>> Thanks for the cc here.
>>
>> Thanks for the quick comments.
>>
>>>
>> <snip>
>>
>>> On the basic camera + ISP usecase, afaiu the downstream edgeAI SDK uses
>>> custom gstreamer elements that make calls to the aforementioned R5 core
>>> that controls the ISP. On top of that there are additional gstreamer
>>> patches that are not yet posted upstream for review from the community,
>>> so the userspace design isn't really set in stone, or upstream-friendly
>>> yet.
>>>
>>
>> I don't see much relation of carve-outs with Gstreamer or it's 
>> pending downstream patches. The memory is mainly managed from 
>> firmwares (mainly openvx layer being used underneath) and there are 
>> even non-gstreamer pure openvx based use-cases/tests which use these 
>> carveouts. At the end of the day, the firmwares from the only SDK 
>> which is released publicly for AM62A uses all these carveouts.
>>
>
> These are programmable cores, you can run whatever you want on them. 
> You can
> make your own firmware if you like, we have support for them in our 
> MCU+(FreeRTOS)
> offering today[0](look at all these firmware you can build/run!).
>
> In a week or so I'll start pushing support for these cores into Zephyr,
> bringing in even more firmware options for these cores.
>
> I simply do not see why one firmware, shipped with one of our SDKs*, 
> doing
> things wrong should force us to hack up our DT here in upstream Linux.


Agreed. I don't see why we should incline towards supporting one of the 
SDKs.

For this patch as it as,

Reviewed-by: Beleswar Padhi <b-padhi@ti.com>

Thanks,
Beleswar

>
> *Speaking of the "only" SDK's firmware, if you take our Yocto meta-ti 
> layer and
> build an SDK yourself, you get firmware by default that *doesn't need 
> extra
> carveouts*! [1][2]
>
> Andrew
>
> [0] 
> https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/makefile.am62ax
> [1] 
> https://git.yoctoproject.org/meta-ti/tree/meta-ti-bsp/recipes-bsp/ti-rtos-fw/ti-rtos-echo-test-fw.bb
> [2] 
> https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tree/ti-ipc/am62axx?h=ti-linux-firmware
>
>>
>>> IMO if that architecture is still under discussion, it might be better
>>> to keep the edgeAI specific carveouts out of the upstream DTs.. just in
>>> case the carevouts have to go away, or change significantly.
>>>
>>> If you are sure that the regions and firmware architecture is set in
>>> stone and won't be updated even if there is a complete redesign of the
>>> userspace/application level stack for accessing the ISP (let's say u
>> sing> libcamera), only then it makes sense to add the carveouts right 
>> now.
>>
>>
>> Yes as I said if whole firmware arch is getting updated then better 
>> to wait. I think probably the firmware team marked in cc can comment 
>> on that. Moreover I don't see any point of adding only half the 
>> regions as that would anyway not work with SDK supplied firmwares, 
>> for e.g. RTOS-to-RTOS ipc test run by firmwares on bootup would fail, 
>> along with other camera+ISP and AI use-cases.
>>
>> Regards
>> Devarsh
>>
>>>>>>
>>>>>> I understand your point, currently with this patch remoteproc 
>>>>>> loading
>>>>>> will not work for some cores. However, the goal here is to 
>>>>>> standardize
>>>>>> as much as possible the memory carveout sizes, push the "demo 
>>>>>> firmware"
>>>>>> to request resources the correct way from resource table, and 
>>>>>> move away
>>>>>> from this dependency and limitations that we have with our firmware.
>>>>
>>>> I understand this, but my view is that w.r.t firmware only goal 
>>>> should not
>>>> just be tp demonstrate correct way of requesting resources from
>>>> resource-tables, optimize the carve-outs etc but also to 
>>>> demonstrate the
>>>> primary use-cases (camera+ISP+edgeAI) which the device is capable of.
>>>>
>>>>>> should soon be able to generate our own firmware using Zephyr,  
>>>>>> which
>>>>>> Andrew is pioneering, so with this firmware we should move to the
>>>>>> correct direction upstream. Downstream we are still using the memory
>>>>>> carveout sizes that the firmware folk want so desperately to 
>>>>>> keep, for
>>>>>> now..
>>>>>>
>>>>>
>>>>> +1
>>>>>
>>>>> I have this Zephyr based firmware for AM62A working and it uses the
>>>>> standard IPC regions as specified in this patch. I'll be posting 
>>>>> the PR
>>>>> for it in Zephyr upstream by the end of week.
>>>>>
>>>>
>>>> I understand this, but will this zephyr based firmware support 
>>>> vision +
>>>> edgeAI analytics ? Does it demonstrate all the unique capabilities 
>>>> of AM62A
>>>> SoC ? If not, then what would be utility of such firmware on AM62A 
>>>> where
>>>> these are the primary use-cases w.r.t AM62A ?
>>>>
>>>> Why should upstream device-tree use carve-outs which match to this 
>>>> demo
>>>> zephyr based firmware (which apparently not many are using and is 
>>>> not going
>>>> into any official SDK release) instead of official firmwares going 
>>>> into SDK
>>>> ? SDK released firmwares are being used by so many customers and SDK
>>>> documentation maps to it, but zephyr firmware that is being pitched 
>>>> here,
>>>> who would be the potential users and what would be it's utility ?
>>>>
>>>> [1]: https://www.ti.com/tool/PROCESSOR-SDK-J721E
>>>>
>>>> Regards
>>>> Devarsh
>>>>
>>>>> For this patch as it is:
>>>>>
>>>>> Acked-by: Andrew Davis <afd@ti.com>
>>>>>
>>>>
>>>>
>>>>> Andrew
>>>>>
>>>>> [0] 
>>>>> https://lore.kernel.org/lkml/20241011123922.23135-1-richard@nod.at/
>>>>> [1] https://git.ti.com/cgit/edgeai/meta-edgeai/tree/recipes-kernel/
>>>>> linux/linux-ti-staging/j721e-evm/0001-arm64-dts-ti-Add-DTB-overlays-for- 
>>>>>
>>>>> vision-apps-and-ed.patch?h=kirkstone
>>>>>
>>>>>> ~ Judith
>>>>>>
>>>>>>>
>>>>>>> [1]:
>>>>>>> https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/
>>>>>>> arch/arm64/boot/dts/ti/k3-am62a7-sk.dts?h=ti-linux-6.6.y-cicd#n103
>>>>>>> [2]: https://www.ti.com/tool/PROCESSOR-SDK-AM62A
>>>>>>>
>>>>>>> Regards
>>>>>>> Devarsh
>>>>>>>
>>>>>>>>        opp-table {
>>>>>>>> @@ -741,3 +771,57 @@ dpi1_out: endpoint {
>>>>>>>>            };
>>>>>>>>        };
>>>>>>>>    };
>>>>>>>> +
>>>>>>>> +&mailbox0_cluster0 {
>>>>>>>> +    status = "okay";
>>>>>>>> +
>>>>>>>> +    mbox_r5_0: mbox-r5-0 {
>>>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>>>> +    };
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&mailbox0_cluster1 {
>>>>>>>> +    status = "okay";
>>>>>>>> +
>>>>>>>> +    mbox_c7x_0: mbox-c7x-0 {
>>>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>>>> +    };
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&mailbox0_cluster2 {
>>>>>>>> +    status = "okay";
>>>>>>>> +
>>>>>>>> +    mbox_mcu_r5_0: mbox-mcu-r5-0 {
>>>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>>>> +    };
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&wkup_r5fss0 {
>>>>>>>> +    status = "okay";
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&wkup_r5fss0_core0 {
>>>>>>>> +    mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
>>>>>>>> +    memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
>>>>>>>> + <&wkup_r5fss0_core0_memory_region>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&mcu_r5fss0 {
>>>>>>>> +    status = "okay";
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&mcu_r5fss0_core0 {
>>>>>>>> +    mboxes = <&mailbox0_cluster2>, <&mbox_mcu_r5_0>;
>>>>>>>> +    memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
>>>>>>>> + <&mcu_r5fss0_core0_memory_region>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&c7x_0 {
>>>>>>>> +    mboxes = <&mailbox0_cluster1>, <&mbox_c7x_0>;
>>>>>>>> +    memory-region = <&c7x_0_dma_memory_region>,
>>>>>>>> +            <&c7x_0_memory_region>;
>>>>>>>> +    status = "okay";
>>>>>>>> +};
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>

Re: [PATCH v6 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Jai Luthra]

[-- Attachment #1: Type: text/plain, Size: 9203 bytes --]

On Apr 10, 2025 at 13:22:29 -0500, Andrew Davis wrote:
> On 4/10/25 6:38 AM, Devarsh Thakkar wrote:
> > Hi Jai,
> > 
> > On 10/04/25 15:48, Jai Luthra wrote:
> > > Hi Devarsh,
> > > 
> > > Thanks for the cc here.
> > 
> > Thanks for the quick comments.
> > 
> > > 
> > <snip>
> > 
> > > On the basic camera + ISP usecase, afaiu the downstream edgeAI SDK uses
> > > custom gstreamer elements that make calls to the aforementioned R5 core
> > > that controls the ISP. On top of that there are additional gstreamer
> > > patches that are not yet posted upstream for review from the community,
> > > so the userspace design isn't really set in stone, or upstream-friendly
> > > yet.
> > > 
> > 
> > I don't see much relation of carve-outs with Gstreamer or it's pending downstream patches. The memory is mainly managed from firmwares (mainly openvx layer being used underneath) and there are even non-gstreamer pure openvx based use-cases/tests which use these carveouts. At the end of the day, the firmwares from the only SDK which is released publicly for AM62A uses all these carveouts.
> > 
> 
> These are programmable cores, you can run whatever you want on them. You can
> make your own firmware if you like, we have support for them in our MCU+(FreeRTOS)
> offering today[0](look at all these firmware you can build/run!).
> 
> In a week or so I'll start pushing support for these cores into Zephyr,
> bringing in even more firmware options for these cores.
> 
> I simply do not see why one firmware, shipped with one of our SDKs*, doing
> things wrong should force us to hack up our DT here in upstream Linux.
> 

I see, if the not-yet-upstream firmware can be updated, then I don't see 
any reason to hardcode carveouts here.

For this patch as is,
Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com>

> *Speaking of the "only" SDK's firmware, if you take our Yocto meta-ti layer and
> build an SDK yourself, you get firmware by default that *doesn't need extra
> carveouts*! [1][2]
> 
> Andrew
> 
> [0] https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/makefile.am62ax
> [1] https://git.yoctoproject.org/meta-ti/tree/meta-ti-bsp/recipes-bsp/ti-rtos-fw/ti-rtos-echo-test-fw.bb
> [2] https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tree/ti-ipc/am62axx?h=ti-linux-firmware
> 
> > 
> > > IMO if that architecture is still under discussion, it might be better
> > > to keep the edgeAI specific carveouts out of the upstream DTs.. just in
> > > case the carevouts have to go away, or change significantly.
> > > 
> > > If you are sure that the regions and firmware architecture is set in
> > > stone and won't be updated even if there is a complete redesign of the
> > > userspace/application level stack for accessing the ISP (let's say u
> > sing> libcamera), only then it makes sense to add the carveouts right now.
> > 
> > 
> > Yes as I said if whole firmware arch is getting updated then better to wait. I think probably the firmware team marked in cc can comment on that. Moreover I don't see any point of adding only half the regions as that would anyway not work with SDK supplied firmwares, for e.g. RTOS-to-RTOS ipc test run by firmwares on bootup would fail, along with other camera+ISP and AI use-cases.
> > 

PS: Devarsh your mail client has format=flowed enabled, which causes 
line length overflows when replying to it.

Please disable it, as advised here:
https://www.kernel.org/doc/html/latest/process/email-clients.html#thunderbird-gui

> > Regards
> > Devarsh
> > 
> > > > > > 
> > > > > > I understand your point, currently with this patch remoteproc loading
> > > > > > will not work for some cores. However, the goal here is to standardize
> > > > > > as much as possible the memory carveout sizes, push the "demo firmware"
> > > > > > to request resources the correct way from resource table, and move away
> > > > > > from this dependency and limitations that we have with our firmware.
> > > > 
> > > > I understand this, but my view is that w.r.t firmware only goal should not
> > > > just be tp demonstrate correct way of requesting resources from
> > > > resource-tables, optimize the carve-outs etc but also to demonstrate the
> > > > primary use-cases (camera+ISP+edgeAI) which the device is capable of.
> > > > 
> > > > > > should soon be able to generate our own firmware using Zephyr,  which
> > > > > > Andrew is pioneering, so with this firmware we should move to the
> > > > > > correct direction upstream. Downstream we are still using the memory
> > > > > > carveout sizes that the firmware folk want so desperately to keep, for
> > > > > > now..
> > > > > > 
> > > > > 
> > > > > +1
> > > > > 
> > > > > I have this Zephyr based firmware for AM62A working and it uses the
> > > > > standard IPC regions as specified in this patch. I'll be posting the PR
> > > > > for it in Zephyr upstream by the end of week.
> > > > > 
> > > > 
> > > > I understand this, but will this zephyr based firmware support vision +
> > > > edgeAI analytics ? Does it demonstrate all the unique capabilities of AM62A
> > > > SoC ? If not, then what would be utility of such firmware on AM62A where
> > > > these are the primary use-cases w.r.t AM62A ?
> > > > 
> > > > Why should upstream device-tree use carve-outs which match to this demo
> > > > zephyr based firmware (which apparently not many are using and is not going
> > > > into any official SDK release) instead of official firmwares going into SDK
> > > > ? SDK released firmwares are being used by so many customers and SDK
> > > > documentation maps to it, but zephyr firmware that is being pitched here,
> > > > who would be the potential users and what would be it's utility ?
> > > > 
> > > > [1]: https://www.ti.com/tool/PROCESSOR-SDK-J721E
> > > > 
> > > > Regards
> > > > Devarsh
> > > > 
> > > > > For this patch as it is:
> > > > > 
> > > > > Acked-by: Andrew Davis <afd@ti.com>
> > > > > 
> > > > 
> > > > 
> > > > > Andrew
> > > > > 
> > > > > [0] https://lore.kernel.org/lkml/20241011123922.23135-1-richard@nod.at/
> > > > > [1] https://git.ti.com/cgit/edgeai/meta-edgeai/tree/recipes-kernel/
> > > > > linux/linux-ti-staging/j721e-evm/0001-arm64-dts-ti-Add-DTB-overlays-for-
> > > > > vision-apps-and-ed.patch?h=kirkstone
> > > > > 
> > > > > > ~ Judith
> > > > > > 
> > > > > > > 
> > > > > > > [1]:
> > > > > > > https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/
> > > > > > > arch/arm64/boot/dts/ti/k3-am62a7-sk.dts?h=ti-linux-6.6.y-cicd#n103
> > > > > > > [2]: https://www.ti.com/tool/PROCESSOR-SDK-AM62A
> > > > > > > 
> > > > > > > Regards
> > > > > > > Devarsh
> > > > > > > 
> > > > > > > >        opp-table {
> > > > > > > > @@ -741,3 +771,57 @@ dpi1_out: endpoint {
> > > > > > > >            };
> > > > > > > >        };
> > > > > > > >    };
> > > > > > > > +
> > > > > > > > +&mailbox0_cluster0 {
> > > > > > > > +    status = "okay";
> > > > > > > > +
> > > > > > > > +    mbox_r5_0: mbox-r5-0 {
> > > > > > > > +        ti,mbox-rx = <0 0 0>;
> > > > > > > > +        ti,mbox-tx = <1 0 0>;
> > > > > > > > +    };
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +&mailbox0_cluster1 {
> > > > > > > > +    status = "okay";
> > > > > > > > +
> > > > > > > > +    mbox_c7x_0: mbox-c7x-0 {
> > > > > > > > +        ti,mbox-rx = <0 0 0>;
> > > > > > > > +        ti,mbox-tx = <1 0 0>;
> > > > > > > > +    };
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +&mailbox0_cluster2 {
> > > > > > > > +    status = "okay";
> > > > > > > > +
> > > > > > > > +    mbox_mcu_r5_0: mbox-mcu-r5-0 {
> > > > > > > > +        ti,mbox-rx = <0 0 0>;
> > > > > > > > +        ti,mbox-tx = <1 0 0>;
> > > > > > > > +    };
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +&wkup_r5fss0 {
> > > > > > > > +    status = "okay";
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +&wkup_r5fss0_core0 {
> > > > > > > > +    mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
> > > > > > > > +    memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
> > > > > > > > +            <&wkup_r5fss0_core0_memory_region>;
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +&mcu_r5fss0 {
> > > > > > > > +    status = "okay";
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +&mcu_r5fss0_core0 {
> > > > > > > > +    mboxes = <&mailbox0_cluster2>, <&mbox_mcu_r5_0>;
> > > > > > > > +    memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
> > > > > > > > +            <&mcu_r5fss0_core0_memory_region>;
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +&c7x_0 {
> > > > > > > > +    mboxes = <&mailbox0_cluster1>, <&mbox_c7x_0>;
> > > > > > > > +    memory-region = <&c7x_0_dma_memory_region>,
> > > > > > > > +            <&c7x_0_memory_region>;
> > > > > > > > +    status = "okay";
> > > > > > > > +};
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > > 
> > > 
> > 

-- 
Thanks,
Jai

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]