Porting OV9281 driver to 32.2

plamenk · July 31, 2019, 2:27pm

Hello,
We have developed OV9281 sensor driver for TX2, based on the NVidia’s file ov9281.c.
The driver works OK on L4T 28.2.1.

Now we have ported the driver to L4T 32.2, observing the recommendations in the documentation.
The driver probes OK, but does not stream:
v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=1
VIDIOC_DQBUF: failed: Input/output error

When we enable kernel trace, the steaming seems to start with the following errors:
v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=1

tstamp:10377528527 tag:CHANSEL_PXL_SOF channel:0x00 frame:1 vi_tstamp:10377528031 data:0x00000001
tstamp:10377528701 tag:ATOMP_FS channel:0x00 frame:1 vi_tstamp:10377528039 data:0x00000000
tstamp:10377530668 tag:CHANSEL_LOAD_FRAMED channel:0x04 frame:1 vi_tstamp:10377530309 data:0x08000000
tstamp:10377747006 tag:CHANSEL_PXL_EOF channel:0x00 frame:1 vi_tstamp:10377746347 data:0x031f0002
tstamp:10377747124 tag:ATOMP_FE channel:0x00 frame:1 vi_tstamp:10377746375 data:0x00000000

tstamp:10378620801 tag:CHANSEL_PXL_SOF channel:0x00 frame:2 vi_tstamp:10378620305 data:0x00000001
tstamp:10378620977 tag:ATOMP_FS channel:0x00 frame:2 vi_tstamp:10378620313 data:0x00000000
tstamp:10378622703 tag:CHANSEL_LOAD_FRAMED channel:0x04 frame:2 vi_tstamp:10378622340 data:0x08000000
tstamp:10378839273 tag:CHANSEL_PXL_EOF channel:0x00 frame:2 vi_tstamp:10378838622 data:0x031f0002
tstamp:10378839391 tag:ATOMP_FE channel:0x00 frame:2 vi_tstamp:10378838649 data:0x00000000
. . . . . .

Any help ?

ShaneCCC · August 1, 2019, 2:26am

The trace shows capture successfully.
R32.2 have update the sensor driver to new framework. Could you reference to ov5693 to upgrade ov9281.

plamenk · August 5, 2019, 2:35pm

Hello,
We reworked the OV9281 driver with the new framework, based on ov5693 driver.
No change:
(1) v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=1
VIDIOC_DQBUF: failed: Input/output error

[  127.617531] ov9281 2-0060: ov9281_start_streaming(): err=0
[  127.828408] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[  127.834871] tegra-vi4 15700000.vi: tegra_channel_error_recovery: attempting to reset the capture channel
[  127.844809] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) INTR_STATUS 0x0000000c
[  127.852747] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) ERR_INTR_STATUS 0x0000000c
[  128.104367] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[  128.110814] tegra-vi4 15700000.vi: tegra_channel_error_recovery: attempting to reset the capture channel
[  128.120850] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) INTR_STATUS 0x0001000e
[  128.128749] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) ERR_INTR_STATUS 0x0001000e
[  128.384313] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[  128.390778] tegra-vi4 15700000.vi: tegra_channel_error_recovery: attempting to reset the capture channel
[  128.401760] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) INTR_STATUS 0x0000000c
[  128.409754] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) ERR_INTR_STATUS 0x0000000c
[  128.664339] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[  128.670795] tegra-vi4 15700000.vi: tegra_channel_error_recovery: attempting to reset the capture channel
[  128.681068] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) ERROR_STATUS2VI_VC0 = 0x0000000c
[  128.689959] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) INTR_STATUS 0x0000000c
[  128.697933] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) ERR_INTR_STATUS 0x0000000c
[  128.944250] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[  128.950775] tegra-vi4 15700000.vi: tegra_channel_error_recovery: attempting to reset the capture channel
[  128.961940] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) INTR_STATUS 0x00000008
[  128.969897] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) ERR_INTR_STATUS 0x00000008
[  129.224254] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[  129.230724] tegra-vi4 15700000.vi: tegra_channel_error_recovery: attempting to reset the capture channel
[  129.243090] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) ERROR_STATUS2VI_VC0 = 0x0000000c
[  129.251892] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) INTR_STATUS 0x0000000c
[  129.259863] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) ERR_INTR_STATUS 0x0000000c
[  129.504279] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[  129.510753] tegra-vi4 15700000.vi: tegra_channel_error_recovery: attempting to reset the capture channel
[  129.523255] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) INTR_STATUS 0x0000000c
[  129.531200] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) ERR_INTR_STATUS 0x0000000c
[  129.581910] tegra-vi4 15700000.vi: Status:  4 channel:00 frame:0039
[  129.588351] tegra-vi4 15700000.vi:      timestamp sof 141101715072 eof 141101723488 data 0x00000200
[  129.597495] tegra-vi4 15700000.vi:      capture_id 131 stream  2 vchan  0
[  129.784261] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[  129.790844] tegra-vi4 15700000.vi: tegra_channel_error_recovery: attempting to reset the capture channel
[  129.802235] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) INTR_STATUS 0x0000000c
[  129.810128] nvcsi 150c0000.nvcsi: csi4_stream_check_status (2) ERR_INTR_STATUS 0x0000000c

(2) Enable kernel trace
(3) v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=1
<
Seems to stream OK after the kernel trace is enabled. The capture image is OK.

ShaneCCC · August 6, 2019, 2:55am

You may need to set the resolution and pixel type.

–set-fmt-video=width=1920,height=1080,pixelformat=RG10 --set-ctrl bypass_mode=0

plamenk · August 7, 2019, 9:08am

Hi ShaneCCC,

Sorry, the new command did not help.

OV9281 is a gray-scale sensor (1280x800).
We have added support for 8-bit and 10-bit gray formats “gray”, “y10” in the following kernel files:

New device-tree pixel formats in sensor_common.c:

static int extract_pixel_format(
    const char *pixel_t, u32 *format)
{
    . . .
    else if (strncmp(pixel_t, "gray", size) == 0)
        *format = V4L2_PIX_FMT_GREY;
    else if (strncmp(pixel_t, "y10", size) == 0)
        *format = V4L2_PIX_FMT_Y10;
    . . .
}

New media bus format(s) in camera_common.c:

static const struct camera_common_colorfmt camera_common_color_fmts[] = {
    . . . . . . . .
    {
        MEDIA_BUS_FMT_Y8_1X8,       // Gray 8-bit
        V4L2_COLORSPACE_RAW,
        V4L2_PIX_FMT_GREY,
    },
    {
        MEDIA_BUS_FMT_Y10_1X10,     // Gray 10-bit
        V4L2_COLORSPACE_RAW,
        V4L2_PIX_FMT_Y10,
    },
    . . . . . . . .

New tegra video format entries in vi4_formats.h:

static const struct tegra_video_format vi4_video_formats[] = {
    . . . . . . . .
    TEGRA_VIDEO_FORMAT(RAW8, 8, Y8_1X8, 1, 1, T_L8,
                RAW8, GREY, "GRAY8"),

    TEGRA_VIDEO_FORMAT(RAW10, 10, Y10_1X10, 2, 1, T_R16_I,
                RAW10, Y10, "GRAY10"),
    . . . . . . . .

These changes worked in 28.2 as expected, both for v4l2-ctl and GStreamer.
We have applied the same changes in 32.2.

Test results:
8-bit gray format: v4l2-ctl streaming crashes unless we enable kernel trace, when enabled seems OK.
GStreamer fails
10-bit gray format: v4l2-ctl streaming OK
GStreamer fails
10-bit bayer_bggr: v4l2-ctl streaming OK
GStreamer OK

Both gray level formats cause GStreamer crash with error:
gst-launch-1.0 -v nvarguscamerasrc ! fakesink
. . .
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute:521 No cameras available

The GStreamer runs OK with bayer pixel format, but instead of gray-level image it displays
color image with invalid (de-bayered) colors:
gst-launch-1.0 nvarguscamerasrc ! ‘video/x-raw(memory:NVMM),width=1280, height=800, framerate=21/1,\ format=NV12’ ! nvvidconv flip-method=0 ! ‘video/x-raw,width=640, height=400’ ! nvvidconv !\ nvegltransform ! nveglglessink -e

ShaneCCC · August 8, 2019, 2:57am

@plamenk
nvarguscamerasrc not support gray-level sensors. You can fake report as RGB sensor to try.

plamenk · August 8, 2019, 2:05pm

Tried several RGB formats, none of them works

greivin.fallas · September 2, 2019, 6:32pm

Hi plamenk,

Currently I am working on a custom OV9281 driver but I am not able to get buffers from the camera.

I tested 1280x720 and 1280x800 resolutions but there are not buffers, even on RAW10 and RAW8 modes.

I checked the frame counter register (0x4244) but its value is always zero.

Did you modify the table mode provided by Nvidia to get capture?

In my case, I haven’t modified the tables.

Regards.

plamenk · September 3, 2019, 6:54am

Hi greivin.fallas

The mode tables, defined in ov9281_mode_tbls.h, did not work with our OV9281 sensor. We had no time to investigate the problem. At present we use single mode 1280 x 800 (8-bit or 10-bit), which works OK on Jeston Nano 32.2 and with some problems on TX2, seen above.

Greetings

greivin.fallas · September 6, 2019, 2:05am

Hi plamenk,

Thanks for the answer,

Is there a possibility to try your table mode on my OV9281 camera?

Just wondering if my problem is related to a configuration issue because in my case the frame counter is always zero.

Thanks.

plamenk · September 9, 2019, 6:52am

Hi greivin.fallas,

Sorry, I can’t help you because we actually don’t write any mode table. We have FPGA, which initializes the sensor, and that was enough to use the default 1280x800 mode.

Greetings

plamenk · May 21, 2021, 7:23am

Hi jpx.dumont

Sorry, but our driver is proprietary and we can’t share it.

Greetings,
Plamen