Hi,
in an application we are running CodecEngine and OMX concurrently. Video Frames are
processed by an algorithm running on the DSP and then get H264 encoded via
gstreamer-OMX (OMX.TI.DUCATI.VIDENC)
We are using ezsdk_dm814x-evm_5_05_02_00
Codec Engine is encapsulated in a shared library called “libce.so”:
( libce.so (libc6,hard-float) => /usr/local/lib/libce.so)
This setup is similliar to the example provided in the ezsdk:
ti-ezsdk_dm814x-evm_5_05_02_00/component-sources/codec_engine_3_22_01_06/examples/ti/sdo/ce/examples/apps/video_copy/dualcpu_separateconfig
Instead of providing an “object-file” we are providing a shared library.
OMX is build by ezsdk 5.05.02:
( libOMX_Core (libc6,hard-float) => /usr/local/lib/libOMX_Core)
All Sources are compiled with Flags “-Bsymbolic” so there won’t be any
same-symbols-mismatch between OMX and Codec Engine and each shared library
is using its own symbols first.
The software is working without problems. The only issue is when the programm has been run 4 times....
the fifth and following runs will fail:
It fails in DomxCore_mapPhyAddr2UsrVirtual while trying to
map 0x9A100000 (IPC_SR_MC_HDVICP2_HDVPSS )
The problem in DomxCore_mapPhyAddr2UsrVirtual() function:
The Code first tries to ProcMgr_translateAddr().....if it is not SUCESSFULL
(meaning the Memory is not mapped yet) it will try to ProcMgr_map() the memory.
The function returns with 159195136 (this is no valid documentated return value!!!)
Then code tries to ProcMgr_translateAddr() again....and will also fail
Because DomxCore_mapPhyAddr2UsrVirtual is failling (not giving us a correct address ) and
DomxProcMgrIf_HLOS.c:316: DomxCore_mapPhyAddr2UsrVirtual: Assertion `(status >= 0)' failed.
Unable to handle kernel NULL pointer dereference at virtual address 00000000
At the moment it is unclear why mapPhyAddr2UsrVirtual is failling after 4 application restarts...
Probably there is something wrong with SharedRegion configuration and handling?
Perhaps this might be also related to unclean? deinitalization of Codec Engine or OMX.
Which should be the right deinitalization-order in order not to mess up SharedRegions??
It would be good to have more information about Shared Regions:
-> who creates or should create them? who should be the owner? What are the M3 Firmwares doing?
-> #define DOMX_CORE_DOPROCINIT (0) or #define DOMX_CORE_DOPROCINIT (1) for OMX Layer?
-> memconfig in firmware loader correct?
-> is it possible to have omx and CE run together? (concerning syslink used twice?? syslink_setup + syslink_destroy twice?)
-> sometimes when SharedRegions are messed up? CE is unable to upload DSP-Firmware
and camera has to be rebooted
Any Idea how we can fix this?
Thank you! Regards
Benjamin
-------------------------------------------------------------------------------------------------------------------------------
Some additional changes that were made:
Firmware Loading:
Following is the firmware loading performed by init script:
./prcm_config s
sleep 1
./firmware_loader_no_init 1 dm814x_hdvicp.xem3 start -mmap mm_dm81xxbm.bin
./firmware_loader_no_init 2 dm814x_hdvpss.xem3 start -mmap mm_dm81xxbm.bin
md5sums:
6e28a7bb9f52187baebefb294a21054c dm814x_hdvicp.xem3
2ca936395fa92e169ff1698c62bc353d dm814x_hdvpss.xem3
-> Version: 05_02_00_48
Firmware Loader has been patched to do no Shared Region Configuration.
There are no calls to SharedRegion_setEntry() any more in the loader.
firmware_loader.c - Line 663
frmldr_createSr won’t be called cause of:
if(0){ // (TRUE == ipcInit_memCfg) {
idx2HeapHdl = 0;
….
Firmware loading is sucessfull: (checked via trace output buffer of M3’s)
N:Video P:1 #:00030 T:0000000004e2ea43 M:xdc.runtime.Main S:Module<ti.omx> @<omx rpc_rcm_server_start> @line<258> msg<After RcmServer_start>
N:VPSS P:2 #:00032 T:0000000011b53acf M:xdc.runtime.Main S:Module<ti.omx> @<omx rpc_rcm_server_start> @line<258> msg<After RcmServer_start>
OMX LAYER:
component-sources/omx_05_02_00_48/src/ti/omx/memcfg/src/memcfg.c
static int32_t memcfg_module_init_shared_region (void) - Line 251
Following changes were made:
/* if (MEMCFG_sharedRegionTypeMaster ==
MEMCFG_sharedRegionConfigTable.aSRInfo[i].srType)
{*/
srOwnerProcId = MultiProc_self ();
createHeap = TRUE;/*
}
else
{
srOwnerProcId = SharedRegion_DEFAULTOWNERID;
createHeap = TRUE;
}*/
In TI Forums there was written assigning SharedRegion_DEFAULTOWNERID is not valid
LINK (http://e2e.ti.com/support/embedded/linux/f/354/t/135217.aspx)
