ARM reads captured data from shared memory DVRRDK-DM8168

To get captured frames on A8 you will have to create a chain like capture ->ipcFramesOut (VPSS M3) -> ipcFramesIn (A8)

The usecase /dvr_rdk/mcfw/src_linux/mcfw_api/usecases/multichhd_vcap_venc_vdis.c can be used as reference for ipcFramesOut -> ipcFramesIn connection.

THe demo file /dvr_rdk/demos/mcfw_api_demos/mcfw_demo/demo_vcap_venc_vdis_ipc_frames_exch.c can be used as reference for app code to get video frames from mcfw.

The frames will have physical address of the buffer populated. If you want to access the buffer via CPU do mmap of the physcial address to get virt buffer pointer

Dear Badri,
  Thanks for your reply.
  If we want to use shared memory (eg, SharedRegion_getHeap), is there any document and complete sample code for reference?

The API documentation of SharedRegion APIs can be found in <til_tools>/<ipc>/packages/ti/ipc/SharedRegion.h

Example code for SharedRegion can be found in syslink package.

http://processors.wiki.ti.com/index.php/SysLink_UserGuide has section on SharedRegion.

For use in DVR RDK refer ti_vsys.c Vsys_allocBuf/Vsys_freeBuf API implementation

Dear Badri,

For use in DVR RDK refer ti_vsys.c Vsys_allocBuf/Vsys_freeBuf API implementation
==> This file describe the usage to allocate buffer and free buffer.

 Are there any examples about below
    a. how to put data into the shared region in either A8 side or M3/DSP side?
    b. how to get data from the shared region in either A8 side or M3/DSP side?

The ipc module ListMP provides the functionality to put data in shared region and get data from shared region. This is the same module that is used in RDK to exchange frames from one core to another.

ListMP code can be found in ti_tools/<ipc>/packages/ti/sdo/ipc/ListMP.c

Function to put in sharedMemory is ListMP_putTail

Function to get from sharedMemory is ListMP_getHead

Is there any more simple code to help beginner to understand that? (pure description about usage for SharedRegion_XXX and example)

You can refer it here

DVRRDK_03.50.00.05\ti_tools\syslink\syslink_2_20_02_20\examples\archive\TI816X_linux_elf\ex04_sharedregion.zip

This will show how SharedRegions are used. Once you get familiar with APIs you can grep them in DVR RDK code to see how they are used in our code. This will gice you better idea. There are examples of other modules as well in DVRRDK_03.50.00.05\ti_tools\syslink\syslink_2_20_02_20\examples\archive\ directory based on different platforms.

Dear  Yogesh,

thanks for your opinion.

Q1. Could it be applied to 03.00.xx.xx? 

Q2. the Memory_alloc has a alignment parameter, how could I use that?

Hi,

Q1. Could it be applied to 03.00.xx.xx? 

- Yes. RDK 3.0 will have corresponding SysLink version in ti_tools you can look for example in that.

Q2. the Memory_alloc has a alignment parameter, how could I use that?

- As I look at the code, the 'align' parameter in Memory_alloc()->MemoryOS_alloc() in SysLink is not being used. Memory_alloc() translates into malloc() in Linux user space and kmalloc() or vmalloc() in kernel space based on 'flags' that you pass. None of these calls take alignment as input, so you can not use that (Linux would take care of alignment based on size). I think the main intention behind having align parameter in Memory_alloc() was to ensure if SysLink is ported to OS which has API for memory allocation that allows to specify alignment, interface should still remain same. Also, It allows us to match this API with BIOS side. For Linux or QNX 'align' parameter is not being used. 

Dear Yogesh,

Thanks for your reply.

if I need a aligned memory when using Memory_alloc, how can I do that?

It is possible to create aligned memory if you use HeapMemMP. Are you passing heap handle to Memory_alloc() or you are passing NULL? In first case, while allocating from heap Memory_getMaxDefaultTypeAlign() restricts it to 4 if align is passed as 0, otherwise it will take align value and pass it to IHeap_alloc() This can be HeapMemMP or HHeapBufMP_alloc. In second case, 'align' doesn't take effect.

I would request you to have a look at HeapMemMP_alloc() APIs to see how alignment is handled. In short, to have aligned memory you would need to create HeapMemMP.

Dear Yogesh,
  Thanks for your reply.
  About the following function,
  SharedRegion_getSRPtr (Ptr addr, UInt16 regionId)
  how did I know the range of the regionId, and is there any different properties for usage between these regions?

SharedRegions are created at the time of configuration from slave cores (M3/DSP). It means you know the shared region IDs that you have created. If you open up a map file of any of the slave core you can see SharedRegions created in it (SR0, SR1, SR2 etc). Map files get generated in dvr_rdk\build\dvr_rdk\bin\ti81xx-evm folder. To see how shared regions are set you might want to look at dvr_rdk\mcfw\src_bios6\cfg\ti816x\SYSLINK_common.cfg as an example, in that please look at SharedRegion.setEntryMeta();

You can look at Vsys_allocBuf() to see how SharedRegion_getSRPtr () is used. In general ,I would say if you read through DVRRDK_03.50.00.05\ti_tools\ipc\ipc_1_24_03_32\packages\ti\ipc\SharedRegion.h it will get better idea of what each API in that module is doing and what its parameters mean. This applies to other modules in SysLink/ipc.

Dear Yogesh,
  Thanks for your reply.

  By checking \dvr_rdk\mcfw\src_bios6\cfg\ti816x\config_2G.bld, we found some region are cacheable, some aren't.
  Q1. why not all regions are cacheable?
  Q2. how to make all region are cacheable?

Hi,

Please refer dvr_rdk\mcfw\src_bios6\cfg\ti816x\SYSLINK_common.cfg, comments provide detailed description why each region is kept cached or non-cached

e.g.

/*
        This section is mainly used for bitstream buffer's
        which need to be cached on A8 side for better performance
        of HDD, ethernet read/write

        A8  - CACHED
        M3  - CACHED
        DSP - CACHED
*/

SharedRegion.setEntryMeta( 1,
    {
      base:        sr1MemSection.base,
      len:         sr1MemSection.len,
      name:        sr1MemSection.name,
      isValid:     true,
      ownerProcId: srOwnerProcId,
      cacheEnable: true,
      cacheLineSize: 128,
      createHeap:  true
    }
);

set true or false for cacheEanble to make it cacheble or non-cacheable.

System will not work if you enable caching for all regions. There is a reson why cache is disabled for some regions.

Sr0 has to be cache disabled. This is because we place IPC control structures in SharedRegion0 and the IPC control structures used in mcfw assume caching is disabled (ie. Structure is not aligned to cache line)/

Remote debug mem has to be cache disabled. This is because no cache coherency operation is done by the slave cores and it is expected that this memory region is not cached.

HDVPSS descriptors has to be cache disabled. This is because the HDVPSS IP reads configuration from DDR and the HDVPSS driver on M3 doesnt take care of doing cache choerency operations.

Note that enabling or disabling caching property of shared region doesnt really enable caching. Caching is controlled by processor configuration and is different for different cores.

IN summary you cannot change cache configuration.System will not work if you modify default configuration

Dear Yogesh,

Thanks for your very detail explanation

Hereunder are my new question.
Q1. We found some regions can't be seen by all, why? how could I modify that?
Q2. how do I know the owner of the region? (someone use SharedRegion_setEntry() in dynamical configuration ?? how about static configuration ??)
Q3. SharedRegion configuration can be done statically by updating the CFG file for a "particular slave", and what's the config file? Is it dvr_rdk\mcfw\src_bios6\cfg\ti816x\SYSLINK_common.cfg? In the default, the configuration of ti816x is done statically, right?

BTW Badri answered your last question.

Q1. We found some regions can't be seen by all, why? how could I modify that?

-  All regions are maintained in the local tables for all the cores, since all the slave cores are executing SYSLINK_common.cfg they have a local view of all SharedRegions and hence by default all commonly added SharedRegions are accessible from all the cores. Now, it may happen that there are some SharedRegions needed not be accessed by other cores e.g. Have a look at System_ipcIntraDucatiSrOpen() it adds SYSTEM_IPC_SR_M3_LIST_MP  SharedRegion that is only accessed by M3Video or M3VPSS. A8 and DSP need not have this entry in their SharedRegion table. 

Q2. how do I know the owner of the region? (someone use SharedRegion_setEntry() in dynamical configuration ?? how about static configuration ??)

Application need not worry about SharedRegion owner. This is decided at static time through configuration or while doing setEntry dynamically.  ownerProcId comes into picture if heap needs to be associated with shared region. If owner of the SharedRegion is calling setEntry with createHeap = TRUE, heap will be _created_ out of that SharedRegion. If non-owner core is calling setEntry the heap will be just _opened_. If you are calling setEntry dynamically you must ensure the SharedRegion you are adding is not overlapping with existing one or the entry doesn't exist already, in these cases you will get SharedRegion_E_FAIL or SharedRegion_E_ALREADYEXISTS. 

Please understand SharedRegion module on each core maintains a table and that is a _local_ view of every SharedRegion in the system.

Q3. SharedRegion configuration can be done statically by updating the CFG file for a "particular slave", and what's the config file? Is it dvr_rdk\mcfw\src_bios6\cfg\ti816x\SYSLINK_common.cfg? In the default, the configuration of ti816x is done statically, right?

Yes thats correct. All three slave cores execute SYSLINK_common.cfg

Dear Yogesh,
 Thanks for your very detail explanation

Hereunder are my new question.
Q1. We found the cacheline size is always 128 in SYSLINK_common.cfg. Will the access performance get better if I increase this value? what's the range of this value?
    is there any restriction about this value (like power of 2)? Or is there any thing I should pay attention to?

128 is a default value for cacheLineSize. Range of this value might be specific to a core. I'm not sure if this has been tested with different value other than 128.

Dear Yogesh,
 Thanks for your reply.

Because we want to improve the performance, I need to clarify every possibility. Please help that.   
Really appreciate.