This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

IPC Shared Region: Placing variables in Shared Region

 

I'm using a C6670 and trying to solve the same problem as discussed here http://e2e.ti.com/support/embedded/bios/f/355/t/123986.aspx i.e. I'd like to place a variable in a SharedRegion section using a #pragma or similar. A simple example of the contents of the *.cfg file is as follows:  

var SharedRegion = xdc.useModule('ti.sdo.ipc.SharedRegion'); 

SharedRegion.setEntryMeta(0,
{

base: 0x0C000000, 
len: 0x00010000,
ownerProcId: CONTROLLER_PROC_ID,
isValid: true,
createHeap: false,
 name:"my_shared_region",

});

in the generated linker.cmd file the Shared Region is listed 

SECTIONS
{
ti.sdo.ipc.SharedRegion_0: { . += 0x10000;} run > 0xc010000, type = NOLOAD

}

I thought that I'd be able to do something like

int my_example_buffer[1024];
#pragma DATA_SECTION(my_example_buffer, "ti.sdo.ipc.SharedRegion_0");

This seems to result in the buffer being put at the end of the shared region i.e. at  0x0C010000 . Is is possible to get the linker to place a variable within a SharedRegion and if so, how? The Verified answer in the previously mentioned thread doesn't work either!

 

 

 

 

 

 

 

 

  • You cannot place things into the SharedRegion.  That is why we generate the section so that this memory is reserved for SharedRegion usage.  Basically part of the SharedRegion is used for IPC handshake and the rest is a Shared memory heap that can be used between the cores.  You Cannot place your variable within the SharedRegion because it will get over written by SharedRegion.

    Is your buffer meant to be used across different cores?  If so, does it have to be allocated statically or can it be done dynamically by a heap?  If it can be done dynamically, I would simply use the heap that SharedRegion gives you.  If it has to be done statically, then I would use the #pragma as you are, specify my own section, and place my section at the memory I want.

    Judah

  • Hi Judah,

    Yes this the buffer needs to be both used across cores and statically allocated. I thought that using the Shared Region would allow us to avoid having to perform explicit cache line invalidation/writeback operations, but perhaps that's incorrect?

    Would the following be a sensible approach?

    1. Create a custom RTSC platform to define a segment to be used as a non-cached area of MSMCSRAM.
    2. Use MPAX logic to map a virtual address to the segment to be used as a non-cached area.
    3. Create a section that exists in the non-cached segment.
    4. Use the #pragma to place the buffer at the physical address in this section. Read/write operations would be via the virtual address.

    This suggestion seems quite complex though! Perhaps the simpler approach would be to just to ensure that the buffer is aligned on a cache line boundary in MSMCSRAM and be aware of the need to invalidate/writeback when required?

    Thanks for your prompt reply. At the very least it suggests that I'm trying to use SharedRegion not how they're intended.

    Andrew

  • Andrew,

    I think you nailed the steps necessary if you want the buffer in the non-cached msmc shared memory.

    Judah

  • Would TI be able to provide a more concrete example? I'm now confused how Shared Regions are used "normally" and without the heap option.

  • There are two examples (Notify and MessageQ) provided by IPC that use SharedRegion in the "normal" sense.  Have you looked at these?

    In the typical case, a shared heap is created in a SharedRegion.  This shared heap can be used across different processors.  For examples, I can call Memory_alloc() from core0 and then pass the message to core1 and core1 could then process the message and then call Memory_free().

    In the case you don't want a heap created by default, then no shared heap will be created.  You would only do this if you were going to manage the memory yourself.

    Maybe explain what you are confused about?  SharedRegion is a pretty basic module.  There's no smarts in it.

    Judah

  • My confusion lay in how Shared Region should be used when the shared heap isn't used. It looks like I can just use the Shared Region (accessed via a non-cached address) to achieve what I was after. The main thing is that I don't need to concern myself with making custom platforms and dedicated segments as I suggested earlier.