rdeyes

Hello, @rreignier! Thank you very much for your advise! It worked!
 
I've completed your overlay with @gsumner's regulator nodes (I've inserted my board pins), so it loads on OrangePi-PC:
&{/} { reg_vdd_1v5_csi: vdd-1v5-csi { compatible = "regulator-fixed"; regulator-name = "vdd1v5-csi"; regulator-min-microvolt = <1500000>; regulator-max-microvolt = <1500000>; gpio = <&pio 6 13 0>; /* PG13 */ enable-active-high; regulator-boot-on; regulator-always-on; }; reg_vcc_csi: vcc-csi { compatible = "regulator-fixed"; regulator-name = "vcc-csi"; regulator-min-microvolt = <2800000>; regulator-max-microvolt = <2800000>; gpio = <&pio 6 11 0>; /* PG11 */ enable-active-high; regulator-boot-on; regulator-always-on; }; reg_vcc_af_csi: vcc-af-csi { compatible = "regulator-fixed"; regulator-name = "vcc-af-csi"; regulator-min-microvolt = <2800000>; regulator-max-microvolt = <2800000>; gpio = <&pio 0 17 0>; /* PA17 */ enable-active-high; regulator-boot-on; regulator-always-on; }; };  
And the final piece, that was missing is the forked version of fswebcam, you've mentioned today. (The regular version from apt repo gave me "black square".)
 
So, despite my C++ app with ioctls may still not working (maybe I shall try rolling back to kernel 5.8 to make it), I am at least now capable of taking pictures with scripts! (And I'll definetely try OpenCV later, I have not yet installed it.)
 
So, big, BIG THANK YOU!!!
 
P.S. I've noticed one small weird thing:
The overlay I've posted in my previous comment now fails with 'ov5640_check_chip_id: failed to read chip identifier', as if it failed to power the camera on. And, I swear, it did not before trying your solution. (I never used both overlays simultaniously, so, I think, something else gets modified... maybe, by the forked fswebcam)

@MikePooh, I think there's still some schematic-reading involved at the moment, if you're willing to do that though it should be do-able. I don't know anything about other boards yet so this is the process followed. I think for "it just works" you'll need to wait a bit more. I'm assuming a lot here, e.g. active high and fixed-voltage gpio-switched regulators, so there is risk in following this.

The first step is getting i2c working, the driver won't be able to do anything until you can communicate with the camera. I'll use the h5 in my Orange Pi Zero Plus2 as an example but I believe the process should be identical for h3 boards. Looking at the schematic (https://linux-sunxi.org/images/f/f6/ORANGE_PI-ZERO-PLUS2_V1_0.pdf), on page 9 is the csi connector. We want AFCC_EN, CSI_EN and CSI-PWR-EN to be '1' to power the camera. They might be named differently on different boards, but generally you're looking for the ones that aren't connected to pins (on page 6,  chip U1D) with a CSI_* function (e.g. PE9/CSI_D5/TS_D5). I'm looking for AFCC_EN and CSI-PWR-EN which link to page 6. So AFCC_EN comes from pin PA7/SIM_CLK/PA_EINT7 and CSI-PWR-EN from PA8/SIM_DATA/PA_EINT8. We need to remember those PXX numbers.
 
rreignier said their camera was on the i2c1 bus, so we need to confirm that too. Following CSI-SCK and CSI-SDA from page 9 to page 6 reveals the i2c interface. CSI-SCK for me connects to "PE12/CSI_SCK/TWI2_SCK" and CSI-SDA to "PE13/CSI_SDA/TWI2_SDA". Maybe someone can confirm, but I think TWIx_SDA equals I2Cx. You can test by enabling the i2c bus overlays one after the other and running i2cdetect while measuring with a multimeter on low range (200mv) A/C voltage between ground and the SCK pin on the camera connector - the correct bus will generate a voltage for a short while. We need to remember that bus number.

Note the reset-gpios and powerdown-gpios the same way.

Next is the change to the device tree. In Armbian checkout the linux source  with "apt install linux-source-<kernel version>-current-sunxi" (or linux-source-<kernel version>-current-sunxi64 for h5) which will leave you with a tar in /usr/src of your kernel source. extract it (do it in a new folder or it will trash your current one) and then copy your kernel config in (cp /boot/config-* ./.config). Edit your .dts (./arch/arm/boot/dts/ for h3, ./arch/arm64/boot/dts/allwinner/ for h5) in line with my previous comment, swapping in your values for regulators, i2c bus and reset/powerdown. for a quick bodge, which pin goes in which regulator doesn't actually matter - my change just forced them all on anyway. As lex said, there's supposed to be an order, my change doesn't respect that order but it has worked so far. Then run "make dtbs" from the top level of the kernel source. That should produce a .dtb file in the same folder as the .dts.

backup your current dtb and copy the new one to /boot/dtb/allwinner/*.dtb (that's the h5 path, not sure of the h3 path sorry, might be /boot/dtb/). I think you can alternatively specify this as fdtfile in the armbianEnv.txt. The armbianEnv.txt way will probably survive an update better.

Finally, add a line to /etc/modules that says ov5640. Reboot and you might be good to go. If you don't have a /dev/video0 device we'll have to debug.

Obviously if I've got something wrong feel free to chip in.

Has anyone had success with resolutions other than 640x480? The driver seems to have some code for it, but I haven't gotten anything to work.

@rreignier, I've just gotten an ov5640 going with my Orange Pi Zero Plus2 at 640x480 on mainline, Buster 5.4.43 - maybe the following applies to you too.

I had bus locked errors until I powered up the camera, on the Zero it was PA8 and PA7 for autofocus (which I turned on just in case). Looking at the One schematic (https://linux-sunxi.org/images/7/7e/ORANGE_PI-ONE-V1_1.pdf) it looks like it's PA17, PG11 and PG13 for autofocus.

After that I still wasn't getting an answer on i2c2, the ov5640 datasheet (https://cdn.sparkfun.com/datasheets/Sensors/LightImaging/OV5640_datasheet.pdf) says XVCLK (CLK_CSI_MCLK in the device tree) needs to be running before accessing registers. I couldn't see an a/c voltage on the csi-mclk pin so figured that was the issue. The fix for me was connecting the clock parent in the device tree. I'll post my dtb changes. I'm not sure this is all correct, but it lets me open the camera without having to mess with any gpios etc after boot.

Inside the "model = "OrangePi Zero Plus2";" braces:
reg_vdd_1v5_csi: vdd-1v5-csi { compatible = "regulator-fixed"; regulator-name = "vdd1v5-csi"; regulator-min-microvolt = <1500000>; regulator-max-microvolt = <1500000>; gpio = <&pio 0 8 GPIO_ACTIVE_HIGH>; /* PA8 */ enable-active-high; regulator-boot-on; regulator-always-on; }; reg_vcc_csi: vcc-csi { compatible = "regulator-fixed"; regulator-name = "vcc-csi"; regulator-min-microvolt = <2800000>; regulator-max-microvolt = <2800000>; gpio = <&pio 0 8 GPIO_ACTIVE_HIGH>; /* PA8 */ enable-active-high; regulator-boot-on; regulator-always-on; }; reg_vcc_af_csi: vcc-af-csi { compatible = "regulator-fixed"; regulator-name = "vcc-af-csi"; regulator-min-microvolt = <2800000>; regulator-max-microvolt = <2800000>; gpio = <&pio 0 7 GPIO_ACTIVE_HIGH>; /* PA7 */ enable-active-high; regulator-boot-on; regulator-always-on; }; At top level:
&ccu { /* Use a stable clock source with known fixed rate for MCLK */ assigned-clocks = <&ccu CLK_CSI_MCLK>; assigned-clock-parents = <&osc24M>; assigned-clock-rates = <24000000>; }; &csi { status = "okay"; port { #address-cells = <1>; #size-cells = <0>; /* Parallel bus endpoint */ csi_ep: endpoint { remote-endpoint = <&ov5640_ep>; bus-width = <8>; hsync-active = <1>; /* Active high */ vsync-active = <0>; /* Active low */ data-active = <1>; /* Active high */ pclk-sample = <1>; /* Rising */ }; }; }; &i2c2_pins { bias-pull-up; }; &i2c2 { status = "okay"; ov5640: camera@3c { compatible = "ovti,ov5640"; reg = <0x3c>; pinctrl-names = "default"; pinctrl-0 = <&csi_mclk_pin>; clocks = <&ccu CLK_CSI_MCLK>; clock-names = "xclk"; AVDD-supply = <&reg_vcc_af_csi>; DOVDD-supply = <&reg_vdd_1v5_csi>; DVDD-supply = <&reg_vcc_csi>; reset-gpios = <&pio 4 14 GPIO_ACTIVE_LOW>; /* CSI-RST-R: PE14 */ powerdown-gpios = <&pio 4 15 GPIO_ACTIVE_HIGH>; /* CSI-STBY-R: PE15 */ port { ov5640_ep: endpoint { remote-endpoint = <&csi_ep>; bus-width = <8>; data-shift = <2>; /* lines 9:2 are used */ hsync-active = <1>; /* Active high */ vsync-active = <0>; /* Active low */ data-active = <1>; /* Active high */ pclk-sample = <1>; /* Rising */ }; }; }; }; I also added csi_mclk_pin to sunxi-h3-h5.dtsi (after "csi_pins: csi-pins {") but I suspect you could reference the pin directly in the dtb and skip this:
/omit-if-no-ref/ csi_mclk_pin: csi-mclk-pin { pins = "PE1"; function = "csi"; }; I'm currently having issues with only being able to use 640x480, vlc reporting incorrect frame size and crashes when streaming from motion, but I don't want to derail your thread unless you have the same issues.

Hope that helps,
Greg

Hi @rdeyes
 
On an Orange Pi One (which might be close to your Orange Pi PC), I have managed to get the OV5640 thanks to the amazing work of the contributors of this thread.
 
Last time I have tried was on Armbian 20.08.17 with Linux 5.8.16.
 
The device tree overlay I use is this one (you may have to change some pins) :
/dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; }; &ccu { assigned-clocks = <&ccu 107>; assigned-clock-parents = <&osc24M>; assigned-clock-rates = <24000000>; }; &pio { csi_mclk_pin: csi-mclk-pin { pins = "PE1"; function = "csi"; }; }; &i2c2_pins { bias-pull-up; }; &i2c2 { status = "okay"; ov5640: camera@3c { compatible = "ovti,ov5640"; reg = <0x3c>; pinctrl-names = "default"; pinctrl-0 = <&csi_mclk_pin>; clocks = <&ccu 107>; clock-names = "xclk"; AVDD-supply = <&reg_vcc_af_csi>; DOVDD-supply = <&reg_vdd_1v5_csi>; DVDD-supply = <&reg_vcc_csi>; reset-gpios = <&pio 4 14 1>; /* CSI-RST-R: PE14 */ powerdown-gpios = <&pio 4 15 0>; /* CSI-STBY-R: PE15 */ port { ov5640_ep: endpoint { remote-endpoint = <&csi_ep>; bus-width = <8>; data-shift = <2>; /* lines 9:2 are used */ hsync-active = <1>; /* Active high */ vsync-active = <0>; /* Active low */ data-active = <1>; /* Active high */ pclk-sample = <1>; /* Rising */ }; }; }; }; &csi { status = "okay"; port { #address-cells = <1>; #size-cells = <0>; csi_ep: endpoint { remote-endpoint = <&ov5640_ep>; bus-width = <8>; hsync-active = <1>; /* Active high */ vsync-active = <0>; /* Active low */ data-active = <1>; /* Active high */ pclk-sample = <1>; /* Rising */ }; }; };  
To enable it, I use this command:
sudo armbian-add-overlay csi-ov5640.dts And then, to take a picture:
media-ctl --device /dev/media1 --set-v4l2 '"ov5640 1-003c":0[fmt:JPEG_1X8/1920x1080]' fswebcam -d /dev/video0 -r 1920x1080 -D 0 --jpeg 100 /tmp/test.jpg  
I hope this can help you and others.

I do not have the board with me right now, I will try later.
 
But yesterday, after a system update to Linux 5.10, the camera switched to /dev/video1 and I had to use this fork of fswebcam with these commands:
$ media-ctl --device /dev/media1 --set-v4l2 '"ov5640 1-003c":0[fmt:YUYV8_2X8/1280x720]' $ ./fswebcam --displayfps 1 -S 30 -d /dev/video0 -r 1280x720 -p YUV420P - > /tmp/cam_1280x720_yuv420p.jpg  
And for reference, to use it with OpenCV I had to specify the size and format:
#include <iostream> #include <opencv2/opencv.hpp> int main(int, char**) { VideoCapture cap; cap.open(1, CAP_V4L2); if (!cap.isOpened()) { cerr << "ERROR! Unable to open camera\n"; return -1; } cap.set(cv::CAP_PROP_FRAME_WIDTH, 1280); cap.set(cv::CAP_PROP_FRAME_HEIGHT, 720); cap.set(cv::CAP_PROP_FOURCC, cv::VideoWriter::fourcc('Y','U','1','2')); Mat frame; // The first images might be black so take several before for(size_t i = 0; i < 10; ++i) { cap >> frame; } if (frame.empty()) { cerr << "ERROR! blank frame grabbed\n"; return -1; } imwrite("/tmp/opencv_frame.jpg", frame); return 0; }  

Hi @srinath,
I think, there are two possibilities:
 
1. Your overlay is compiled, but not loaded. This may happen, because it tries to access nodes, that are not described. Neither within itself, nor within the device tree.
 
To check, whether it is loaded, you should inspect '/proc/device-tree'. The best way to start is
$ ls /proc/device-tree/__symbols__/ And there must be an 'i2c2' file, containing a string path to dt-node (in my case '/soc/i2c@1c2b400').
 
So now, you need to check out this node. Like I do on my system (+ rreigner's overlay with my completion)
$ ls /proc/device-tree/soc/i2c@1c2b400/ '#address-cells' camera@3c clocks compatible interrupts name phandle pinctrl-0 pinctrl-names reg resets '#size-cells' status $ cat /proc/device-tree/soc/i2c@1c2b400/status okay $ cat /proc/device-tree/soc/i2c@1c2b400/reg | xxd 00000000: 01c2 b400 0000 0400 ........ $ ls /proc/device-tree/soc/i2c@1c2b400/camera@3c/ AVDD-supply clock-names clocks compatible DOVDD-supply DVDD-supply name phandle pinctrl-0 pinctrl-names port powerdown-gpios reg reset-gpios Some files may contain gibberish, that may be resolved by piping them to xxd.
 
2. If the previous test is fine (status contains "okay" and camera@3c child node present), your i2c2 bus may just not end up as /dev/i2c-2! (I have this situation on my OrangePi-PC.)
So it is present and works fine, but it's adapter has a different number and a different name. You just need to know it and pass it's "nickname" to i2c-detect.
So you can list all i2c adapters on your system like this:
$ ls /dev/i2c-* /dev/i2c-0 /dev/i2c-1 /dev/i2c-2  
And you can access their system interface via '/sys/class/':
$ ls /sys/class/i2c-adapter/ i2c-0 i2c-1 i2c-2 $ ls -l /sys/class/i2c-adapter/i2c-*/of_node lrwxrwxrwx 1 root root 0 Mar 17 14:08 /sys/class/i2c-adapter/i2c-1/of_node -> ../../../../../firmware/devicetree/base/soc/i2c@1c2b400 lrwxrwxrwx 1 root root 0 Mar 17 14:09 /sys/class/i2c-adapter/i2c-2/of_node -> ../../../../../firmware/devicetree/base/soc/i2c@1f02400 So, most of i2c adapters have of_node within their system interface, which is a symlink to their dt-node. Remember, how my i2c2 dt-node was called? '/soc/i2c@1c2b400'. And this is an of_node of i2c-1 adapter!
 
So to probe my i2c2 I need to tell i2cdetect to check '/dev/i2c-1':
# i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- And see camera activity on address 3c, as expected.
 
Hope, this helps
 
Upd. Now since @srinath edited comment, mine looks not related.