Robert LabTeam Posted July 10, 2017 Posted July 10, 2017 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 Posted July 19, 2017 Posted July 19, 2017 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 Posted July 19, 2017 Posted July 19, 2017 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 Posted July 19, 2017 Posted July 19, 2017 (edited) 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 Posted July 19, 2017 Posted July 19, 2017 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 Posted July 19, 2017 Posted July 19, 2017 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 Posted July 19, 2017 Posted July 19, 2017 @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 Posted July 19, 2017 Posted July 19, 2017 @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 Posted July 19, 2017 Posted July 19, 2017 @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 Posted July 19, 2017 Posted July 19, 2017 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 Posted July 19, 2017 Posted July 19, 2017 @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 Posted July 19, 2017 Posted July 19, 2017 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 Posted July 20, 2017 Posted July 20, 2017 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 Posted July 20, 2017 Posted July 20, 2017 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 Posted July 20, 2017 Posted July 20, 2017 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?
dmorse Posted July 20, 2017 Posted July 20, 2017 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 Posted July 23, 2017 Posted July 23, 2017 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 Posted August 5, 2017 Posted August 5, 2017 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 Posted August 6, 2017 Posted August 6, 2017 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 Posted August 12, 2017 Posted August 12, 2017 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 Posted August 12, 2017 Posted August 12, 2017 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 Posted August 12, 2017 Posted August 12, 2017 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 Posted August 12, 2017 Posted August 12, 2017 or not. if i understand schematics correctly, on opi0+2h3 both csi_en and csi_pwr_en are connected to pa08
zador.blood.stained Posted August 12, 2017 Posted August 12, 2017 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 Posted September 1, 2017 Posted September 1, 2017 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 Posted September 11, 2017 Posted September 11, 2017 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:
olivluca Posted September 21, 2017 Posted September 21, 2017 Today I tried mainline kernel but there's no gc2035 module there. Is it so or did I miss something?
olivluca Posted September 21, 2017 Posted September 21, 2017 Found it, the csi interface isn't supported in mainline kernel
Recommended Posts