DVSDK 4.x FAQ

From Texas Instruments Wiki
Jump to: navigation, search

The DVSDK (Digital Video Software Development Kit) software package provides the ability to develop with a known set of TI software components on known hardware platforms. Due to the vast array of hardware platforms available today the DVSDK cannot be tested across all platforms and it is necessary to select a small number of platforms that can be carefully validated to hit the majority of customers needs. The latest DVSDK 4.01 has support for :

Many people however, use a combination of EVMs and 'other' hardware to meet their development needs for form-factor, connectivity, cost, etc. Whilst not 'officially' supported to run on community boards, like 'BeagleBoard', there is much demand to be able to easily migrate the base DVSDK software development environment between the official supported EVM and community board.

This FAQ provides some information starting from installing DVSDK on 'unofficial' host distribution to a scripts to 'convert' standard DVSDK environment to your favorite community boards.


How to install DVSDK 4.01 on unsupported host

Officially DVSDK 4.01 supports Ubuntu 10.04 LTS 32-bit host only. And to install DVSDK on unsupported host use '--forcehost' option as shown below

./dvsdk_<platform>-evm_4_01_00_09_setuplinux --forcehost

How to build and install DVSDK 4.01 on BeagleBoard-xM

This section provides some information on how to run the DVSDK on beagleboard-xM (http://beagleboard.org) and uses some 'unofficial' scripts to 'convert' the standard DVSDK environment. It is designed to be a 'guide' to the software changes that need to be made and not intended as production software. The goal of the 'script' here is to provide the minimum number of changes to facilitate a quick port to beagleboard-xM that is as close as possible to the EVM version. For a more 'correct' solution and for incorporating a wider set of software components, it is recommended to review building DVSDK specifically from Arago project sources (http://arago-project.org/git/), or utilising other upstream distributions, such as Angstrom (http://www.angstrom-distribution.org/) and it's online 'narcissus' builder for binary versions (http://narcissus.angstrom-distribution.org/). These other methods may or may-not require further modification depending on the current up-stream status of the components.

The steps below are however, known to be compatible with the standard DVSDK release noted above, using the standard components included in the release.

1. Download and install DM3730 DVSDK 4.01 on suitable host machine.

2. Download the script from here.

3. Edit the script to match your network configuration

  • NOTE1 :: this script will access external internet locations to fetch files and it may be necessary to modify the 'PROXY' variables inside this script for your environment.
  • NOTE2 :: if using a proxy server, this script will also require 'corkscrew' to be installed for proxy handling. The git proxy configuration files will be set up by the script as necessary.

4. Run the dvsdk beagle-xm setup script

host $ cd ${HOME}/ti-dvsdk_dm3730-evm_4_01_00_09 
host $ ./setup-dvsdk-4-01-beaglexm-110126.sh
  • NOTE1 :: this script requires 'git' tools to be installed on your host machine.
  • NOTE2 :: whitespace warnings while applying git patches can be safely ignored

5. Rebuild DVSDK components as shown below

host $ make clean
host $ make all

6. Plug an SD card on Linux host machine.

7. Run dmesg command to check the device node. Triple check this to ensure you do not damage your HDD contents!

host $ dmesg
  [14365.272631] sd 6:0:0:1: [sdc] 3862528 512-byte logical blocks: (1.97 GB/1.84 GiB)
  [14365.310602] sd 6:0:0:1: [sdc] Assuming drive cache: write through
  [14365.325542] sd 6:0:0:1: [sdc] Assuming drive cache: write through
  [14365.325571]  sdc: sdc1 sdc2

8. Run mksdboot script installed in DVSDK as shown below using the correct device detected for the SD card above.

host $ sudo ./bin/mksdboot.sh --device /dev/sdc --sdk `pwd`

9. Unplug SD from host PC.

10. Power ON BeagleBoard-xM and you should see the Matrix GUI. At this point you can play various DSP and ARM demos.


What the script is doing ...

Most DVSDK software for dm37xx-evm is dependent only on the DM37xx processor, and not on the actual board, so the majority of changes provided in the script are to patch in the required hardware specific pieces. These changes are taken from Open Embedded (http://cgit.openembedded.org) repository, as used for Angstrom Distribution (http://www.angstrom-distribution.org/) which has very complete support for beagleboard-xM. The base linux kernel is the same as the one used for the dm37xx-evm, enabling us to re-use existing driver application software from the DMAI (Davinci Multimedia Application Interface) and graphics modules without modification. The pieces that are specific are as follows :-

* x-loader
* u-boot
* linux kernel
  * including enabling V4L2 display buffers (required by dvsdk demos)
* alsa sound configuration
  * alsa.state
* serial port configuration
  * ttyS2 instead of ttyS0, kernel command line and inittab
* ethernet config
  * eth0 to usb0 in /etc/network/interfaces
* hostname
  * modified to highlight difference from evm

There are also some 'tweaks' which make things look a bit better and the installer a bit easier.

* switch 3D graphics to use double buffering to avoid tearing
  * 'FLIP' mode in powervr.ini 
* switch to hd720 to support larger number of HD TV dispays
  * kernel command line omapfb.mode=
* leverage larger memory (512M) available on beagleboard-xM
  * kernel command line mem=
* makefile
  * add some parallelism for component build
  * re-order install (to fixup module install order)
  * install graphics directly into etc/ and /lib/modules
  * include 'depmod' install target to rerun depmod when new content is installed

Known Limitations

[ Note : The following are being worked on for future DVSDK updates ]

  • Blitrix 2D demos not working, due to hardcoded rotation in demonstration application
  • Encode path not tested

Things to note

For a more complete 'port', the DMAI interface layer should be modified for correct selection of DVI modes. Instead, in this example, the DVSDK-Demo applications are configured to use the '-O system' (when using DVI display output boot configuration) to tell the DMAI module to use system defined options for display - users should take note of this option when running the demos manually without the Matrix Launcher.

Package 'Feeds' will not be correct for machine specific components, since the filesystem is still configured to be a dm37xx-evm and this patched build does not have corresponding machine/feeds.

Build and Install GStreamer RTSP

One request we get often is how to install additional GStreamer plugin in DVSDK root file system. This section of FAQ provides command to install GStreamer RTSP server in root file system and similar procedure can be used to install other plugins.

  • Build and install gst-rtsp server in root file system
 host # tar jxf gst-rtsp-0.10.7.tar.bz2
 host # cd gst-rtsp-0.10.7
 Setup cross compilation environment (for more information refer Software Developer Guide section Setting_up_cross_compilation_environment)
 host # source <dvsdk_installation_dir>/linux-devkit/environment-setup
 Configure and run make
 host # ./configure --host=arm-none-linux-gnueabi --prefix=<target_filesystem_root>/usr
 host # make 
 host # make install

For more information about gst-rtsp usage refer package README file.

How do I uninstall DVSDK 4.x

Unfortunately, DVSDK 4.x installer does not add anything in your System menu to do a clean uninstall. You can uninstall (or remove) the complete DVSDK by executing the below command on your host:

host # rm –rf ${DVSDK}

Caution: Above command will delete ${DVSDK} directory. Take appropriate backup before executing command.

How do I link DSPLINK libs in Qt/e Application

If you want to execute dsplink API from Qte GPP application then add the below line in Qte pro file.

LIBS += $(LINK_INSTALL_DIR)/dsplink/gpp/export/BIN/Linux/OMAPL138/RELEASE/dsplink.lib
QMAKE_CXXFLAGS += $(shell cat $(LINK_INSTALL_DIR)/dsplink/gpp/export/BIN/Linux/OMAPL138/DEBUG/API_defines.txt) \
  $(shell cat $(LINK_INSTALL_DIR)/dsplink/gpp/export/BIN/Linux/OMAPL138/DEBUG/API_includes.txt)

The above line will add dsplink's includes path, cflags in qmake's auto generated Makefile.

Refer Software Developers Guide for more information on cross compiling Qt/e application in DVSDK environment.

Note: You should export LINK_INSTALL_DIR to point to your dsplink root directory before executing qmake as documented in Software Developers Guide.

Why 3D Graphics demos do not Run in my AM37x/DM37x setup?

Same as below issue

Why do i get error like "Unable to initialise EGL" while running 3D demos in AM37x/DM37x?

Same as below issue

Why do i see "No SGX hardware" when Linux boots-up in AM37x/DM37x?

Same as below issue.

Why boot trace shows OMAP3630, while my EVM is actually AM37x/DM37x?

All of these issues observed in recently shipped EVMs, This issue occurs due to non handling of the updated eFuse setting for device identification.

Workaround identified for this issue. This issue would be fixed in the up comming DVSDK release.

More detailed information on this issue and workaround patch is available in forum post [1].

What is the need of frame copy using Framecopy_execute even if the recorded size is same as capture size?

This applies only to the video encode DVSDK demo prior to DVSDK version 4.02, with the version 4.02 and greater this copy is avoided.

In few platforms line length for capture/display buffers needs to be multiple of 32. So the line length is 736 for D1 resolution (width 720). One can play with codec parameters to accept line length different from image width and able to feed the captured buffer as it is. But these settings are different for different codecs.

Also, on the display path, if you want to display smaller resolution frames on a higher resolution display (for eg. D1 in 720P), there is a need to do a copy.

So in the interest of keeping the code generic for various codecs and resolutions, a copy is performed on both the encode path and the display path at all times for D1 resolution.

It is possible to have a no-frame copy version, but it to keep the code simpler the copy is being done, and at D1 resolution the frame copy was judged to be a low overhead (when accel attribute of Framecopy_attrs is set).

Why do i get error like "tps6507x 1-0048: TSC mode read failed" while running audio_soc_example?

There is a resource conflict (I2C) between touch screen driver & Audio driver in DSP. So ensure that while running audio_soc_example touch screen driver is not being used.

There is a solution provided in below forum post to solve I2C resource conflict between touch screen driver & Audio driver at DSP.

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/109856.aspx

Why do audio_soc_example application on OMAPL138 hung?

This is due to resource conflicts (I2C, McAsp, AIC), between audio driver that would be running in DSP when audio_soc_example run and Advanced Linux Sound Architecture (ALSA) driver in kernel side. So kernel must disable ALSA the driver to avoid conflicts.

Also there is a resource conflict as mentioned in above FAQ "Why do i get error like "tps6507x 1-0048: TSC mode read failed" while running audio_soc_example?", Ensure to follow this.

Refer Software Developers Guide at section "Running the Audio SOC example" for more details on how to rebuild kernel with ALSA disabled and run audio_soc_example.

What is the memory partition in various modules in DVSDK?

MEMORY MAP in DVSDK for DM3730
Category Memory Segment Name Length Start Address Usage
Linux Memory LINUX_MEM_1 55 MB 0x80000000 First memory segment given to Linux Memory Manager in Kernel
Unused Unused 25MB 0x83700000
CMEM CMEM 16 MB 0x85000000 Physically Contiguous memory allocator module
DSP Algorithms DDRALGHEAP 24 MB 0x86000000 Algorithms running in DSP
DSP text/data DDR2 6MB 0x87800000 DSP code, const, bss
DSPLINK (MEM) DSPLINK (MEM) 1 MB 0x87E00000
DSPLINK (RESET) DSPLINK (RESET) 4KB 0x87F00000
unused unused 1020 KB 0x87F01000
Linux Memory LINUX_MEM_2 128MB 0x88000000 2nd memory segment given to Linux Memory Manager in Kernel

Each application in DVSDK differs little on there memory map, below is specifically for Multimedia demos

MEMORY MAP in DVSDK for OMAPL138
Category Memory Segment Name Length Start Address Usage
Linux Memory LINUX_MEM_1 32 MB 0xC0000000 First memory segment given to Linux Memory Manager in Kernel
CMEM CMEM 18 MB 0xC2000000 Physically Contiguous memory allocator module
DSP text/data DDR2 3MB 0xc3200000 DSP code, const, bss
DSPLINK (RESET) DSPLINK (RESET) 0x1000 Bytes 0xc3500000
DSPLINK (MEM) DSPLINK (MEM) 0xff000 Bytes 0xc3501000
DSP Algorithms DDRALGHEAP 10 MB 0xC3600000 Algorithms running in DSP
Linux Memory LINUX_MEM_2 64MB 0xC4000000 2nd memory segment given to Linux Memory Manager in Kernel

How to change memory partition?

http://processors.wiki.ti.com/index.php/DVSDK_4.x_MemoryMap

How do i change by ARM frequency for DM3730?

Follow below steps to change ARM frequency.

  • Move to DVSDK installed location
cd ti-dvsdk_dm3730-evm_04_03_00_06
  • Modify u-boot to run ARM at required freq, this steps applicable for release 04.03.00.06 and later, different procedure needs to be followed for earlier releases.
In file psp/u-boot-2010.06-psp04.02.00.0/sdk/board/ti/evm/evm.c in function misc_init_r change the below below line
set_mpu_clk(300); <-- This runs ARM at 600MHz, set 400 for 800 MHz, & 500 for 1GHz, Ensure that your device is capable for running at required frequency, refer TRM section "1.5.2 Device Identification" to know if your device supports the required freq.
  • Rebuild u-boot
make u-boot_clean
make u-boot
  • Transfer the rebuilt u-boot to SDcard, this can be done only with sudo permission (Note: SD card is already prepared with DVSDK 4.03.00.06 in it),
sudo mount /dev/sdc1 your-sdcard-mount-dir <-- Mount the SD boot partition, follow Userguide to know SD card device node
sudo cp psp/u-boot-2010.06-psp04.02.00.07.sdk/u-boot.bin your-sdcard-mount-dir <-- This overwrites the existing u-boot
sudo umount your-sdcard-mount-dir
  • Boot your EVM with the SDcard (having new u-boot) as usual.
  • Observe that ARM is running at 600MHz, your boot trace should be as follows
=============================================================================
[ 0.000000] per task-struct memory footprint: 2304 bytes
[ 0.000000] Calibrating delay loop... 597.64 BogoMIPS (lpj=2334720)
[ 0.000000] pid_max: default: 32768 minimum: 301
=============================================================================

How to enable trace in DMAI?

Before running any DMAI based application, set the debug level as below

   # export DMAI_DEBUG=1
  • DMAI_DEBUG=0 disables DMAI trace, even if it is set by Dmai_setLogLevel in the application itself.
  • DMAI_DEBUG=1: errors and warnings
  • DMAI_DEBUG=2: all messages

Refer section "Debugging a DMAI application" in document <your-dvsdk-install-directory>/<dmai-directory>/docs/html/user__guide.html

Other troubleshoots?

Media:DVSDK_bootTraces.zip

This zip file has boot traces of DVSDK at various settings, Below are the files present in this archive. Name reflects the setting used.
  • BootTrace_DM365_DVSDK_4_02_00_06_SDcard.txt
  • BootTrace_DM365_DVSDK_4_02_00_06_SDcard_SubsequentBoot.txt
  • BootTrace_DM3730_DVSDK_4_02_00_06_SDcard_1GHzPart.txt
Note: there is a bug with this release in handling device id for 1Ghz parts, this is rectified in subsequent releases.
  • BootTrace_DM3730_DVSDK_4_02_00_06_SDcard_1GHzPart_SubsequentBoot.txt
  • BootTrace_DM3730_DVSDK_4_03_00_06_SDcard_1GHzPart.txt
  • BootTrace_DM3730_DVSDK_4_03_00_06_SDcard_1GHzPart_SubsequentBoot.txt

Other resources

  1. Changing_DSPLink_Memory_Map [2]
  2. TraceUtil [3]
  3. Changing_the_DVEVM_memory_map [4]