gsumner

Validating
  • Content Count

    4
  • Joined

  • Last visited

About gsumner

  • Rank
    Newbie

Recent Profile Visitors

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

  1. I think I understand that media-ctl is setting the resolution/format (or group of formats) that will be able to be successfully opened by a program. I'm confused by the media-ctl, v4l2-ctl and program order of operations though, it seems like you have to run your program first, see it fail, run v4l2-ctl -V to see the (last?) format it tried to open, then you go back and set something compatible with media-ctl and try again... is that correct? Surely it should see what the program is asking for and reconfigure itself? With fswebcam (which seems to want JPEG format), running: media-ctl --device /dev/media0 --set-v4l2 '"ov5640 2-003c":0[fmt:JPEG_1X8/1920x1080]' fswebcam -d /dev/video0 -r 1920x1080 -D 0 --jpeg 100 /tmp/test.jpg there's a weird issue where 1 in 3 or 4 images has a green tinge. All the detail is there, just greenish. Does anyone have the same issue? I'm also having an issue with vlc, it seems to want planar yuv (YUYV8_2X8), but I can't get a successful stream out of it. cvlc complains "rawvideo decoder warning: invalid frame size (3110400 < 4665600)", which agrees with the "Size Image" field of v4l2-ctl -V. I wonder if the frame size error is related to the green/purple image problem or separate, 3110400 means 12bit/pixel while 4665600 is 18bit/pixel. The format and v4l2-ctl -V agree on 3110400 so I wonder where 4665600 comes from... and I also don't understand how to differentiate yuv422 and yuv420 from media-ctl --known-mbus-fmts. @mostly, ISP CONTROL 03 "Draw window for AFC enable" looks interesting for autofocus. I might try enabling that to see what happens. I wonder if the autofocus is a oneshot thing that the driver would need to fire off every time or constantly focusing. I'm also having the same issues with YUV green/purple images that you mention, if you run ffmpeg with "-input_format mjpeg" you can at least get back to the "green tinge" problem. I tried signing the driver I built previously with the keys I found in the Linux source package but I keep getting exec format error, I was hoping to avoid rebuilding the whole kernel. Are the signing keys available? Maybe that defeats the purpose of keys though! I guess if swapping between mjpeg and yuv is only reconfiguring the soc and not the camera module itself then we should look at sun6i_csi for these format and frame size issues(?).
  2. @mostly awesome, thanks! I tried a couple others for anyone else wondering. e.g.: media-ctl --device /dev/media0 --set-v4l2 '"ov5640 2-003c":0[fmt:JPEG_1X8/1920x1080]' v4l2-ctl --set-fmt-video=width=1920,height=1080,pixelformat=JPEG fswebcam -d /dev/video0 -r 1920x1080 -D 0 --jpeg 100 /tmp/test.jpg The colour balance and noise are terrible, but it's a start! I see there's something in media-ctl to change colourspace, but it's the first time I've heard of media-ctl and I've got no idea what I'm doing yet. Still no luck with 2592x1944 which I'd like to get going though. @jgauthier I'm not sure you need a bitbang i2c, the schematic for your board (https://drive.google.com/drive/u/0/folders/0B4PAo2nW2KfnflVqbjJGTFlFTTd1b1o1OUxDNk5ackVDM0RNUjBpZ0FQU19SbDk1MngzZWM?tid=0B4PAo2nW2Kfndjh6SW9MS2xKSWs) says they connect to TWI2. If the TWIx == I2Cx thing holds, I2C2 might work for you(?). It looks like CSI-PWR-EN controls all the power to your camera too, that net might be strongly pulled-up next to U9 too. So maybe try enable PD14 for your regulator and I2C2 for the bus.
  3. @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.
  4. @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