CMEM and C6RunLib issue

Just to be sure: did you load CMEM with a configuration preparing at least one buffer of the needed size? If being unsure, please provide your current CMEM setting.

Regards,
Joern.

P.S. With "cat /proc/cmem" you can take a look into the current CMEM buffer situation...

"cat /proc/cmem" output:

Block 0: Pool 0: 4 bufs size 921600 (921600 requested)

Pool 0 busy bufs:

Pool 0 free bufs:
id 0: phys addr 0x9a01f000
id 1: phys addr 0x99f3e000
id 2: phys addr 0x99e5d000
id 3: phys addr 0x99d7c000

Size of my buffer is exactly 921600 bytes. I load cmemk module by this command:

modprobe cmemk phys_start=0x96C00000 phys_end=0x9A100000 pools=4x921600

Function CMEM_alloc() works ok, error happens while calling function process() which supposed to be executed on DSP core.

As far as I'm concerned when application calls function which is supposed to be executed on DSP, it creates CMEM buffer of the size of the DSP executable image (0x9A100000 - 0x96C00000 = 0x3500000). But before this I have already allocated a buffer by CMEM_alloc of 921600 bytes in this memory area so creating a buffer fails. I can't use malloc because I need to get physically contigous buffer.

Hm. I don't think so. I don't think that it is CMEM that's used to allocate buffer for the DSP executable image. However, in each case this buffer for the DSP code I would not await to be located within the memory managed by CMEM. See EZSDK memory map, and compare with your settings - maybe that leads a step further...

In my opinion CMEM simply provides some pools of buffers (of contiguous memory) for allocation, exactly for those purposes you've intended with your 921600 bytes long buffers.

The error about the 0x3500000 bytes first has to do with your CMEM phys_start=0x96C00000 and phys_end=0x9A100000 setting. For me it seems to be somewhat conflicting with other memory settings, at least regarding the standard memory maps (but actually I don't know how much physical memory at all you have, and which memory map settings you are using). In each case this area is more then wide enough to contain your pool of the 4 buffers of size 921600 bytes.

But you write, the CMEM memory alloc would have been successfully - that leaves me a bit loss, because else I had assumed that when allocating your first buffer CMEM starts managing the whole preset memory area and meets some conflict.

I never used C6Run (CodecEngine framework instead), but now I found within the C6Run FAQ this snippet of information you've given above, too: "Initialize CMEM if not already initialized, create a CMEM buffer of the size of the DSP executable image, copy the DSP executable data from the ARM process memory to the CMEM buffer." But I wonder because there is not written about a buffer (or buffer pool) which has to be preconfigured for this purpose. In each case I do not belive that your DSP executable is actually as big as 0x3500000 bytes. But maybe it is bigger than 921600 bytes. Maybe you should try to provide one bigger buffer and some less of the 921600 buffers. Just for testing around the issue. If that solves the problem for the first, you would have to think of where unused memory regions are which might be handled by CMEM too get the amount of buffers you actually need...

Thank you for responding.

While compiling C6EZRun Framework I can configure which physical addresses it will use. Here are the variables by default:

DSP_REGION_BASE_ADDR = 0x96C00000 // starting address of region that C6Run uses
DSP_REGION_CMEM_SIZE = 0x02000000 // size of region given to heap for allocating buffers that the DSP and ARM can share
DSP_REGION_CODE_SIZE = 0x01500000 //size of region given to DSP for executable code, its stack, heaps, etc.

If I call DSP-function after CMEM_alloc I got an error on DSP-function "failed to allocate heap buffer of size 0x3500000". From all appearances C6Run needs the whole memory area of 35 megabytes to work. If I call an even simple DSP-function (only printf) I got an error on CMEM_alloc "failed to allocate heap buffer of size 0xe1000".

I rebuild C6Run with new addresses:
DSP_REGION_BASE_ADDR = 0x98C00000
DSP_REGION_CMEM_SIZE = 0x01000000
DSP_REGION_CODE_SIZE = 0x00500000

modprobe cmemk phys_start=0x96c00000 phys_end=0x98c00000

In this case with simple DSP-functions all works fine, I successfully pass arguments by value to DSP. But when I try to pass pointer to DSP I got error "./process.gpp_stub.c: C6RUN_SHAREDMEM_lookupBuffer() failed". I tried different combinations of cmemk module parameters but nothing has changed.

Interestingly C6Run seems to use CMEM more directly to provide functions for buffer allocating/freeing, even from that area based on DSP_REGION_BASE_ADDR. 

Unfortunately I have no experience with C6Run (and will not gather in the future, as it is no longer maintained by TI).

But from this entry in TI's wiki I got the feeling, that maybe you don't need to use the buffer pool management by CMEM, but instead CMEM_alloc just may/should use C6RUN_MEM_malloc... maybe that vague thought helps a step further.

Best regards,
Joern.