AM57x ARM-DSP Shared Memory

Gerard

Other Parts Discussed in Thread: AM5728

System Background:

AM5728 Processor
4GB RAM shared between ARM and DSP processors
- 3.5 GB for ARM
- 256 MB for DSP1
- 256 MB for DSP2
Memory is partitioned (via DMM, DSP MMU, etc) so the ARMs and DSPs have no overlap
Processor SDK 02.00.01.07
IPC 3.40.01.08

Question:

The ARM and DSP messaging will be handled via IPC's MessageQ - there are examples and documentation to cover this. The ARM and DSPs also have a need to transfer a large file (~3MB) from the ARM to the DSPs. The transfer happens infrequently - once during an initialization phase of our application SW.

What is the best way to handle this data/file transfer?

Searching the forum I see references to ARM-DSP shared memory but most reference older kernels and SDKs that predate the creation of the Processor SDK (and usually reference old IPC versions). So, I'm looking for the best present day solution. Perhaps the answer is we should not only use MessageQ for our messaging but also this data transfer? If the answer is to use generic shared memory, what works best with the versions of the Processor SDK and IPC noted above? My concern is how the solution works with the RAM partitioning noted.

Thank you!

over 9 years ago

0 Biser Gatchev-XID over 9 years ago

TI__Guru**** 393215 points

Can you clarify which Processor SDK is this - Linux, Linux-RT or RTOS?

0 Gerard over 9 years ago in reply to Biser Gatchev-XID

Expert 1290 points

Both the Linux and RTOS side of the Processor SDK - the ARM side of the file/data transfer will be Linux and the DSPs will be RTOS.

Thank you

0 Rahul Prabhu over 9 years ago in reply to Gerard

TI__Guru** 116170 points

Gerard,

I recommend that you checkout the example in the IPC package for DRA7xx/AM57xx devices that can be found under the path ipc_3_xx_xx_xx\examples\DRA7XX_linux_elf

The messageq example included in the package demonstrates slave cores (DSP or M4) creating a message to pass data around. The host sends a message to the slave core with a dummy payload. Please review the example and let us know if this will help you get started.

The example currently uses the platform definition form the TI RTOS package. The platform definition and the shared memory used by IPC is documented in the Platform.xdc file in bios_6_4x_xx_xx\packages\ti\platforms\evmDRA7XX.

 *            A 8A00_0000    80_0000  (   8 MB) IPU1 (code, data), benelli
 *              8A80_0000    80_0000  (   8 MB) IPU2 (code, data), benelli
 *            B 8B00_0000   100_0000  (  16 MB) HOST (code, data)
 *            C 8C00_0000   100_0000  (  16 MB) DSP1 (code, data)
 *            D 8D00_0000   100_0000  (  16 MB) DSP2 (code, data)
 *            E 8E00_0000   100_0000  (  16 MB) SR_0 (ipc)

Regards,

Rahul

0 Gerard over 9 years ago in reply to Rahul Prabhu

Expert 1290 points

I had previously looked at the MessageQ examples you referenced. Is MessageQ the preferred method/answer for any kind of transfer between ARM and DSP processors then? Is using some other shared memory mechanism not a good option?

Thank you

0 Garrett Ding over 9 years ago in reply to Gerard

TI__Mastermind 43296 points

Gerard,

You can also use CMEM to transfer large data in addition to MessageQ for control message or data pointer, see here for CMEM details:

Regards, Garrett

0 Gerard over 9 years ago in reply to Garrett Ding

Expert 1290 points

As noted in my initial post, we've set up the memory map for the MPU and DSPs in such a way that there is no overlap. I am assuming that in order to utilize CMEM, we would have to change our memory map configuration so that the MPU memory map includes some of the DSP1/DSP2 memory space. For MessageQ, however, this is not necessary (please confirm).

Are my assumptions correct?

0 Garrett Ding over 9 years ago in reply to Gerard

TI__Mastermind 43296 points

Gerard,

To use CMEM, you will need to create the CMEM nodes in Linux DTS file, e.g. am57xx-evm-cmem.dtsi in Processor SDK Linux:

cmem_block_mem_0: cmem_block_mem@a0000000 {

reg = <0x0 0xa0000000 0x0 0x0c000000>;

no-map;

status = "okay";

};

And you can check the CMEM blocks by 'cat /proc/iomem'.

For messageQ, the memory (rpmsg vring buffers) are allocated from CMA region defined in am572x-idk.dts, e.g.

dsp1_cma_pool: dsp1_cma@99000000 {

compatible = "shared-dma-pool";

reg = <0x0 0x99000000 0x0 0x4000000>;

reusable;

status = "okay";

};

We can discuss more in tomorrow's scheduled call.

Regards, Garrett

0 Christopher Peters over 9 years ago in reply to Rahul Prabhu

Genius 3380 points

Rahul, no SR_0 defined in the evmAM572X platform we are using. :(

0 Kevin Schuster over 9 years ago in reply to Garrett Ding

Expert 1210 points

I cannot find such an entry in my am572x-idk.dts file. But actually I think I saw something similar like "shared-dma-pool" during boot up. So is there another location I should look for?

0 Garrett Ding over 9 years ago in reply to Kevin Schuster

TI__Mastermind 43296 points

Kevin,

Were you looking into the Processor SDK Linux package board-support/linux-.../arch/arm/boot/ ? Are you using Processor SDK 2.0.1 or a pre-release of 2.0.2?

-Garrett

0 Kevin Schuster over 9 years ago in reply to Garrett Ding

Expert 1210 points

I am looking into the Processor SDK 2.0.1 board support folder of linux-4.1.13+gitAUTOINC+8dc66170d9-g8dc6617.

0 Garrett Ding over 9 years ago in reply to Kevin Schuster

TI__Mastermind 43296 points

Kevin,

Just realize you should be working with AM572x general purpose EVM instead of IDK. For the GP EVM cma pools, please look into the am57xx-beagle-x15.dts which is included in am57xx-evm.dts. The cma pools in am572x-idk.dts are only available in PSDK 2.0.2 early release.

Regards,
Garrett

0 Kevin Schuster over 9 years ago in reply to Garrett Ding

Expert 1210 points

Thank you, found it!

So what can I do now? Create a new block for the reserved memory section and one for the cmem section? I have a problem with creating CMEM buffer and pools (already described in this thread e2e.ti.com/.../506018 ) and I don't know how to use the CMEM stuff to create a buffer for sharing stuff between ARM and DSP1.

As I can see, I have some addresses in the RSC table for the DSP1. Do I have to create a node with an address mentioned in the rsc table? Something like this:
cmem_block_mem_0: cmem_block_mem@80000000 {
reg = <0x0 0x80000000 0x0 0x0c000000>;
no-map;
status = "okay";
};
-> Because of this define in the rsc table.
#define DSP_MEM_IOBUFS 0x80000000

Would that be an idea? Or what can I do to make it work? What should be the right address for sharing the CMEM buffer???

0 Garrett Ding over 9 years ago in reply to Kevin Schuster

TI__Mastermind 43296 points

Kevin,

Yes, you will need a CMEM pool for the data sharing, and the address in the cmem_block_mem is the physical address of memory.
DSP_MEM_IOBUFS is the virtual address. PHYS_MEM_IOBUFS is the corresponding phys address and you may need to update it for your application/platform.

This link (e2e.ti.com/.../430693) should help understand the CMEM pool and IOBUFS, (thanks to Chris who forwarded me the link).

Regards,
Garrett

0 Kevin Schuster over 9 years ago in reply to Garrett Ding

Expert 1210 points

The link is not working.

0 Christopher Peters over 9 years ago in reply to Kevin Schuster

Genius 3380 points

The link includes the ) at the end, cut that off and it should work.

0 Kevin Schuster over 9 years ago in reply to Garrett Ding

Expert 1210 points

Thanks for your answer, this helped very much!

I found out how this stuff works out now and described it here
e2e.ti.com/.../503515

Processors

Processors forum

AM57x ARM-DSP Shared Memory