| Message ID | 20241003170118.24932-3-afd@ti.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | TI K3 M4F support on AM62 and AM64 SoCs | expand |
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?
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
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";