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

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

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

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