AM6442: Multi core shared memory

Hello Chris,

One thing to keep in mind when looking at the memory maps listed in the MCU+ SDK's Memory Map Layout document is that not everything is fixed in place. The most important thing is that every core in the system knows what the memory map is, so you don't have any cores accidentally overwriting another core's data.

Let's look at the MSRAM allocation:

1) the first 512 KB is used during SBL boot (not actually used during runtime). So
A) this memory is free if using Linux SPL boot instead (documented in the Uboot docs here), and
B) this memory is technically available during runtime after the SBL ends. However, initialized data cannot be placed there by the SBL, since it would overwrite important SBL data. E.g., if this memory region was only used after Linux finished booting, that should be safe.

2) The regions set aside for R5Fx_x: these 4 regions being allocated per core are completely arbitrary. Most of the TI R5F examples you will find in the MCU+ SDK don't even use the SRAM.

3) The "reserved for DMSC" section cannot be moved. However, I believe pretty much every other section listed should be able to be moved around or removed if you need it (e.g., if you are not implementing IPC between MCU+ cores, there is no need for section "IPC between MCU's").

Let's look at the DDR allocation: 

Linux uses DDR a bit differently from MCU+ cores. You tell Linux the size of the DDR, and which parts of the DDR are reserved for specific things, and then Linux dynamically uses the rest of the DDR that has not been allocated. So it is completely arbitrary that the r5f DDR memory regions are placed starting at 0xA000_0000. You could move it to 0x9000_0000, or 0xB000_0000, or wherever - as long as everyone knows where the memory is!

As an example, let's look at 
mcu_plus_sdk_am64x_08_05_00_24/examples/drivers/ipc/ipc_rpmsg_echo_linux/am64x-evm/r5fss1-0_freertos/ti-arm-clang/linker.cmd
and the linux devicetree file for the same board,
board-support/linux-5.10.168+gitAUTOINC+2c23e6c538-g2c23e6c538/arch/arm64/boot/dts/ti/k3-am642-evm.dts

In the linker command file, we place the resource table that is required for RPMsg communication at DDR_0, at 0xA2100000. The rest of the DDR data is placed behind the resource table.

This should match the Linux device tree file:

                main_r5fss1_core0_dma_memory_region: r5f-dma-memory@a2000000 {
                        compatible = "shared-dma-pool";
                        reg = <0x00 0xa2000000 0x00 0x100000>;
                        no-map;
                };

                main_r5fss1_core0_memory_region: r5f-memory@a2100000 {
                        compatible = "shared-dma-pool";
                        reg = <0x00 0xa2100000 0x00 0xf00000>;
                        no-map;
                };

...

&main_r5fss1_core0 {
        mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core0>;
        memory-region = <&main_r5fss1_core0_dma_memory_region>,
                        <&main_r5fss1_core0_memory_region>;
};

Where Linux creates the VIRTIO buffers used for RPMsg communication, places them at 0xA2000000, and then updates the resource table that the linker command file placed at 0xA2100000 so the R5F core knows where the VIRTIO buffers are.

So if you wanted to place these memory regions somewhere else, you would need to update both the MCU+ linker command file, and the Linux devicetree, so that they matched.

Other questions 

Yes, unallocated memory can be used for shared memory, or other uses.

Is there a miminum DDR size? The minimum DDR size will come from your usecase, NOT from the arbitrary memory allocations in our out-of-the-box example. If you can get Linux to run properly with 512 MB DDR, then you can simply move the R5F memory allocations to a lower memory address.

Is there specific performance data? At this point in time, we have not run benchmarks on the shared memory performance (partially because each usecase will be unique).

Regards,

Nick