DSP video playback lock up on C4

I was wondering if any could help me with a playback problem on my
BeagleBoard C4. I'm using the following command to play the Big Buck
Bunny video test but it locks up in what appear to be random points (re:
not the same place each time):
modprobe mailbox_mach
modprobe bridgedriver base_img=/lib/dsp/baseimage.dof
gst-launch playbin2
uri=file:///root/big_buck_bunny_480p_surround-fix.avi

The serial console is still active buy my HDMI monitor is frozen. I'm
using Matchbox so its a fullscreen video playback and I can't get back
to the window manager when the playback locks up. I'm using the X
driver from the SGX package though I believe the playback is not going
through X. Don't know if that part is relevant at this point.

I'm using kernel 3.2.30, no patches, with the following DSP bridgedriver
configs:
CONFIG_TIDSPBRIDGE=m
CONFIG_TIDSPBRIDGE_MEMPOOL_SIZE=0x600000
# CONFIG_TIDSPBRIDGE_DEBUG is not set
CONFIG_TIDSPBRIDGE_RECOVERY=y
# CONFIG_TIDSPBRIDGE_CACHE_LINE_CHECK is not set
CONFIG_TIDSPBRIDGE_WDT3=y
CONFIG_TIDSPBRIDGE_WDT_TIMEOUT=5
# CONFIG_TIDSPBRIDGE_NTFY_PWRERR is not set
# CONFIG_TIDSPBRIDGE_BACKTRACE is not set

I didn't see any related kernel patches in Robert's stable_kernel tree,
but I might have missed something.

Modules loaded:
# lsmod
bridgedriver 150260 0 - Live 0xbf106000 (C)
mailbox_mach 3761 0 - Live 0xbf102000
mailbox 3701 2 bridgedriver,mailbox_mach, Live 0xbf0fe000
pvrsrvkm 175518 3 - Live 0xbf0c5000 (O)
drm 190817 4 pvrsrvkm, Live 0xbf081000 (O)
arc4 1038 2 - Live 0xbf07d000
carl9170 68053 0 - Live 0xbf067000
ath 13103 1 carl9170, Live 0xbf060000
mac80211 173814 1 carl9170, Live 0xbf02c000
cfg80211 143725 3 carl9170,ath,mac80211, Live 0xbf000000

I have the DSP binaries from Buildroot 2012.05, which appear to be the
latest, along with the gst DSP plugin:
BR2_PACKAGE_GST_DSP=y
BR2_PACKAGE_TIDSP_BINARIES=y
BR2_PACKAGE_DSP_TOOLS=y

My kernel args:
# cat /proc/cmdline
console=ttyO2,115200n8 console=tty0,38400 vram=16M omapfb.debug=n
omapdss.debug=n mpurate=720 mem=128M omapdss.def_disp=dvi
omapfb.mode=dvi:1280x720MR-16@60 omapfb.vram=0:8m,1:4m,2:4m
root=/dev/mmcblk0p2 rootwait

I've seen Robert's kernel is at 3.2.30 though I'm not clear if the
TIDSPBRIDGE driver has been tested with this kernel. Maybe it's my
kernel args or, possibly, my toolchain. I roll my own with Crosstool-NG
using Linaro's 2012.04 4.6 gcc and glibc 2.13. I may try it with
CodeSourcery's toolchain if I can't figure something else out. I also
need to get gdb on the target and see if that tells me anything.

Anyway, if anyone has some suggestions on how to debug this I'd
appreciate the pointers. Thanks.

I last tried it with v3.4, playback was definitely less "jerky" then
v3.2, but both seemed to work... I should really retest with v3.6 as
some kernel patches hit mainline.. But from the user space side, it
seems like no one is really working on this anymore..

Regards,

Hello !

I am experiencing quite the same issue as You on a Beagleboard xM.

My “witness test” is from the Ubuntu Wiki (written by Robert C Nelson)

  • Ubuntu 12.04,
  • Using an unofficial kernel from Robert C Nelson (see wiki) as the official image is not compiled with tidspbridge support.
  • The gst-dsp project that contains the gstreamer plugins and dsp tools

At first just check the dsp communication by :

  • check your driver initialization /proc/interrupts must show interrupts affectation :

26: 5 INTC dsp
28: 0 INTC DspBridge iommu fault
36: 0 INTC dsp_wdt

  • check that dsp-test run cleanly : it blocks some seconds and then return “copied 1000 times successfully”).
  • you may also run the userspace-dspbridge samples.

If it runs then you may have the video running. But be aware that few h264 video files can be read by dsp. With the ubuntu image I did not manage to run “big buck bunny video” (h264,mp4,…). But I got a file from divxtest that runs very fine (that’s not 720p tough).

About the toolchain :

I roll my own with Crosstool-NG
using Linaro’s 2012.04 4.6 gcc and glibc 2.13. I may try it with
CodeSourcery’s toolchain if I can’t figure something else out.

I’m using the following environnements :

  • Code Sourcery arm2009q,
  • Code Sourcery arm2012-…

I have been using the following kernels :

  • git linux-omap (until 3.6 rc6)
  • git linux-stable 3.2.30
  • others from omapzoom (from OMAPpedia dspproject wiki).
    I did compile the userspace-dspbridge (even the dsp sample that compiles against bios 5.21 only and CGT 7.4.1).

So I think it has nothing to do with gcc version neither 3.x kernels, but some patch missing or particular kernel config (it makes me think that I shall try Robert C Nelson kernel config on my sources.), or maybe missing uboot initialization, or user-space code error.

Here is what I got when I run any of the userspace binaries (here dsp-test) :
root@(none):/home/us-dspbridge# dsp-test
[ 75.850891] Unable to handle kernel NULL pointer dereference at virtual address 00000018
[ 75.864593] pgd = dd3a0000
[ 75.869903] [00000018] *pgd=9e6fc831, *pte=00000000, *ppte=00000000
[ 75.879180] Internal error: Oops: 17 [#1]
[ 75.885986] Modules linked in: bridgedriver©
[ 75.893280] CPU: 0 Tainted: G C (3.2.30 #3)
[ 75.901550] PC is at __lock_acquire+0x7c/0x1cf0
[ 75.908843] LR is at lock_acquire+0xd4/0xf8
[ 75.915710] pc : [] lr : [] psr: 20000093
[ 75.915710] sp : de791c50 ip : de798c80 fp : c0a6b350
[ 75.932830] r10: c06223b0 r9 : c05e3a30 r8 : 00000018
[ 75.940734] r7 : 00000000 r6 : 00000002 r5 : 00000001 r4 : 00000001
[ 75.949951] r3 : 60000093 r2 : 00000000 r1 : 00000000 r0 : 00000018
[ 75.959045] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
[ 75.970947] Control: 10c5387d Table: 9d3a0019 DAC: 00000015
[ 75.979125] Process dsp-test (pid: 617, stack limit = 0xde7902f0)
[ 75.987731] Stack: (0xde791c50 to 0xde792000)

Robert, do you have some particular patches around the tidspbridge that may resolve the situation ?

Best Regards,
Selso.

hi !

For now I did manage to make the dsp-test running. with my toolchain and in particular :

  • kernel 3.2.30 with no patch
  • RobertCNelson config file for his ubuntu omap package.
    Note :
    I have compiled the gst-dsp from the git repository (I may give you my CFLAGS). I wishing to recompile it to be sure (as I did search many ways)
    With that config the mailbox and bridge driver come as module (I did compile mailbox as part of kernel, does it may cause regression ? It should not). So you have to load them manually (and mailboxmach prior to bridgedriver).

Looking forware making gstreamer-dsp working now…

I am recompiling

I am posting the config file if you wanna test it.

config-3.2.30-x14 (94.6 KB)

When you say user space, do you mean gst-dsp or the driver? I think,
with DSP, terminology has been that "user space" was the driver and the
dof files were the DSP "kernel". Maybe I'm just confusing the matter.

If the user space is not being maintained, how are most distros handling
video decoding? Use the processor only, with NEON support? If so, I
guess I could fall back to that.

I can try 3.6 easily enough. I'm not applying any patches with 3.2 so I
could just try the same with 3.6. It's at least worth a try. Video
playback via gst-dsp and friends is sooooo close as it is. I haven't
tried 3.4 yet either. Might be another step to try.

I'll get gdb on my target and see if I can tell if its in gst-dsp. If
its in the driver I'll have to do some kernel debugging. In my own
drivers I just use printk(). I may need to use something more
sophisticated than that for this.

Thanks.

hi !

Howdy.

For now I did manage to make the dsp-test running. with my toolchain
and in particular :
      * kernel 3.2.30 with no patch
      * RobertCNelson config file for his ubuntu omap package.

I actually don't have the dsp-test. I need to get that working too, I
think. I've just used gst-dsp to test the whole stack all at once. A
brute force kind of test. Debugging this will be better with some DSP
tools.

Note :
I have compiled the gst-dsp from the git repository (I may give you my
CFLAGS). I wishing to recompile it to be sure (as I did search many
ways)

Buildroot 2012.08 uses the released 0.10.2 package for gst-dsp. I think
2012.05 is the same (but don't have that one unpacked at the moment to
verify). I could probably patch this to pull from git.

With that config the mailbox and bridge driver come as module (I did
compile mailbox as part of kernel, does it may cause regression ? It
should not). So you have to load them manually (and mailboxmach prior
to bridgedriver).

I have a tiny shell script to launch my test. It loads the drivers like
so:
modprobe mailbox_mach
modprobe bridgedriver base_img=/lib/dsp/baseimage.dof

After this, my module list looks like this:
bridgedriver 150260 0 - Live 0xbf106000 (C)
mailbox_mach 3761 0 - Live 0xbf102000
mailbox 3701 2 bridgedriver,mailbox_mach, Live 0xbf0fe000

So I think the module loading is correct at this point.

Looking forware making gstreamer-dsp working now....

I don't know much about gstreamer, though I like the description of the
framework. I'd like to dive a bit deeper into it. This may be my way
of doing that.

Don’t expect the debugger to help you :frowning: : especially for kernel and DSP environnement.
Do you have a link to your buildroot ?

The userspace-dspbridge is project from OMAPpedia : link
It gives you samples for DSP AND userspace application.
That just an alternative for the gst-dsp project.

gst-dsp project is a set of tools (dsp-test) and gstreamer plugin that use TI DSP codecs.

Now that your stuff don’t work you may first want to validate minimal dsp functionnality. I suggest you install with buildroot or by your own the dsp-test bin.

Your driver are loaded but that’s not enough : sometimes I don’t have the interrupts affected to DSP : don’t expect to get things working then.

Don't expect the debugger to help you :frowning: : especially for kernel and
DSP environnement.
Do you have a link to your buildroot ?

http://gitorious.org/beaglebox

You should be able to build just the rootfs using

   make XI=<path to toolchain install directory> buildroot
   make XI=<path to toolchain install directory> buildroot-pkg

The path should be to the top of the toolchain package. So if you
installed it under /usr and the toolchain's gcc is in /usr/bin the
command would look like this:

   make XI=/usr buildroot

BeagleBox builds its own toolchain and creates and RPM for it (on Fedora
and CentOS). The default location for the installed RPM
is /opt/beagleboxTC.

The -pkg target will copy the rootfs.tar to ../pkg. FYI: there is a
setup script function in docs/bashsetup.sh. I use it to bounce around
the source and build trees and package directory.

The userspace-dspbridge is project from OMAPpedia : link
It gives you samples for DSP AND userspace application.
That just an alternative for the gst-dsp project.

gst-dsp project is a set of tools (dsp-test) and gstreamer plugin that
use TI DSP codecs.

Yeah, that's what I'm using right now. I think I've run dsp-test in the
past, but I'm not positive of that. I'll look into that tonight.

Now that your stuff don't work you may first want to validate minimal
dsp functionnality. I suggest you install with buildroot or by your
own the dsp-test bin.

Yeah, I'll give the dsp-test a try.

Your driver are loaded but that's not enough : sometimes I don't have
the interrupts affected to DSP : don't expect to get things working
then.
         26: 4026 INTC dsp
         28: 0 INTC DspBridge iommu fault
         36: 0 INTC dsp_wdt

Actually, it does work for a short period. Then, after a random amount
of time, the playback locks up. I can play the Big Buck Bunny for a
little while, then it stops.

I don't have audio setup so can't verify that's also working, but the
video playback is quite nice until it locks up.

Hi !

Just to say I did manage to play video file in my environnement, but only get stable playing with 480p files. Notice that in the DVSDK only 480p samples are provided.
So I réencoded using VLC with these parameters (MRL) : :sout=#transcode{vcodec=h264,vb=1500,scale=1,venc=x264{profile=baseline,level=30,nocabac,nobframes,ref=3,subme=7,psy=1,psy_rd=1.00:0.00,mixed_ref=1,me_range=16,chroma_me=1,trellis=0,}}:duplicate{dst=std{access=file,mux=mp4,dst=/home/sli/mnt/ram/video_700x480_avc1_low_profile_aac.mp4}}