mostly

Even if there is something bad in electrical design, it is somehow solvable from software side - year ago i had both 1080p and 2592x1944 working without any artifacts on kernel 3.4.113 on the same board OrangePiPC+. I believe 2-3fps is due to some bottleneck in ffmpeg (you'll likely see 100% core utilization by ffmpeg). I'm getting poor fps in ffmpeg at 720p and 1080p, but optimized uvc_h264_lb_allwinner with hw encoding gives pretty stable 15fps at 720p (no artifacts at all) and 7fps at 1080p (with /2 patch, some color artifacts are visible).

Tried it and got almost adequate FHD picture with OV5640_PCLK_ROOT_DIV / 2 . If using ffmpeg, the only problem that i see is that there is more green than expected. In the meantime, i brought up h264 hw encoding from uboborov sunxi-cedar-mainline + uvc_h264_lb_allwinner (turned on writing to file and FPS calculation in settings inside main.c). It works well with 1280x720@15fps (real 15fps in h264 file), but with 1920x1080 OV5640_PCLK_ROOT_DIV / 2 it gives some artifacts with colors and adds shadows to dark objects on white background. Not sure yet if this problem is from hw encoder side or ov5640. Were you able to get real 30fps? uvc_h264_lb_allwinner shows actual FPS, and 1280x720 framerate is always 15 and 1920x1080 framerate is always 7 regardless of what set in media-ctl format @ 1/ So a64 does not need that patch, and also does not need "connecting the clock parent in the device tree" in dts. Since we see these strange clocks behavior, can this custom clock source be not suitable for some modes?...

I'm not experiencing that, all still image captures are ok, both at 720p and 1080p. But problem with green 1080p video capture still here. Somebody was trying this register but it seems to be not the right one: https://patchwork.kernel.org/patch/10342907/ There is one interesting commit claiming adding autofocus: https://github.com/D3Engineering/linux_kernel_qcomlt/blob/7b3c6e86d236db6d0c523dbd3297deb7563d7bf1/drivers/media/i2c/ov5640.c but it's for legacy This way of building modules works for me: https://yoursunny.com/t/2018/one-kernel-module/ + touch .scmversion

Yes noise is annoying. Maybe "5.6 color interpolation (CIP)" mentioned in ov5640 datasheet can deal with it (CIP seems to be already enabled in driver initialization, maybe tuning of CIP parameters can help). Also not sure what to do with autofocus. The driver also has nothing for it, but i have not found in the datasheet how to enable it. One problem found with 1920x1080 resolution: still image capture with fswebcam works but attempt to get 1080p video with ffmpeg gives noisy greenish picture where only contours of objects can be recognized, exactly like in that message: 1280x720 is fine.

Thank you! That's the part that i was missing. Now i'm able to run ov5640 on OrangePiPcPlus with kernel 5.4.45. My dts: https://pastebin.com/gdQnnrxQ /dev/video1 appears after reboot (no manual modprobe ov5640 needed). ov5640 for some reason does not leave any footprint in dmesg. I've kept compatible = "allwinner,sun6i-a31-i2c" in i2c2@1c2b400 to be able to check chip id by i2cdetect. And nothing was working without compatible = "allwinner,sun8i-h3-csi" and other stuff inside csi@1cb0000. Would be nice to pull the solution into official build (maybe as overlay) . Ov5640 module is one of very few official orangepi accessories according to https://linux-sunxi.org/CSI media-ctl --device /dev/media1 --set-v4l2 '"ov5640 1-003c":0[fmt:UYVY/1920x1080]' 1920x1080 and 1280x760 are working well for me fswebcam -d /dev/video1 -r 1920x1080 -D 3 --jpeg 100 /mnt/sd/aaa.jpg --- Opening /dev/video1... Trying source module v4l2... /dev/video1 opened. No input was specified, using the first. Delaying 3 seconds. --- Capturing frame... Captured frame in 0.00 seconds. --- Processing captured image... Setting output format to JPEG, quality 100 Writing JPEG image to '/mnt/sd/aaa.jpg'.

3.4.113 (Armbian_5.46) fex: [csi0] vip_dev0_mname = "ov5640" sunxi-pio -m "PG11<1><0><1><1>" modprobe ov5640 modprobe vfe_v4l2 Yup maybe it's just needed to set somewhere a bit enabling that i2c lane, or something else H3/board-specific. I was thinking about connecting oscilloscope to csi to see if there is any activity at all.

Was playing with it last October, exactly the same result. OV5640 now works only on kernel 3.x Somebody has to fix mainline driver(s).

Still trying to solve this. Problem reproducible on clean installation of Armbian_19.11.3_Orangepipcplus_bionic_current_5.3.9 . Behavior is the same as on 4.19.62 (despite minor improvements in both uplink and downlink). Welcome to Armbian Bionic with Linux 5.3.9-sunxi root@orangepipcplus:~# iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 128 KByte (default) ------------------------------------------------------------ [ 4] local 192.168.1.170 port 5001 connected with 192.168.1.1 port 24443 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.1 sec 125 MBytes 103 Mbits/sec ^Croot@orangepipcplus:~# iperf -c 192.168.1.1 ------------------------------------------------------------ Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 43.8 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.170 port 32978 connected with 192.168.1.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 258 MBytes 216 Mbits/sec g_ncm gives the same pattern, difference between uplink and downlink is bit higher. Tried connecting OrangePiZero (as mentioned before, it has the same download throughput degradation problem) as gadget to regular USB port of OrangePiPcPlus, and speed in direction OrangePiZero->OrangePiPcPlus is around 200 Mbits/sec, and OrangePiPcPlus->OrangePiZero is around 100 Mbits/sec. So networking and host USB drivers are still able to process inbound 200 Mbits/sec, and 100 Mbits/sec bottleneck is probably somewhere around otg/gadget drivers level. In the meantime, found similar problem report describing highly asymmetric speeds when using cdc_ncm. Might be the same issue but that case had been solved by moving to some NIC-specific driver Added armbianmonitor -u from 5.3.9.

What different pin? My working recipe for OV5640 + Orange Pi PC Plus + legacy kernel: fex: [csi0] vip_dev0_mname = "ov5640" Run following commands each time or add to /etc/rc.local sunxi-pio -m "PG11<1><0><1><1>" modprobe ov5640 (dmesg: [OV5640@lex]init_sensor - frame_rate: 0, max_win_size: 11) modprobe vfe_v4l2 (multiple lines in dmesg and then /dev/video0 appears) dmesg [ 207.918084] [OV5640@lex]init_sensor - frame_rate: 0, max_win_size: 11 [ 230.644298] [ISP] isp platform_id = 5! [ 230.662302] [OV5640@lex]CSI_SUBDEV_PWR_ON! [ 230.730036] [OV5640@lex]sensor_init 0x0 [ 230.768753] [OV5640@lex]CSI_SUBDEV_STBY_ON! [ 230.768764] [OV5640@lex]sensor_s_release_af [ 230.780030] [OV5640@lex]disalbe oe! [ 230.801648] [OV5640@lex]CSI_SUBDEV_STBY_OFF! [ 230.837794] [OV5640@lex]enable oe! [ 230.850068] [OV5640@lex]sensor_init 0x0 [ 230.890663] [OV5640@lex]sensor_s_ctrl id: 9963797 - value: 1 [ 230.903089] [OV5640@lex]sensor_s_vflip = 1 [ 230.903115] [OV5640@lex]sensor_s_ctrl id: 9963796 - value: 1 [ 230.915584] [OV5640@lex]sensor_s_hflip = 1 [ 230.916508] [OV5640@lex]CSI_SUBDEV_STBY_ON! [ 230.916532] [OV5640@lex]sensor_s_release_af [ 230.929022] [OV5640@lex]disalbe oe! test the capture: fswebcam -r 1600x1200 -D 3 -p YUV420P aaa.jpg

I'm using g_ether to connect OrangePiPc+ to network over USB OTG. On legacy kernel, that was giving 140 Mbits/sec IN (download from network to OrangePiPc+) and 170 Mbits/sec OUT. After upgrading to mainline kernel 4.19.62 (or 5.3.9), IN throughput degraded to 93-98 Mbits/sec (while OUT improved reaching up to 210 Mbits/sec in CDC EEM mode). This easily reproducible on both my boards OrangePiPc+ and OrangePiZero with latest Bionic images (clean installations + "modprobe g_ether iProduct="Linux-USB Ethernet/RNDIS Gadget" iManufacturer="Netchip Technology, Inc." dev_addr=02:81:05:F0:5C:24 host_addr=02:81:05:F0:5C:23 use_eem=0" ). Any ideas where is the bottleneck and how to resolve it? Tried several USB cables and USB host devices. Throughput measured by iperf; samba and nfs are showing the same. ifconfig stats indicating 0 tx/rx errors.

yes, just change module name accordingly in the second line

I was not able to change resolution on mainline, but thanks a lot for pointing to the right patch. The patch still has wrong parameters for 1024x768. After changing them to appropriate values (according to timings calculator), green box disappeared and hdmi sound becаme perfectly clear. Pull request #1013

Hello, I have following issue with HDMI resolution 1024x768. As soon as kernel starts loading, little light-green box 6x4px appears at the bottom-left corner of the screen and never goes away. The box always stays on top of everything including mouse pointer and vdpau-accelerated video, not visible on screenshots. Also HDMI sound is full of clicks in this resolution only. Other resolutions are ok. Seems that there is no problem with DVI 1024x768 (entire screen is greenish when connected by HDMI but i see that mouse pointer is visible in that area). First seen this on TV 42PC1RR which has native resolution 1024x768, also reproduced on fullhd monitor S24D390 in 1024x768 mode. Both screens work fine with other 1024x768 sources with same HDMI cables. Problem visible on latest Armbian Xenial 5.38, also on Armbian Xenial 5.24.

Faced exactly the same issue. The solution is here: