Armbian 5.25 on OrangePI PC: The gc2035 video camera doesn't work

[Robert LabTeam 0]

Hi Guys, I've solved the problem and got it working on OPI0+2 H3 (tested on 5.32, but it should for all versions). I have noticed that my camera does not receive any voltage. I mean exaclty these lines: VCC_CSI and VDD1V5_CSI.  As we can see there are two LDOs which needs an external high state on the enable pin. It should come from MCU, however the driver does not handle it before ask through i2c if there is some camera.
You should set high state on the lines VCC_CSI and VDD1V5_CSI before using the camera. I did not do that by software because I am still waiting for schematic for my board, however if you have solder iron, you can connect these two lines to AFVCC_CSI (5.0V) on the extension board. Of course, you need to cut the PCB lines which comes from MCU (otherwise you can damage MCU -  I assume it is not 5V compliant). If you know exact name of lines, do that by software and do not make a mess on the extension board

Cheers!

Robert

[dmorse 0]

I'm hitting this same issue with the orangepi zero plus2 (h3). I'm trying to get the 5.20 version of Arbian built for my board now (which is pretty tricky because that is not a build option for my board)

 

Robert, is the the camera breakout board you have? Could you send me a picture of what you had to do to make it work? 

[olivluca 6]

I finally worked around the issue by modifying boot.cmd adding the lines

gpio set PL10
gpio set PG11

at the beginning, right after the "DO NOT EDIT THIS FILE " comment.

The I regenerated boot.scr

 

mkimage -A arm -T script -O linux -d boot.cmd boot.scr

And rebooted.

 

Before that I tried

 

sudo sunxi-pio -m PL10'<default><default<default><1>'
sudo sunxi-pio -m PG11'<default><default<default><1>'

but it didn't work

 

 

[olivluca 6]

On 8/7/2017 at 11:41 AM, Igor said:

 

There were some changes / fixes in driver sources. I don't have this camera ... Can you check? Just switch to beta repository, upgrade and reboot.

Using the beta repository at least solves the segmentation fault when trying to remove vfe_v4l2 but the gc2035 module doesn't accept the hres parameter anymore and the image is worse.

 

Edit: I spoke too soon: the segmentation fault is still there.

Edit 2: it seems the hres parameter isn't necessary, I just had to change motion config to get the same image as before. Maybe before the driver didn't respect the required picture size while now it does?

Edited July 19, 2017 by olivluca

[dmorse 0]

I've given olivluca's solution a shot and that does not work for me. 

 

Taking a look at the orangepizeroplus2-h3.fex file in the kernel source I an see what appears to be a lot of different GPIO settings in there. Might setting these make a difference? 

[olivluca 6]

1 minute ago, dmorse said:

I've given olivluca's solution a shot and that does not work for me.

 

Sorry, I forgot to say that mine is an orange pi pc. I got the gpios from the boot.cmd in 5.20 but it seems that's not an option in your case.

[Leonardo Lontra 2]

@olivluca Your Don't need more hres mode, now is a dynamic change. For example, If you want 1600x1200 with more image quality, sets resolution and fps to <=8, or 1600x1200 with higher fps, but less image resolution, sets fps to >= 20. Internally, change hres based on resolution or/and framerate.

[Leonardo Lontra 2]

@dmorse I have the same problem with armbian 5.24, just back to 5.20 and uses last kernel, works for me. It seems to me that there is something about u-boot, but I'm not sure about that.

[dmorse 0]

@Leonardo Lontra Asp previously mentioned, building 5.20 for the pi zero h3 is difficult because that board was not supported back then. 

[Leonardo Lontra 2]

7 minutes ago, dmorse said:

@Leonardo Lontra Asp previously mentioned, building 5.20 for the pi zero h3 is difficult because that board was not supported back then. 

I not have an orange pi zero for test, but you can try check:

- If i2cdetect shows camera address:

   $ i2cdetect -y 1 (Paste the stdout for us)

 

Maybe it's a wrong address in the fex file.

[dmorse 0]

@Leonardo Lontra I'm not sure how this utility works, but this looks pretty empty to me.

 

root@orangepizeroplus2:~#  i2cdetect -y 1  
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
root@orangepizeroplus2:~#

 

 

[Leonardo Lontra 2]

45 minutes ago, dmorse said:

@Leonardo Lontra I'm not sure how this utility works, but this looks pretty empty to me.

 

root@orangepizeroplus2:~#  i2cdetect -y 1  
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
root@orangepizeroplus2:~#

Can you write another image that is not armbian and check if the camera works? If works, it's a point to start investigating this.

 

[dmorse 0]

I get the same result using the standard ubuntu server build from the orangepi website, but at least with that one I can see /dev/video0. I haven't actually tried to use the device yet, will do that next.

 

root@OrangePI:~# i2cdetect -y 1 
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
root@OrangePI:~# ls /dev/video0 
/dev/video0
root@OrangePI:~#

 

[olivluca 6]

4 hours ago, dmorse said:

I get the same result using the standard ubuntu server build from the orangepi website, but at least with that one I can see /dev/video0. I haven't actually tried to use the device yet, will do that next.

 

 

 

In that image it seems uboot activates PL10 and PA17.

Try following my instructions but using PA17 instead of PG11.

[dmorse 0]

Quote

In that image it seems uboot activates PL10 and PA17.

Try following my instructions but using PA17 instead of PG11

 I don't have a boot.cmd file in /media/boot in that build, only a boot.scr

 

Do you know a way to turn the boot.scr into a boot.cmd for editing and then turn it back? 

[olivluca 6]

No, I mean with the armbian image.

[dmorse 0]

I added this to the top of my /boot/boot.cmd on that build

# DO NOT EDIT THIS FILE
gpio set PL10
gpio set PA17

and then make a boot.scr out of it and started up from that. Sill can't see /dev/video0. 

Still getting this out of dmesg

 

root@orangepizeroplus2:~# dmesg | grep -i gc2035
[    4.539492] [CSI_ERR][GC2035]sensor_read err at sensor_detect!
[    4.539514] [CSI_ERR][GC2035]chip found is not an target chip.
root@orangepizeroplus2:~#

 

 

 

[olivluca 6]

On 19/7/2017 at 7:17 PM, olivluca said:

I finally worked around the issue by modifying boot.cmd adding the lines

gpio set PL10
gpio set PG11

....

Before that I tried

 

sudo sunxi-pio -m PL10'<default><default<default><1>'
sudo sunxi-pio -m PG11'<default><default<default><1>'

but it didn't work

 

 

 

I wonder why setting the gpio with uboot works while setting them in userspace doesn't work. Maybe the syntax of sunxi-pio is wrong or something else is missing?

 

[thedon 1]

I got past the error

[ISP] isp platform_id = 5!
[CSI_ERR][GC2035]sensor_read err at sensor_detect!
[CSI_ERR][GC2035]chip found is not an target chip.

 

following is seen in dmesg output now

[    7.787818] [CSI][GC2035]V4L2_IDENT_SENSOR=2035
[    8.210055] [CSI][GC2035]disalbe oe!
 

but when I try capturing an image from the camera from a python script using pyimage, it crashes with the following error

[ 2173.632135] [CSI][GC2035]enable oe!
[ 2173.632583] [CSI][GC2035]V4L2_IDENT_SENSOR=2035
[ 2174.125239] [VFE_ERR]try rgb888 bus error when pix fmt is rgb888/prgb888 at try_fmt_internal!
[ 2174.134937] [VFE_ERR]pixel format (0x33424752) width 640 height 480 invalid at vidioc_s_fmt_vid_cap.
[ 2174.545886] [VFE_ERR]buffer count is invalid, set to 3 in video capture
 

tried fswebcam also and same error occurs there as well;

 

Have any of you encountered it before and can help?

[Orfait 0]

Hi,

 

I don't know what command you use for taking a picture. Here is mine :

fswebcam -r 1600x1200 -p YUV420P - > cam1600x1200.jpg

Hope it may help you.

[kotc 0]

hi guys, it looks like mainline uboot doesnt set PG11 (CSI_EN) on opipc etc anymore. i was lucky to have it enabled on my opi0+2h3. so to make camera work on opipc/opipc+/opilite/opi1 you have to:

sunxi-pio -m "PG11<1><0><1><1>"

then load modules (or create uboot which enables it at boot time). and PA17 is CSI_PWR_EN which is already set correctly in fex as vip_dev0_power_en. (btw. on opi0+2 CSI_PWR_EN is PA08).

[zador.blood.stained 761]

5 minutes ago, kotc said:

hi guys, it looks like mainline uboot doesnt set PG11 (CSI_EN) on opipc etc anymore.

Why should it? Enabling CSI power it's not a job for the u-boot. As I said earlier in this thread, somebody needs to get their hands dirty and add a new option to the CSI driver, and the pin in question should be parsed from script.bin

[kotc 0]

now that i look at it, i enabled PG13 on opi0+2h3, which probably also supplied power and made camera powered. ho hum. funny those little boards, stealing power from any source they can ;). and yeah, i agree camera driver should handle all powering. not to mention it would be nice if it didnt segfault on rmmod

[kotc 0]

or not. if i understand schematics correctly, on opi0+2h3 both csi_en and csi_pwr_en are connected to pa08

[zador.blood.stained 761]

7 hours ago, kotc said:

if i understand schematics correctly, on opi0+2h3 both csi_en and csi_pwr_en are connected to pa08

Yes, looks right, so it needs to be configurable per board (i.e. OPi One uses PA17 for CSI-PWR-EN and PG11 for CSI-EN)

 

7 hours ago, kotc said:

i enabled PG13 on opi0+2h3, which probably also supplied power and made camera powered.

Looks like PG13 is wired to the I2S/PCM interface of the AP6212 module.

[garlic 0]

I had solved this problem by my friend.

Run this script

sunxi-pio -m "PG11<1><0><1><1>"
modprobe gc2035
modprobe vfe_v4l2

The most import is that don't load gc2035 & vfe_v4l2 before. So you had better remove it in /etc/modules

This is my /etc/modules

#w1-sunxi
#w1-gpio
#w1-therm
#gc2035
#vfe_v4l2
#sunxi-cir
#v4l2loopback

you may see /dev/video0, but when you reboot, it lose again

I add my scrip to /etc/rc.local

this is my /etc/rc.local

sunxi-pio -m "PG11<1><0><1><1>"
modprobe gc2035
modprobe vfe_v4l2
sleep 5
modprobe v4l2loopback devices=2
/root/vidcopy/vidcopy -w 640 -h 480 -r 30 -i /dev/video0 -o /dev/video1 -f UYVY
sleep 5
/root/vidcopy/vidcopy -w 640 -h 480 -r 30 -i /dev/video1 -o /dev/video2 -f UYVY
exit 0

Thanks my friend: "虚耗"

[olivluca 6]

On 19/7/2017 at 8:06 PM, Leonardo Lontra said:

@olivluca Your Don't need more hres mode, now is a dynamic change. For example, If you want 1600x1200 with more image quality, sets resolution and fps to <=8, or 1600x1200 with higher fps, but less image resolution, sets fps to >= 20. Internally, change hres based on resolution or/and framerate.

 

I'm getting weird results with motion:

 

If I set 800x600 the image is OK but flipped horizontally

If I set 640x480 the image is OK

if I set 1600x1200 this is what I get:

[g40 1]

Ditto. See here: 

 

 

[olivluca 6]

Today I tried mainline kernel but there's no gc2035 module there. Is it so or did I miss something?

[olivluca 6]

Found it, the csi interface isn't supported in mainline kernel