Update for srv1-linux has been posted.  
    http://code.google.com/p/srv1-linux/updates/list
 
The TIMER2 problem seemed to be specific to the Blackfin board I was using and went away when I changed boards.  So now we have motor control with the SRV-1 robot.  This can be tested using the "led" program in uClinux/user/blkfin-test/camera_test/led.c .   Eventually, this code will expand to test the various SRV_protocol functions and work directly with SRV1Console.
 
The video capture is still broken with 2009 linux.  Perhaps other users can look at the code to see if there is an obvious problem.  I created two versions of ov9655 driver - one with ov9655 registers and the other with ov7725 registers.  To build for ov9655, you just need to copy srv1-linux/uClinux/linux-2.6.x/drivers/media/video/blackfin/ov9655_9655.c to ov9655.c and ov9655_9655.h to ov9655.h.  To build for ov7725, copy ov9655_7725.c to ov9655.c and ov9655_7725.h to ov9655.h.  Hopefully we will eventually have a way to autodetect.
 
The other remaining issue is support for 2500kbps console.  There is no way from u-boot to set this speed, so my current idea is to change the default 38400 baud rate in the linux kernel to 38400.  I will post this if it works.
 
I have also posted SRV1 u-boot source as well as 115kbps u-boot.ldr to  
    http://code.google.com/p/srv1-linux/downloads/list

I see you didn't modify the i2c driver to support sccb protocol.
Maybe this helps:
http://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?_forum_action=ForumMe ssageBrowse&thread_id=35907&action=ForumBrowse

Another update.  Rather than getting stuck on v4l capture, a shifting test pattern has replaced v4l capture.  The test program is now srv1.c, not led.c or v4l_test.c
    http://code.google.com/p/srv1-linux/source/detail?r=24
 
This actually works with SRV1Console.  It doesn't yet support the 'M' command for motor control, instead using the old keyboard commands ('8' = forward, '2' = back, '4' = spin left, '6' = spin right, '5' = stop).  Lasers work - 'l' = on, 'L' = off.  'I' captures and sends a JPEG frame.   There's something screwy with the first frame and serial buffers aren't getting flushed, so it takes a long time to get a response to a motor or laser command.  But this is a start.
 
This test program does unmask a new problem, which is that we seem to be losing data at 2500k baud, and it's not a lot better at 921k.  Even 115k glitches occasionally with the Matchport connection, but it is rare.
 
Martin is looking at v4l capture, so hopefully we'll have resolution soon.  It should be easy to start adding other SRV_protocol functions, but we're going to have to figure out the issue with data loss - this may be something that has to be fixed in the Blackfin serial driver, so we need to isolate it.

Are there any news regarding the v4l-driver?

I checked your google-code project for the srv1.c boardconfig. I think you didn't adjust the MMC_SPI .chip_select for your pinout on the S-32 Header. You are using GPIO-H8 for the SPI chipselect, that should be pin 40, not 5.

I'm sorry to say we are not yet ready to start supporting the uClinux project since our uClinux developement team dissolved this past summer. We are getting this up and running and hope to have a new uImage to post within the next few weeks, but for now we are trying to understand what does and does not work from the last uImage and work through the road blocks that were holding up this project. I will post something here when we are ready to proceed.
 
Thanks for your patience.
 
T. Jump

You are correct that you cannot connect. As I said in my reply yesterday, the uClinux firmware is not complete. There are no control functions active in the uClinux firmware. There are some test video functions and this is all. Until we release a new version your only option is to write your own changes to the firmware.
 
T. Jump