OV5640 camera module reg read error

[FrancisTheodoreCat]

Got my PineCube today, and ran into a snag getting the camera working.

I'm running the latest Armbian Focal build (21.02.1 on kernel 5.10.12-sunxi), and whenever I try and access the camera module, whether via ffmpeg or gstreamer, I get the following errors in the syslog:

[ 2518.009350] ov5640 1-003c: ov5640_read_reg: error: reg=300a
[ 2518.014994] ov5640 1-003c: ov5640_set_power_on: failed to read chip identifier

Also happens about 13 seconds after boot.

Checked the CSI cable, and it seems to be properly seated on both ends. Any ideas?

(I think I got the cedar hardware H264 acceleration gstreamer plugin working, but this kinda derailed any actual testing.)

[FrancisTheodoreCat]

I now get the following errors printed to the syslog when I try to access the camera via /dev/video0:

[  125.371915] i2c i2c-1: mv64xxx_i2c_fsm: Ctlr Error -- state: 0x2, status: 0x0, addr: 0x3c, flags: 0x0
[  125.381245] ov5640 1-003c: ov5640_read_reg: error: reg=300a
[  125.386847] ov5640 1-003c: ov5640_set_power_on: failed to read chip identifier

This happens regardless of kernel version, and even when using the trunk build image from the wiki, which I presume works on other PineCubes. Is this a hardware issue, or a kernel/device-tree regression? From my searches on that particular ov5640 error, it's usually a device-tree misconfiguration causing it.

I did check continuity from connector to connector for the CSI cable, and it passed. So if it were a hardware issue, it's likely the camera module itself, which I don't have a spare of to test with.

If anyone else with a working PineCube and a working copy of Armbian is willing to test, I put together a script for using the H3's Cedar H264 acceleration to serve up an HLS stream page:
https://github.com/francistheodorecatte/...mer_hls.sh

[metabenic]

I confirmed my camera is working on the Armbian image from the wiki. I tried the "gstreamer: h264 HLS" example from the wiki (software encoding) and I can see images from the camera in my browser.

Then I tried to do hardware encoding with your script, but I was unable to get it working. After following your instructions, here's what I get:

Code:

Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
Setting pipeline to PAUSED ...
0:00:01.108083798  2042  0x2665600 ERROR          cedar_h264enc gstcedarh264enc.c:340:gst_cedarh264enc_change_state: Cannot open VE
ERROR: Pipeline doesn't want to pause.
Setting pipeline to NULL ...
Freeing pipeline ...

And when I load the webpage, I get a blank screen and this in the console:

Code:

192.168.4.30 - - [15/Feb/2021 03:58:40] "GET / HTTP/1.1" 200 -
192.168.4.30 - - [15/Feb/2021 03:58:40] "GET /dist/hls.js HTTP/1.1" 200 -
192.168.4.30 - - [15/Feb/2021 03:58:41] code 404, message File not found
192.168.4.30 - - [15/Feb/2021 03:58:41] "GET /playlist.m3u8 HTTP/1.1" 404 -

Any ideas to fix the error?

[FrancisTheodoreCat]

Interesting. The blank webpage is due to gstreamer not outputting a playlist.m3u8 file for the hls.js script to pull from.

The error you're getting from gstreamer is probably due to the cedar acceleration only being able to parse NV12 or NV16 color space information, which is YUV4:2:0 and YUV4:2:2 respectively (I think). I haven't been able to test that bit, due to the camera on my PineCube... not working.

The relevant part of the script to change is this line:

media-ctl --set-v4l2 '"ov5640 1-003c":0[fmt:UYVY8_2X8/1920x1080@1/15]'

I think the format needs to be YUV420 UYVY instead of UYVU8_2X8, like so:

media-ctl --set-v4l2 '"ov5640 1-003c":0[fmt:YUVY/1920x1080@1/15]'

I'll update my script to reflect that. Can you try it out?

edit:
If that doesn't work, the pixel format will probably have to be changed to YUV422(?), and the gstreamer input format to NV16.

[metabenic]

When I tried these settings:

Code:

'"ov5640 1-003c":0[fmt:UYVY/1920x1080@1/15]'
format=NV16

I get this error:

Code:

Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
0:00:01.176724874  2396  0x1a9e640 ERROR           GST_PIPELINE grammar.y:723:gst_parse_perform_link: could not link v4l2src0 to cedarh264enc0, cedarh264enc0 can't handle caps video/x-raw, width=(int)1920, height=(int)1080, format=(string)NV16, framerate=(fraction)15/1
WARNING: erroneous pipeline: could not link v4l2src0 to cedarh264enc0, cedarh264enc0 can't handle caps video/x-raw, width=(int)1920, height=(int)1080, format=(string)NV16, framerate=(fraction)15/1

I tried various other combinations of formats but I either get the same error as before, or I get this error:

Code:

Unable to setup formats: Invalid argument (22)

[FrancisTheodoreCat]

Hm, it's probably down to the video color space format. I know the Cedar accelerator can only handle NV12 and NV16 color spaces, but I don't know what the equivalent V4L2 format is. I'll poke at it more once I get a working camera on my PineCube.

edit:
Try the updated script. I did some more reading on color space stuff, and I think I got it right. Also removed the x/raw bit of the pipeline that cedarh264enc didn't like. gstreamer now only spits out the following:

0:00:01.044829353  1974  0x1dda840 ERROR          cedar_h264enc gstcedarh264enc.c:340:gst_cedarh264enc_change_state: Cannot open VE

Along with the ever-present dmesg errors:

[ 1511.713485] ov5640 1-003c: ov5640_read_reg: error: reg=300a
[ 1511.713504] ov5640 1-003c: ov5640_set_power_on: failed to read chip identifier

I will note,  media-ctl --print-topology does show the camera on /dev/video0:

Media controller API version 5.10.0

Media device information
------------------------
driver          sun6i-csi
model          Allwinner Video Capture Device
serial         
bus info        platform:1cb4000.camera
hw revision    0x0
driver version  5.10.0

Device topology
- entity 1: sun6i-csi (1 pad, 1 link)
            type Node subtype V4L flags 0
            device node name /dev/video0
pad0: Sink
<- "ov5640 1-003c":0 [ENABLED]

- entity 5: ov5640 1-003c (1 pad, 1 link)
            type V4L2 subdev subtype Sensor flags 0
            device node name /dev/v4l-subdev0
pad0: Source
[fmt:UYVY8_2X8/1920x1080@1/15 colorspacergb xferrgb ycbcr:601 quantization:full-range]
-> "sun6i-csi":0 [ENABLED]

All I can think is the camera module, or the CSI cable, is bad. Or both.

[JuanEsf]

Hello everyone. I have not had the opportunity to try armbian with gstreamer, at the moment I am trying to compile openwrt that can consume less resources, although openwrt already starts, I still need to add the camera and video engine modules. Based on that I can say that the armbian image uses the megous kernel which has no video-engine node in dts file. Martin cerny is enabling the graphics processor in allwinner v3s and he can find the missing nodes.

Video-engine node:
https://github.com/mcerveny/linux/commit...7463be1495

dts v3s:
https://github.com/megous/linux/blob/ora...i-v3s.dtsi

dts pinecube:
https://github.com/megous/linux/blob/ora...necube.dts

My u-boot with dts changes for audio and video nodes:
https://github.com/juanesf/u-boot/blob/a...i-v3s.dtsi

[cooler]

The error you're getting from gstreamer is probably due to the cedar acceleration only being able to parse NV12 or NV16 color space information, which is YUV4:2:0 and YUV4:2:2 respectively (I think). I haven't been able to test that bit, due to the camera on my PineCube... not working.

If that doesn't work, the pixel format will probably have to be changed to YUV422(?), and the gstreamer input format to NV16.

Could anyone point me on what are these YUV, UYVY, NV16 and other abbrevations mean? What are the relations between "fmt:" media-ctl values and "video/x-raw,format=" in gstreamer pipeline?

PS. These questions are because hardware encoder only accepts *something* NV12, but camera node outputs *something* UYVY. And there is a recoding step in gstreamer pipeline consuming CPU and probably loosing FPS. While I could not find a list of supported media-ctl settings to do a bruteforce or try to understand the relation with this "format".