DM8168: Problem with shared memory allocation.

Krunal Patil

Hi,

I am trying to allocate shared memory from IPC_SR_FRAME_BUFFERS region. I am able to do it with single process but I want to allocate memory from two separate process at the same time.

Below is the scenario and its behavior (I hope I will be able to explain it clearly) . I created two sample application to minimize the scope:

Sample Application-1 (Process-1) : which does following:

Init OMX using OMX_Init();

Allocate heap using SharedRegion_getHeap()

Allocate buffer using Memory_alloc()

Wait infinite using while (1)

Deinit OMX

Sample Application-2 (Process-2) : which does following:

Allocate heap using SharedRegion_getHeap()

Allocate buffer using Memory_alloc()

Scenario-1

Run Sample Application-1 in background - Memory allocated successfully.

Again Run Sample Application-1 - OMX Failed to initialize and gives errors - Attached log -

Fullscreen 3527.scenario-1_omx_init_errors.txt Download

Assertion at Line no: 419 in /swcoe/sdk/cm/netra/arago-tmp/work/dm816x-evm-none-linux-gnueabi/ti-syslink-2_00_05_85-r4i/syslink_2_00_05_85/packages/ti/syslink/utils/hlos/knl/Linux/../../../../../../ti/syslink/ipc/hlos/knl/Linux/MessageQDrv.c: (cargs.args.create.handle != NULL) : failed Assertion at Line no: 419 in /swcoe/sdk/cm/netra/arago-tmp/work/dm816x-evm-none-linux-gnueabi/ti-syslink-2_00_05_85-r4i/syslink_2_00_05_85/packages/ti/syslink/utils/hlos/knl/Linux/../../../../../../ti/syslink/ipc/hlos/knl/Linux/MessageQDrv.c: (cargs.args.create.handle != NULL) : failed Assertion at Line no: 419 in /swcoe/sdk/cm/netra/arago-tmp/work/dm816x-evm-none-linux-gnueabi/ti-syslink-2_00_05_85-r4i/syslink_2_00_05_85/packages/ti/syslink/utils/hlos/knl/Linux/../../../../../../ti/syslink/ipc/hlos/knl/Linux/MessageQDrv.c: (cargs.args.create.handle != NULL) : failed Assertion at Line no: 1244 in /home/krunal/release_014/ezsdk_504/component-sources/syslink_2_00_05_85/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (handle != NULL) : failed Assertion at Line no: 700 in /home/krunal/release_014/ezsdk_504/component-sources/syslink_2_00_05_85/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (queueId != MessageQ_INVALIDMESSAGEQ) : failed ServiceMgr_prime: MessageQ_put failed: status = 0xfffffffe Assertion at Line no: 1244 in /home/krunal/release_014/ezsdk_504/component-sources/syslink_2_00_05_85/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (handle != NULL) : failed Assertion at Line no: 700 in /home/krunal/release_014/ezsdk_504/component-sources/syslink_2_00_05_85/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (queueId != MessageQ_INVALIDMESSAGEQ) : failed ServiceMgr_prime: MessageQ_put failed: status = 0xfffffffe Assertion at Line no: 1244 in /home/krunal/release_014/ezsdk_504/component-sources/syslink_2_00_05_85/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (handle != NULL) : failed Assertion at Line no: 700 in /home/krunal/release_014/ezsdk_504/component-sources/syslink_2_00_05_85/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (queueId != MessageQ_INVALIDMESSAGEQ) : failed ServiceMgr_prime: MessageQ_put failed: status = 0xfffffffe Assertion at Line no: 1244 in /home/krunal/release_014/ezsdk_504/component-sources/syslink_2_00_05_85/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (handle != NULL) : failed Assertion at Line no: 700 in /home/krunal/release_014/ezsdk_504/component-sources/syslink_2_00_05_85/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (queueId != MessageQ_INVALIDMESSAGEQ) : failed ServiceMgr_prime: MessageQ_put failed: status = 0xfffffffe Assertion at Line no: 1244 in /home/krunal/release_014/ezsdk_504/component-sources/syslink_2_00_05_85/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (handle != NULL) : failed Assertion at Line no: 700 in /home/krunal/release_014/ezsdk_504/component-sources/syslink_2_00_05_85/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (queueId != MessageQ_INVALIDMESSAGEQ) : failed ServiceMgr_prime: MessageQ_put failed: status = 0xfffffffe Assertion at Line no: 1244 in /home/krunal/release_014/ezsdk_504/component-sources/syslink_2_00_05_85/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (handle != NULL) : failed ServiceMgr_rxThreadFxn: bind() failed with errno = 98 Assertion at Line no: 766 in /home/krunal/release_014/ezsdk_504/component-sources/syslink_2_00_05_85/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (handle != NULL) : failed

Query: Does OMXInit is can be done only once? Isn't it re-entrant?

Scenario-2

Run Sample Application-1 in background - Memory allocated successfully.
Run Sample Application-2 - Allocation failed with error - Attached log -

Fullscreen 4338.scenario-2_memory_allocation_failed.txt Download

Assertion at Line no: 1081 in /home/krunal/release_014/ezsdk_504/component-sources/syslink_2_00_05_85/packages/ti/syslink/ipc/hlos/usr/SharedRegion.c: (id < SharedRegion_module->cfg.numEntries) : failed

Query: Is it necessary to call OMXInit() before memory allocation from SharedRegion? Should both OMXInit() and Shared region allocation be done from same process context ?

Query:

How can I allocate memory from shared region when the OMXInit() is done from separate process?

Any help will be highly appreciated.!

Regards,

Krunal

over 13 years ago

0 K Md Feroz Irfan over 13 years ago

TI__Expert 7225 points

Hi Krunal,

Assume, this is on Dm816x on ezSDK 5.04 on Linux???

Or is it Android?

Best Regards

Feroz

0 Krunal Patil over 13 years ago in reply to K Md Feroz Irfan

Genius 3120 points

Hi Feroz,

First of all sorry I accidentally clicked "Verify answer" button which I have undo.

Ultimately we would like to use this concept in Android but just to reduce complexity I have done above experiments in Linux.

Above description and observation is on Linux platform.

Regards,

Krunal

0 Kedar Chitnis over 13 years ago

TI__Genius 9101 points

Kunal,

I am not the OMX expert but I believe OMXInit cannot be called from 2 process's
OMX init create's some message Q's with specific names and/or other syslink resources for receving messages and if this is created again with the same name then syslink will give error. This is my understanding atleast

regards
Kedar

0 Krunal Patil over 13 years ago in reply to Kedar Chitnis

Genius 3120 points

Hi Kedar,

Thanks for sharing your views. I believe the same.

Do you see any other way, in case where one process call's OMXInit() and other process can allocate memory from sharedRegion?

I tried to do this but ended with error (error log attached my original post) which indicates the SharedRegion module is not initialized.

Regards,

Krunal

0 Kedar Chitnis over 13 years ago in reply to Krunal Patil

TI__Genius 9101 points

You will need to do this the hard way.

You will need to call Syslink_init() and then open the exact shared memory regions created in OMXInit()

Once the SR's are open then you can get heap handle for that SR and allocate memory.

You will need to use syslink APIs directly for this.
You can refer to syslink samples for the same of opening a already setup SR region.

regards
Kedar

0 Krunal Patil over 13 years ago in reply to Kedar Chitnis

Genius 3120 points

Ok. Thanks for the pointers. I will try this tomorrow and confirm the results.

Just to make myself clear, does that mean syslink_init() can be called from multiple processes? Because, OMX_Init() might also be calling this internally (not sure, can check the source and verify).

Regards,

Krunal

0 Chris Ring over 13 years ago in reply to Krunal Patil

TI__Genius 17205 points

Assuming you mean SysLink_setup(), yes, it can (and should) be called from different processes if they use the SysLink APIs.

Chris

0 Krunal Patil over 13 years ago in reply to Chris Ring

Genius 3120 points

Yes, My mistake its Syslink_setup(). http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/syslink/latest/docs/html/_sys_link_8h.html#a559f183c1e0d85c62e5e796abcfbca34

Thanks Chris for correcting me. I will try this tomorrow.

Regards,

Krunal

0 Krunal Patil over 13 years ago in reply to Krunal Patil

Genius 3120 points

Hi All,

Thanks for the help. I am able to allocate memory from two separate processes.

Regards,

Krunal

Processors

Processors forum

DM8168: Problem with shared memory allocation.