L4T 24.2 Rasperry Pi CSI camera driver debug

Autonomous Machines Jetson & Embedded Systems Jetson TX1
1

I’ve been working on interfacing with the Raspberry Pi Camera Version 2 (IMX219).

It’s tricky when I don’t have the datasheet, it’s not available online so through a combination of using a Logic Analyzer on the I2C bus on the Raspberry Pi Camera and reviewing a lot of different drivers I think I have figured out most of the registers. If anyone is interested I’ll put a register map up.

I’ve written a driver and can interact with it through yavta and v4l2-ctl but I seem to be running into errors that are challenging to track down. I’m hoping to get some help understanding what some of these errors are to help me plan for my next steps.

I am new to working with cameras so I have some general questions:

  1. Is vi2 the video interface driver?
  2. What is SCF?
  3. What is the ‘Group Delay’ setting for v4l2?
  4. What is the ‘Coarse Time’ setting for v4l2?
  5. What is the ‘Frame Length’ setting for v4l2?
  6. I have a suspicion that the CSI from the camera is not being detected by the TX1. Mostly because of these two lines from dmesg:
[  618.607844] tegra_mipi_cal 700e3000.mipical: Mipi cal timeout,val:58a1, lanes:100000
[  618.808450] video4linux video0: frame start syncpt timeout!0

Is this correct? If so I’ll find a gigahertz scope to look at these signals to determine how clean these signals really are.

Also, I’ll look through the TRM but just in case the signals are attenuated are there any registers that adjust the receiver equalization and envelope threshold detectors of the CSI interface of the TX1?

To put things into context here is the full dmesg dump of the camera interaction with the following command:

v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 --stream-to=data.raw

[ 3856.667480] imx219 6-0010: imx219_power_on: power on
[ 3856.675504] imx219 6-0010: camera_common_try_fmt: size 1920 x 1080
[ 3856.675515] imx219 6-0010: camera_common_try_fmt: got controls from v4l2_g_ctrl
[ 3856.675523] imx219 6-0010: camera_common_try_fmt: Using Sensor Mode: 0
[ 3856.675532] imx219 6-0010: camera_common_try_fmt: invalid resolution supplied(set mode) 1920 1080 0
[ 3856.675539] imx219 6-0010: camera_common_try_fmt: size 1920 x 1080
[ 3856.675545] imx219 6-0010: camera_common_try_fmt: got controls from v4l2_g_ctrl
[ 3856.675551] imx219 6-0010: camera_common_try_fmt: Using Sensor Mode: 0
[ 3856.675557] imx219 6-0010: camera_common_try_fmt: invalid resolution supplied(set mode) 1920 1080 0
[ 3856.714923] imx219 6-0010: imx219_s_stream++
[ 3856.746309] imx219 6-0010: imx219_set_gain++
[ 3856.746333] imx219 6-0010: imx219_set_gain: val: 0
[ 3856.746617] imx219 6-0010: imx219_set_frame_length: val: 4000
[ 3856.747496] imx219 6-0010: imx219_set_coarse_time: val: 2000
[ 3856.748366] imx219 6-0010: imx219_s_stream: Coarse Time: 2000
[ 3856.748383] imx219 6-0010: imx219_s_stream: Starting stream
[ 3856.757703] tegra_mipi_cal 700e3000.mipical: Mipi cal timeout,val:58a1, lanes:100000
[ 3856.958043] video4linux video0: frame start syncpt timeout!0
[ 3856.977565] tegra_mipi_cal 700e3000.mipical: Mipi cal timeout,val:58a1, lanes:100000
[ 3857.177955] video4linux video0: frame start syncpt timeout!0
[ 3857.393117] video4linux video0: frame start syncpt timeout!0
[ 3857.598139] video4linux video0: frame start syncpt timeout!0
[ 3857.798216] video4linux video0: frame start syncpt timeout!0
[ 3858.007949] video4linux video0: frame start syncpt timeout!0
[ 3858.027464] tegra_mipi_cal 700e3000.mipical: Mipi cal timeout,val:58a1, lanes:100000
[ 3858.228389] video4linux video0: frame start syncpt timeout!0
[ 3858.438545] video4linux video0: frame start syncpt timeout!0
[ 3858.648422] video4linux video0: frame start syncpt timeout!0
[ 3858.858489] video4linux video0: frame start syncpt timeout!0
[ 3858.867940] tegra_mipi_cal 700e3000.mipical: Mipi cal timeout,val:58a1, lanes:100000
[ 3859.068336] video4linux video0: frame start syncpt timeout!0
[ 3859.277919] video4linux video0: frame start syncpt timeout!0
[ 3859.478115] video4linux video0: frame start syncpt timeout!0
[ 3859.688168] video4linux video0: frame start syncpt timeout!0
[ 3859.695078] imx219 6-0010: imx219_s_stream++
[ 3859.723818] imx219 6-0010: imx219_power_off: power off
  1. Why is it that when I set the image size 1920x1080 I see this from the camera_common_try_fmt function.
[ 3856.675539] imx219 6-0010: camera_common_try_fmt: size 1920 x 1080
[ 3856.675545] imx219 6-0010: camera_common_try_fmt: got controls from v4l2_g_ctrl
[ 3856.675551] imx219 6-0010: camera_common_try_fmt: Using Sensor Mode: 0
[ 3856.675557] imx219 6-0010: camera_common_try_fmt: invalid resolution supplied(set mode) 1920 1080

It’s strange because my /drivers/media/i2c/imx219_mode_tbls.h

has this structure:

static const struct camera_common_frmfmt imx219_frmfmt[] = {
// Frame Size,    Framerates??,   Num Framerates, HDR Enable,  Mode
  {{1920,1080},   imx219_30fps,   3,              0,           IMX219_MODE_1920X1080     },
  {{1280,720},    imx219_60fps,   4,              0,           IMX219_MODE_1280X720      },
  {{640,480},     imx219_60fps,   4,              0,           IMX219_MODE_640X480       },
};

hmm looking at the camera_common.c it looks like I need to place the highest framerate at the top of the imx21_XXfps structures, currently I have them in lowest framerate to highest.

...

    for (i = 0; i < s_data->numfmts; i++) { 
      if (mf->width == frmfmt[i].size.width &&
          mf->height == frmfmt[i].size.height &&
          mf->maxframerate == frmfmt[i].framerates[0] &&                                                               
          hdr_en == frmfmt[i].hdr_en) {
          s_data->mode = frmfmt[i].mode;                                                                               
          s_data->fmt_width = mf->width;
          s_data->fmt_height = mf->height;
          s_data->fmt_maxfps = mf->maxframerate;                                                                       
          break;                                                                                                       
      }                                                                                                                
    } 

...

Is this correct?

Thanks for any help,

Dave

2

We are very interested in multiple Pi cameras for TX1. Did you make your adapter card or use the card (J20) from auvidea?

https://devtalk.nvidia.com/default/topic/961159/jetson-tx1/multiple-csi-cameras-on-one-jetson-tx1-dev-board/

I assume Pi camera V1 has the same interface as V2, will it be easier to use V1 camera for driver development/debugging? OV5647 full data sheet and other resources are available.

3

@yahoo2016

You have a good point. If the ov5647 datasheet is available it would make life a lot easier.

Thanks for the idea. Who knows, maybe working with that sensor will give me some insight to the imx219.

Dave

4

You can ask for the datasheet to Sony, they gave it to us. Trying to guess the registers is not the best path to follow.

5

@DavidSoto, Then you have better contacts than I do.

I tried to get in contact with Sony but I could only get in contact with a distributor and when asked about the IMX219, here was their reply:

“…Regarding the IMX219, as this is a consumer type of sensor used for smartphones and tablets, there is a high volume threshold (hundreds of thousands to millions of units per year) to gain access. …”

I do agree with what you say, guessing registers it never a good thing but I didn’t have a choice.

6

We are creating the driver for several customers, I will keep you updated with the progress. Also try looking for reference implementations on the web for other systems, that will give you a good reference on which registers you have to use.

7

If you have not found OV5647 full data sheet, it can be downloaded from here:

8

OV5647 Update

It took me a little while to adapt the kernel to use the OV5647.

I used my Saleae to capture the I2C transactions between the Raspberry PI and the OC5647.

If anyone’s interested here are a record of just the I2C transactions exported to CSV files.

OV5647: Configuring the camera for 1920 x 1080
http://www.cospandesign.com/images/uploaded/OV5647%201920%201080.csv

OV5647: Configuring the camera for 1280 x 720
http://www.cospandesign.com/images/uploaded/OV5647%201280%20720.csv

OV5647: Configuring the camera for 640 x 480
http://www.cospandesign.com/images/uploaded/OV5647%20640%20480.csv

I analyzed the 1920 x 1080 using the datasheet to figure out how the Raspberry Pi configured the camera:
http://www.cospandesign.com/images/uploaded/ov5647_1920_1080_analysis.txt

It’s unfortunate there seems to be some undocumented registers.

Different Output

After I wrote the driver I’ve seen different results. Instead of this constantly repeating on the serial console:

[ 1170.969351] tegra_mipi_cal 700e3000.mipical: Mipi cal timeout,val:58a1, lanes:100000
[ 1171.178674] video4linux video0: frame start syncpt timeout!0

I see only this:

[ 76.712594] video4linux video0: frame start syncpt timeout!0

When running nvcapture on the a terminal I see this:

Encoder Profile = Baseline
Inside NvxLiteH264DecoderLowLatencyInitNvxLiteH264DecoderLowLatencyInit set DPB and MjstreamingInside NvxLiteH265DecoderLowLatencyInitNvxLiteH265DecoderLowLatencyInit set DPB and Mjstreaming
Available Sensor modes :
1920 x 1080 FR=30.000000 CF=0x1009208a10 SensorModeType=4 CSIPixelBitDepth=10 DynPixelBi[ 69.624810] ov5647 6-0036: could not find device ctrl.
tDepth=10
1280 x 720 FR=60.000000 CF=0x1009208a10 SensorModeType=4 CSIPixelBitDepth=10 DynPixelBitDepth=10
** Message: <main:5184> iterating capture loop ....

NvCameraSrc: Trying To Set Default Camera Resolution. Selected 1280x720 FrameRate = 30.000000 ...

Framerate set to : 30 at NvxVideoEncoderSetParameterNvMMLiteOpen : Block : BlockType = 4
===== MSENC =====
NvMMLiteBlockCreate : Block : BlockType = 4
[ 71.198330] nvmap_alloc_handle: PID 1754: nvgstcapture: WARNING: All NvMap Allocations must have a tag to identify the subsystem allocating memory.Plase pass the tag to the API call NvRmMemHanldeAllocAttr() or relevant.
[ 72.718031] pgd = ffffffc0c8126000
[ 72.721649] [0000000c] *pgd=000000014812a003, *pmd=0000000000000000
[ 72.728191] Library at 0x7f8f953428: 0x7f8f88f000 /usr/lib/aarch64-linux-gnu/tegra/libscf.so
[ 72.736653] Library at 0x7f8f953424: 0x7f8f88f000 /usr/lib/aarch64-linux-gnu/tegra/libscf.so
[ 72.746689] vdso base = 0x7f90015000
Received error from camera daemon....exiting....
Socket read error. Camera Daemon stopped functioning.....

when I output dmesg I see a lot of debug data but in particular I see this:

[ 166.718953] ov5647 6-0036: camera_common_try_fmt: size 1920 x 1080
[ 166.718963] ov5647 6-0036: camera_common_try_fmt: got controls from v4l2_g_ctrl
[ 166.718969] ov5647 6-0036: could not find device ctrl.
[ 168.277441] nvmap_alloc_handle: PID 1822: nvgstcapture: WARNING: All NvMap Allocations must have a tag to identify the subsystem allocating memory.Plase pass the tag to the API call NvRmMemHanldeAllocAttr() or relevant.
[ 168.277896] fence timeout on [ffffffc0da681840] after 1500ms
[ 168.277899] fence timeout on [ffffffc0d36d5b40] after 1500ms
[ 168.277901] name=[8:isp.0_0], current value=0 waiting value=1
[ 168.277903] name=[30:vi_4], current value=0 waiting value=1
[ 168.277906] ---- mlocks ----
[ 168.277907] ---- mlocks ----

[ 168.277942] ---- syncpts ----
[ 168.277943] ---- syncpts ----
[ 168.277958] id 5 (gpu.0_506) min 2944 max 2944 refs 1 (previous client : )
[ 168.277962] id 6 (gpu.0_505) min 14 max 14 refs 1 (previous client : )
[ 168.277966] id 7 (gpu.0_503) min 1774 max 1774 refs 1 (previous client : gpu.0_503)
[ 168.277969] id 8 (isp.0_0) min 0 max 3 refs 4 (previous client : )
[ 168.277973] id 9 (isp.0_1) min 0 max 3 refs 4 (previous client : )
[ 168.277978] id 11 (isp.0_2) min 9 max 18 refs 11 (previous client : )
[ 168.277982] id 12 (isp.0_3) min 0 max 3 refs 4 (previous client : )
[ 168.277989] id 15 (isp.1_2) min 1 max 1 refs 1 (previous client : )
[ 168.277994] id 17 (gpu.0_501) min 1046 max 1046 refs 1 (previous client : )
[ 168.277998] id 18 (gpu.0_500) min 2 max 2 refs 1 (previous client : )
[ 168.278001] id 19 (gpu.0_499) min 2 max 2 refs 1 (previous client : )
[ 168.278005] id 20 (gpu.0_498) min 2 max 2 refs 1 (previous client : )
[ 168.278008] id 21 (gpu.0_497) min 2 max 2 refs 1 (previous client : )
[ 168.278011] id 22 (gpu.0_496) min 2 max 2 refs 1 (previous client : )
[ 168.278015] id 23 (vi_0) min 0 max 3 refs 4 (previous client : vi_0)
[ 168.278021] id 25 (vi_2) min 2 max 7 refs 7 (previous client : vi_2)
[ 168.278032] id 30 (vi_4) min 0 max 3 refs 4 (previous client : vi_4)
[ 168.278043] id 35 (gpu.0_495) min 6 max 6 refs 1 (previous client : )
[ 168.278046] id 36 (gpu.0_494) min 6 max 6 refs 1 (previous client : )
[ 168.278052] id 38 (gpu.0_493) min 6 max 6 refs 1 (previous client : )
[ 168.278055] id 39 (gpu.0_492) min 8 max 8 refs 1 (previous client : )
[ 168.278059] id 40 (gpu.0_491) min 6 max 6 refs 1 (previous client : )
[ 168.278062] id 41 (gpu.0_490) min 6 max 6 refs 1 (previous client : )
[ 168.278065] id 42 (gpu.0_489) min 6 max 6 refs 1 (previous client : )

I’m not 100% sure but it seems as though there are some syncpts detected. Is this the case?

What does this mean?

nvmap_alloc_handle: PID 1822: nvgstcapture: WARNING: All NvMap Allocations must have a tag to identify the subsystem allocating memory.Plase pass the tag to the API call

Scope Signals

I finally got in touch with a very generous group that let me use their nice oscilloscope.

1024×784 84.2 KB

1024×784 99.6 KB

I attached the differential probes on the bottom side of the circuit board on the exposed vias for the differential clock and lane 0 of the data right underneath the TX1 connector. I was hoping to at least see the start of frame tokens (LP01) and it looks like it’s there but the actual high speed signal looks pretty bad (Please correct me if I’m wrong).

Unfortunately I didn’t have much time so I couldn’t run through all the tests I wanted to do. I also felt uncomfortable about removing the 50Ohm load on their differential probes so I think the extra 50 ohm load accounts for the amplitude attenuation of the clock (68mv pp).

If anyone is interested there are some other captures here:
http://www.cospandesign.com/images/uploaded/

The traces are 100ohm differential impedance but there does seem to be a low pass effect that is really attenuating things. I just got back to start analyzing everything, I was going to see if there are some equalizer configuration registers within the TX1 register set or perhaps some emphasis settings within the camera.

If anyone has any suggestions they would be welcome.

Answer to some questions

If anyone is interested in answers to at least some of the questions I asked above:

  1. Is vi2 the video interface driver? It’s the video interface sub system
  2. What is the ‘Group Delay’ setting for v4l2? I think this is a way to write a bunch of registers at once.
  3. What is the ‘Coarse Time’ setting for v4l2? I think This is the exposure time of the image. I’m curious why it’s called the Coarse Time and why there is a Coarse Time and Coarse Time Short??

V4L2_CID_COARSE_TIME
V4L2_CID_COARSE_TIME_SHORT

Hopefully we can capture an image soon.

Dave

9

Great work! I’d like to get Pi camera to TX1 adapters and start to develop multi camera applications. Do you make your adapter or purchase from somewhere?

10

I am working with a client on this board and after a demo we are planning to make the boards available. I’ll let you know when we can do this.

Regarding the drivers, I’ve made a branch of the kernel on my public github account:

[url]https://github.com/CospanDesign/nvidia-tx1-kernel[/url]

The notable differences for the ov5647 are in:

driver/media/i2c/ov5647.c
driver/media/i2c/ov5647_mode_tbls.h
include/media/ov5647.h

If anyone can give any feedback I would be very grateful.

Dave

11

I’ll get Auvidea J20 or J100 ASAP and try ov5647s with you code.

12

You can find some instructions for the J20 here:

13

I hope we can just buy the camera adapter/driver in source or binary listed as off-the-shelf package like those:

https://www.leopardimaging.com/TX1_Camera_Kit.html

rather than getting quotes as custom products.

14

Hi yahoo2016. RidgeRun is a software only company, we don’t do hardware. So in case of the kit you should be able to buy the J20 adapter from auvidea and the camera sensor can be anyone that you would like to pick if it shares the same pins-interfaces than the raspberry pi - btw you can buy it from here: http://www.mcmelectronics.com/product/RASPBERRY-PI-RPI-8MP-CAMERA-BOARD-/28-21440

Once we get the driver in place we make the wiki page public with example pipelines and we always with the source code for our drivers to our customers so you can enhance it or customise it if needed.

15

Hi Dave.

I am testing your OV5647 driver but I encounter a strange error during the compilation process.
The OV5647 driver compiles successfully only if OV5693 driver is selected in the Kernel configuration. If the ov5693 driver isn’t selected, the ov5647 shows the following error during compilation process:

"make zimage fails!!"
drivers/media/i2c/ov5647.c:33:33: fatal error: cam_dev/camera_gpio.h: No such file or directory

I analyze the OV5647 driver files and I figure out that it is based on OV5693 driver, it is pretty much similar. Both drivers has the same line that includes the camera_gpio.h (include “cam_dev/camera_gpio.h”). I don’t understand why the OV5693 compiled alone (only this camera driver selected) don’t give any error, but the OV5647 alone gives that error. Also, I don’t understand if I select both driver in kernel configuration (make menuconfig), the error disappears.

I add your OV5647 driver to default kernel source of Jetpack L4T 24.2 version and recompile it.

If you have any clue about this issue I will appreciate any help.

Thanks in advance!

Daniel G

16

Hi everyone!

Finally I could fix that strange error of the previous post. The error message was:

"make zimage fails!!"
drivers/media/i2c/ov5647.c:33:33: fatal error: cam_dev/camera_gpio.h: No such file or directory

The cause of the error was a problem in the configuration of the driver build process. The problem was a missing include path in the compile instruction. To fix the error I modify the drivers/media/i2c/Makefile by adding the following lines:

ifneq (,$(filter $(CONFIG_VIDEO_I2C_OV5647),y m))
	ccflags-y += -I$(srctree)/drivers/media/platform/tegra
endif

ifneq (,$(filter $(CONFIG_VIDEO_LC898212),y m))
	ccflags-y += -I$(srctree)/drivers/media/platform/tegra
endif

I also added a fix to LC899212 driver, because I figured out that if I deselected the OV5693 driver (before adding the FIX) the driver crashes during compiling process. The error was pretty similar, a missing include file in the path: drivers/media/platform/tegra.

I hope this could help someone. Thanks!

Daniel G

17

That’s great.

I have a Wednesday deadline to finish up the second version of the circuit boards and haven’t been able to work on the camera driver. Hopefully tomorrow I should be able to get back to it.

There are two things I thought of today when I read your post.

  1. The Device Source Tree may need to be modified.
  2. ‘board-t210ref-camera.c’ needs to be modified to tell the kernel how to talk to the camera.

[b]NOTE: this is what I’ve learned since working on this project and I see the following output when I use ‘v4l2-ctl --all’ command (shown below).

I am not an expert so if someone can give us some feedback on if the following is correct it would be very much appreciated.
[/b]

ubuntu@tegra-ubuntu:~$ v4l2-ctl --all
Driver Info (not using libv4l2):
        Driver name   : tegra-video
        Card type     : vi-output-0, ov5647 6-0036
        Bus info      : platform:vi:0
        Driver version: 3.10.96
        Capabilities  : 0x84200001
                Video Capture
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps   : 0x04200001
                Video Capture
                Streaming
                Extended Pix Format
Priority: 2
Video input : 0 (Camera 0: no power)
Format Video Capture:
        Width/Height      : 1920/1080
        Pixel Format      : 'RG10'
        Field             : None
        Bytes per Line    : 3840
        Size Image        : 4147200
        Colorspace        : sRGB
        Transfer Function : Default
        YCbCr Encoding    : Default
        Quantization      : Default
        Flags             : 

Camera Controls

                   frame_length (int)    : min=0 max=32767 step=1 default=1968 value=1968 flags=slider
                    coarse_time (int)    : min=22 max=32760 step=1 default=1961 value=1961 flags=slider
              coarse_time_short (int)    : min=22 max=32760 step=1 default=1961 value=1961 flags=slider
                     group_hold (intmenu): min=0 max=1 default=0 value=0
                    bypass_mode (intmenu): min=0 max=1 default=0 value=0
                           gain (int)    : min=256 max=4096 step=1 default=256 value=256 flags=slider

Device Source Tree

Because you’re not using the TX1 carrier board you’ll probably need to modify the Device Source Tree in order to tell the kernel that it will be talking to the Auvidia J20 board and not the ‘jetson-cv’ board.

The device source tree’s are located in:

/arch/arm64/boot/dts

What I did was copied the following files:

  • tegra210-jetson-cv-p2597-2180-a00.dts
  • tegra210-jetson-cv-base-p2597-2180-a00.dts

To something that related to my board, like:

  • tegra210-mit-uav-reva.dts
  • tegra210-jetson-cv-base-mit-uav-reva.dts

Among other things I removed all of the ‘plugin’ support within the ‘base’ file because I didn’t have to worry about external camera expansion boards and created a ‘dtsi’ file that I used to declare support for the OV5647:

/arch/arm64/boot/dts/tegra210-platforms/tegra210-camera-mit-uav-reva-ov5647.dtsi

This allowed me to declare which GPIOs I used to reset the camera along with which I2C bus is associated with the CSI port.

I then included this file directly into the ‘tegra210-jetson-cv-base-mit-uav-reva.dts’ file.

If you want to see what it looks like it’s located here:

When I get a moment I might just combine the two files into one file.

Board T210Ref

The ‘board-t210ref-camera.c’ file is where the kernel configures support for the X1 camera interface. It seems as though there is some redundancy between the DTS file and this file but it looks like both of them are required.

Within the file you’ll need to add three different things.

  1. Include the header file:
...
#include <media/ov5693.h>
#include <media/ov5647.h>
#include <media/soc_camera.h>
...
  1. Static structures defining your camera:
#if IS_ENABLED(CONFIG_VIDEO_OV5647)
static int t210ref_ov5647_power(struct device *dev, int enable)
{
	return 0;
}

static struct camera_common_pdata t210ref_ov5647_data;

static struct i2c_board_info t210ref_ov5647_camera_i2c_device = {
	I2C_BOARD_INFO("ov5647", 0x36),
};

static struct tegra_camera_platform_data t210ref_ov5647_camera_platform_data = {
	.flip_v			      = 0,
	.flip_h			      = 0,
	.port			        = TEGRA_CAMERA_PORT_CSI_A,
	.lanes			      = 2,
	.continuous_clk		= 0,
};

static struct soc_camera_link ov5647_iclink = {
	.bus_id		      = 0, /* This must match the .id of tegra_vi01_device */
	.board_info	    = &t210ref_ov5647_camera_i2c_device,
	.module_name	  = "ov5647",
	.i2c_adapter_id	= 6, /* VI2 I2C controller */
	.power		      = t210ref_ov5647_power,
	.priv		        = &t210ref_ov5647_camera_platform_data,
	.dev_priv	      = &t210ref_ov5647_data,
};

static struct platform_device t210ref_ov5647_bottom_soc_camera_device = {
	.name	= "soc-camera-pdrv",
	.id	= 0,
	.dev	= {
		.platform_data = &ov5647_iclink,
	},
};

#endif

You may need to change the CSI Port depending on the physical location of the camera connector.

  1. Declare your camera in the ‘init’ function:

Inside the “t210ref_camera_init()” function

...

#if IS_ENABLED(CONFIG_VIDEO_OV5647)
  if (of_machine_is_compatible("nvidia,mit-uav-reva")) {
    pr_info("%s: MIT UAV REVA Detected\n", __func__);

		//Register all camera

		//Register Front Left Camera
		//platform_device_register(&t210ref_ov5647_front_left_soc_camera_device);

		//Register Front Right Camera
		//platform_device_register(&t210ref_ov5647_front_right_soc_camera_device);

		//Register Bottom Camera
    if (of_find_node_by_name(NULL, "ov5647_a"))
    {
      pr_info("%s: Detected OV5647 in Device Tree\n", __func__);
		  platform_device_register(&t210ref_ov5647_bottom_soc_camera_device);
    }
    else
      pr_warning("%s: Did not find ov5647_a in device tree\n", __func__);
	}

#endif

...

If you are using the TX1 Devboard you would change the ‘mit-uav-reva’ to ‘jetson-cv’ or whatever your board is called.

Again, this is what I’ve learned when I got this working and any feedback would be appreciated.

Dave

18

Dear cospan,

First, I’d like to thanks for your great work and hope you’ve done all before deadline.

We also try to get raspberry pi camera working on TX1 with J100(audidea).

This is J100’s CSI pin map

Pin Function Jetson TX1 Description
1 GND - Ground
2 CSI-B_D0- C28 CSI-2 bus B lane 0
3 CSI-B_D0+ C29 CSI-2 bus B lane 0
4 GND - Ground
5 CSI-B_D1- E26 CSI-2 bus B lane 1
6 CSI-B_D1+ E27 CSI-2 bus B lane 1
7 GND - Ground
8 CSI-B_CLK- D27 CSI-2 bus B clock
9 CSI-B_CLK+ D28 CSI-2 bus B clock
10 GND - Ground
11 CAM0_GPIO G8 GPIO0_CAM0_PWR
12 CAM0_MCLK F9 CAM0_MCLK
13 I2C_PM_CLK A6 3.3V level (converted from 1.8V of the Jetson TX1)
14 I2C_PM_DAT B6 3.3V level (converted from 1.8V of the Jetson TX1)
15 3.3V - 3.3V power supply

As you can see, there is only GPIO0_CAM0_PWR for pwdn_gpio.
There is no reset gpio. When see driver code reset_gpio exist and controlled by driver.
And on my board i2c failed during open function.

BTW I’m wondering your custom board pin map.

Thanks.

19

@Leesuan,

Thanks! Yeah I made the deadline.

I have been calling pwdn_gpio the reset pin, my mistake. I should be calling it the pwdn_gpio.

I would like to give you more details about the board I’ve been working with but I can’t at this time. That said, if we can get the camera working on the board I’ll share all the source code.

We will eventually release the board.

Dave

20

I’m still seeing this error within dmesg:

[  374.093537] video4linux video0: frame start syncpt timeout!0

After looking through the X1 TRM I found the debug and status registers for CSI on pages 2303 - 2368

Specifically I noticed the following registers:

CSI_PIXEL_STREAM_PIXEL_PARSER_A_STATUS_0 (Page 2307)
CSI_CSI_CIL_A_STATUS_0 (Page 2315)
CSI_CSI_CILA_STATUS_0 (Page 2315)
CSI_DEBUG_CONTROL_0 (Page 2314)
CSI_DEBUG_COUNTER_0_0 (Page 2325)
CSI_DEBUG_COUNTER_1_0 (Page 2325)
CSI_DEBUG_COUNTER_2_0 (Page 2325)

Enabling Debug Messages

After some grepping around in the kernel there was a file called (head slappingly obvious enough)

/drivers/media/platform/tegra/csi/csi2_fops.c

where there already is code that will print these registers out.

I enabled the DEBUG flag and changed all dev_dbg to dev_info and now I see where, I think, the error is.

Exercising CSI Capture

To exercise everything I run this command:

v4l2-ctl -d /dev/video0 -w --verbose --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 --stream-to=data.raw

I see this result on the console:

ubuntu@tegra-ubuntu:~$ v4l2-ctl -d /dev/video0 -w --verbose --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 --stream-to=data.raw
VIDIOC_QUERYCAP: ok
VIDIOC_S_EXT_CTRLS: ok
VIDIOC_G_FMT: ok
VIDIOC_S_FMT: failed: Invalid argument
VIDIOC_REQBUFS: ok
VIDIOC_QUERYBUF: ok
VIDIOC_QBUF: ok
VIDIOC_QUERYBUF: ok
VIDIOC_QBUF: ok
VIDIOC_QUERYBUF: ok
VIDIOC_QBUF: ok
VIDIOC_QUERYBUF: ok
VIDIOC_QBUF: ok
VIDIOC_STREAMON: ok
        Index    : 0
        Type     : Video Capture
        Flags    : mapped, done, error
        Field    : None
        Sequence : 0
        Length   : 4147200
        Bytesused: 4147200
        Timestamp: 18446743798852329136.18446744073434681117s (Monotonic, End-of-Frame)

        Index    : 1
        Type     : Video Capture
        Flags    : mapped, done, error
        Field    : None
        Sequence : 1
        Length   : 4147200
        Bytesused: 4147200
        Timestamp: 18446743798852329136.18446744073434681117s (Monotonic, End-of-Frame)

        Index    : 2
        Type     : Video Capture
        Flags    : mapped, done, error
        Field    : None
        Sequence : 2
        Length   : 4147200
        Bytesused: 4147200
        Timestamp: 18446743798852329136.18446744073434681117s (Monotonic, End-of-Frame)

So it attempted and failed to capture 3 images, outputting dmesg I get this:

[37514.706577] ov5647 6-0036: ov5647_power_on: power on
[37514.749070] ov5647 6-0036: camera_common_try_fmt: size 1920 x 1080
[37514.749079] ov5647 6-0036: camera_common_try_fmt: got controls from v4l2_g_ctrl
[37514.749084] ov5647 6-0036: could not find device ctrl.
[37514.789411] vi vi: csi2_write:port 0 offset 0x00000218 val:0x00000000
[37514.789418] csi2_pp_write:offset 0x0000001c val:0xffffffff
[37514.789422] csi2_cil_write:offset 0x00000010 val:0xffffffff
[37514.789427] csi2_cil_write:offset 0x00000014 val:0xffffffff
[37514.789431] csi2_cil_write:offset 0x0000000c val:0x00000000
[37514.789434] csi2_cil_write:offset 0x00000000 val:0x00000000
[37514.789437] csi2_cil_write:offset 0x00000008 val:0x0000004a
[37514.789445] vi vi: csi2_read:port 0 offset 0x000000d0
[37514.789449] csi2_cil_write:offset 0x00000000 val:0x00000000
[37514.789453] vi vi: csi2_write:port 0 offset 0x000000d0 val:0x00000001
[37514.789456] csi2_pp_write:offset 0x00000010 val:0x0000f007
[37514.789459] csi2_pp_write:offset 0x00000018 val:0x00000000
[37514.789462] csi2_pp_write:offset 0x00000004 val:0x2a0301f0
[37514.789465] csi2_pp_write:offset 0x00000008 val:0x00000011
[37514.789468] csi2_pp_write:offset 0x0000000c val:0x00140000
[37514.789470] csi2_pp_write:offset 0x00000014 val:0x00000000
[37514.789473] csi2_pp_write:offset 0x00000000 val:0x003f0001
[37514.789476] csi2_pp_write:offset 0x0000021c val:0x454340e1
[37514.789479] csi2_pp_write:offset 0x00000010 val:0x0000f005
[37514.789789] ov5647 6-0036: ov5647_s_stream++
[37514.811617] ov5647 6-0036: ov5647_set_gain: gain 0100 val: 0010
[37514.812213] ov5647 6-0036: ov5647_set_frame_length: val: 1104
[37514.812786] ov5647 6-0036: ov5647_set_coarse_time: val: 1096
[37514.814224] ov5647 6-0036: ov5647_set_coarse_time_short: val: 1096
[37514.815395] ov5647 6-0036: ov5647_s_stream--
[37515.014015] video4linux video0: frame start syncpt timeout!0
[37515.019906] csi2_pp_read:offset 0x0000001c
[37515.020001] vi vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00004000
[37515.020055] csi2_cil_read:offset 0x00000010
[37515.020122] vi vi: TEGRA_CSI_CIL_STATUS 0x00000013
[37515.020169] csi2_cil_read:offset 0x00000014
[37515.020238] vi vi: TEGRA_CSI_CILX_STATUS 0x00070070
[37515.020283] csi2_pp_read:offset 0x00000220
[37515.020346] vi vi: TEGRA_CSI_DEBUG_COUNTER_0 0x00000000
[37515.020392] csi2_pp_read:offset 0x00000224
[37515.020456] vi vi: TEGRA_CSI_DEBUG_COUNTER_1 0x00000000
[37515.020501] csi2_pp_read:offset 0x00000228
[37515.020565] vi vi: TEGRA_CSI_DEBUG_COUNTER_2 0x0000008b
[37515.020623] csi2_cil_write:offset 0x00000020 val:0x00000001
[37515.020696] vi vi: csi2_write:port 0 offset 0x00000214 val:0x00000001
[37515.020971] csi2_cil_write:offset 0x00000020 val:0x00000000
[37515.021052] vi vi: csi2_write:port 0 offset 0x00000214 val:0x00000000
[37515.021133] csi2_pp_write:offset 0x00000010 val:0x0000f002
[37515.021201] vi vi: csi2_write:port 0 offset 0x00000218 val:0x00000000
[37515.021251] csi2_pp_write:offset 0x0000001c val:0xffffffff
[37515.021300] csi2_cil_write:offset 0x00000010 val:0xffffffff
[37515.021349] csi2_cil_write:offset 0x00000014 val:0xffffffff
[37515.021396] csi2_cil_write:offset 0x0000000c val:0x00000000
[37515.021442] csi2_cil_write:offset 0x00000000 val:0x00000000
[37515.021489] csi2_cil_write:offset 0x00000008 val:0x0000004a
[37515.021556] vi vi: csi2_read:port 0 offset 0x000000d0
[37515.021607] csi2_cil_write:offset 0x00000000 val:0x00000000
[37515.021674] vi vi: csi2_write:port 0 offset 0x000000d0 val:0x00000001
[37515.021724] csi2_pp_write:offset 0x00000010 val:0x0000f007
[37515.021771] csi2_pp_write:offset 0x00000018 val:0x00000000
[37515.021819] csi2_pp_write:offset 0x00000004 val:0x2a0301f0
[37515.021866] csi2_pp_write:offset 0x00000008 val:0x00000011
[37515.021913] csi2_pp_write:offset 0x0000000c val:0x00140000
[37515.021959] csi2_pp_write:offset 0x00000014 val:0x00000000
[37515.022006] csi2_pp_write:offset 0x00000000 val:0x003f0001
[37515.022054] csi2_pp_write:offset 0x0000021c val:0x454340e1
[37515.022101] csi2_pp_write:offset 0x00000010 val:0x0000f005
[37515.224186] video4linux video0: frame start syncpt timeout!0
[37515.230084] csi2_pp_read:offset 0x0000001c
[37515.230186] vi vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00004000
[37515.230240] csi2_cil_read:offset 0x00000010
[37515.230306] vi vi: TEGRA_CSI_CIL_STATUS 0x00000013
[37515.230352] csi2_cil_read:offset 0x00000014
[37515.230416] vi vi: TEGRA_CSI_CILX_STATUS 0x00060070
[37515.230463] csi2_pp_read:offset 0x00000220
[37515.230528] vi vi: TEGRA_CSI_DEBUG_COUNTER_0 0x00000000
[37515.230574] csi2_pp_read:offset 0x00000224
[37515.230640] vi vi: TEGRA_CSI_DEBUG_COUNTER_1 0x00000000
[37515.230684] csi2_pp_read:offset 0x00000228
[37515.230747] vi vi: TEGRA_CSI_DEBUG_COUNTER_2 0x0000009a
[37515.230809] csi2_cil_write:offset 0x00000020 val:0x00000001
[37515.230882] vi vi: csi2_write:port 0 offset 0x00000214 val:0x00000001
[37515.231141] csi2_cil_write:offset 0x00000020 val:0x00000000
[37515.231219] vi vi: csi2_write:port 0 offset 0x00000214 val:0x00000000
[37515.231298] csi2_pp_write:offset 0x00000010 val:0x0000f002
[37515.231368] vi vi: csi2_write:port 0 offset 0x00000218 val:0x00000000
[37515.231417] csi2_pp_write:offset 0x0000001c val:0xffffffff
[37515.231466] csi2_cil_write:offset 0x00000010 val:0xffffffff
[37515.231513] csi2_cil_write:offset 0x00000014 val:0xffffffff
[37515.231560] csi2_cil_write:offset 0x0000000c val:0x00000000
[37515.231606] csi2_cil_write:offset 0x00000000 val:0x00000000
[37515.231653] csi2_cil_write:offset 0x00000008 val:0x0000004a
[37515.231718] vi vi: csi2_read:port 0 offset 0x000000d0
[37515.231768] csi2_cil_write:offset 0x00000000 val:0x00000000
[37515.231835] vi vi: csi2_write:port 0 offset 0x000000d0 val:0x00000001
[37515.231883] csi2_pp_write:offset 0x00000010 val:0x0000f007
[37515.231930] csi2_pp_write:offset 0x00000018 val:0x00000000
[37515.231977] csi2_pp_write:offset 0x00000004 val:0x2a0301f0
[37515.232023] csi2_pp_write:offset 0x00000008 val:0x00000011
[37515.232070] csi2_pp_write:offset 0x0000000c val:0x00140000
[37515.232115] csi2_pp_write:offset 0x00000014 val:0x00000000
[37515.232162] csi2_pp_write:offset 0x00000000 val:0x003f0001
[37515.232209] csi2_pp_write:offset 0x0000021c val:0x454340e1
[37515.232255] csi2_pp_write:offset 0x00000010 val:0x0000f005
[37515.433915] video4linux video0: frame start syncpt timeout!0
[37515.440378] csi2_pp_read:offset 0x0000001c
[37515.440491] vi vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00004000
[37515.440544] csi2_cil_read:offset 0x00000010
[37515.440615] vi vi: TEGRA_CSI_CIL_STATUS 0x00000013
[37515.440661] csi2_cil_read:offset 0x00000014
[37515.440728] vi vi: TEGRA_CSI_CILX_STATUS 0x00060070
[37515.440774] csi2_pp_read:offset 0x00000220
[37515.440839] vi vi: TEGRA_CSI_DEBUG_COUNTER_0 0x00000000
[37515.440885] csi2_pp_read:offset 0x00000224
[37515.440947] vi vi: TEGRA_CSI_DEBUG_COUNTER_1 0x00000000
[37515.440991] csi2_pp_read:offset 0x00000228
[37515.441053] vi vi: TEGRA_CSI_DEBUG_COUNTER_2 0x00000095
[37515.441112] csi2_cil_write:offset 0x00000020 val:0x00000001
[37515.441185] vi vi: csi2_write:port 0 offset 0x00000214 val:0x00000001
[37515.441765] csi2_cil_write:offset 0x00000020 val:0x00000000
[37515.441851] vi vi: csi2_write:port 0 offset 0x00000214 val:0x00000000
[37515.441934] csi2_pp_write:offset 0x00000010 val:0x0000f002
[37515.442003] vi vi: csi2_write:port 0 offset 0x00000218 val:0x00000000
[37515.442053] csi2_pp_write:offset 0x0000001c val:0xffffffff
[37515.442101] csi2_cil_write:offset 0x00000010 val:0xffffffff
[37515.442149] csi2_cil_write:offset 0x00000014 val:0xffffffff
[37515.442197] csi2_cil_write:offset 0x0000000c val:0x00000000
[37515.442245] csi2_cil_write:offset 0x00000000 val:0x00000000
[37515.442292] csi2_cil_write:offset 0x00000008 val:0x0000004a
[37515.442356] vi vi: csi2_read:port 0 offset 0x000000d0
[37515.442407] csi2_cil_write:offset 0x00000000 val:0x00000000
[37515.442477] vi vi: csi2_write:port 0 offset 0x000000d0 val:0x00000001
[37515.442526] csi2_pp_write:offset 0x00000010 val:0x0000f007
[37515.442575] csi2_pp_write:offset 0x00000018 val:0x00000000
[37515.442622] csi2_pp_write:offset 0x00000004 val:0x2a0301f0
[37515.442669] csi2_pp_write:offset 0x00000008 val:0x00000011
[37515.442716] csi2_pp_write:offset 0x0000000c val:0x00140000
[37515.442762] csi2_pp_write:offset 0x00000014 val:0x00000000
[37515.442810] csi2_pp_write:offset 0x00000000 val:0x003f0001
[37515.442858] csi2_pp_write:offset 0x0000021c val:0x454340e1
[37515.442904] csi2_pp_write:offset 0x00000010 val:0x0000f005
[37515.644290] video4linux video0: frame start syncpt timeout!0
[37515.650172] csi2_pp_read:offset 0x0000001c
[37515.650270] vi vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00004000
[37515.650319] csi2_cil_read:offset 0x00000010
[37515.650388] vi vi: TEGRA_CSI_CIL_STATUS 0x00000013
[37515.650433] csi2_cil_read:offset 0x00000014
[37515.650502] vi vi: TEGRA_CSI_CILX_STATUS 0x00060070
[37515.650549] csi2_pp_read:offset 0x00000220
[37515.650613] vi vi: TEGRA_CSI_DEBUG_COUNTER_0 0x00000000
[37515.650659] csi2_pp_read:offset 0x00000224
[37515.650723] vi vi: TEGRA_CSI_DEBUG_COUNTER_1 0x00000000
[37515.650768] csi2_pp_read:offset 0x00000228
[37515.650830] vi vi: TEGRA_CSI_DEBUG_COUNTER_2 0x00000089
[37515.650892] csi2_cil_write:offset 0x00000020 val:0x00000001
[37515.650964] vi vi: csi2_write:port 0 offset 0x00000214 val:0x00000001
[37515.651260] csi2_cil_write:offset 0x00000020 val:0x00000000
[37515.651341] vi vi: csi2_write:port 0 offset 0x00000214 val:0x00000000
[37515.651425] csi2_pp_write:offset 0x00000010 val:0x0000f002
[37515.651497] vi vi: csi2_write:port 0 offset 0x00000218 val:0x00000000
[37515.651547] csi2_pp_write:offset 0x0000001c val:0xffffffff
[37515.651597] csi2_cil_write:offset 0x00000010 val:0xffffffff
[37515.651645] csi2_cil_write:offset 0x00000014 val:0xffffffff
[37515.651695] csi2_cil_write:offset 0x0000000c val:0x00000000
[37515.651741] csi2_cil_write:offset 0x00000000 val:0x00000000
[37515.651788] csi2_cil_write:offset 0x00000008 val:0x0000004a
[37515.651852] vi vi: csi2_read:port 0 offset 0x000000d0
[37515.651903] csi2_cil_write:offset 0x00000000 val:0x00000000
[37515.651969] vi vi: csi2_write:port 0 offset 0x000000d0 val:0x00000001
[37515.652018] csi2_pp_write:offset 0x00000010 val:0x0000f007
[37515.652065] csi2_pp_write:offset 0x00000018 val:0x00000000
[37515.652112] csi2_pp_write:offset 0x00000004 val:0x2a0301f0
[37515.652159] csi2_pp_write:offset 0x00000008 val:0x00000011
[37515.652206] csi2_pp_write:offset 0x0000000c val:0x00140000
[37515.652252] csi2_pp_write:offset 0x00000014 val:0x00000000
[37515.652300] csi2_pp_write:offset 0x00000000 val:0x003f0001
[37515.652349] csi2_pp_write:offset 0x0000021c val:0x454340e1
[37515.652396] csi2_pp_write:offset 0x00000010 val:0x0000f005
[37515.854128] video4linux video0: frame start syncpt timeout!0
[37515.861379] csi2_pp_read:offset 0x0000001c
[37515.861501] vi vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00004000
[37515.861553] csi2_cil_read:offset 0x00000010
[37515.861622] vi vi: TEGRA_CSI_CIL_STATUS 0x00000013
[37515.861667] csi2_cil_read:offset 0x00000014
[37515.861732] vi vi: TEGRA_CSI_CILX_STATUS 0x00060070
[37515.861779] csi2_pp_read:offset 0x00000220
[37515.861843] vi vi: TEGRA_CSI_DEBUG_COUNTER_0 0x00000000
[37515.861888] csi2_pp_read:offset 0x00000224
[37515.861950] vi vi: TEGRA_CSI_DEBUG_COUNTER_1 0x00000000
[37515.861995] csi2_pp_read:offset 0x00000228
[37515.862057] vi vi: TEGRA_CSI_DEBUG_COUNTER_2 0x00000087
[37515.862116] csi2_cil_write:offset 0x00000020 val:0x00000001
[37515.862190] vi vi: csi2_write:port 0 offset 0x00000214 val:0x00000001
[37515.862484] csi2_cil_write:offset 0x00000020 val:0x00000000
[37515.862566] vi vi: csi2_write:port 0 offset 0x00000214 val:0x00000000
[37515.862647] csi2_pp_write:offset 0x00000010 val:0x0000f002
[37515.862716] vi vi: csi2_write:port 0 offset 0x00000218 val:0x00000000
[37515.862763] csi2_pp_write:offset 0x0000001c val:0xffffffff
[37515.862812] csi2_cil_write:offset 0x00000010 val:0xffffffff
[37515.862860] csi2_cil_write:offset 0x00000014 val:0xffffffff
[37515.862904] csi2_cil_write:offset 0x0000000c val:0x00000000
[37515.862949] csi2_cil_write:offset 0x00000000 val:0x00000000
[37515.862994] csi2_cil_write:offset 0x00000008 val:0x0000004a
[37515.863063] vi vi: csi2_read:port 0 offset 0x000000d0
[37515.863112] csi2_cil_write:offset 0x00000000 val:0x00000000
[37515.865864] vi vi: csi2_write:port 0 offset 0x000000d0 val:0x00000001
[37515.865915] csi2_pp_write:offset 0x00000010 val:0x0000f007
[37515.865941] csi2_pp_write:offset 0x00000018 val:0x00000000
[37515.865967] csi2_pp_write:offset 0x00000004 val:0x2a0301f0
[37515.865992] csi2_pp_write:offset 0x00000008 val:0x00000011
[37515.866015] csi2_pp_write:offset 0x0000000c val:0x00140000
[37515.866040] csi2_pp_write:offset 0x00000014 val:0x00000000
[37515.866063] csi2_pp_write:offset 0x00000000 val:0x003f0001
[37515.866087] csi2_pp_write:offset 0x0000021c val:0x454340e1
[37515.866110] csi2_pp_write:offset 0x00000010 val:0x0000f005
[37515.867244] csi2_pp_write:offset 0x00000010 val:0x0000f002
[37515.867366] ov5647 6-0036: ov5647_s_stream++
[37515.882842] ov5647 6-0036: ov5647_power_off: power off

Decoding

So no one needs to decode this on their own:

[37515.020623] csi2_cil_write:offset 0x00000020 val:0x00000001 CSI_CSICIL_SW_SENSOR_A_RESET_0
-CSI receive to reset

[37515.020971] csi2_cil_write:offset 0x00000020 val:0x00000000 CSI_CSICIL_SW_SENSOR_A_RESET_0
-CSI receiver out of reset

[37515.021133] csi2_pp_write:offset 0x00000010 val:0x0000f002 CSI_PIXEL_STREAM_PPA_COMMAND_0
-Disable Pixel Parser

[37515.021251] csi2_pp_write:offset 0x0000001c val:0xffffffff CSI_CSI_PIXEL_PARSER_A_STATUS_0
-Reset all Pixel Parser Status Bits

[37515.021300] csi2_cil_write:offset 0x00000010 val:0xffffffff CSI_CSI_CILA_STATUS_0
-Reset all CIL Status Bits

[37515.021349] csi2_cil_write:offset 0x00000014 val:0xffffffff CSI_CSI_CIL_A_STATUS_0
-Reset all CIL Status Bits

[37515.021396] csi2_cil_write:offset 0x0000000c val:0x00000000 CSI_CSI_CIL_A_INTERRUPT_MASK_0
-Clear all interrupt masks

[37515.021442] csi2_cil_write:offset 0x00000000 val:0x00000000 CSI_CILA_PAD_CONFIG0_0
-Reset pad configuration

[37515.021489] csi2_cil_write:offset 0x00000008 val:0x0000004a CSI_PHY_CILA_CONTROL0_0
-Settle time for data lane when moving from LP → HP to 10
-Bypass the Lower Power to High Power sequence detect (just look for LP00 instead of LP11->LP01->LP00)

[37515.021607] csi2_cil_write:offset 0x00000000 val:0x00000000 CSI_CILA_PAD_CONFIG0_0
-Reset pad configuration

[37515.021724] csi2_pp_write:offset 0x00000010 val:0x0000f007 CSI_PIXEL_STREAM_PPA_COMMAND_0
-Reset PPA

[37515.021771] csi2_pp_write:offset 0x00000018 val:0x00000000 CSI_CSI_PIXEL_PARSER_A_INTERRUPT_MASK_0
-Clear all interrupt masks

[37515.021819] csi2_pp_write:offset 0x00000004 val:0x2a0301f0 CSI_PIXEL_STREAM_A_CONTROL0_0
-Short frames will not be padded out
-Single bit Errors in the header will not be corrected
-Short line will not be padded out
-Throw away embedded data
-STORE: output for storing RAW data to memory through ISP
-Word Count Check is enabled
-CRC is checked
-Number of bytes per line is to be extracted from the header
-Data identifier byte in packet header should be compared agains CSI_PPA_DATA_TYPE and the VIRTUAL_CHANNEL_ID
-Packet header is sent
-CSI_A is used

[37515.021866] csi2_pp_write:offset 0x00000008 val:0x00000011 CSI_PIXEL_STREAM_A_CONTROL1_0
-Top Field detection for interlaced video frame (not used)

[37515.021913] csi2_pp_write:offset 0x0000000c val:0x00140000 CSI_PIXEL_STREAM_A_GAP_0
-Sets the min/max gap of viclk cycles from the end of the frame to the next frame
-Sets the min/max gap of viclk cycles from the end of one line to the next line

[37515.021959] csi2_pp_write:offset 0x00000014 val:0x00000000 CSI_PIXEL_STREAM_A_EXPECTED_FRAME_0
-Disable timeout between lines, if this were enable the CSI core would inject an ‘end frame’ into the stream

[37515.022006] csi2_pp_write:offset 0x00000000 val:0x003f0001 CSI_INPUT_STREAM_A_CONTROL_0
-Skip Packet feature is disabled
-Align CSIA and CSIB (I think this is used for 4 data lane mode)
-2 data lanes

[37515.022054] csi2_pp_write:offset 0x0000021c val:0x454340e1 CSI_DEBUG_CONTROL_0
-Configure Debug Count 2 to 69: PPA Headers Parsed (Number of Headers parsed)
-Configure Debug Count 1 to 67: PPA Frame Starts Outputted (Number of frame starts detected)
-Configure Debug Count 0 to 64: PPA Lines processed (Number of lines parsed)

[37515.022101] csi2_pp_write:offset 0x00000010 val:0x0000f005 CSI_PIXEL_STREAM_PPA_COMMAND_0
-Single Shot
-Enable

…Wait 200 ms…

ERROR Detected!
[37515.224186] video4linux video0: frame start syncpt timeout!0

Post Mortem

[37515.230186] vi vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00004000 CSI_CSI_PIXEL_PARSER_A_STATUS_0
-PPA_STMERR: Stream Error, set when the control output of PPA does not follow the correct sequence.
The correct sequence for CSI is: SF → (SL_DATA or EF), SL_DATA → (DATA or EL_DATA), DATA →
EL_DATA, EL_DATA → (SL_DATA or EF), EF → SF. Stream Errors can be caused by receiving a
corrupted stream.

[[37515.230306] vi vi: TEGRA_CSI_CIL_STATUS 0x00000013 CSI_CSI_CIL_A_STATUS_0
-CILA_CTRL_ERR: Control Error. Set when CIL-A detects LP state 01 or 10 followed by a stop state (LP11)
instead of transitioning into the Escape mode or Turn Around mode (LP00).
-CILA_SOT_MB_ERR: Start of Transmission Multi Bit Error. Set when CIL-A detects a multi bit start of
transmission byte error in one of the packet’s SOT bytes. The packet will be discarded.
-CILA_SOT_SB_ERR: Start of Transmission Single Bit Error. Set when CIL-A detects a single bit error in
one of the packet’s Start of Transmission bytes. The packet will be sent to the CSI-A for processing.

[37515.230416] vi vi: TEGRA_CSI_CILX_STATUS 0x00060070 CSI_CSI_CILA_STATUS_0
-CILA_DATA_LANE1_CTRL_ERR: Control Error. Set when CIL-A detects LP state 01 or 10 followed by a stop state (LP11) instead of transitioning
-CILA_DATA_LANE1_SOT_MB_ERR: Start of Transmission Multi Bit Error. Set when CIL-A detects a multi bit start of transmission byte error in one of the packet’s SOT bytes on data lane-1. The packet will be
discarded.
-CILA_DATA_LANE1_SOT_SB_ERR: Start of Transmission Single Bit Error. Set when CIL-A detects a single bit error in one of the packet’s Start of Transmission bytes on data lane-1. The packet will be sent to the CSI-A for processing.
(This one doesn’t happen all the time)

-CILA_DATA_LANE0_CTRL_ERR: Control Error. Set when CIL-A detects LP state 01 or 10 followed by a stop state (LP11) instead of transitioning
-CILA_DATA_LANE0_SOT_MB_ERR: Start of Transmission Multi Bit Error. Set when CIL-A detects a multi bit start of transmission byte error in one of the packet’s SOT bytes on data lane-0. The packet will be
discarded.
-CILA_DATA_LANE0_SOT_SB_ERR: Start of Transmission Single Bit Error. Set when CIL-A detects a single bit error in one of the packet’s Start of Transmission bytes on data lane-0. The packet will be sent to the CSI-A for processing.

[37515.230528] vi vi: TEGRA_CSI_DEBUG_COUNTER_0 0x00000000 CSI_DEBUG_COUNTER_0_0
PPA No Lines Processed

[37515.230640] vi vi: TEGRA_CSI_DEBUG_COUNTER_1 0x00000000 CSI_DEBUG_COUNTER_1_0
PPA No Frames Processed

[37515.230747] vi vi: TEGRA_CSI_DEBUG_COUNTER_2 0x0000009a CSI_DEBUG_COUNTER_2_0
154 Headers Parsed

Analysis

I’m not sure if the 154 headers parsed is significant or if the CSI core is attempting to parse garbage on the line as headers.

Based on the controller it looks like the LP11->LP01->LP00 is skipped and the CSI controller is looking for the high speed ‘synchronization’ token on the data lanes.

Unfortunately, I don’t have $4,000 a year to get the access to the MIPI D-PHY and CSI Specifications (ridiculous!) so I’ve been learning about it from various CSI/D-PHY Protocol Analyzer presentation decks from keysight, techtronics and the likes.

It seems like what should happen when the CSI transitions to high speed is:

SOT: Start of transmission
DATA IDENTIFIER: Identify packet
WORD COUNT: 16-bit word count (number of data words to send)
ERROR CORRECTION CODE: 8-bit ECC
DATA: WORD COUNT * Word Size Number of data packets to send
CHECKSUM: 16-bit Checksum Packet
EOT: End of transmission

Surprisingly, I can’t find the bit order of CSI, is it LSB or MSB first? I’ experimented with both directions but haven’t seen any improvement.

Any ideas?

Dave