3 3
rreignier

OV5640 device tree overlay for OrangePi One H3

Recommended Posts

Could you please share the full step-by-step how-to enable the OV5640 camera on mainline kernel on H3 devices. Including CSI, drivers etc. Thanks in advance.

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites
On 6/21/2020 at 9:26 PM, gsumner said:

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.

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

 

16 hours ago, gsumner said:

Has anyone had success with resolutions other than 640x480?

 

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'.

 

Share this post


Link to post
Share on other sites

Wow! That's very nice!

Thanks a lot for the help.

I did not have the time to try it yet.

But for sure, a dts overlay should be pushed to armbian!

Share this post


Link to post
Share on other sites
8 hours ago, mostly said:

according to https://linux-sunxi.org/CSI


media-ctl --device /dev/media1 --set-v4l2 '"ov5640 1-003c":0[fmt:UYVY/1920x1080]'

 

@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.

Share this post


Link to post
Share on other sites
On 6/25/2020 at 10:53 PM, gsumner said:

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.

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.

Share this post


Link to post
Share on other sites

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(?). 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
3 3