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.

Syslink shared memory - static allocation

Other Parts Discussed in Thread: OMAPL138

Hi,

I am using syslink_2_21_03_11 with OMAP L138. I would like to better understand the way shared region is statically allocated in HLOS. I only understand how to do so on slave processor running SYS/Bios.

AT the following link I found some information http://e2e.ti.com/support/embedded/tirtos/f/355/t/141150.aspx:

"Actually, the method that's the most preferred and the easiest to do, is for you to not call SharedRegion_setEntry dynamically at all. If you want any extra SharedRegion, if you set it statically in the cfg file of the slave (any slave), it gets automatically pulled into and mapped into all processes that may run after that on A8, and you don't need to call SharedRegion_setEntry explicitly on the A8 at all. You can simply call SharedRegion_getHeap and start using the heap for your shared memory allocations. This is the method we suggest as the easiest to use."

How is the map of shared regions passed to other cores? Do I have to allocate at least one shared region on the host too? If so, how do I define the size and the address of the region at the host?

Regards

Gleb

 

  • Hi Gleb,

    In a system where SharedRegions are statically configured on the slaves (ie. the use case that is being referred to by that passage), they are defined by calling SharedRegion.setEntryMeta() in the .cfg file of each slave. On a device with multiple slave cores, these definitions need to match up across all .cfg files. On the OMAPL138 however, you only have one slave processor (the DSP), so all you need to do is to call SharedRegion.setEntryMeta() in the .cfg file for the DSP. This call ensures that the SharedRegion information is embedded into the slave executable. When this slave executable is loaded, the information will appear in the slave's memory.

    On the HLOS, when you run your SysLink-based application, you would typically call Ipc_control(Ipc_CONTROLCMD_LOADCALLBACK) and Ipc_control(Ipc_CONTROLCMD_STARTCALLBACK). The first one reads out the SharedRegion information from the slave's memory. The second one then maps each SharedRegion to the application process' address space, so that the application can access it.

    In any given SysLink application, it is implicit that there is at least one SharedRegion (SR 0) defined on all cores. This is a special SharedRegion that contains much of the internal shared control data that is necessary for SysLink/IPC to operate. If you define this SharedRegion on the DSP's .cfg file, it will be automatically picked up by the host upon calling Ipc_control().

    If you take a look at some of the examples provided in SysLink (e.g. ex02_messageq), you should be able to see how the SharedRegions are setup.

    Hope this helps,

    Vincent

  • Hi Vincent,

    Thank you for the reply, things get more clear now. I still don't understand two points:

    "On the HLOS, when you run your SysLink-based application, you would typically call Ipc_control(Ipc_CONTROLCMD_LOADCALLBACK) ..."

    "In any given SysLink application, it is implicit that there is at least one SharedRegion (SR 0) defined on all cores. "


    Do I need to statically declare SR0 on HLOS too or only on DSP?

    If HLOS definition is needed then how do I make it (i.e. in which file or function call)?

    If only DSP definition is required then I don't understand how a call to Ipc_control can find the shared region defined by slave. How does this lookup mechanism work?

     

    Regards

    Gleb

  • Hi Gleb,

    Do I need to statically declare SR0 on HLOS too or only on DSP?

    No. You only need to define it statically on the DSP in the .cfg file.

    If only DSP definition is required then I don't understand how a call to Ipc_control can find the shared region defined by slave. How does this lookup mechanism work?

    The magic here is that there is a special symbol defined in the DSP executable (_Ipc_ResetVector) that marks a location with the info about the SharedRegions defined on the DSP. When Ipc_control is called, it simply looks up that address and pulls out the relevant info about the SharedRegions.

    Best regards,

    Vincent

  • Thanks, Vincent, all is clear now.