Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.

DM357 DVSDK FAQ

From Texas Instruments Wiki
Jump to: navigation, search

This page is intented to address Frequently Asked Questions about the DM357 DVSDK package.

Where is the Errata logged for DM357 DVSDK?

See DM357_DVSDK_Errata.

DVSDK demos do not run

Q: I have booted my DM357 and I am trying to run the DVSDK demos. When I start the demos (encode+decode, encode, decode) I see the following message on the serial console:

 <demo name> demo started.
 DavinciDisplay DavinciDisplay.1: Display Manager failed to allocate layer
 DavinciDisplay DavinciDisplay.1: Unable to configure video layer for id = 0
 Error: Failed to create display device
 Demo interface started at level <interface level>


A: This is the result of incorrect kernel video parameters being set in the bootargs variable of u-boot. The Getting Started Guide (GSG) that ships in hard copy with the board has the correct video parameters, but the GSG in the docs directory of the dvsdk has the wrong parameters. The video parameters in the bootargs should look like:

 video=davincifb:vid0=0,2025K:vid1=0,1350K:osd0=720x576x16,2025K

What mem value to use for bootargs

Q: I see that the GSG in the DVSDK docs directory says to use mem=116M but the default bootargs and the GSG that ships with my DM357 EVM says to use mem=232M. Which is the correct value?

A: The default configuration for the DM357 EVM is to use mem=232M. This gives as much memory to the Linux kernel as possible. You can reduce this value if you wish, but doing so will leave unused memory sitting idle on the system.

What does HMJCP stand for?

MPEG4/H.264/JPEG Co-Processor. Both encode and decode are included in this co-processor.

Where are the codec datasheets?

They can be found under

./packages/ti/sdo/codecs/<codecname>/docs

For example: -

./packages/ti/sdo/codecs/jpegdec/docs/JPEG_PS_Decoder_C64XPLUS_Datasheet.pdf

This is part of the standard convention for RTSC codec packages.

Why are some of the datasheets marked DM6446?

This is basically just a question of validation. The codecs were originally validated on the DM6446 platform. Instead of renaming and re-releasing all codec packages the decision was made to use the original well-tested, well-validated codec packages which were known to work with the compatible HMJCP co-processor. These codecs work (and were validated on) the DM357 platform.

Note that recent releases of codec packages have more generic naming to reduce confusion and automatically scale to compatible new platforms.

What is hmjcp.accel and do I need to rebuild it?

This is the MPEG4/H.264/JPEG Co-Processor binary. No you do not need to rebuild it. There are no build scripts available to do so since the HMJCP is a fixed-function accelerator.

Why do I get an 'execv' error when trying to run the demo software?

If you get an error like the following...

Processor_create: execv failed: No such file or directory

...the issue is likely that the wrong OSAL runtimeEnv has been set. As per Integrating_a_Codec_Engine, the DM357 should be configured as a GPP+Accelerator device, not a pure GPP device. So you should use osalGlobal.runtimeEnv = DSPLINK_LINUX and Engine.createFromServer() as per Configuring_Codec_Engine_in_Arm_apps_with_createFromServer.

If you are setting osalGlobal.runtimeEnv = LINUX (correct for single processor DM365 or DM355 but not DM357) and the Engine is configured with a server, the OSAL implementation may incorrectly try to create a Linux process by running the hmjcp.accel in a new Linux process (as a Linux executable!).

Bottom line - we suggest you copy the cfg file from one of the DVSDK demos when applying this to your own application. For example the decode demo uses the following configuration: -

/* Load support for the Codec Engine OSAL */
var osalGlobal = xdc.useModule('ti.sdo.ce.osal.Global');
 
/* Configure CE to use it's DSP Link Linux version */
osalGlobal.runtimeEnv = osalGlobal.DSPLINK_LINUX;
 
/*
 *  ======== Engine Configuration ========
 */
var Engine = xdc.useModule('ti.sdo.ce.Engine');
var demoEngine = Engine.createFromServer(
    "decode",
    "./hmjcp.accel",
    "ti.sdo.dm357.hmjcp"
    );
 
/* Add the speech decoder */
var g711dec = xdc.useModule('ti.sdo.codecs.g711.ce.G711DEC');
demoEngine.algs[ demoEngine.algs.length++ ] =
    { name: "g711dec", mod: g711dec, local: true };
 
/* Load support for the 'Davinci Multimedia Application Interface' modules */
var DMAI = xdc.loadPackage('ti.sdo.dmai');
 
/* Load support for SimpleWidget */
var SW = xdc.loadPackage('ti.sdo.simplewidget');

Can I run the DM357 software on a DM6446?

You cannot use the hmjcp.accel binary on the DM6446 platform however any GPP-application-code written for either platform can be reused providing the same XDM interfaces are used (IVIDDEC, IVIDENC, IIMGDEC, IMGENC in this case).

Can I run gstreamer on DM357?

Yes. See http://gstreamer.ti.com

My custom DM357 board has only 64Mb DDR2. Can I still run the demos?

Yes. However you may need to cut a few Mb from the kernel to e.g. mem=40M, CMEM with 8Mb, and the co-processor as 16Mb. A design decision was made during the co-processor development to allow plenty of space to ensure multi-channel video use-cases worked or large JPEG images could be handled. In addition since the Linux kernel requires its start address to be a multiple of 16MB this imposes some limitations on incremental reductions.

There is a wealth of material available to guide customers thru the kernel trimming and memory map adjustment process. For example: -

Note that Montavista DevRocket has tooling to make this process quite straightforward.

Obviously there are tradeoffs in using less DDR2 i.e. lower cost .v. reduced functionality e.g. browsers on the GPP perform better with more DDR2 (cached pages etc)