Introduction

The goal of this tutorial is to provide the steps needed to rebuild the firmware for the M3 coprocessors present in the Texas Instruments DM81xx platforms using the RidgeRun SDK. Also some instructions are given to use the remote_debug_client.out utility to dump in the ARM side those messages coming from the M3 handling the VPSS unit as well as some references to use UIA logger.

What is needed

RidgeRun Professional SDK for DM816x
EZSDK
EZSDK Overlay package - TI NDA required
remote_debug_client.out
loggerSMDump.out
MJPEG codec

Rebuilding the firmware

You will want to rebuild the firmwae if you need to debug an issue that you suspect is present on the binary blob that is loaded into the coprocessors or you want to improve the TI code adding new drivers like the writeback driver or adding support for a new codec to run in the HDVICP2 unit. In these cases you rebuild the firmware to produce a new .xem3 (M3) or .xe674 (DSP) file. RidgeRun's SDK already contains the logic to handle this scenario but it depends on the installation of the EZSDK overlay which you need to get from TI under NDA. It is called ezsdk_dm816x-evm_5_05_02_00_overlay_setuplinux.

Steps

1. Install EZSDK in your home directory

2. (Optional) If your system uses audio, install the audio codecs on top of the EZSDK

3. Install the EZSDK overlay on top of the EZSDK that you just installed in your home directory, i.e, select the destination directory to be: /home/$USER/ti-ezsdk_dm816x-evm_5_05_02_00

./ezsdk_dm816x-evm_5_05_02_00_overlay_setuplinux

4. Copy the MJPEC codec in the EZSDK in your home directory.

EZSDK_PATH=/home/<user>/ti-ezsdk_dm816x-evm_5_05_02_00/component-sources
tar -xzf ivahd_jpegvenc_01_00_04_00_production.tar.gz
cp -r ivahd_jpegvenc_01_00_04_00_production $EZSDK_PATH

Remember to change the EZSDK_PATH for the correct one.

5. If you have compiled the SDK previously in your computer likely it created a tarball with the information required from the EZSDK and saved that tarball in some path like /opt/ridgerun/downloads, you need to remove that tarball so the next time the SDK will create a new one that contain the EZSDK overlay extra files.

rm -rf /opt/ridgerun/downloads/ti-ezsdk_dm816x-evm_5_05_02_00-trimmed.tar.gz*

6. Now go to your fresh cloned DEVDIR and open the make config menu

cd $DEVDIR
`make env`
make config

select the support to rebuild the firmware

-> Proprietary software 
 -> [*] Build HDVICP2/VPSS drivers and codec

7. (Optional) If you want to rebuild the DSP code including the audio codecs please select:

[*] Support external AAC and MP3 audio codecs

and uncheck

[ ] Support prebuilt DSP Firmware with AAC compression enabled

8. Finally close your configuration file and save your changes.

9. Now your SDK is configured to rebuild the M3 firmware. This adds around 30 min to the SDK build time.

cd $DEVDIR
make

10. While the SDK is building it will install the new firmware in $DEVIDR/fs/fs/lib/firmware and it is take from:

$DEVDIR/proprietary/ezsdk-5_05_02_00/ezsdk/component-sources/omx-ti81xx-src_05_02_00_48/bin/dm816xbm/bin/ti816x-evm/

and the coprocessors script is updated as well. Now you are ready to start using the new firmware.

Important note: Since the EZSDK overlay installs another package for OMX that contains also the code that is running in the M3, it will install that OMX library as well in your filesystem. For that reason we use one DEVDIR to build the firmware and another DEVDIR to test that firmware, one that didn't have the build M3 code enabled.

Debugging software layers for M3/ARM interaction

If you want to debug the layers involved in the M3 interaction you should pay attention to:

a) V4L2: if you are capturing using V4L2 and not OMX

b) Gstreamer

c) Syslink

d) VPSS kernel module

e) M3 VPSS code

f) M3 HDVICP code

V4L2

V4L2 driver makes uses of the VPSS kernel module to finally send messages using syslink to the M3 core that runs the VPSS driver, on the M3 side there is a daemon called server proxy that executes the instructions send from the V4L2 kernel driver.

If you want to enable some of the debug messages you need to go to the kernel source code and change the debug level:

static int debug = 0;

to some value like 2. then you need to rebuild and install your kernel again

cd $DEVDIR
make kernel
cd $DEVDIR/proprietary/ezsdk-5_05_02_00
make install
cd $DEVDIR
make install

you should see now more messages using dmesg on the console.

Gstreamer

You can launch your application enabling the gstreamer debug and playing with the debug level according your needs. You can also redirect the output of the debug to a file or to a console choosing which element should be considered for debug messages.

GST_DEBUG=*omx*:5 GST_DEBUG_FILE=/dev/console myApplication &

in case of a pipeline:

GST_DEBUG=*omx*:5 GST_DEBUG_FILE=/dev/console gst-launch-0.10 filesrc... &

Syslink

In order to enable the syslink debug you need to specify which level of debug you want while inserting the syslink kernel module. This is done on the coprocessors script which is installed by the EZSDK, you have two options:

a) Go to $DEVIDR/fs/fs/etc/init.d and edit the file named coprocessors (assuming that you are using NFS) and modify the script to mount syslink with debug enabled:

	if [ -f /lib/modules/2.6.37-ridgerun/kernel/drivers/dsp/syslink.ko ] ; then
	    rmmod syslink 2>/dev/null || true
	    modprobe syslink TRACE=1 TRACEFAILURE=1 TRACECLASS=2
	fi

you can play with the different levels and get more information about them on the Syslink Trace Types wiki. The problem with this approach is that if you run make install in your devdir it would lose your changes.

b) Do the change directly on the original coprocessors script located in $DEVDIR/proprietary/ezsdk-5_05_02_00/coprocessors.init.in, then run

cd $DEVDIR/proprietary/ezsdk-5_05_02_00
rm coprocessors.init
make
make install

to install the script with the modification

VPSS kernel module

Very similar to syslink, you need to debug the messages to make them appear using dmesg:

	if [ -f /lib/modules/2.6.37-ridgerun/kernel/drivers/video/ti81xx/vpss/vpss.ko ] ; then
	    rmmod vpss 2>/dev/null || true
	    modprobe vpss sbufaddr=0xBFB00000 i2c_mode=0 debug=1
	fi

M3 VPSS code

Add debug messages

If you need to debug the VPSS code in the ezsdk, you have to add some debug messages to the code. To add these messages, you have to use Vps_printf. For example:

Vps_printf ("Debug message %s", __FUNCTION__);

This will write the messages to a specific section of memory. You can use the remote debug client application to read this section of memory.

Remote debug client application

You can see the debug message in runtime using the remote debug client application:

/remote_debug_client.out 0xbfef0000 &

This application will read this section of memory where the Vps_prinf is writing the messages. This is an example of the output that you will see:

/remote_debug_client.out 0xbfef0000 &
~ #  [c6xdsp ] Remote Debug Shared Memory @ 0xbfef0000
 [m3video] Remote Debug Shared Memory @ 0xbfef5020
 [m3vpss ] Remote Debug Shared Memory @ 0xbfefa040
 [m3vpss ] EGR DEBUG Vps_captMakeList
 [m3vpss ] EGR DEBUG psScalarDequeue
 [m3vpss ] EGR DEBUG psScalarDequeue
 [m3vpss ] EGR DEBUG psScalarDequeue
 [m3vpss ] EGR DEBUG psScalarDequeue
 [m3vpss ] EGR DEBUG psScalarDequeue
 [m3vpss ] EGR DEBUG psScalarDequeue
 [m3vpss ] EGR DEBUG psScalarDequeue
 [m3vpss ] EGR DEBUG psScalarDequeue
 [m3vpss ] EGR DEBUG psScalarDequeue
 [m3vpss ] EGR DEBUG psScalarDequeue
 [m3vpss ] EGR DEBUG psScalarDequeue
 [m3vpss ] EGR DEBUG psScalarDequeue
 [m3vpss ] EGR DEBUG psScalarDequeue
 [m3vpss ] EGR DEBUG psScalarDequeue
 [m3vpss ] EGR DEBUG psScalarDequeue
 [m3vpss ] EGR DEBUG vcoreVipAllocPath
 [m3vpss ] EGR DEBUG vcoreVipAllocPath scEnable=0

M3 HDVICP2 code - OMX

The use of the VPSS traces on the HDVICP2 M3 core has not been verified, in order to get traces from the HDVCIP2 (encoders/decoders) it is possible to use the loggerSMDump.out utility.

to see logs from both Media Controllers (VIDEO & VPSS)

target #./loggerSMDump.out 0x9E400000 0x100000 all

To see logs from both VIDEO Media Controller

target #./loggerSMDump.out 0x9E400000 0x100000 video

To see logs from both VPSS Media Controller

target #./loggerSMDump.out 0x9E400000 0x100000 vpss

You can read more about it from OMX Viewing Media Controller Traces