DVSDK 4.01 on IGEPv2 RC4

It would help if you could run with CE_DEBUG=3 before the command like this and share the output:

Ofcourse I am assuming it is only a environment problem and your builds are all fine.

root@dm37x-evm:/usr/share/ti/dvsdk-demos# CE_DEBUG=3 ./decode -o -v /usr/share/ti/data/videos/davincieffect.264 -a /usr/share/ti/data/sounds/davincieffect_lc.aac
-O system

Thanks for the quick answer, I ran the the command as instructed:

CE_DEBUG=3 ./decode -o -v /usr/share/ti/data/videos/davincieffect.264 -a /usr/share/ti/data/sounds/davincieffect_lc.aac -O system.txt > output 2> errors.txt

As you can see I redirected stdout to output.txt and stderr to errors.txt, I'm attaching both files in a .tar.gz to this post.

The error message seems to indicate a memory allocation issue. (DSP_EBASE + 0xc) from dsplink. I am not 100% sure what that means but if you could post your boot args and loadmodules.sh it might help someone else pin-point the issue.

 I would generally associate something like this to one of two possible culprits

1. The run time memory map does not match the build time memory map.  [What the log printed (see below) does not match where you actually loaded cmem]

2. You forgot to rebuild the decode server? [If you rebuild dsplink, cmem etc, you must rebuild the server]

Perhaps someone who understands what memory allocation has failed in dsplink may be able to pinpoint better

This is what your app is "seeing" at run time: Does the cmem location make sense? How did you load cmem?

@5,924,041us: [+2 T:0x40c80490 S:0x40c7fd64] OP - Processor_create_d> Adding DSP segment #0 to Link configuration: name='DDR2', startAddress=0x87a00000, sizeInBytes=0x600000, shared=1, syncd=0
@5,924,072us: [+2 T:0x40c80490 S:0x40c7fd64] OP - Processor_create_d> Adding DSP segment #1 to Link configuration: name='DSPLINKMEM', startAddress=0x85901000, sizeInBytes=0xff000, shared=1, syncd=0
@5,924,102us: [+2 T:0x40c80490 S:0x40c7fd64] OP - Processor_create_d> Adding DSP segment #2 to Link configuration: name='RESET_VECTOR', startAddress=0x85900000, sizeInBytes=0x1000, shared=1, syncd=0
@5,924,133us: [+2 T:0x40c80490 S:0x40c7fd64] OP - Processor_create_d> Adding DSP segment #3 to Link configuration: name='L4PER', startAddress=0x49000000, sizeInBytes=0x100000, shared=0, syncd=0
@5,924,163us: [+2 T:0x40c80490 S:0x40c7fd64] OP - Processor_create_d> Adding DSP segment #4 to Link configuration: name='IRAM', startAddress=0x5c7f8000, sizeInBytes=0x8000, shared=1, syncd=0
@5,924,194us: [+2 T:0x40c80490 S:0x40c7fd64] OP - Processor_create_d> Adding DSP segment #5 to Link configuration: name='L1DSRAM', startAddress=0x5cf04000, sizeInBytes=0x10000, shared=1, syncd=0
@5,924,224us: [+2 T:0x40c80490 S:0x40c7fd64] OP - Processor_create_d> Adding DSP segment #6 to Link configuration: name='L1PSRAM', startAddress=0x5ce00000, sizeInBytes=0x4000, shared=1, syncd=0
@5,924,255us: [+2 T:0x40c80490 S:0x40c7fd64] OP - Processor_create_d> Adding DSP segment #7 to Link configuration: name='DDRALGHEAP', startAddress=0x85a00000, sizeInBytes=0x2000000, shared=0, syncd=0
@5,924,285us: [+2 T:0x40c80490 S:0x40c7fd64] OP - Processor_create_d> Adding DSP segment #8 to Link configuration: name='L4CORE', startAddress=0x48000000, sizeInBytes=0x1000000, shared=0, syncd=0
@5,924,407us: [+2 T:0x40c80490 S:0x40c7fd64] OP - Processor_create_d> Found 'CMEM' entry, adjusting base and size according to CMEM_getBlock()
@5,924,438us: [+0 T:0x40c80490 S:0x40c7fd64] OP - Processor_create_d> Setting CMEM base to 0x9ae00000, size to 0x2000000
@5,924,468us: [+2 T:0x40c80490 S:0x40c7fd64] OP - Processor_create_d> Adding DSP segment #9 to Link configuration: name='CMEM', startAddress=0x9ae00000, sizeInBytes=0x2000000, shared=0, syncd=0

Carefully grepping the output.txt above I have seen this message:

@6,097,869us: [+7 T:0x40c80490 S:0x40c7fd64] OP - Processor_create_d> Loading and starting DSP server 'cs.x64P' FAILED, status=[0x8000800c] (look for error code 'DSP_EBASE + 0xc' in dsplink*/packages/dsplink/gpp/inc/usr/errbase.h)

Accessing the errbase.h file (I have attatched it for others convenience) I founf the following definition for the error.

/* A memory allocation failure occurred. */
#define DSP_EMEMORY                 (DSP_EBASE + 0xCl).

So it must have something to do with the memory range saved by cmemk.ko (which is properly loaded into my kernel).

Since my board is not the Texas EVM but aIGEPv2 RC4 I used custom insmod parameters for insmod instead of the default ones provided by TI, here's my insmod line:

insmod  /home/root/dm3730/lib/modules/2.6.35.11/kernel/drivers/dsp/cmemk.ko phys_start=0x9AE00000 phys_end=0x9CE00000 pools=20x4096,4x131072,2x5250000,6x184
3200,2x691200

So maybe I just need to tweak some configuration file so that the system is aware of this change and looks for said memory range where it actually is and not where TI placed it on the EVM. Or maybe the system can get the location through cmemk device...I would really appreciate some input here.

Thanks

Since it seems it's an issue with my memory map. I have read http://processors.wiki.ti.com/index.php/Changing_the_DVEVM_memory_map

but most of the info there is outdated and most of the files mentioned there, ought to configure a memory map are no longer in place on newer versions of the software. Can someone guide me through the configuration and rebuilding process to use a custom memory map?

Thanks

hello,

are you sure you are using DVSDK 4.01 root filesystem ? the reason for asking this is i noticed you are using cmem pool whereas DVSDK 4.01 rootfilesystem uses cmem heap feature. And this also brings another question: are you using the bootargs as provided by DVSDK 4.01 ? Note that for newer 720P codec you need to use the different mem=xxx option. I would recommend running DVSDK 4.01 setup script to generate right bootargs and also using system wide loadmodule from DVSDK 4.01.

HTH,

Thanks

Brijesh

I was using DVSDK 4.01 root filesystem with a modified load-modules.sh (provided by my board manufacturer for an older version of the DVSDK), since it seems not to be working properly right now I am building the whole system again almost exactly as provided by Texas (instead of the kernel in the package I use 2.6.35.11 supported by the manufacturer of IGEP, since 2.6.32 provided by Texas does not even boot on my board) but for the rest I am building it as texas ships it. And I will use TI's load-module.sh and TI's minicom script (generated by setup.sh) to configure my uboot to be certain it uses the appropriate bootargs.

I will post shortly to share my findings.

Hi Jodi.

By rebuildind DVSDK with 2.6.35 kernel and modifying the load modules.sh and changing bootargs  with mem=55M.  i am able to load the CodecEngine , but . decode application fails with error  unable to open /dev/video2.

2.6.35 kernel from IGEVP doesn't create /dev/videox devices.  it will be created by V4l2 driver as mentioned in http://processors.wiki.ti.com/index.php/UserGuideDisplayDrivers_PSP_03.00.00.05.

omap-vout module is responsible for the same.

I have enabled V4L2 Driver as  mentioned in above link. But kernel crashes while booting..

Regards

Krishna

I used mem=80M, otherwise the system did not perform correctly and I would get random errors (I will run tests again tomorrow since it's the same hardware and if it works with 55 for you it should do so for me too.

Running decode with I get the following:

root@dm37x-evm:/proc# export CE_DEBUG=1
root@dm37x-evm:/proc# cd
root@dm37x-evm:~# cd dm3730/usr/bin/
root@dm37x-evm:~/dm3730/usr/bin# ./runDVSDK_decode
killall: matrix_guiE: no process killed
cat: write error: No space left on device
Decode demo started.
@0,543,701us: [+6 T:0x40025290] CE - Engine_init> CE debugging on (CE_DEBUG=1; allowed CE_DEBUG levels: 1=min, 2=good, 3=max)
Starting interface

[DSP] @0x000001db:[T:0x00000000] server - main> Welcome to DSP server's main().
@24,658,050us: [+6 T:0x41c5a490] CE - Engine_createNode> Remote node creation FAILED (0x80008008).
[DSP] @0,158,995tk: [+4 T:0x87c2d334] (null) - API: Test id  0 failed
[DSP] @0,159,055tk: [+7 T:0x87c2d334] ti.sdo.ce.alg.Algorithm - Algorithm_create> Algorithm creation FAILED; make sure that 1) alg params are correct/appropriate, 2) there is enough internal and external algorithm memory available -- check DSKT2 settings for heap assignments and scratch allocation
[DSP] @0,159,184tk: [+6 T:0x87c2d334] CV - VISA_create2> FAILED to create local codec.
@24,658,721us: [+6 T:0x41c5a490] CV - VISA_create2> FAILED to create remote codec (0x8).
@24,658,782us: [+7 T:0x41c5a490] ti.sdo.dmai - [Vdec2] Failed to open video decode algorithm
Error: Failed to create video decoder: h264dec
Starting Matrix GUI application.
root@dm37x-evm:~/dm3730/usr/bin#

any ideas?

Are you using a 3530 or a 3730?

The 3730 codecs will not work on 3530, hence the question.  There is a processor lock which will check for the dsp silicon. If you can you read the register at location 0x4830A204 on the DSP you can find out what silicon is present with you.    If you do a bit wise and of the value with 0x0ffff000 you should get 0x0B891000. [ Info obtained from Technical reference manual].

Hi Jordie.

instead of  using DVSDK 4.  i have used IGEP GST framework and thier SDK  VM to build DVSDK demos.

i am able to build  DVSDK demos, steps i have mentioned in  IGEVP forum.

today i am testing those demos.

under  linux-2.6.35-10- IGEVP kernel builds omap-vout as module. After booting i am able insert omap-vout module sucessfully.

with this /dev/video1 and /dev/video2 are getting created.

now i am getting problem while  running decode example.

let me consolidate the steps and update.

Krishna

What parameters did you use to load the module and the modules it depends on ?

'Cause I'm inserting it into my kernel (IGEP's 2.6.35) and still no /dev/videoX devices get created

Thanks