newb question: how to pass HeapMemMP allocated pointers between cores?

Kent,

On the DSP, you would use SharedRegion_getSRPtr() to translate the local address into a portable address. Then use some transport of your choice to pass the srptr to the ARM; many people use MessageQ for this. On the ARM, you would use SharedRegion_getPtr() to translate the srptr into a local address.

Don't forget that cache management is your responsibility if you have cache enabled for the shared region.

~Ramsey

Ok, did that but during debugging both cores I couldnt get a variable write on the DSP side to be reflected on the ARM side, they both seemed to have their own unique values even though at the same address...\

Thinking it might be cache related I modified static setup of sharedregion to be:

var SHAREDMEM0           = 0xc2000000;
var SHAREDMEMSIZE0       = 0x00310000;
SharedRegion.setEntryMeta(0,
    { base: SHAREDMEM0,
      len:  SHAREDMEMSIZE0,
      ownerProcId: 1,
      isValid: true,
      name: "shared0",
      createHeap: true,
      cacheEnable: false,
      cacheLineSize: 0,
    });

with cache disabled, but now both CPUs hang while trying to do IPCstart, seemingly in some loop that includes SharedRegion_getCacheLineSize() etc...

Any help?

Kent,

The 'cacheEnable' property above does not *set* the cachability of the memory; its used to tell the SharedRegion module *if* the memory is cached. The memory is most likely cached by the DSP (this is actually controlled by the MAR bits), so you need to set this property to TRUE. This will tell the IPC software to add cache management calls. Setting it to false is probably why your Ipc_start is hanging.

It sounds like your DSP variable value is sitting in the DSP's cache and needs to be written out to DDR in order for the ARM to see the updated value. Add a Cache_wb or Cache_wbInv call to write your value out to DDR. See ti.sysbios.hal.Cache documentation.

Cache operations are performed on cache lines (typically 128 bytes). Keep this in mind when allocating variables in shared memory. If a variable is write-only on the DSP and read-only on the ARM, then you just need to issue a writeback on the DSP. But if the variable is read-write on DSP, then you need to issue a writeback-invalidate, and be sure not to reference the variable until the ARM has written to it.

The shared memory is typically not cached on the ARM side, so you don't need cache operations there. But if you enable cache on the ARM, the you must follow the same cache management rules there.

~Ramsey

Ok thanks for the info...so what I tried was to disable caching on my shared mem pages by adding Cache to my DSP static setup and turning off MAR 194 (0xc2) as it was on...

Rebuilt both cores and tried debug again, and it is still hanging in IPCstart...

I actually got two shared mems set up on 1 MAR page, one is temporary:

var SharedRegion = xdc.useModule('ti.sdo.ipc.SharedRegion');
/* Shared Memory Map */
var SHAREDMEM0           = 0xc2000000;
var SHAREDMEMSIZE0       = 0x00310000;
SharedRegion.setEntryMeta(0,
    { base: SHAREDMEM0,
      len:  SHAREDMEMSIZE0,
      ownerProcId: 1,
      isValid: true,
      name: "shared0",
      createHeap: true,
      cacheEnable: false,
    });

//var SHAREDMEM1           = 0x80000000;
//var SHAREDMEMSIZE1       = 0x00020000;
var SHAREDMEM1           = 0xc2F00000;
var SHAREDMEMSIZE1       = 0x00050000;
SharedRegion.setEntryMeta(1,
    { base: SHAREDMEM1,
      len:  SHAREDMEMSIZE1,
      ownerProcId: 1,
      isValid: true,
      name: "shared1",
      createHeap: true,
      cacheEnable: false,
    });

  Also, looking in SharedRegion.h I see this:

    Bool cacheEnable;
    /*!< Whether to perform cache operations for the region
     *
     *  If 'TRUE', a cache invalidate is performed before any read
     *  and a cache write back invalidate is performed after any
     *  write for the shared region.  The cache operations are done
     *  for all caches.  If 'FALSE', no cache operations are performed.
     */

   So if set TRUE, why would I have to do explicit cache calls, or is this comment wrong?

Kent,

Would you post the software product versions you are using (SYS/BIOS, SysLink, XDCtools, etc) to establish a baseline.

I'm puzzled regarding the hang in Ipc_start. Just to be clear, is the DSP hanging in the Ipc_start loop or in the Ipc_attach loop? My understanding is that this was working but breaks when changing cache configuration. Also, please verify that you have the following in your dsp.cfg file.

/* ipc configuration */
var Ipc = xdc.useModule('ti.sdo.ipc.Ipc');
Ipc.sr0MemorySetup = false;

Your cache configuration looks correct. Just to verify, both shared regions are to be in uncached memory. They both share MAR bit 194 (0xC200_0000 - 0xC2FF_FFFF), so bit-2 of Cache.MAR192_223 should be cleared. Something like this.

Cache = xdc.useModule('ti.sysbios.family.c64p.Cache');
Cache.MAR192_223 &= ~(1 << 2); /* clear bit-2 */

Kent Dekome said:

So if set TRUE, why would I have to do explicit cache calls, or is this comment wrong?

The comment is correct but it does not explain enough. SharedRegion and other IPC modules (HeapMemMP, GateMP, ListMP, etc) need to update data structures in the shared region memory. For example, HeapMemMP_alloc has to update the heap used and free lists which resides in the shared region memory. These modules look at the SharedRegion.cacheEnable property to know if they need to perform cache operations. However, there is no way for these modules to know what your code does with an allocated block of memory from the shared region. So, after your code writes to a block of memory returned from HeapMemMP_alloc, it must call Cache_wb before the remote core is able to see it. The IPC software stack would not know when to do this.

I've attached a message queue example configured for OMAPL138. Use the dsp configuration as a baseline. These examples are also available in the SysLink 2.20 release in the examples/archive folder. Here are brief instructions for building the example.

unzip ex02_messageq
cd ex02_messageq
edit products.maak
make all
make install
cp install/ex02_messageq <target file system>

~Ramsey

Both cores hang in Ipc_attach()...

Here's my cfg files for both cores, I use a common cfg file because thats what the MessageQ example I originally looked at did...not using SysLink yet just trying to get both cores to share mem using SYSBIOS...

SYSBIOS 6.33.4.39

IPC 1.24.2.27

XDC 3.23.3.53

6712.hera_arm.cfg

5611.hera_dsp.cfg

7317.hera_common.cfg

Had to drop the .xs extension on the last one to get it to upload...

Kent,

Looking at your dsp cfg file, the cache configuration looks incorrect. You are setting bit-1 (a value of 2 = 10 in binary, the left-most bit is bit-0). Furthermore, when the bit is set, it enables cache for that memory. You must clear the bit (set it to zero) to disable cache on that memory.

Your memory map looks like this I think.

/*
 *  base addr    size                comment
 *  ----------------------------------------------------------------------------
 *  C000_0000    200_0000  (  32 MB) MAR 192 - 193  don't care
 *  C200_0000    100_0000  (  16 MB) MAR 194        SR_0, SR_1  no-cache
 *  C300_0000   1D00_0000  ( 464 MB) MAR 195 - 223  don't care
 */

So, to make sure and clear MAR bit-2, you would use the following code.

Cache = xdc.useModule('ti.sysbios.family.c64p.Cache');
Cache.MAR192_223 &= ~(1 << 2);  /* xxxx xxxx xxxx xxxx xxxx xxxx xxxx x0xx */

I've also come to realize that you are using SYS/BIOS on both the ARM and DSP processors, and that you started with an IPC MessageQ example. I had thought you were running Linux on the ARM and using SysLink. This was an oversight by me, sorry. This has some significant consequences.

I previously told you to configure Ipc.sr0MemorySetup to false; this applies only when running Linux on the ARM. When running SYS/BIOS on the ARM, it must be configured to TRUE as follows.

/* ipc configuration */
var Ipc = xdc.useModule('ti.sdo.ipc.Ipc');
Ipc.sr0MemorySetup = true;

Kent Dekome said:

Both cores hang in Ipc_attach()...

When you are using an all SYS/BIOS system and have Ipc.procSync = Ipc.ProcSync_ALL, then your application code need only call Ipc_start; it should not call Ipc_attach. When you see the DSP hang in Ipc_attach, is this on the call stack from Ipc_start (which calls Ipc_attach internally) or are you calling this in your application? If its being called from Ipc_start, then hopefully the change above will fix this. If you are calling it from your application, then remove that call.

Finally, the example I attached only applies if you are using Linux and SysLink. Please ignore it.

You made your original post in the Linux forum but you should be in the BIOS forum. I'll get the moderator to move this thread. This way the IPC team will see your thread and be able to provide better support. Please come back to this forum if you move to Linux/SysLink.

~Ramsey

When I enabled Cache in DSP static setup it already had a couple bits turned on, I actually turned off the bit for MAR194 so my setup should be correct as far as that...

I will try Ipc.sr0MemorySetup = true in ARM project...

I originally posted to OMAPL138 forum by somebody moved the thread to Linux...

UPDATE:

this didnt seem to accomplish anything...and the help docs say this shouldnt even be enabled for my config...

1) I have turned off cache for the mar page I am using for shared mem

2) I am not hanging in IPcStart() on either core

3) I set an int on DSP side: *g_piBuf = -3;

4) I see it on the ARM side and set it there: *g_piBuf = -2;

5) I see it on the DSP side and set it there: *g_piBuf = -1;

6) I fail to see this back on the ARM side...

All my ptrs are declared volatile, if this makes a difference...