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.


From Texas Instruments Wiki
Jump to: navigation, search

Important Note:

The software discussed on this site is available for download, but is no longer being actively developed. This wiki is in maintenance mode and the software is supported on Multi-media Codec E2E forum

This document serves as an addendum to the TopTenCodecPackageCheckList, specifically geared towards ARM-side codecs. Don't forget to follow those rules as well! Following these guidelines will greatly improve codec integrateability!

XDAIS Compliance

QualiTI_XDAIS_Compliance_Tool supports C6x codecs and ARM codecs. For ARM support, you will need XDAIS 6.23 or later which comes with Framework Components 2.23 and Codec Engine 2.23. There are more details on the QualiTI tool here.

Sample QualiTI XDAIS-complaince check screenshot

Currently, QualiTI checks the following rules:

  • Rules 8, 9, 10: Namespace compliance
  • Rule 12: IALG interface implementation
  • Rule 13+: correct linker section names (Applies to 64P codedcs only)
  • Rule 15: library filename & filetype
  • Rule 20: must declare worst-case stack requirements
  • Rules 21, 22: must characterize static data & program memory requirements
  • Rule 25: All C6x algorithms must be supplied in little-endian format
  • Rule 26: All static/global data must be far on c6x (Applies to 64P codedcs only)

If you would still like to check for XDAIS compliance using command line tools, we'll need to do a bit of work as described in the following sections.

Namespace Compliance

If you have two codecs in your system with the same global variable name, you'll get an unexpected (and nasty!) surprise. XDAIS imposes a naming convention on global variables to insure a unique name, so let's check an actual library (Note: if you want to actually try it as shown below, use the DM355 MPEG4 Decoder library in DVSDK

Run nm on your library via:

host$ /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-nm -g libmp4dec.a

Ideally, you will see output like:

00000188 T MP4VDEC_TI_DM350_BitstreamShowBitsByteAlign
000001e0 T MP4VDEC_TI_DM350_BitstreamShowBitsByteAlignTT
         U MP4VDEC_TI_DM350_CheckBitStuffing
         U MP4VDEC_TI_DM350_flush_bits

If you have global variables that do not follow MODULE_VENDOR_* then you'll need to change these to local variables.

One way to do this is to use objcopy --localize-symbol which converts globals to locals after link:

host$ /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-objcopy <library_name> -w --localize-symbol \!MODULE_VENDOR*

This step should be done after the partial link and before the final link. The final link should always be done with the symbols you don't want to hide. If done before the partial link, you risk hiding symbols needed for linking which may result in an "unresolved reference" error.

IALG Names

On a similar topic, make sure your IALG function table pointers are correctly named. After running nm as outlined above, you must see at least MODULE_VENDOR_IALG and MODULE_VENDOR_IMOD.

For example, we can check the MPEG4 Decoder library and find the correct IALG names:

host$ /opt/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-nm -g libmp4dec.a | grep IALG
         U MP4VDEC_TI_IALG
         U MP4VDEC_TI_IALG
00000000 D MP4VDEC_TI_IALG

host$ /opt/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-nm -g libmp4dec.a | grep IMP4VDEC

Section Info

You can always check your library's section names with:

host$ /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-objdump -h libmp4dec.a

This is less important for ARM-only codecs than for 64x+ codecs since: (1) most code is automatically text and (2) poorly named sections get placed like normal text sections.

Other Details

Since copying and pasting tends to be quite easy, we frequently see DM6446 stuff in DM355 systems - watch out for these:

runtimeEnv configuration

When configuring your app for a single processor environment (e.g., DM355 - or even a configuration without any remote algs!), don't refer to DSP Link in your app's cfg file:

var osalGlobal = xdc.useModule('ti.sdo.ce.osal.Global');
osalGlobal.runtimeEnv = osalGlobal.DSPLINK_LINUX;

Instead, do:

var osalGlobal = xdc.useModule('ti.sdo.ce.osal.Global');
osalGlobal.runtimeEnv = osalGlobal.LINUX;

This will remove any inadvertent dependencies on DSP Link.

Similarly, any TraceUtils-related configuration (or API calls in your app sources) is unnecessary. While you may not get any configuration warnings/errors, TraceUtils is only useful on ARM+DSP devices.

Similarly, make sure the doesn't reference dsplinkk.ko and properly inserts the target's correct modules (for DM355, you'll want dm350mmap.ko). Don't forget to list your CMEM pool requirements in your docs, too.