Questions on shared region on syslink

Hi, Eric,

There is an earlier post on how shareregion be set up in e2e forum at http://e2e.ti.com/support/embedded/bios/f/355/t/141150.aspx. I extract the relevant info as below and hope this helps.

When creating Shared Region entries dynamically you will need to call the SharedRegion_setEntry API, which adds the SharedRegion into the local SharedRegion information table. Therefore, To enable usage from other cores, SharedRegion_setEntry must be called on each core that shares this SharedRegion.

There is a dependency of  sorts due to SharedRegion_setEntry taking a virtual address argument. So, when creating a Shared Region on a slave core, you would need a mapped virtual address, and in order to do this you would need to use SysLink ProcMgr_map API on the Host, and map the shared region's physical address to the slave core's virtual address space. Then this slave virtual address can be used by the slave to call SharedRegion_setEntry on the slave.

Rex

Thanks! I read the thread and it looks like on all slave cores I also need to call SharedRegion_setEntry API.

In my case, I didn't use the dynamic allocation, I used shared region 2 and 3 instead. Region 2 is pointed to DDR3 and region 3 is pointed to MSMC. Is this a static mapping and do I still need to call SharedRegion_setEntry API on all slave cores? If yes, in the syslink\samples\rtos\sharedRegion folder I didn't see sample codes for this?

The DSP Linux code (on CORE 0) used the DDR3 address 0x8000,0000 to 0x803E,4760. This region can't be used for other purpose. What is the purpose to map/share part of this region to other cores as shown in the console log?

Regards, Eric 

lding said:

Does this mean Linux virtual address 0x9fe25100 is mapped to physical address 0x80000100?

I'm not familiar with that output (don't know the application), but I would say "Yes".

lding said:

If so, I used memset() to set the memory content of Linux virtual memory in SharedRegionApp.c. Then on other DSP cores I used CCS memory window to look at the physical address. However I didn't see the value I set. Can you explan how sharedRegion works?

SharedRegions are just DDR memory, like any other DDR memory.  However, since it's shared it needs to be cache-aware and managed.  And since there are two processors involved, each one with a cache, each side needs to manage the cache.  After memset() on Linux, the virtual address needs to be flushed to memory.  Then, on the DSP the cache(s) need to be invalidated before reading the memory window in CCS (otherwise the memory window will be reading possibly cached contents from old stale data).

Regards,

- Rob

lding said:

In my case, I didn't use the dynamic allocation, I used shared region 2 and 3 instead. Region 2 is pointed to DDR3 and region 3 is pointed to MSMC. Is this a static mapping and do I still need to call SharedRegion_setEntry API on all slave cores?

No, SharedRegion_setEntry() is the run-time equivalent to static creation in a .cfg file.

lding said:

The DSP Linux code (on CORE 0) used the DDR3 address 0x8000,0000 to 0x803E,4760. This region can't be used for other purpose. What is the purpose to map/share part of this region to other cores as shown in the console log?

Since you've stated that you're using static SR config, I suggest you look into how those addresses are chosen.  Does the static config assign virtual addresses or physical ones?  Are those addresses immediate constants, or are they obtained through some Program.cpu.memoryMap[]?  If virtual, how is the mapping to physical addresses done?

Regards,

- Rob

Rob,

Thanks very much for the explanation. I found that "User vitual address" is actually the physical address. E.g., in Linux core I wrote something to this User vitual address, it showed up at the same address in CCS memory browser, not at the "Shared region pointer".

User vitual address   =  [0x9fe25100]
Shared region pointer =  [0x80000100]

For "SharedRegion_setEntry() is the run-time equivalent to static creation in a .cfg file.", can you explain how this is done in .cfg file? I am attaching the .cfg for core 1.2664.SharedRegion_c6678_core1.cfg

Regards, Eric

lding said:

Thanks very much for the explanation. I found that "User vitual address" is actually the physical address. E.g., in Linux core I wrote something to this User vitual address, it showed up at the same address in CCS memory browser, not at the "Shared region pointer".

User vitual address   =  [0x9fe25100]
Shared region pointer =  [0x80000100]

Odd, I don't know what that "Shared region pointer" is then.  Its value (0x80000100) falls in DDR3 on the evm6678 platform, but so does 0x9f325100 (DDR3 goes from 0x80000000 -> 0xa0000000).  It makes more sense that it would be the 0x9f325100 value, though, since 0x80000100 falls in the area given to Linux, and shared regions are generally carved out of high DDR3 areas.  But those "Shared region pointer" prints seem to follow the "User virtual address" prints in their lower address offset values (assuming 0x9fe25000 as the user virtual base and 0x80000000 as the shared region pointer base), however I don't know that application and what it's trying to display.

lding said:

For "SharedRegion_setEntry() is the run-time equivalent to static creation in a .cfg file.", can you explain how this is done in .cfg file?

Here is an entry from a Codec Engine server .cfg file for the platform ti_platforms_evm6678:
var SharedRegion  = xdc.useModule('ti.sdo.ipc.SharedRegion');
var ipcSharedMem = Program.cpu.memoryMap["MSMCSRAM"];

/*
 *  Need to define the shared region. The IPC modules use this
 *  to make portable pointers. All processors need to add this
 *  call with their base address of the shared memory region.
 *  If the processor cannot access the memory, do not add it.
 */

var entry = new SharedRegion.Entry();

entry.base = ipcSharedMem.base;
entry.len = ipcSharedMem.len;
entry.ownerProcId = 0;
entry.isValid = true;
entry.cacheLineSize = 64;
entry.name = "MSMCSRAM";

SharedRegion.setEntryMeta(
    0,  /* index */
    entry
);
where Program.cpu.memoryMap["MSMCSRAM"] comes from this definition in ti.catalog.c6000.TMS320C6678:

Regards,

- Rob

Rob,

Yes, both addresses:  [0x9fe25100] and [0x80000100] falled in DDR3 region. The application here is the sharedregion demo inside Linux MCSDK 2.0 GA release. What I wrote (using Linux user space application) appeared at address 0x9fe25100 when looked through CCS memory window. I don't know what this 0x80000100 meant but I can move forward.

The next question is the BIOS side. In the syslink\ti\syslink\samples\rtos\sharedRegion, there are source code (SharedRegionApp.c) and .cfg to build applications on cores 1, 2 .... 7. Do you have a CCS project to build this?

There are 7 .cfg files (SharedRegion_c6678_coreX.cfg) for core 1, 2, ... 7 for 6678. The only difference is that: MultiProc.setConfig("COREX", ["CORE0", "CORE1", "CORE2", "CORE3", "CORE4", "CORE5", "CORE6", "CORE7"]);

Why we need different .out files for different cores? If this is necessary, is it possible to use one .cfg file but do something inside SharedRegionApp.c to achieve this? The problem for me is that I have a openMP application (built by CCS project) I wanted to run on cores 1-7. The openMP use .cfg as well, and the .out file is the same for all cores and loaded in DDR3. It takes about 10 minutes to build. If I have to use different .out on each core based on its own .cfg, it will take me 70 min to build the openMP application. Do you have any general recommendation how to use a single .cfg file?

Regards, Eric

Rob,

Just want to update you that I found a wiki page for building syslink with CCS: http://processors.wiki.ti.com/index.php/Creating_CCS_Project_for_SysLink_samples, The example is for message Q on TI814X. I did the similar for sharedregion on 6678, when build I encountered errors:

ti\syslink\ipc\rtos\package\package.bld.xml (The system cannot find the file specified).

ti\syslink\ti\syslink\ipc\rtos\interfaces\package\package.bld.xml (The system cannot find the file specified).

Do you know where this file came from? From command line, I can do "make syslink-user" and "make syslink-rtos-all" without problem.

Regards, Eric

Hello Eric,

That build error is caused by not having built the SysLink libraries.  After installing the SysLink product, you need to set your DEVICE and the various product and tools installation directories in the products.mak file at the root of the SysLink install.  Then you need to build the syslink libraries for your device.  If you run "make help" at the root of the syslink installation, you will see the various build targets.  However, as far as I know, SysLink for DSP Linux on C6678 is not supported.  You can have BIOS running on all cores, and then you just use Ipc and not SysLink.

Best regards,

    Janet

Nonsense; the c6x-linux has already ported syslink to the c6x.

If you have build the c6x-linux environment, the succes will in the "./Build/syslink_evmc6678.el/ti/syslink" directory.

Move this directoy ("/syslink") to you "/opt/ti/bios_6_34_02_18/packages/ti" diretory, or include somewhere in your build script.