Hi Andrew!
On October 3, 2024 thus sayeth Andrew Davis:
> From: Hari Nagalla <hnagalla@xxxxxx>
>
> 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@xxxxxx>
> Signed-off-by: Andrew Davis <afd@xxxxxx>
> ---
> .../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
