[PATCH v12 0/5] TI K3 M4F support on AM62 and AM64 SoCs

[PATCH v12 0/5] TI K3 M4F support on AM62 and AM64 SoCs

[Andrew Davis]

Hello all,

M4F driver[0] and DT bindings[1] are in, so last step is adding the
nodes to the base AM64/AM62 DTSI files, plus a couple of our
SK boards. These can be used as a reference for other boards using
AM64/AM62, or I can add these nodes for existing upstream boards,
just let me know.

Thanks,
Andrew

[0] commit ebcf9008a895a ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem")
[1] commit 9fedb829372d4 ("dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs")

Changes for v12:
 - Rebased on v6.12-rc1
 - Dropped taken patches
 - Added Tested-by tags

Previous series (v11):
https://lore.kernel.org/linux-arm-kernel/20240802152109.137243-1-afd@ti.com/

Hari Nagalla (5):
  arm64: dts: ti: k3-am62: Add M4F remoteproc node
  arm64: dts: ti: k3-am625-sk: Add M4F remoteproc node
  arm64: dts: ti: k3-am64: Add M4F remoteproc node
  arm64: dts: ti: k3-am642-sk: Add M4F remoteproc node
  arm64: dts: ti: k3-am642-evm: Add M4F remoteproc node

 arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi       | 13 +++++++++++++
 .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 19 +++++++++++++++++++
 arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi       | 13 +++++++++++++
 arch/arm64/boot/dts/ti/k3-am642-evm.dts       | 19 +++++++++++++++++++
 arch/arm64/boot/dts/ti/k3-am642-sk.dts        | 19 +++++++++++++++++++
 5 files changed, 83 insertions(+)

-- 
2.39.2

[PATCH v12 1/5] arm64: dts: ti: k3-am62: Add M4F remoteproc node

[Andrew Davis]

From: Hari Nagalla <hnagalla@ti.com>

The AM62x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed.

Disable by default as this node is not complete until mailbox data
is provided in the board level DT.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Andrew Davis <afd@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
---
 arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
index bb43a411f59b2..68e906796aefe 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
@@ -174,4 +174,17 @@ mcu_mcan1: can@4e18000 {
 		bosch,mram-cfg = <0x0 128 64 64 64 64 32 32>;
 		status = "disabled";
 	};
+
+	mcu_m4fss: m4fss@5000000 {
+		compatible = "ti,am64-m4fss";
+		reg = <0x00 0x5000000 0x00 0x30000>,
+		      <0x00 0x5040000 0x00 0x10000>;
+		reg-names = "iram", "dram";
+		resets = <&k3_reset 9 1>;
+		firmware-name = "am62-mcu-m4f0_0-fw";
+		ti,sci = <&dmsc>;
+		ti,sci-dev-id = <9>;
+		ti,sci-proc-ids = <0x18 0xff>;
+		status = "disabled";
+	};
 };
-- 
2.39.2

[PATCH v12 2/5] arm64: dts: ti: k3-am625-sk: Add M4F remoteproc node

[Andrew Davis]

From: Hari Nagalla <hnagalla@ti.com>

The AM62x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed. The first region is used
as a DMA pool for the rproc device, and the second region will furnish
the static carveout regions for the firmware memory.

The current carveout addresses and sizes are defined statically for
each rproc device. The M4F processor does not have an MMU, and as such
requires the exact memory used by the firmware to be set-aside.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Andrew Davis <afd@ti.com>
---
 .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

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 44ff67b6bf1e4..6957b3e44c82f 100644
--- a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
@@ -56,6 +56,18 @@ linux,cma {
 			linux,cma-default;
 		};
 
+		mcu_m4fss_dma_memory_region: m4f-dma-memory@9cb00000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9cb00000 0x00 0x100000>;
+			no-map;
+		};
+
+		mcu_m4fss_memory_region: m4f-memory@9cc00000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0x9cc00000 0x00 0xe00000>;
+			no-map;
+		};
+
 		secure_tfa_ddr: tfa@9e780000 {
 			reg = <0x00 0x9e780000 0x00 0x80000>;
 			alignment = <0x1000>;
@@ -464,6 +476,13 @@ mbox_m4_0: mbox-m4-0 {
 	};
 };
 
+&mcu_m4fss {
+	mboxes = <&mailbox0_cluster0 &mbox_m4_0>;
+	memory-region = <&mcu_m4fss_dma_memory_region>,
+			<&mcu_m4fss_memory_region>;
+	status = "okay";
+};
+
 &usbss0 {
 	bootph-all;
 	status = "okay";
-- 
2.39.2

Re: [PATCH v12 2/5] arm64: dts: ti: k3-am625-sk: Add M4F remoteproc node

[Bryan Brattlof]

Hi Andrew!

On October  3, 2024 thus sayeth Andrew Davis:
> From: Hari Nagalla <hnagalla@ti.com>
> 
> The AM62x SoCs of the TI K3 family have a Cortex M4F core in the MCU
> domain. This core can be used by non safety applications as a remote
> processor. When used as a remote processor with virtio/rpmessage IPC,
> two carveout reserved memory nodes are needed. The first region is used
> as a DMA pool for the rproc device, and the second region will furnish
> the static carveout regions for the firmware memory.
> 
> The current carveout addresses and sizes are defined statically for
> each rproc device. The M4F processor does not have an MMU, and as such
> requires the exact memory used by the firmware to be set-aside.
> 
> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
> Signed-off-by: Andrew Davis <afd@ti.com>
> ---
>  .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> 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 44ff67b6bf1e4..6957b3e44c82f 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
> @@ -56,6 +56,18 @@ linux,cma {
>  			linux,cma-default;
>  		};
>  
> +		mcu_m4fss_dma_memory_region: m4f-dma-memory@9cb00000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0x9cb00000 0x00 0x100000>;
> +			no-map;
> +		};
> +
> +		mcu_m4fss_memory_region: m4f-memory@9cc00000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0x9cc00000 0x00 0xe00000>;
> +			no-map;
> +		};
> +

The only issue I have here is this takes away memory from people who do 
not use these firmware or causes them to work around this patch if they 
choose to have different carveouts.

Would an overlay be appropriate for this?

~Bryan

Re: [PATCH v12 2/5] arm64: dts: ti: k3-am625-sk: Add M4F remoteproc node

[Nishanth Menon]

On 16:06-20241003, Bryan Brattlof wrote:
> Hi Andrew!
> 
> On October  3, 2024 thus sayeth Andrew Davis:
> > From: Hari Nagalla <hnagalla@ti.com>
> > 
> > The AM62x SoCs of the TI K3 family have a Cortex M4F core in the MCU
> > domain. This core can be used by non safety applications as a remote
> > processor. When used as a remote processor with virtio/rpmessage IPC,
> > two carveout reserved memory nodes are needed. The first region is used
> > as a DMA pool for the rproc device, and the second region will furnish
> > the static carveout regions for the firmware memory.
> > 
> > The current carveout addresses and sizes are defined statically for
> > each rproc device. The M4F processor does not have an MMU, and as such
> > requires the exact memory used by the firmware to be set-aside.
> > 
> > Signed-off-by: Hari Nagalla <hnagalla@ti.com>
> > Signed-off-by: Andrew Davis <afd@ti.com>
> > ---
> >  .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 19 +++++++++++++++++++
> >  1 file changed, 19 insertions(+)
> > 
> > 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 44ff67b6bf1e4..6957b3e44c82f 100644
> > --- a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
> > +++ b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
> > @@ -56,6 +56,18 @@ linux,cma {
> >  			linux,cma-default;
> >  		};
> >  
> > +		mcu_m4fss_dma_memory_region: m4f-dma-memory@9cb00000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0x00 0x9cb00000 0x00 0x100000>;
> > +			no-map;
> > +		};
> > +
> > +		mcu_m4fss_memory_region: m4f-memory@9cc00000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0x00 0x9cc00000 0x00 0xe00000>;
> > +			no-map;
> > +		};
> > +
> 
> The only issue I have here is this takes away memory from people who do 
> not use these firmware or causes them to work around this patch if they 
> choose to have different carveouts.

They can define their own overlays.

> 
> Would an overlay be appropriate for this?

Why is this any different from existing boards? Are you suggesting a
change for all existing boards as well?

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

Re: [PATCH v12 2/5] arm64: dts: ti: k3-am625-sk: Add M4F remoteproc node

[Andrew Davis]

On 10/4/24 6:26 AM, Nishanth Menon wrote:
> On 16:06-20241003, Bryan Brattlof wrote:
>> Hi Andrew!
>>
>> On October  3, 2024 thus sayeth Andrew Davis:
>>> From: Hari Nagalla <hnagalla@ti.com>
>>>
>>> The AM62x SoCs of the TI K3 family have a Cortex M4F core in the MCU
>>> domain. This core can be used by non safety applications as a remote
>>> processor. When used as a remote processor with virtio/rpmessage IPC,
>>> two carveout reserved memory nodes are needed. The first region is used
>>> as a DMA pool for the rproc device, and the second region will furnish
>>> the static carveout regions for the firmware memory.
>>>
>>> The current carveout addresses and sizes are defined statically for
>>> each rproc device. The M4F processor does not have an MMU, and as such
>>> requires the exact memory used by the firmware to be set-aside.
>>>
>>> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
>>> Signed-off-by: Andrew Davis <afd@ti.com>
>>> ---
>>>   .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 19 +++++++++++++++++++
>>>   1 file changed, 19 insertions(+)
>>>
>>> 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 44ff67b6bf1e4..6957b3e44c82f 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
>>> +++ b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
>>> @@ -56,6 +56,18 @@ linux,cma {
>>>   			linux,cma-default;
>>>   		};
>>>   
>>> +		mcu_m4fss_dma_memory_region: m4f-dma-memory@9cb00000 {
>>> +			compatible = "shared-dma-pool";
>>> +			reg = <0x00 0x9cb00000 0x00 0x100000>;
>>> +			no-map;
>>> +		};
>>> +
>>> +		mcu_m4fss_memory_region: m4f-memory@9cc00000 {
>>> +			compatible = "shared-dma-pool";
>>> +			reg = <0x00 0x9cc00000 0x00 0xe00000>;
>>> +			no-map;
>>> +		};
>>> +
>>
>> The only issue I have here is this takes away memory from people who do
>> not use these firmware or causes them to work around this patch if they
>> choose to have different carveouts.
> 
> They can define their own overlays.
> 
>>
>> Would an overlay be appropriate for this?
> 
> Why is this any different from existing boards? Are you suggesting a
> change for all existing boards as well?
> 

Yes, I believe that is what is being suggested, and I agree with it.
It would also help with all these non-SK boards we now have, they
would simply apply the same overlay when using the firmware that
requires these carveouts.

I've been thinking on doing that for a while, but I wanted to keep
the same pattern just for this one last series. Then we can attempt
to refactor next.

Andrew

[PATCH v12 3/5] arm64: dts: ti: k3-am64: Add M4F remoteproc node

[Andrew Davis]

From: Hari Nagalla <hnagalla@ti.com>

The AM64x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed.

Disable by default as this node is not complete until mailbox data
is provided in the board level DT.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Andrew Davis <afd@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
---
 arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
index ad4bed5d3f9eb..a243c981e8535 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
@@ -161,4 +161,17 @@ mcu_esm: esm@4100000 {
 		/* Interrupt sources: esm0_cfg, esm0_hi, esm0_low, mrti0 */
 		ti,esm-pins = <0>, <1>, <2>, <85>;
 	};
+
+	mcu_m4fss: m4fss@5000000 {
+		compatible = "ti,am64-m4fss";
+		reg = <0x00 0x5000000 0x00 0x30000>,
+		      <0x00 0x5040000 0x00 0x10000>;
+		reg-names = "iram", "dram";
+		resets = <&k3_reset 9 1>;
+		firmware-name = "am64-mcu-m4f0_0-fw";
+		ti,sci = <&dmsc>;
+		ti,sci-dev-id = <9>;
+		ti,sci-proc-ids = <0x18 0xff>;
+		status = "disabled";
+	};
 };
-- 
2.39.2

[PATCH v12 4/5] arm64: dts: ti: k3-am642-sk: Add M4F remoteproc node

[Andrew Davis]

From: Hari Nagalla <hnagalla@ti.com>

The AM64x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed. The first region is used
as a DMA pool for the rproc device, and the second region will furnish
the static carveout regions for the firmware memory.

The current carveout addresses and sizes are defined statically for
each rproc device. The M4F processor does not have an MMU, and as such
requires the exact memory used by the firmware to be set-aside.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Andrew Davis <afd@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am642-sk.dts | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
index 86369525259c3..26d4ad5e96f1c 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
@@ -99,6 +99,18 @@ main_r5fss1_core1_memory_region: r5f-memory@a3100000 {
 			no-map;
 		};
 
+		mcu_m4fss_dma_memory_region: m4f-dma-memory@a4000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa4000000 0x00 0x100000>;
+			no-map;
+		};
+
+		mcu_m4fss_memory_region: m4f-memory@a4100000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa4100000 0x00 0xf00000>;
+			no-map;
+		};
+
 		rtos_ipc_memory_region: ipc-memories@a5000000 {
 			reg = <0x00 0xa5000000 0x00 0x00800000>;
 			alignment = <0x1000>;
@@ -681,6 +693,13 @@ &main_r5fss1_core1 {
 			<&main_r5fss1_core1_memory_region>;
 };
 
+&mcu_m4fss {
+	mboxes = <&mailbox0_cluster6 &mbox_m4_0>;
+	memory-region = <&mcu_m4fss_dma_memory_region>,
+			<&mcu_m4fss_memory_region>;
+	status = "okay";
+};
+
 &ecap0 {
 	status = "okay";
 	/* PWM is available on Pin 1 of header J3 */
-- 
2.39.2

[PATCH v12 5/5] arm64: dts: ti: k3-am642-evm: Add M4F remoteproc node

[Andrew Davis]

From: Hari Nagalla <hnagalla@ti.com>

The AM64x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed. The first region is used
as a DMA pool for the rproc device, and the second region will furnish
the static carveout regions for the firmware memory.

The current carveout addresses and sizes are defined statically for
each rproc device. The M4F processor does not have an MMU, and as such
requires the exact memory used by the firmware to be set-aside.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Andrew Davis <afd@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am642-evm.dts | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index 97ca16f00cd26..19d7ed8a9ea0f 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -101,6 +101,18 @@ main_r5fss1_core1_memory_region: r5f-memory@a3100000 {
 			no-map;
 		};
 
+		mcu_m4fss_dma_memory_region: m4f-dma-memory@a4000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa4000000 0x00 0x100000>;
+			no-map;
+		};
+
+		mcu_m4fss_memory_region: m4f-memory@a4100000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa4100000 0x00 0xf00000>;
+			no-map;
+		};
+
 		rtos_ipc_memory_region: ipc-memories@a5000000 {
 			reg = <0x00 0xa5000000 0x00 0x00800000>;
 			alignment = <0x1000>;
@@ -776,6 +788,13 @@ &main_r5fss1_core1 {
 			<&main_r5fss1_core1_memory_region>;
 };
 
+&mcu_m4fss {
+	mboxes = <&mailbox0_cluster6 &mbox_m4_0>;
+	memory-region = <&mcu_m4fss_dma_memory_region>,
+			<&mcu_m4fss_memory_region>;
+	status = "okay";
+};
+
 &serdes_ln_ctrl {
 	idle-states = <AM64_SERDES0_LANE0_PCIE0>;
 };
-- 
2.39.2

Re: [PATCH v12 0/5] TI K3 M4F support on AM62 and AM64 SoCs

[Vignesh Raghavendra]

Hi Andrew Davis,

On Thu, 03 Oct 2024 12:01:13 -0500, Andrew Davis wrote:
> M4F driver[0] and DT bindings[1] are in, so last step is adding the
> nodes to the base AM64/AM62 DTSI files, plus a couple of our
> SK boards. These can be used as a reference for other boards using
> AM64/AM62, or I can add these nodes for existing upstream boards,
> just let me know.
> 
> Thanks,
> Andrew
> 
> [...]

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/5] arm64: dts: ti: k3-am62: Add M4F remoteproc node
      commit: be4bac3bcb281b264bd35ae1ff7bbbb99e3e00fe
[2/5] arm64: dts: ti: k3-am625-sk: Add M4F remoteproc node
      commit: 23a6aba92e53883bccbbb27933aad6dd09992e6f
[3/5] arm64: dts: ti: k3-am64: Add M4F remoteproc node
      commit: ef1876ff76096b3cad6fdb8b797226e4914f5726
[4/5] arm64: dts: ti: k3-am642-sk: Add M4F remoteproc node
      commit: 6e36e6200360e1703071b38fa5e91f4894716658
[5/5] arm64: dts: ti: k3-am642-evm: Add M4F remoteproc node
      commit: 8e77fc1fbb291e193664df0ac5176ac9fbfb3ea8

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Vignesh