I’m happy to report that I am now able to encode video on the Gumstix Overo Water using the DSP in the OMAP3530. It wasn’t difficult to make it work but it took several attempts at building the kernel before I got it right and, as you might know, cross compilation takes time.
I started with building the latest Gumstix Overo image from the overo-2011.03 branch as instructed by this tutorial from Gusmtix. That worked very well and I can highly recommend it if you want to get started with building your own images for the Gumstix Overo series. The only glitch with the build was fetching the sources for ksymoops-2.4.11 because kernel.org servers were down for maintenance. If that still happens when you try, you can temporarily modify the ksymoops_2.4.11.bb recipe to use:
SRC_URI = "http://mirror.linux.org.au/linux/utils/kernel/ksymoops/v2.4/ksymoops-${PV}.tar.bz2
Then I continued with the DSP tutorial by Jumpnow which is a really good step by step tutorial for getting video and DSP up and running. It was a relieve following this tutorial after the few days of absolute confusion I found myself in while trying to get an overview of the DSP options. The build went fine except that fetching of libtasn1-1.7 got stuck. I ended up aborting the process, downloading libtasn1 manually from http://mirrors.dotsrc.org/gnu/libtasn1/, putting the package in the source directory and restarting the process. It finished without any more trouble and the resulting image worked well on the Gumstix Overo Water with one exception: When I tried to run a Gstreamer pipeline using the TIVidenc1 block it crashed with the following error:
CMEMK Error: ioctl(): bad command type 0x1e (should be 0xfe)
CMEMK Error: Unknown ioctl received.
CMEM Error: getVersion: Failed to retrieve version from driver: -1.
CMEM Error: init: major version mismatch between interface and driver.
CMEM Error: needs driver version 0x3000000, got 0xffffffff
Searching Google I found a few discussions (e.g. this or this) that lead me believe that gstreamer-ti is not compatible with kernel 2.6.39. In fact, it sounds like kernel 2.6.34 is the preferred one, which would also be consistent with the Caspa camera drivers only being available for this kernel.
So I switched back to kernel 2.6.34-caspapx which is done by editing org.openembedded.dev/conf/machine/overo.conf – at this point I already had a git branch to contain my hacks and fixes. There are two lines that must be changed to make the overo-2011.03 branch use and be compatible with the 2.6.34-caspapx kernel:
'SERIAL_CONSOLE = "115200 ttyO2' to 'SERIAL_CONSOLE = "115200 ttyS2'
'PREFERRED_PROVIDER_virtual/kernel = "linux-omap3"' to 'PREFERRED_PROVIDER_virtual/kernel = "linux-omap3-caspapx"'
Thanks to Paparazzi for the tip. I did have some issues building the dsp-console-image with this configuration, namely while building the rootfs bitbake was complaining about unsatisfiable dependencies, looks something like this:
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for task-base-extended:
* libgcc1 (>= 4.3.3) *
Eventually, the error went away… What I did was trying to build gcc-cross and virtual/kernel on their own first, I don’t know for sure until I try again from scratch.
Anyway, the DSP is now working! The image below is a screenshot of my desktop computer receiveing H.264 video from the Gumstix Overo Water over UDP:
I was using encoder defaults and as you can see, the CPU load on the ARM is 47%. This is too high and it’s because I am using USB webcam which needs colospace conversion, which is done on the ARM. It seems none of my Logitech cameras can provide UYVY pixel format which is the only input format supported by TIVidenc1 on the OMAP3530. So I am now considering going back to the Caspa VL or similar camera, in particular I am considering the camera options from e-con Systems.