Jump to content

rdeyes

Members
  • Posts

    5
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi, @srinath, nice to see your camera detected! I believe, media-ctl takes only '/dev/media*' devices, passing '/dev/video*' to it was a mistake. But, please, carefully read the last comment from @rreignier, he described how to take a picture. As for video recording, I had not tried it myself, but I'm sure, there are options, described in fswebcam's manual entry (after a standard ritual of './configure', 'make' and 'make install' inside cloned git repo you should have it too) for that, experiment with them. Also you can make a python/C++ program with OpenCV library and try the arguments, suggested in comment from @rreignier.
  2. Since there is no camera node on i2c2, the overlay is not loaded. It tries to access regulator nodes 'reg_vcc_af_csi', 'reg_vdd_1v5_csi' and 'reg_vcc_csi': AVDD-supply = <&reg_vcc_af_csi>; DOVDD-supply = <&reg_vdd_1v5_csi>; DVDD-supply = <&reg_vcc_csi>; And there are no such nodes in "bare" device tree, so I've added them to overlay. In your "bare" device tree, there are none either, because file 'arch/arm/boot/dts/sun8i-h3-nanopi-duo2.dts' (I'm accessing this file from the root of linux kernel source btw) does not contain any and all the .dtsi files included into it are same as for mine board. So you may need the regulators. And you may see them in my reply to @rreigner inserted as a code. So put them into your overlay .dts (I did this right before the &ccu node). And you also need to correct the regulator pins for your board the "gpio = " strings within the regulator nodes. For that you need to find your board schematics. It is a .pdf file and can be found at the very bottom of https://wiki.friendlyarm.com/wiki/index.php/NanoPi_Duo2 So here is the direct link to your schematics http://wiki.friendlyarm.com/wiki/images/a/ab/Schematic_NanoPi_Duo2-V1.0-1807.pdf At page 11 there are pins for csi camera interface. You must find AVDD, DVDD and DOVDD pins and see their names... Wait! They are not going to GPIO! On NanoPi-Duo2 they are powered on by the very default! So this is why your camera is powered on without any overlay. You're very lucky! Forget everything, I've said from the start. You don't need regulators. Delete those 3 strings (AVDD-supply, DOVDD-supply, DVDD-supply) from rreigner's overlay, so there are no unresolved links left. And then insert this new overlay (instead of the previous) and reboot. Good luck.
  3. 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.
  4. 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)
  5. Hello! Guys, I need your help! Recently I've been trying for 2 weeks to make ov5640 work on my OrangePi-PC (Armbian 21.05.0-trunk Buster with Linux 5.10.19-sunxi) and yet did not suceed. I'm currently using DeviceTree overlay: /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target-path = "/"; __overlay__ { /* DOVDD power supply. */ reg_cam_dovdd: cam-dovdd-1v8 { compatible = "regulator-fixed"; regulator-name = "cam-dovdd-1v8"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; enable-active-high; gpio = <&pio 6 13 0>; /* DOVDD: AFCC_EN: PG13, GPIO_ACTIVE_HIGH: 0 */ regulator-boot-on; regulator-always-on; }; /* AVDD power supply. */ reg_cam_avdd: cam-avdd-2v8 { compatible = "regulator-fixed"; regulator-name = "cam-avdd-2v8"; regulator-min-microvolt = <2800000>; regulator-max-microvolt = <2800000>; enable-active-high; gpio = <&pio 0 17 0>; /* AVDD: CSI_PWR_EN: PA17, GPIO_ACTIVE_HIGH: 0 */ regulator-boot-on; regulator-always-on; }; /* DVDD power supply. */ reg_cam_dvdd: cam-dvdd-1v5 { compatible = "regulator-fixed"; regulator-name = "cam-dvdd-1v5"; regulator-min-microvolt = <1500000>; regulator-max-microvolt = <1500000>; enable-active-high; gpio = <&pio 6 11 0>; /* CSI_EN: PG11, GPIO_ACTIVE_HIGH: 0 */ /* startup-delay-us = <5000>; */ /* 5ms delay. */ regulator-boot-on; regulator-always-on; }; }; }; fragment@1 { target = <&pio>; __overlay__ { csi_mclk_pin: csi-mclk-pin { pins = "PE1"; function = "csi"; }; }; }; fragment@2 { target = <&csi>; __overlay__ { 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 */ pclk-sample = <1>; /* Rising */ }; }; }; }; fragment@3 { target = <&i2c2_pins>; __overlay__ { bias-pull-up; }; }; fragment@4 { target = <&i2c2>; __overlay__ { status = "okay"; ov5640: camera@3c { compatible = "ovti,ov5640"; reg = <0x3c>; pinctrl-names = "default"; pinctrl-0 = <&csi_mclk_pin>; clocks = <&ccu 107>; /* CLK_CSI_MCLK: 107 */ clock-names = "xclk"; AVDD-supply = <&reg_cam_avdd>; DOVDD-supply = <&reg_cam_dovdd>; DVDD-supply = <&reg_cam_dvdd>; reset-gpios = <&pio 4 14 1>; /* CSI-RESET#: PE14, GPIO_ACTIVE_LOW: 1 */ powerdown-gpios = <&pio 4 15 0>; /* CSI-STBY-EN: PE15, GPIO_ACTIVE_HIGH: 0 */ port { /* Parallel bus endpoint. */ 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 */ }; }; }; }; }; }; With this overlay /dev/video1 is created, ov5640 driver loads, no complaints from driver in dmesg whatsoever, camera is powered on and I/O from /dev/video1 somehow hits the camera (I slightly modified drivers/media/i2c/ov5640.c to see in dmesg, that something is being written/read on camera registers). However, I am not able to use the camera (In my C++ application ioctl(VIDIOC_DQBUF, &buffer) function falls into endless loop, yet the same app works perfectly on my laptop with built-in camera). Also command $ v4l2-ctl -d /dev/video1 --list-ctrls shows nothing. If I enable v4l2 debug with # echo 0x1f > /sys/class/video4linux/video1/dev_debug and then try v4l2-ctl command, dmesg is spammed with VIDIOC_QUERYCTRL: error -25 ... . And if I try using my app I have VIDIOC_DQBUF: error -512 in dmesg. I've also tried applying @gsumner's solution with modified .dts file and 'assigned-*' properties within &ccu node and it gave me the same result. So I'm out of ideas, what am I doing wrong and what to do next... Please, help. And thank you in advance.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines