2009-08-31 22:09:13     v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

2009-08-31 22:09:13     v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

James Buckley (UNITED KINGDOM)

Message: 79418   

Hi,

I have a development board setup with an Omnivision OV9655 CMOS sensor. I'm trying to get the camera to work, but am having problems with a weird EINVAL returned from a v4l ioctl.

I've enabled the blackfin camera driver, chosen OV9655 as the sensor, adjusted the uncached DMA region (4M) and kernel load address (0x40 0000). Loading the module goes fine (camera detected), however when I try and call the VIDIOCGCAP ioctl, it returns with an EINVAL error.

Looking through the code for the driver, EINVAL can't be returned by code handling that specific ioctl, so it must be returned further up the ioctl chain. The OV9655 has a max resolution of 1280x1024, which required m to allocate 4MB DMA space to fit a frame, and the kernel load address to be over 0x20 0000 (I tried 0x400000 and it was okay). Another thread mentions that using high load addresses caused a weird EINVAL error, but no solution.

Does anybody know whats causing this? trying the v4l_test program just gets the error 'cannot get device capabilities: Invalid argument.', writing my own code reveals the exact same problem.

This is all on a BF527. I appreciate that the 527 is new and the ppi driver has only recently been ported, however it doesn't seem like I'm even reaching the stage of where this would be a problem.

Any help would be great,

James

QuoteReplyEditDelete

2009-08-31 22:18:29     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

James Buckley (UNITED KINGDOM)

Message: 79419   

EDIT: After reading a little further down the forum page, I noticed someone else is in the almost exact same situation as me. They seem to be able to get further, but I believe they are not using a 527. I am infact also using a bluetechnix development board, but not the camera module. Instead I have wired the camera exactly as is done on the Surveyor SRV-1 (as that is what the OV9655 sensor driver was written for I believe).

My /dev/video0 shows up fine (unlike the other person), however trying any ioctl returns an error with EINVAL.

Any help would be great,

James

QuoteReplyEditDelete

2009-08-31 22:20:54     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

James Buckley (UNITED KINGDOM)

Message: 79420   

EDIT2 (can't seem to edit a post): I'm using the daily snapshot release of uClinux and the toolchain, as support for the BF527 does not seem to appear in the 2008 release.

Sorry for the triple post.

QuoteReplyEditDelete

2009-09-01 06:57:56     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

Michael Hennerich (GERMANY)

Message: 79430    Please use the 2009R1 linux-kernel, uclinux-dist and toolchain release.

  blackfin.uclinux.org/gf/project/uclinux-dist/frs

Better checkout from our svn /branches/2009R1

svn checkout

svn://firewall-sources.blackfin.uclinux.org:80/svn/linux-kernel/branches

/2009R1 linux-kernel

SVN trunk which the daily snapshot are generated from is known to have

problems.

-Michael

QuoteReplyEditDelete

2009-09-02 18:50:19     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

James Buckley (UNITED KINGDOM)

Message: 79501   

Thank you, that solved the problem.

After solving the previous problem, my own v4l_test program could successfully grab an image. However, the resulting image looked wrong (imagine a UYVY image which was actually just UYUY). It turns out the reason for this is because the camera has not been initialised correctly. Looking through the OV9655 driver there are a couple of errors:

in the my_init() function, a call to 'WriteWord(client, 0x12, 0x80)' is made. That should write 0x80 to register 0x12 in the camera (which actually causes a device reset). However, the function WriteWord right shifts the third parameter by eight (>>8) before sending it over i2c. This results in 0x12 0x00 being sent (which does something else). After removing the shift, the parameter is correctly sent. I've confirmed this with an oscilloscope.

Secondly, there is an array 'myconfig' which contains a list of register-parameter pair values. Currently, it only one parameter pair. I fleshed out the parameter table with values taken from the Surveyor SRV-1 firmware. These all successfully get sent to the camera.

The result of all this is that the camera now works (and the images look pretty good!). Over the next few days I'm going to improve the driver to support multiple resolutions, colour formats (specifically RGB) etc.., generally make the driver full featured and work as expected. I'll post a patch if you want (as the driver in it's current state doesn't work).

At the moment i've hacked the i2c driver to enable SCCB mode, this causes a camera to be detected at address 0x62 as well as 0x60 (I guess as the driver defines the read/write i2c addresses to be 0x30 and 0x31, and then get left shifted by one, which makes 0x60 and 0x62). However, it doesn't seem to cause a problem.

Cheers,

James

QuoteReplyEditDelete

2009-09-02 18:53:32     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

James Buckley (UNITED KINGDOM)

Message: 79502   

EDIT: Also, it seems as the buffer locations in blackfin_cam are being misreported through the api. looking through the pr_debug message outputs, the memory locations being used do not line up with those being reported through the offsets[] array. At the moment I'm ignoring the v4l addresses and have hard coded the actual ones. Obviously this is only a hack, I'll look into the problem further...

QuoteReplyEditDelete

2009-09-02 21:04:05     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

Mike Frysinger (UNITED STATES)

Message: 79503   

sure, we'll happily take patches to the blackfin_cam and related driver code

QuoteReplyEditDelete

2009-09-03 02:17:45     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

r sultana (INDIA)

Message: 79506   

Hi James,

I am working on the ov9655 sensor on the blackfin 527 EZKIT. I am trying to validate the existing the v4l driver and facing similar issues in bringing up the sensor with the driver code.

Can you please send me the register-pair parameter values, so that i can also proceed further.

Thanks for the help.

rsultana.

QuoteReplyEditDelete

2009-09-03 10:09:05     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

r sultana (INDIA)

Message: 79563   

Hi James,

I have followed your post and done the following changes in the v4l driver, but still not able to capture the sxga UYVY image.

Changes done:

1. Changed the boot load address to 0x400000

2. Removed the bit shifting code in the WriteWord implementation.

3. Modified the myconfig array with all the register-pair values as per the surveyor distribution.

I am using the v4l_test application for testing. I have done some changes in it so that the do loop runs only 2 times. (The test application as it is runs in a while loop indefinetly.)

But the data, i see in the pix_buf array is not an accurate image. (The images are attached).

Please have a look at the images and confirm, whether the data has been captured from driver level.

Also, can you send me the v4l_test application you are using. And let me know any other chnages you have implemented in the driver code also.

I would appreciate your help.

Thanks once again,

RSultana.

second.bmp

image.bmp

QuoteReplyEditDelete

2009-09-03 20:59:29     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

James Buckley (UNITED KINGDOM)

Message: 79589   

Looking at your images, there definitely seems some else is wrong also. Even before making any changes to OV9655 driver, the images I acquired looked real. You could see a picture (it was just green and purple). When the camera is first powered on, it seems to output UYUY instead of UYVY.

Have you edited the i2c routines in i2c-bfin-twi.c to enable SCCB mode. There is a similar post on the forum with the changes required (don't have the link at the moment).

I'll never used the v4l_test program supplied within the blackfin test suite. The program I'm using is written by me. I'll see if I can post the code up (needs a little clean up).

James

QuoteReplyEditDelete

2009-09-04 01:25:19     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

r sultana (INDIA)

Message: 79598   

Hi,

I have gone through the i2c-bfin-twi.c file, and found the following code.

/* Enable TWI */

        write_CONTROL(iface, read_CONTROL(iface) | TWI_ENA);

SCCB is not set.

But with this code, I am able to see that ov9655 sensor is being detected. Please find the below log of kernel boot-up:

OV9655: i2c driver ready

i2c /dev entries driver

in sensor_attach_adapter

OV9655: detecting client on address 0x60

OV9655: detected I2C client (id = 0000)

OV9655 Rev5

OV9655 ManufactureID read propery

OV9655: V4L driver Blackfin CMOS Camera now ready

And i can see the /dev/video0 entry also.

Let me know if i can proceed further assuming the i2c is  communicating with the sensor correctly.

Thanks,

Rsultana.

QuoteReplyEditDelete

2009-09-04 08:25:02     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

r sultana (INDIA)

Message: 79613   

Hi,

Looking into the log, the client id returned 0x000, i think the i2c client i.e, our sensor has not been registered to the i2c bus. Let me know, if i am correct.

I am in the process of changing the mode to SCCB and then give a try with that also.

I have gone through the previous posts on SCCB & I2C, and i have a doubt, is it possible to have i2c configured to TWI mode in u-boot and SCCB mode in linux and still working.  Or is it that i2c should be configured in same mode both in u-boot and in linux.

And  can you share your changes w.r.t driver code also, so that i can proceed further.

It would be of great help to me.

Thanks,

Rsultana.

QuoteReplyEditDelete

2009-09-04 17:34:53     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

James Buckley (UNITED KINGDOM)

Message: 79618   

Don't worry about that ID = 0x0000 problem, it doesn't seem to affect anything. I can confirm that even though your device will be detected using i2c, it's not possible to communicate properly unless you enable SCCB mode. Enable SCCB will cause the sensor to be detected at 0x60 and 0x62 as well. Although that is a problem (which can easily be solved), the sensor will still work.

There is no need to alter u-boot (I think that post was to do with discovering/probing). Only the linux drivers need altering.

QuoteReplyEditDelete

2009-09-04 17:47:43     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

James Buckley (UNITED KINGDOM)

Message: 79619   

EDIT: I'll post a patch with all of the edits I've currently done to the kernel. At the moment I can't guarantee that anything works, all I can say is that it works for me. I can currently capture at 640x480 and 1280x1024 in UYVY. Most of the things I have changed are just hacks (particulaly the resolution-changing code), to get a proof-of-concept. Once I have everything working, I'll implement a more robust driver.

Once again, please don't judge me by the aulity of code, I've just being implementing 1-minute hacks to get the camera working.

Code to follow shortly...

QuoteReplyEditDelete

2009-09-04 18:11:20     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

James Buckley (UNITED KINGDOM)

Message: 79620   

See attached ov9655_driver_hack.diff.tar.gz

I'm not sure about how the licences work with taking sensor register settings from the surveyor project. I think credit needs to be given, but this patch is merely a snapshot of what I have done.

ov9655_driver_hack.diff.tar.gz

QuoteReplyEditDelete

2009-09-07 13:47:09     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

Roland Laurès (FRANCE)

Message: 79655   

That's great you did this job, I didn't look at what you did, but I was doing the same thing here. In fact I get the driver working 2 or 3 weeks ago, but as nobody seems interested, I thought that I had time to send it. The big difference is that I was not able to get a correct synchronisation will changing the resolution, then I did a initialisation table which support only 640x480. Reducing the maximum supported resolution.

An other difference is the media I used to solve the i2c problem. As you know this is not real i2c, but an other format, I found this functions which were present in a driver for ov9655 on linux :

static int ReadWord(struct i2c_client *client, unsigned char offset, u16 *data)

{

    int ret;

    BUG_ON(client == NULL);

        ret = i2c_smbus_read_byte_data(client,offset);

        if(ret >= 0) {

            *data = ret; // copie data

            ret = 0; // set just ok to ret.

        }

    return ret;

}

static int WriteWord(struct i2c_client *client,

                 unsigned char offset, unsigned short data)

{

    return i2c_smbus_write_byte_data(client, offset, data);

}

I'll take a look at what you've done and test it too. It will probably work better than mine (first driver for linux I was modifying...).

QuoteReplyEditDelete

2009-09-07 13:49:03     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

Roland Laurès (FRANCE)

Message: 79656   

On my side I'm working with a Surveyor-SRV1 board with the ram chipset modified (originally 32 MB I put it to 64 MB by changing the chip and modifying the u-boot). I'm using 2009R1 distrib too. And the processor is then a BF537 r0.2

I'm using the driver through ffmpeg.

QuoteReplyEditDelete

2009-09-07 15:01:44     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

James Buckley (UNITED KINGDOM)

Message: 79657   

And it works ok? I infact also own an SRV-1, and am using the camera module from that system on the Bluetechnix development board. Are the pictures ok? I found that I had to modify the driver because the registers needed programming before I got a useful picture.

Also, how are you (if any) doing any communication to the device. I found that on the SRV-1 the presence of only a serial port (be it connected via wifi), is severly limiting, in usefullness and speed. I was almost thinking of setting up a PPP connection over serial to provide an IP connection (although slow).

James

QuoteReplyEditDelete

2009-09-07 16:44:27     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

James Buckley (UNITED KINGDOM)

Message: 79659   

Interesting that i2c_smbus_read_byte_data() works. Looking at the wikipedia page, the difference between i2c and SMBus is that SMBus HAVE to acknowledge their address (where i2c can NACK if they are not ready). Looking at the SCCB protocol, it seems the main difference is that infact no device has to ACK at all.

Really what I've done for the resolution switching code is an extreme hack, I just wanted to prove that it could be done. The code I currently have is more 'proper', but unfinished.

Before reading your post about smbus mode working, I was going to alter the bfin-twi code to enable SCCB only when it's transmitting/receiving to the sensor's specific address. My code currently reads the PID register from the camera to ensure it's presence, so if both the smbus read & write functions work, it should be possible to implement a fully working driver without any modifications to the twi at all (which is what is needed).

My design requires the use of some i2c port expanders, which is why it's important for me to be able to work with both i2c and SCCB devices.

Thanks for the info,

James

QuoteReplyEditDelete

2009-09-08 04:18:10     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

Roland Laurès (FRANCE)

Message: 79668   

It is working well, I get a good image on ffmpeg. For now, I have a little problem, I should have set the registers for a 640x480 image, but the sensor send me 2 images of 320x240 on the left and 2 green images for the right section of 320x480. Then I read it as a 320x240 image only which gives me a perfect image. Some time I have synchronisation problems which need a reset of the blackfin to solve (unplug and replug the sensor doesn't work at all), the problem shows as an image with green blurp some time. This make the image impossible to compress... But when it start working with a good image then the problem doesn't show at all.

About my communication : I use the BF0 to communicate as a terminal to the device (I stayed to 57600), and use the BF1 at 230400 with a 3G modem.

This is the way the project must communicate with the world. This gives me at the office a link of 110kb/s. ffmpeg seems able to use only 60 kb/s. I don't really know why. I though it was a problem of implementation of the DMA for the uart. But I think it is well implemented. I'm making an application which will monitor the cpu usage soon and launch ffmpeg at the same time, and be able to say how much time the CPU spend waiting for devices and how much time it spend computing images.

QuoteReplyEditDelete

2009-09-08 08:00:18     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

James Buckley (UNITED KINGDOM)

Message: 79676   

Could you tell me what frame rate you manage to achieve. Is the picture quality still reasonably good after compression?

QuoteReplyEditDelete

2009-09-10 02:58:19     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

Roland Laurès (FRANCE)

Message: 79724   

I'm managing to get something around 15 fps. But every x seconds, the quality just drop sinificantly for some images, then get back to a real good quality. I don't really understand why... I try to suppress variable light (like neon) but still it was doing this... I'm currently writing an other part of the project, which will monitor the cpu and network usage. This will allow me to understand a little better where there should be a problem...

QuoteReplyEditDelete

2009-09-11 09:57:06     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

Dusko Cencan (GERMANY)

Message: 79804   

Hi

The last days I read everyting I could find according BF5xx and OV9655 Cam on uClinux, including this thread and testing the patches from James.

I have a custom Board (32MB Ram, Ethernet, USB OTG, RS232, SD Card) with Bluetechnix CM-527 modul attached to it. I2C and ppi are wired exactly the way as it  is on the SRV-1 board to ensure compatibility with the ov9655.c driver and v4l.I boot my kernel via tftp in uBoot. After various attempts tu get I2C working, I realised that there was a wiring problem, now thats OK. Without the patches from James my Cam is recognized. With the patch it is recognized two times (as mentioned above from someone) , but only the first address 0x60 could be initialized. The second address has a "init error 0xffffffed " error. After then every operation and streaming attempt ends on a kernel panic after I manually reboot the machine. While on and running  I got no Kernel Panic.

Trying to stream, V4l_test gives me "unsupported video format", so I commented the "return -1" value in the v4l_test app so that the driver does not halt on this place. Tests with ffmpeg and v4l_test streaming the /dev/video0 picture to a file were always unsuccessful, because I got memory problems. First ffmpeg was not able to "allocate DMA". I changed the kernel start address to 0x300000 or 0x400000 and reserved 1MB uncached DMA memory in the kernel config. Any other settings then 1MB DMA gave me "could not allocate DMA" when starting ffmpeg. Right now I got a lot of paging faults while trying to stream. Also errors like "[mpeg4 @ 0x807180]get_buffer() failed (-1 0 0 (nil))

SIGSEGV" .

So it does not work actually. The part that work for me is 160x120 video encoding to a file on a NFS mounted computer via ffmpeg. I can see the video, but while encoding ffmpeg and v4l use 13mb memory and left me only approx. 500kb of memory. With higher resolution settings I got either paging faults or "Running out of memory" kernel messages. Looking at the 160x120 video, I assume that the video Input was a way higher resolution (maybe 1280x1024) but was actually cropped to 160x120. The viewing angle of the video recorderd was very very low, so I assumed that. 13mb of memory usage also sounds like a higher resolution of the input stream.

Does anyone else got problems with memory? When I start the system , I got 13mb left. Uncached DMA is set to 1mb.

My output:

"

i2c-adapter i2c-0: adapter [i2c-bfin-twi] registered 

i2c-bfin-twi i2c-bfin-twi.0: Blackfin BF5xx on-chip I2C TWI Contoller, regs_base@ffc01400 

Linux video capture interface: v2.00 

i2c-core: driver [OV9655] registered 

i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x30 

OV9655: detecting client on address 0x60 

i2c-adapter i2c-0: client [OV9655] registered with bus id 0-0030 

i2c-adapter i2c-0: master_xfer[0] R, addr=0x30, len=1 

OV9655: PID register contained 0x96 

i2c-adapter i2c-0: master_xfer[0] W, addr=0x30, len=2 

Init settings downloaded: 6767 

i2c-adapter i2c-0: master_xfer[0] W, addr=0x30, len=2 

i2c-adapter i2c-0: master_xfer[0] W, addr=0x30, len=2 

....

#### approx 20 times repeating those lines...

i2c-adapter i2c-0: master_xfer[0] W, addr=0x30, len=2

i2c-adapter i2c-0: master_xfer[0] W, addr=0x30, len=2

OV9655: V4L driver Blackfin CMOS Camera now ready

i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x31

OV9655: detecting client on address 0x62

i2c-adapter i2c-0: client [OV9655] registered with bus id 0-0031

i2c-adapter i2c-0: master_xfer[0] R, addr=0x31, len=1

OV9655: PID register contained 0xFF

OV9655: init error 0xffffffed

OV9655: i2c driver ready

################################################

Mem-Info:

DMA per-cpu:

CPU 0: hi: 0, btch: 1 usd: 0

Active_anon:0 active_file:963 inactive_anon:0

inactive_file:909 dirty:0 writeback:0 unstable:0

free:204 slab:1408 mapped:0 pagetables:0 bounce:0

DMA free:816kB min:696kB low:868kB high:1044kB active_anon:0kB inactive_anon:0kB active_file:3852kB inactive_file:3636kB present:30476kB pages_scanned:0 all_unreclaimable? no

lowmem_reserve[]: 0 0 0

DMA: 12*4kB 2*8kB 1*16kB 1*32kB 1*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB 0*32768kB = 816kB

1872 total pagecache pages

7679 pages RAM

1266 pages reserved

0 pages shared

6188 pages non-shared

Allocation of length 98304 from process 179 failed

DMA per-cpu:

CPU 0: hi: 0, btch: 1 usd: 0

Active_anon:0 active_file:963 inactive_anon:0

inactive_file:909 dirty:0 writeback:0 unstable:0

free:204 slab:1408 mapped:0 pagetables:0 bounce:0

DMA free:816kB min:696kB low:868kB high:1044kB active_anon:0kB inactive_anon:0kB active_file:3852kB inactive_file:3636kB present:30476kB pages_scanned:0 all_unreclaimable? no

lowmem_reserve[]: 0 0 0

DMA: 12*4kB 2*8kB 1*16kB 1*32kB 1*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB 0*32768kB = 816kB

1872 total pagecache pages

NULL pointer access

Deferred Exception context

CURRENT PROCESS:

COMM=ffmpeg PID=179

CPU = 0

TEXT = 0x005a0000-0x005b102c DATA = 0x0059802c-0x0059a340

BSS = 0x0059a340-0x005c0000 USER-STACK = 0x005dfd90

"

QuoteReplyEditDelete

2009-09-13 15:18:34     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

Dusko Cencan (GERMANY)

Message: 79847   

Hi,

Somehow I managed to solve the "page allocation failure" and "could not allocate DMA" errors.

Running v4l_test with a few loops gives me green images, simmilar to those r_sultana attached. I still got the problem with the init error on the second i2c address (0x62). Do you have the same errors on the 0x62 address? I patched the source with Buckleys code. James, can you post some of your code for setting picture parameters to the camera and grabbing an image?

i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x31

OV9655: detecting client on address 0x62

i2c-adapter i2c-0: client [OV9655] registered with bus id 0-0031

i2c-adapter i2c-0: master_xfer[0] R, addr=0x31, len=1

OV9655: PID register contained 0xFF

OV9655: init error 0xffffffed

OV9655: i2c driver ready

QuoteReplyEditDelete

2009-09-13 16:07:33     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

Dusko Cencan (GERMANY)

Message: 79848   

Hi again,

I managed to eliminate the init error, I made a mistake in the blackfin_c code while adding James's patch. Now my dmesg output is:

Linux video capture interface: v2.00

i2c-adapter i2c-0: adapter [i2c-bfin-twi] registered

i2c-bfin-twi i2c-bfin-twi.0: Blackfin BF5xx on-chip I2C TWI Contoller, regs_base@ffc01400

Initializing camera

i2c-core: driver [OV9655] registered

OV9655: starting probe for adapter i2c-bfin-twi (0x190001)

i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x30

OV9655: detecting client on address 0x60

i2c-adapter i2c-0: client [OV9655] registered with bus id 0-0030

OV9655: detected I2C client (id = 0000)

i2c-adapter i2c-0: master_xfer[0] R, addr=0x30, len=1

OV9655: PID register contained 0x96

i2c-adapter i2c-0: master_xfer[0] W, addr=0x30, len=2

Init settings downloaded: 6767

i2c-adapter i2c-0: master_xfer[0] W, addr=0x30, len=2

## A LOT OF THESE "i2c-adapter i2c-0: master_xfer[0] W, addr=0x30, len=2" messages   

i2c-adapter i2c-0: master_xfer[0] W, addr=0x30, len=2

i2c-adapter i2c-0: master_xfer[

Registering bcap device

Configuring ppi

bcap_reg_reset:

Configuring Video4Linux driver

OV9655: V4L driver Blackfin CMOS Camera now ready

i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x30

OV9655: i2c driver ready

Funny thing is, I got only one client registered, not two. But again, grabbing some pictures in UYVY format results in green images.

QuoteReplyEditDelete

2009-09-14 06:21:52     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

James Buckley (UNITED KINGDOM)

Message: 79871   

What you described (detection of camera on 0x60 and 0x62) happens to me also, however normally I do not get an init error.

I'll post my v4l code for testing the camera (it simply grabs a yuv image, converts it to RGB, and puts it in a .PPM file). However I don't have access to the code right now (I can get it in a couple of days).

However the code I wrote was crated by just looking at the v4l api documentation. The V4L2 documentation is much better, and is probably worth looking at in order to understand the V4L1 api (actually both are quite similar).

James

QuoteReplyEditDelete

2009-09-14 08:45:10     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

Dusko Cencan (GERMANY)

Message: 79874   

Hi James,

Thanks for your reply. As I wrote in my previous post I managed to fix the init errors (I made an error while patching with your code). You can look at the output in the post above, the cam ist is not detected on 0x62. However I think the communication could be OK. Right now I managed to grab a very clear picture in VGA resolution with my modified v4l_test app. Any other format looks bad. Trying SXGA results in a bad image. Funny thing is that the image I get when setting SXGA comes as 256x256. I will attach an working image with VGA an the not working version with SXGA (same camera angle).

QuoteReplyEditDelete

2009-09-14 09:05:35     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

Dusko Cencan (GERMANY)

Message: 79875   

Here are the images...

NOT_WORKING.jpg

working.bmp

QuoteReplyEditDelete

2009-09-16 03:26:16     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

Roland Laurès (FRANCE)

Message: 80012   

Ok, Here is the thing :

First I didn't managed to make the camera work on a 32 MB system, I changed the SRV componant to get 64 MB.

Second, I didn't had this "green" problem, on my case it was a synchronisation problem between the clock of the camera and the rythm at which the blackfin was reading data....

It's perhaps the same on your case, and need to be tunned to fit your board crystals or something... On my case I made it work by using SRV parameters for the sensor... And if you used the code from James, then I guess you should have the same than mine... Can you tell us how you get the good image and the not working one ?

QuoteReplyEditDelete

2009-09-16 04:09:11     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

Roland Laurès (FRANCE)

Message: 80014   

ok, the godd one is from VGA and the bad one from SXGA. Sorry I didn't understand that at first...

On my side I got performance issues at SXGA, then I didn't make it work at this resolution... I dropped to vga configured and qvga captured...

QuoteReplyEditDelete

2009-09-16 09:20:38     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

Dusko Cencan (GERMANY)

Message: 80017   

Hi Roland,

SXGA works, in fact it worked shortly after VGA start working. The problem was not the hardware or the driver. First problem was related to memory. Right now SXGA only works when I disable uncached DMA region in the kernel config. After that it seems to work but I didn't realize for some time because XnView I used to open the UYVY images doesn't like SXGA images. VGA images seem to open ok, SXGA images (~2.5mb) not. Then I tried YUV Player Deluxe, the image opened fine. Right now I am working on code to convert UYVY images to RGB, cause I tried to set the parameters to RGB in the Driver, but it does not work.

When capturing images in a loop, I got ~7-8 fps in SXGA. Means, writing the top buffer, then writing the buttom buffer and so on. Main problem is still memory. I got only 4M left while running the loop.What do you mean with performance issues? I dont use the hardware for streaming, I need to run a lot of image recognition and manipulation software on it, so I dont need 15fps or higher. 

I attached the working SXGA Image in jpeg format. I think it looks quite good.

test_1.jpg

QuoteReplyEditDelete

2009-09-16 10:25:52     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

Roland Laurès (FRANCE)

Message: 80019   

yeah, the image looks great.

About my performance issue, I don't really know what is the problem... It's just that I cannot use more than 60kbps over my 3g modem when using ffmpeg, while I can use 110 kbps with ftpput... I also see key frame with a dropped quality. Cpu spend all it's time between working and waiting state... I guess there is in some way a problem with the dma system for the serial line (to the 3g modem) or something like this. Then the cpu needs to spend a lot of time sending char or compressing stuff... I guess there is too much context change... But this problem doesn't belong in this thread. And I've no real data to show for now, I'm doing a monitoring application to try to better understand what is going on my bfin.

About the 1280x1024, I was not able to get a good capture rate at this resolution, I dropped to 640x480, and now it seems better. But I still have the issue i described. Also, to correct easyly the memory problem you have, I changed the RAM componant to get 64 MB instead of 32. I don't know if this is possible for you to do so.

QuoteReplyEditDelete

2009-09-16 11:54:45     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

Dusko Cencan (GERMANY)

Message: 80022   

Roland,

I discovered that writing the images to a file, which is actually not what you are doing, takes a very long time. I usually write the images to a NFS mounted folder on my desktop machine. There seems to be a difference in performance when enabling or disabling L1 cache for the network adapter. Cant test directly writing the file to RAM because of memory shortage. ffmpeg uses L1 cache and a lot of RAM. Of course encoding the stream takes a lot cpu time, so it only seems reasonable when you get a performance drop. Maybe there is a way to optimize ffmpeg. What format du you use for ffmpeg? Have you testet SXGA without encoding with ffmpeg or writing to a file? Just filling top and buttom buffers with images in a loop. I get arround 7-8 fps. Bluetechnix CM-527 Core module with 525Mhz.

QuoteReplyEditDelete

2009-09-16 12:14:47     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

James Buckley (UNITED KINGDOM)

Message: 80023   

At 1280x1024 the capture fps SHOULD be 7-8 fps (this is the limit of the sensor for that resolution). At 30fps the capture rate should be around 30fps. Also, after switching resolutions the first 3 frames will be messed up (while the camera's autogain adjusts). These first 3 pictures may be washed out or missing any blue color, but are normal.

James

QuoteReplyEditDelete

2009-09-16 12:19:36     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

James Buckley (UNITED KINGDOM)

Message: 80024   

All network packets need to be checksummed before/after sending/receiving. Placing the checksumming code in level 1 (which is what that 'networking option' does), should improve transfer speeds.

Writing images to ram is extremely quick (it's what I do with my test_app before ftp'ing them over the network (at 9.1MB/s = 72.8mb/s).

Putting the camera driver into RGB won't work yet (there's no support in the driver), and YUV->RGB conversion takes a long time (or needs heavily optimising - better off putting the camera into RGB mode).

I will post my test code, but still haven't had a change to get at it.

James

QuoteReplyEditDelete

2009-09-16 22:49:32     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

Dusko Cencan (GERMANY)

Message: 80040   

Hi,

I2C comm works fine now, thanks to James. First I realized that my custom base board was not wired properly(only 1st revision), after some quick and dirty tweaks it works.

I am going to enable L1 cache again. I disabled it because of ffmpeg. Now that SXGA works, I need to free up some memory. My UYVY -> RGB algorithm is basically working now (just tested on one image on my desktop machine). Why does the driver use two buffers? One is located at 0x1000 + X*Y*DEPTH and the other one 0x1000000 (should be above 16Mb). I just need one image in the buffer, for example the button buffer, an other for saving the temp image for conversion and another for my image processing calculations. The driver seems to switch bottom and top buffer. 1st frame in bottom buffer, 2nd frame in top, 3rd in bottom, 4st in top and so on... I dont see the reason for this, but I am just a newbie to Camera drivers. I am going to disable the top buffer in the driver, so that every frame is stored in the first buffer and use the top buffer for my purpose. Actually, I think I do understand why the camera is working even without DMA. On the uClinux Doc is written that the DMA should be reserved, but I think that the uncached DMA space is reserved at the end of the memory.  Addressing @16MB+ImageSize is not going to use the DMA space, or do I miss something important?

Another thing: Is there any chance getting the REAL Datasheet and Doc from Omnivision? The one cruising on the net is kind of useless. The registers are not documented very well. I understand that this is proprietary technology, but how are open-source guys like us going to modify and develop real drivers if the camera is closed. Maybe I am just to spoiled by open source system like unix/linux.

If someone is interested, I can submit the UYVY to RGB code implemented within the uClinux+ov9655 environment(not 100% finished yet). James, you got your own code as I understand correctly. Would be nice if people can get RGB, even RGB support in the driver is not working, yet. For many people, performance is not that important, but they need RGB for some reason. I would like to help where I can. My project requires RGB Images and some intensive image processing calculations, based on movement detection and raw image manipulations. A conversion between two formats is not perfect, but OK right now. I got no choice, actually.

I guess, we all stay in touch...seems to be more "demand" for working OV drivers than there is in the uClinux project, now.

I would like to thank James for his SCCB modifications. Very nice work, hopefully this code will be implemented in further uClinux releases.

Best regards,

Dusko Cencan

QuoteReplyEditDelete

2009-11-27 19:14:01     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

tchouk leway (GERMANY)

Message: 82818   

Hi,

I am new in this Forum and also in the world of Hardware Programming. Shortly i get the SRV 1 Robot Kit with the Omnivision CAM. I am about to flash on it the last uClinux dist but i could not found some helpfull DOCs.

Have someone get some doc for me how i should proceed to get my SRV 1 work with uClinux and my Camera to? It would be very great.

Best regards

Tchouk leway

TranslateQuoteReplyEditDelete

2010-02-08 16:52:02     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

Joseph Orender (UNITED STATES)

Message: 85777   

Just wondering the status of this thread. It's been a few months.

-Joseph

QuoteReplyEditDelete

2010-07-12 09:48:52     Re: v4l_camera driver with OV9655 CMOS has erronous EINVAL returned from ioctl

Howard Gordon (UNITED STATES)

Message: 91170   

Surveyor is now actively working on direct support of linux port to SRV1.  We have a working kernel with 2009 release, and have successfully added support for the PWM timers (motor control) and 2500kbps console, but do not yet have working video capture.  Note that video capture did work with Martin Strubel's 2008 patch.  We are also looking to support both OV9655 and OV7725 sensors.

Project is located here -

      code.google.com/p/srv1-linux/

We would be grateful for input or involvement in this project by others who have already solved linux issues on SRV1.  I will start a new thread addressing this topic as well.

Attachments: