This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Problem Outputting Video to Component on Leopardboard DM365



I have a Leopardboard DM365 (based on TI's DM365), on which I try play a video to the Component output.
I use RidgeRun's SDK, which is based on TI's dvsdk3.10.00.19.
I took the decode demo from dvsdk, which run's fine on DM365EVM, stripped out the UI, IR and keyboard parts from the code and tried to run the demo on Leopardboard DM365.
It does not run. The control thread keeps running, but the other threads get stuck.
The display thread get stuck on dvsdk's Display_get() and I believe that this is the root of the problem.
I tried to dig into the kernel and found out that eventually it waits forever on videobuf_waiton() in the kernel (Linux kernel 2.6.32 path: linux-2.6.32/drivers/media/video/videobuf-core.c).


Here are the boot arguments (kernel cmd) I used:
setenv bootargs mem=40M davinci_enc_mngr.ch0_output=COMPONENT davinci_enc_mngr.ch0_mode=720P-60 davinci_display.cont2_bufsize=6291456 console=ttyS0,115200n8 root=/dev/nfs rw nfsroot=10.0.0.1:/home/asaf/leopard_dm365/sdk/leo365/fs/fs ip=10.0.0.2 video=davincifb:vid0=off:vid1=off:osd0=1280×720x16,14400K dm365_imp.oper_mode=0

The patch that I used to remove the EVM specific parts from the code and to add debug messages can be found in the following URL:
http://www.megaupload.com/?d=XNFHRCHS

The patch should be applied to the following directory: /dvsdk_3_10_00_19/dvsdk_demos_3_10_00_16/dm365

I used as test files the video files from TI - davincieffect.[mpeg4,264]

To run the decoder I had to modify a little bit the loadmodules.sh script. The modified script is appended to the end of this message.

I used the following command line to run the decoder:
./decode -v data/videos/davincieffect.264 -y3 -o -O component
I also tried
./decode -v data/videos/davincieffect.mpeg4 -y3 -o -O component
with and without the parameters after -y3

I have no idea why the display thread gets stuck in kernel code.
I have been struggling with this board for more than a month already... I would be very happy to solve this issue.

Could anyone shed some light on the issue? Even the slightest hint would be greatly appreciated.

TIA,
Asaf Gery

Here is the modified loadmodules.sh:

#!/bin/sh
# WARNING: this file is generated automatically, and any change will be overwritten by the Makefile
# The reserved memory that is used by cmemk is cut from the end of RAM by the mem=XX param of the kernel

rmmod cmemk 2>/dev/null
rmmod irqk 2>/dev/null
rmmod edmak 2>/dev/null
rmmod dm365mmap 2>/dev/null

PHYS_START=`printf '0x%x' $((\`sed -e 's/.*mem=\(.*\)M .*/\1 * 1024 * 1024/' /proc/cmdline\` + 2147483648 \`grep -q y.cont2 /proc/cmdline && sed -e 's/.*y.cont2_bufsize=\([0-9]*\) .*/+ \1/' /proc/cmdline\` \`grep -q re.cont /proc/cmdline && sed -e 's/.*e.cont_bufsize=\([0-9]*\) .*/+ \1/' /proc/cmdline\`))`
PHYS_END=`printf '0x%x' $((\`sed -e 's/.*mem=\(.*\)M .*/\1 * 1024 * 1024/' /proc/cmdline\` + 2147483648 + 77594624))`

echo "Loading CMEM from $PHYS_START to $PHYS_END"
modprobe cmemk phys_start=$PHYS_START phys_end=$PHYS_END pools=8x24,1x28,16x56,8x62,1x74,1x80,1x384,1x448,1x512,1x768,1x2688,1x3456,1x4224,1x10240,1x17024,1x30720,1x65792,4x100224,1x319264,1x343168,1x576000,4x1382400,8x1479936,16x1645056,1x2648000,4x1382400,1x3365824,1x16538976

modprobe edmak.ko
modprobe irqk.ko
modprobe dm365mmap.ko

rm -f /dev/cmem ; mknod /dev/cmem c `awk '$2 ~ /cmem/ {print $1}' /proc/devices` 0
rm -f /dev/edma ; mknod /dev/edma c `awk '$2  ~ /edma/ {print $1}' /proc/devices` 0
rm -f /dev/irqk ; mknod /dev/irqk c `awk '$2  ~ /irqk/ {print $1}' /proc/devices` 0
rm -f /dev/dm365mmap ; mknod /dev/dm365mmap c `awk '$2  ~ /dm365mmap/ {print $1}' /proc/devices` 0
lsmod


  • Asaf,

    I just starting working with the LeopardBoard DM368 and I am having the same issue.  Did you ever solve this issue?  If so, please let me know how you solved it.

    Also, I have a LI 5M camera board connected to the LeopardBoard and when I run  the application ./video_loopback_dm368.x470MV -O component -I camera -y 4 for 1280x720 I don't get any output while 720x480 resolution component output works fine.  Do you have any suggestions?

    Thanks,

    -Chuck

  • Hi Chuck,

    I wish I could have helped you. I did not manage to output any video at all. Eventually my client gave up and returned the board.
    My only advice to you, would be: get rid of this board. The vendor does not provide a decent support, the software is buggy, their forum as well as this forum are useless.
    I was posting questions and later one answering my self...
    I have also talked to a colleague who had similar experience with another product of this vendor, his engineer was spending more than a month trying to make it work. His conclusion was they it was very interesting to debug the product, but he didn't manage to make it work...  My advice is to stay away from their boars, they don't worth the headache and time spent trying to make them work.

    These are my 2 cents.

    Regards,
    Asaf

  • Asaf,

    Thank you for telling me about your experience and for your advise.

    -Chuck

  • All,

    It turns out that Steve's recipe for hosting TI's DVSDK 4.02 onto the LeopardBoard DM368 is very good but incomplete ;-) - please see Mark's post at http://designsomething.org/leopardboard/f/23/p/665/2847.aspx#2847.  Steve's post can be found at: http://tw.myblog.yahoo.com/stevegigijoe/article?mid=366&prev=369&next=363.

    My configuration is: LeopardBoard DM368 v 1.5 + LI-5M03 Camera Board + DVSDK 4.02.00.06 installed per Steve's recipe.  After DVSDK installation, creation of SD Card file system, etc. - the only resolution that would work using ./video_loopback_dm368.x470MV -O component -I camera -y x was 720x480 while using -y 4 or -y 5 (1280x720 or 1920x1080) will not output video via the VPBE component video output.

    As Mark points out, the problem is due to the way the EVMDM36x derives its VPBE clocks externally via the CPLD resulting in the way the davinci_enc_select_venc_clock() function operates due to the fact that it checks the requested clock frequency against the current frequency of pll1_sysclk6 or pll2_sysclk5; therefore, Mark's modification must be applied.  Although I find that my 16:9 LCD TV can tolerate more than the 1 part in 1000 frequency variance Mark cites.

    It's interesting that running ./video_loopback_dm368.x470MV -O component -I camera -y 4 (or -y 5) will not cause an error (or any other complaint) but the application will hang at the DMAI Display_get() function that is called after Display_create() is called.

    Thanks again Steve and Mark,

    -Chuck