Custom Xavier NX board: `no reply from camera processor`

Hello,

tl;dr: custom carrier board with two imagers doesn’t want to capture frames! Apologies for the lengthy post, I’ve tried to include as much data as possible.

I am bringing up the device tree for a custom Xavier NX carrier board (emmc version) which attaches CSI2 and 3 to one Arducam IMX477-based imager board, and CSI4 to another of the same imager board. That is, four lanes for each. To simplify things (I hope), my intention is to enable image acquisition from both imagers using two lanes each—so just CSI2 lane 0 and 1, as well as CSI4 0 and 1. That said, all four lanes and associated clocks for both are connected. I am also trying to use the provided IMX477 driver in Jetpack.

The i2c lines go through a muxing configuration similar to that of the Jakku developer kit. I’m convinced this part is working because I have two instances of the Jetpack-provided driver binding properly on boot (based on the output of dmesg | grep imx:

[    5.001496] imx477 9-001a: tegracam sensor driver:imx477_v2.0.6
[    5.303345] imx477 10-001a: tegracam sensor driver:imx477_v2.0.6
[    6.816693] tegra194-vi5 15c10000.vi: subdev imx477 9-001a bound
[    6.825422] tegra194-vi5 15c10000.vi: subdev imx477 10-001a bound

And when I run various commands, I can see the i2c clock/data on the pins of both the imagers on a scope. Additionally, when I attempt to open the stream with v4l2-ctl, I can also probe the CSI data lines and see signals that match those of a working system, sitting around the nominal 1.2V.

For the imager on CSI2 (serial C), I tried to match the device tree provided for use with Xavier NX developer kit[1]. For the imager on CSI4 (serial E), I confirmed in this post that I should have the right port indices designated in the device tree. However, this is the most suspicious bit for me: the sample dtsi for CSI 2/C and the aforementioned post for CS4 claim to need vi port-index 4, but I assume they can’t be the same (I haven’t tested this, but I don’t think it makes sense anyway), so I bumped the port for CSI-E to 6 (If C is 4, D could be 5, E as 6…!?), but this doesn’t work. Also, it doesn’t explain why the CSI-2 imager isn’t working either. Regardless, I intend to give this a try next time I’m in the lab.

Regardless, when I run sudo media-ctl -p, I can see the elements of both pipelines are properly enabled:

sudo media-ctl -p
[sudo] password for ubuntu:
Media controller API version 0.1.0

Media device information
------------------------
driver          tegra194-vi5
model           NVIDIA Tegra Video Input Device
serial
bus info
hw revision     0x3
driver version  0.0.0

Device topology
- entity 1: imx477 9-001a (1 pad, 1 link)
            type V4L2 subdev subtype Sensor flags 0
            device node name /dev/v4l-subdev0
        pad0: Source
                [fmt:SRGGB10_1X10/1920x1080 field:none colorspace:srgb]
                -> "15a00000.nvcsi--2":0 [ENABLED]

- entity 3: 15a00000.nvcsi--2 (2 pads, 2 links)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev1
        pad0: Sink
                <- "imx477 9-001a":0 [ENABLED]
        pad1: Source
                -> "vi-output, imx477 9-001a":0 [ENABLED]

- entity 6: vi-output, imx477 9-001a (1 pad, 1 link)
            type Node subtype V4L flags 0
            device node name /dev/video0
        pad0: Sink
                <- "15a00000.nvcsi--2":1 [ENABLED]

- entity 18: imx477 10-001a (1 pad, 1 link)
             type V4L2 subdev subtype Sensor flags 0
             device node name /dev/v4l-subdev2
        pad0: Source
                [fmt:SRGGB10_1X10/3840x2160 field:none colorspace:srgb]
                -> "15a00000.nvcsi--1":0 [ENABLED]

- entity 20: 15a00000.nvcsi--1 (2 pads, 2 links)
             type V4L2 subdev subtype Unknown flags 0
             device node name /dev/v4l-subdev3
        pad0: Sink
                <- "imx477 10-001a":0 [ENABLED]
        pad1: Source
                -> "vi-output, imx477 10-001a":0 [ENABLED]

- entity 23: vi-output, imx477 10-001a (1 pad, 1 link)
             type Node subtype V4L flags 0
             device node name /dev/video1
        pad0: Sink
                <- "15a00000.nvcsi--1":1 [ENABLED]

However, neither interface is able to acquire frames. the v4l2-ctl command just hangs, and I can see a loop of retries in dmesg -w:

$ v4l2-ctl -d /dev/video0 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=3
───────────────────────────────────────────────────────────────────────────────────
[62735.930039] [RCE] vi5_hwinit: firmware CL2018101701 protocol version 2.2
[62738.410059] tegra194-vi5 15c10000.vi: no reply from camera processor
[62738.410220] tegra194-vi5 15c10000.vi: uncorr_err: request timed out after 2500 ms
[62738.410385] tegra194-vi5 15c10000.vi: err_rec: attempting to reset the capture channel
[62738.418915] tegra194-vi5 15c10000.vi: err_rec: successfully reset the capture channel
[62745.577923] tegra194-vi5 15c10000.vi: no reply from camera processor
[62745.578084] tegra194-vi5 15c10000.vi: uncorr_err: request timed out after 2500 ms
[62745.578266] tegra194-vi5 15c10000.vi: err_rec: attempting to reset the capture channel
[62745.581631] tegra194-vi5 15c10000.vi: err_rec: successfully reset the capture channel
[62748.105911] tegra194-vi5 15c10000.vi: no reply from camera processor
[62748.106066] tegra194-vi5 15c10000.vi: uncorr_err: request timed out after 2500 ms

The above output happens identically for both /dev/video0 and /dev/video1.

Through various posts I’ve found you can enable more verbose output, but I don’t know if it’s helpful:

$ sudo bash -c "echo 'file camera_common.c +p' > /sys/kernel/debug/dynamic_debug/control"
$ v4l2-ctl -d /dev/video1 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=3
<ctrl-c>
$ v4l2-ctl -d /dev/video0 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=3
<ctrl-c>
───────────────────────────────────────────────────────────────────────────────────────
[62966.859423] imx477 10-001a: camera_common_mclk_enable: enable MCLK with 24000000 Hz
[62966.859501] imx477 10-001a: camera_common_dpd_disable: csi 4
[62967.219819] [RCE] vi5_hwinit: firmware CL2018101701 protocol version 2.2
[62969.831826] tegra194-vi5 15c10000.vi: no reply from camera processor
[62969.831985] tegra194-vi5 15c10000.vi: uncorr_err: request timed out after 2500 ms
[62969.832119] tegra194-vi5 15c10000.vi: err_rec: attempting to reset the capture channel
[62969.835592] tegra194-vi5 15c10000.vi: err_rec: successfully reset the capture channel
[62977.479724] tegra194-vi5 15c10000.vi: no reply from camera processor
...
[62977.479910] tegra194-vi5 15c10000.vi: uncorr_err: request timed out after 2500 ms
[62977.480050] tegra194-vi5 15c10000.vi: err_rec: attempting to reset the capture channel
[62977.483605] tegra194-vi5 15c10000.vi: err_rec: successfully reset the capture channel
[62977.508052] imx477 10-001a: camera_common_dpd_enable: csi 4
[62977.508063] imx477 10-001a: camera_common_mclk_disable: disable MCLK
[62984.904476] imx477 9-001a: camera_common_mclk_enable: enable MCLK with 24000000 Hz
[62984.904573] imx477 9-001a: camera_common_dpd_disable: csi 2
[62985.259675] [RCE] vi5_hwinit: firmware CL2018101701 protocol version 2.2
[62987.751643] tegra194-vi5 15c10000.vi: no reply from camera processor
[62987.751803] tegra194-vi5 15c10000.vi: uncorr_err: request timed out after 2500 ms
[62987.751961] tegra194-vi5 15c10000.vi: err_rec: attempting to reset the capture channel
[62987.759691] tegra194-vi5 15c10000.vi: err_rec: successfully reset the capture channel
[62990.311607] tegra194-vi5 15c10000.vi: no reply from camera processor
...
[62992.839780] tegra194-vi5 15c10000.vi: uncorr_err: request timed out after 2500 ms
[62992.839943] tegra194-vi5 15c10000.vi: err_rec: attempting to reset the capture channel
[62992.843612] tegra194-vi5 15c10000.vi: err_rec: successfully reset the capture channel
[62992.856687] imx477 9-001a: camera_common_dpd_enable: csi 2
[62992.856698] imx477 9-001a: camera_common_mclk_disable: disable MCLK

From this eLinux page mentioned in other forum posts, if I do:

sudo bash -c "echo 1 > /sys/kernel/debug/tracing/tracing_on
echo 30720 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/tegra_rtcpu/enable
echo 1 > /sys/kernel/debug/tracing/events/freertos/enable
echo 2 > /sys/kernel/debug/camrtc/log-level
echo 1 > /sys/kernel/debug/tracing/events/camera_common/enable
echo > /sys/kernel/debug/tracing/trace"

And then sudo cat /sys/kernel/debug/tracing/trace while doing the v4l2-ctl command above, I get a bunch of stuff like this:

     kworker/0:4-7046  [000] ....   383.885057: rtos_queue_peek_from_isr_failed: tstamp:12832960447 queue:0x0bcbb8b8
     kworker/0:4-7046  [000] ....   384.053056: rtos_queue_peek_from_isr_failed: tstamp:12837960450 queue:0x0bcbb8b8
     kworker/0:4-7046  [000] ....   384.221060: rtos_queue_peek_from_isr_failed: tstamp:12842960449 queue:0x0bcbb8b8
 vi-output, imx4-9076  [001] ....   384.324082: tegra_channel_capture_setup: vnc_id 0 W 3840 H 2160 fmt c4
        v4l2-ctl-9074  [000] ....   384.324540: tegra_channel_set_stream: enable : 0x0
        v4l2-ctl-9074  [000] ....   384.324544: tegra_channel_set_stream: imx477 10-001a : 0x0
        v4l2-ctl-9074  [000] ....   384.324742: tegra_channel_set_stream: 15a00000.nvcsi--1 : 0x0
        v4l2-ctl-9074  [000] ....   384.324745: csi_s_stream: enable : 0x0
     kworker/0:4-7046  [000] ....   384.333299: rtos_queue_send_from_isr_failed: tstamp:12847783462 queue:0x0bcb2b38
     kworker/0:4-7046  [000] ....   384.333309: rtos_queue_send_from_isr_failed: tstamp:12847783610 queue:0x0bcb73a0
     kworker/0:4-7046  [000] ....   384.333310: rtos_queue_send_from_isr_failed: tstamp:12847783755 queue:0x0bcb8f20
     kworker/0:4-7046  [000] ....   384.333312: rtos_queue_send_from_isr_failed: tstamp:12847783894 queue:0x0bcb9ce0
     kworker/0:4-7046  [000] ....   384.333313: rtos_queue_send_from_isr_failed: tstamp:12847784033 queue:0x0bcbaaa0
     kworker/0:4-7046  [000] ....   384.333314: rtos_queue_send_from_isr_failed: tstamp:12847784234 queue:0x0bcb2ad0
     kworker/0:4-7046  [000] ....   384.333315: rtos_queue_send_from_isr_failed: tstamp:12847784363 queue:0x0bcb2b38

The comment on that eLinux page for messages like this isn’t very helpful–“Didn’t receive any package from the MIPI bus. Make sure the sensor have output data to the MIPI bus”. As I’ve mentioned, scope captures show the sensor is outputting data on the CSI lines. I assume this means the CSI deserializer doesn’t think it’s receiving any data, and I assume this would have to be from misconfigured device tree ports or a hardware problem…?

Some other notes:

  • System is running Jetpack 4.6.1
  • I’m building the DTB with a modified version of the script in this post, flashing it with flash.sh[2], and confirming it’s taking effect with cat /proc/device-tree/nvidia,dtbbuildtime.
  • When I probe the CSIX_CLK lines on the cable header on the imager board, I don’t see any clock. I’m not sure how this works, but when I probe the same signals on a working system, I also see no clock.
  • The Arducam, like the Pi HQ cam, has an onboard oscillator for INCK on the IMX477, so I assume the Jetson does not need to generate the master clock. I’ve also probed this oscillator and found the ~25MHz clock. Without this, I expect I wouldn’t see any CSI signals anyway.
  • Probing also shows high signals on the Arducam pins PWDN and LED Enable/XCLK. Without these, I expect I wouldn’t see binding drivers or CSI signals anyway.
  • The issue has been reproduced on several systems
  • I’ve looked for what I could as far as pinmuxing goes, but it seems like the only problematic signals are the CSI inputs to the Jetson. The CSI2 pin muxing should be identical to the Jakku carrier board configuration, and I don’t see any options about CSI4 in the dtsi files generated by the pinmuxing spreadsheet.

The associated DTSI files are available here and also reproduced below.
mux_config.dtsi (969 Bytes)
pipeline_config.dtsi (12.4 KB)

Here is the i2cmux configuration for our board. You can ignore mentions of CAM0, and it is accurate that our mux only uses channels 1 and 2, skipping 0.

#define CAM0_PWDN	TEGRA194_MAIN_GPIO(P, 4)
#define CAM1_PWDN	TEGRA194_MAIN_GPIO(P, 5)
#define CAM2_PWDN	TEGRA194_MAIN_GPIO(Q, 6)
#define CAM_I2C_MUX_B 	TEGRA194_AON_GPIO(CC, 3)
#define CAM_I2C_MUX_A 	TEGRA194_MAIN_GPIO(R, 0)

/ {
	cam_i2cmux {
		compatible = "i2c-mux-gpio";
		#address-cells = <1>;
		#size-cells = <0>;
		i2c-parent = <&cam_i2c>;
		mux-gpios = <&tegra_main_gpio CAM_I2C_MUX_A GPIO_ACTIVE_HIGH &tegra_aon_gpio CAM_I2C_MUX_B GPIO_ACTIVE_HIGH>;
		i2c@1 {
			reg = <1>;
			#address-cells = <1>;
			#size-cells = <0>;
			rbpcv3_imx477_c@1a {
				reset-gpios = <&tegra_main_gpio CAM1_PWDN GPIO_ACTIVE_HIGH>;
			};
		};
		i2c@2 {
			reg = <2>;
			#address-cells = <1>;
			#size-cells = <0>;
			rbpcv3_imx477_e@1a {
				reset-gpios = <&tegra_main_gpio CAM2_PWDN GPIO_ACTIVE_HIGH>;
			};
		};
	};

	gpio@6000d000 {
		camera-control-output-low {
			gpio-hog;
			output-low;
			gpios = < CAM1_PWDN 0  CAM2_PWDN 0>;
			label = "cam1-pwdn", "cam2-pwdn";
		};
	};
};

And here is the dtsi for the imager configuration.

/ {
	host1x {
		vi@15c10000 {
			num-channels = <2>;
			ports {
				#address-cells = <1>;
				#size-cells = <0>;
				port@0 {
					reg = <0>;
					rbpcv3_imx477_vi_in0: endpoint {
						port-index = <4>; // one of these has to be wrong...?
						bus-width = <2>;
						remote-endpoint = <&rbpcv3_imx477_csi_out0>;
					};
				};
				port@1 {
					reg = <1>;
					rbpcv3_imx477_vi_in1: endpoint {
						port-index = <6>; // one of these has to be wrong...?
						bus-width = <2>;
						remote-endpoint = <&rbpcv3_imx477_csi_out1>;
					};
				};
			};
		};

		nvcsi@15a00000 {
			num-channels = <2>;
			#address-cells = <1>;
			#size-cells = <0>;
			channel@0 {
				reg = <0>;
				ports {
					#address-cells = <1>;
					#size-cells = <0>;
					port@0 {
						reg = <0>;
						rbpcv3_imx477_csi_in0: endpoint@0 {
							port-index = <2>;
							bus-width = <2>;
							remote-endpoint = <&rbpcv3_imx477_dual_out0>;
						};
					};
					port@1 {
						reg = <1>;
						rbpcv3_imx477_csi_out0: endpoint@1 {
							remote-endpoint = <&rbpcv3_imx477_vi_in0>;
						};
					};
				};
			};
			channel@1 {
				reg = <1>;
				ports {
					#address-cells = <1>;
					#size-cells = <0>;
					port@2 {
						reg = <0>;
						rbpcv3_imx477_csi_in1: endpoint@2 {
							port-index = <4>;
							bus-width = <2>;
							remote-endpoint = <&rbpcv3_imx477_out1>;
						};
					};
					port@3 {
						reg = <1>;
						rbpcv3_imx477_csi_out1: endpoint@3 {
							remote-endpoint = <&rbpcv3_imx477_vi_in1>;
						};
					};
				};
			};
		};
	};

	cam_i2cmux {
		i2c@1 {
			imx477_cam0: rbpcv3_imx477_c@1a {
				compatible = "ridgerun,imx477";
				/* I2C device address */
				reg = <0x1a>;

				/* V4L2 device node location */
				devnode = "video0";

				/* Physical dimensions of sensor */
				physical_w = "3.680";
				physical_h = "2.760";

				sensor_model = "imx477";

				use_sensor_mode_id = "true";

				/**
				* ==== Modes ====
				* A modeX node is required to support v4l2 driver
				* implementation with NVIDIA camera software stack
				*
				* == Signal properties ==
				*
				* phy_mode = "";
				* PHY mode used by the MIPI lanes for this device
				*
				* tegra_sinterface = "";
				* CSI Serial interface connected to tegra
				* Incase of virtual HW devices, use virtual
				* For SW emulated devices, use host
				*
				* pix_clk_hz = "";
				* Sensor pixel clock used for calculations like exposure and framerate
				*
				* readout_orientation = "0";
				* Based on camera module orientation.
				* Only change readout_orientation if you specifically
				* Program a different readout order for this mode
				*
				* == Image format Properties ==
				*
				* active_w = "";
				* Pixel active region width
				*
				* active_h = "";
				* Pixel active region height
				*
				* pixel_t = "";
				* The sensor readout pixel pattern
				*
				* line_length = "";
				* Pixel line length (width) for sensor mode.
				*
				* == Source Control Settings ==
				*
				* Gain factor used to convert fixed point integer to float
				* Gain range [min_gain/gain_factor, max_gain/gain_factor]
				* Gain step [step_gain/gain_factor is the smallest step that can be configured]
				* Default gain [Default gain to be initialized for the control.
				*     use min_gain_val as default for optimal results]
				* Framerate factor used to convert fixed point integer to float
				* Framerate range [min_framerate/framerate_factor, max_framerate/framerate_factor]
				* Framerate step [step_framerate/framerate_factor is the smallest step that can be configured]
				* Default Framerate [Default framerate to be initialized for the control.
				*     use max_framerate to get required performance]
				* Exposure factor used to convert fixed point integer to float
				* For convenience use 1 sec = 1000000us as conversion factor
				* Exposure range [min_exp_time/exposure_factor, max_exp_time/exposure_factor]
				* Exposure step [step_exp_time/exposure_factor is the smallest step that can be configured]
				* Default Exposure Time [Default exposure to be initialized for the control.
				*     Set default exposure based on the default_framerate for optimal exposure settings]
				*
				* gain_factor = ""; (integer factor used for floating to fixed point conversion)
				* min_gain_val = ""; (ceil to integer)
				* max_gain_val = ""; (ceil to integer)
				* step_gain_val = ""; (ceil to integer)
				* default_gain = ""; (ceil to integer)
				* Gain limits for mode
				*
				* exposure_factor = ""; (integer factor used for floating to fixed point conversion)
				* min_exp_time = ""; (ceil to integer)
				* max_exp_time = ""; (ceil to integer)
				* step_exp_time = ""; (ceil to integer)
				* default_exp_time = ""; (ceil to integer)
				* Exposure Time limits for mode (sec)
				*
				* framerate_factor = ""; (integer factor used for floating to fixed point conversion)
				* min_framerate = ""; (ceil to integer)
				* max_framerate = ""; (ceil to integer)
				* step_framerate = ""; (ceil to integer)
				* default_framerate = ""; (ceil to integer)
				* Framerate limits for mode (fps)
				*
				* embedded_metadata_height = "";
				* Sensor embedded metadata height in units of rows.
				* If sensor does not support embedded metadata value should be 0.
				*/
				mode0 { /* IMX477_MODE_3840x2160 */
					mclk_khz = "24000";
					num_lanes = "2";
					tegra_sinterface = "serial_c";
					phy_mode = "DPHY";
					discontinuous_clk = "no";
					dpcm_enable = "false";
					cil_settletime = "0";

					active_w = "3840";
					active_h = "2160";
					mode_type = "bayer";
					pixel_phase = "rggb";
					csi_pixel_bit_depth = "10";
					readout_orientation = "90";
					line_length = "11200";
					inherent_gain = "1";
					mclk_multiplier = "80";
					pix_clk_hz = "840000000";

					gain_factor = "16";
					framerate_factor = "1000000";
					exposure_factor = "1000000";
					min_gain_val = "16"; /* 1.00x */
					max_gain_val = "356"; /* 22x */
					step_gain_val = "1";
					default_gain = "16"; /* 1.00x */
					min_hdr_ratio = "1";
					max_hdr_ratio = "1";
					min_framerate = "2000000"; /* 2.0 fps */
					max_framerate = "30000000"; /* 30.0 fps */
					step_framerate = "1";
					default_framerate = "30000000"; /* 30.0 fps */
					min_exp_time = "13"; /* us */
					max_exp_time = "683709"; /* us */
					step_exp_time = "1";
					default_exp_time = "2495"; /* us */

					embedded_metadata_height = "2";
				};
				mode1 { /* IMX477_MODE_1920X1080 */
					mclk_khz = "24000";
					num_lanes = "2";
					tegra_sinterface = "serial_c";
					phy_mode = "DPHY";
					discontinuous_clk = "no";
					dpcm_enable = "false";
					cil_settletime = "0";

					active_w = "1920";
					active_h = "1080";
					mode_type = "bayer";
					pixel_phase = "rggb";
					csi_pixel_bit_depth = "10";
					readout_orientation = "90";
					line_length = "7000";
					inherent_gain = "1";
					mclk_multiplier = "80";
					pix_clk_hz = "840000000";

					gain_factor = "16";
					framerate_factor = "1000000";
					exposure_factor = "1000000";
					min_gain_val = "16"; /* 1.00x */
					max_gain_val = "356"; /* 22x */
					step_gain_val = "1";
					default_gain = "16"; /* 1.00x */
					min_hdr_ratio = "1";
					max_hdr_ratio = "1";
					min_framerate = "2000000"; /* 2.0 fps */
					max_framerate = "60000000"; /* 60.0 fps */
					step_framerate = "1";
					default_framerate = "60000000"; /* 60.0 fps */
					min_exp_time = "13"; /* us */
					max_exp_time = "683709"; /* us */
					step_exp_time = "1";
					default_exp_time = "2495"; /* us */

					embedded_metadata_height = "2";
				};

				ports {
					#address-cells = <1>;
					#size-cells = <0>;

					port@0 {
						reg = <0>;
						rbpcv3_imx477_dual_out0: endpoint {
							port-index = <2>;
							bus-width = <2>;
							remote-endpoint = <&rbpcv3_imx477_csi_in0>;
						};
					};
				};
			};
		};
		i2c@2 {
			imx477_cam1: rbpcv3_imx477_e@1a {
				compatible = "ridgerun,imx477";
				/* I2C device address */
				reg = <0x1a>;

				/* V4L2 device node location */
				devnode = "video1";

				/* Physical dimensions of sensor */
				physical_w = "3.680";
				physical_h = "2.760";

				sensor_model = "imx477";

				use_sensor_mode_id = "true";

				mode0 { /* IMX477_MODE_3840x2160 */
					mclk_khz = "24000";
					num_lanes = "2";
					tegra_sinterface = "serial_e";
					phy_mode = "DPHY";
					discontinuous_clk = "no";
					dpcm_enable = "false";
					cil_settletime = "0";

					active_w = "3840";
					active_h = "2160";
					mode_type = "bayer";
					pixel_phase = "rggb";
					csi_pixel_bit_depth = "10";
					readout_orientation = "90";
					line_length = "11200";
					inherent_gain = "1";
					mclk_multiplier = "80";
					pix_clk_hz = "840000000";

					gain_factor = "16";
					framerate_factor = "1000000";
					exposure_factor = "1000000";
					min_gain_val = "16"; /* 1.00x */
					max_gain_val = "356"; /* 22x */
					step_gain_val = "1";
					default_gain = "16"; /* 1.00x */
					min_hdr_ratio = "1";
					max_hdr_ratio = "1";
					min_framerate = "2000000"; /* 2.0 fps */
					max_framerate = "30000000"; /* 30.0 fps */
					step_framerate = "1";
					default_framerate = "30000000"; /* 30.0 fps */
					min_exp_time = "13"; /* us */
					max_exp_time = "683709"; /* us */
					step_exp_time = "1";
					default_exp_time = "2495"; /* us */

					embedded_metadata_height = "2";
				};
				mode1 { /* IMX477_MODE_1920X1080 */
					mclk_khz = "24000";
					num_lanes = "2";
					tegra_sinterface = "serial_e";
					phy_mode = "DPHY";
					discontinuous_clk = "no";
					dpcm_enable = "false";
					cil_settletime = "0";

					active_w = "1920";
					active_h = "1080";
					mode_type = "bayer";
					pixel_phase = "rggb";
					csi_pixel_bit_depth = "10";
					readout_orientation = "90";
					line_length = "7000";
					inherent_gain = "1";
					mclk_multiplier = "80";
					pix_clk_hz = "840000000";

					gain_factor = "16";
					framerate_factor = "1000000";
					exposure_factor = "1000000";
					min_gain_val = "16"; /* 1.00x */
					max_gain_val = "356"; /* 22x */
					step_gain_val = "1";
					default_gain = "16"; /* 1.00x */
					min_hdr_ratio = "1";
					max_hdr_ratio = "1";
					min_framerate = "2000000"; /* 2.0 fps */
					max_framerate = "60000000"; /* 60.0 fps */
					step_framerate = "1";
					default_framerate = "60000000"; /* 60.0 fps */
					min_exp_time = "13"; /* us */
					max_exp_time = "683709"; /* us */
					step_exp_time = "1";
					default_exp_time = "2495"; /* us */

					embedded_metadata_height = "2";
				};

				ports {
					#address-cells = <1>;
					#size-cells = <0>;

					port@0 {
						reg = <0>;
						rbpcv3_imx477_out1: endpoint {
							port-index = <4>;
							bus-width = <2>;
							remote-endpoint = <&rbpcv3_imx477_csi_in1>;
						};
					};
				};
			};
		};
	};
};

/ {
	tegra-camera-platform {
		compatible = "nvidia, tegra-camera-platform";

		/**
		* Physical settings to calculate max ISO BW
		*
		* num_csi_lanes = <>;
		* Total number of CSI lanes when all cameras are active
		*
		* max_lane_speed = <>;
		* Max lane speed in Kbit/s
		*
		* min_bits_per_pixel = <>;
		* Min bits per pixel
		*
		* vi_peak_byte_per_pixel = <>;
		* Max byte per pixel for the VI ISO case
		*
		* vi_bw_margin_pct = <>;
		* Vi bandwidth margin in percentage
		*
		* max_pixel_rate = <>;
		* Max pixel rate in Kpixel/s for the ISP ISO case
		*
		* isp_peak_byte_per_pixel = <>;
		* Max byte per pixel for the ISP ISO case
		*
		* isp_bw_margin_pct = <>;
		* Isp bandwidth margin in percentage
		*/
		num_csi_lanes = <4>;
		max_lane_speed = <1500000>;
		min_bits_per_pixel = <10>;
		vi_peak_byte_per_pixel = <2>;
		vi_bw_margin_pct = <25>;
		max_pixel_rate = <7500000>;
		isp_peak_byte_per_pixel = <5>;
		isp_bw_margin_pct = <25>;

		/**
		 * The general guideline for naming badge_info contains 3 parts, and is as follows,
		 * The first part is the camera_board_id for the module; if the module is in a FFD
		 * platform, then use the platform name for this part.
		 * The second part contains the position of the module, ex. "rear" or "front".
		 * The third part contains the last 6 characters of a part number which is found
		 * in the module's specsheet from the vendor.
		 */
		modules {
			module0 {
				badge = "jakku_front_IMX477";
				position = "front";
				orientation = "1";
				drivernode0 {
					pcl_id = "v4l2_sensor";
					devname = "imx477 9-001a";
					proc-device-tree = "/proc/device-tree/cam_i2cmux/i2c@1/rbpcv3_imx477_c@1a";
				};
			};
			module1 {
				badge = "jakku_rear_IMX477";
				position = "rear";
				orientation = "1";
				drivernode0 {
					pcl_id = "v4l2_sensor";
					devname = "imx477 10-001a";
					proc-device-tree = "/proc/device-tree/cam_i2cmux/i2c@2/rbpcv3_imx477_e@1a";
				};
			};
		};
	};
};

Would anyone have any idea what else I could be doing wrong? I’ve asked the hardware guys to probe the CSI signal as close to the SoM as possible to check for signal integrity issues. That said, any feedback on my configuration of the Jetson would be deeply appreciated.

Thank you immensely for reading and I appreciate your time.

[1] Using sources available here in /hardware/nvidia/platform/t19x/jakku/kernel-dts/common, modified copies of tegra194-camera-jakku-rbpcv3-imx477.dtsi and tegra194-camera-rbpcv3-imx477.dtsi.
[2] Running sudo ./flash.sh -k kernel-dtb jetson-xavier-nx-devkit-emmc mmcblk0p1 on a host machine running Ubuntu 18 while the Jetson is in recovery mode connected to host via USB

The port-index in vi@xxx scope is incorrect. Should be 2 and 4 instead of 4 and 6

	vi@15c10000 {
		num-channels = <2>;
		ports {
			#address-cells = <1>;
			#size-cells = <0>;
			port@0 {
				reg = <0>;
				rbpcv3_imx477_vi_in0: endpoint {
					port-index = <4>; // one of these has to be wrong...?
					bus-width = <2>;
					remote-endpoint = <&rbpcv3_imx477_csi_out0>;
				};
			};
			port@1 {
				reg = <1>;
				rbpcv3_imx477_vi_in1: endpoint {
					port-index = <6>; // one of these has to be wrong...?
					bus-width = <2>;
					remote-endpoint = <&rbpcv3_imx477_csi_out1>;
				};
			};

Hi Shane,

Thanks for your response. Using the below vi scope section has enabled one imager, but not the other.
Here’s my current snippet:

   vi@15c10000 {
              num-channels = <2>;
              ports {
                  #address-cells = <1>;
                  #size-cells = <0>;
                  port@0 {
                      reg = <0>;
                      rbpcv3_imx477_vi_in0: endpoint {
~                         port-index = <2>;
                          bus-width = <2>;
                          remote-endpoint = <&rbpcv3_imx477_csi_out0>;
                      };
                  };
                  port@1 {
                      reg = <1>;
                      rbpcv3_imx477_vi_in1: endpoint {
~                         port-index = <4>;
                          bus-width = <2>;
                          remote-endpoint = <&rbpcv3_imx477_csi_out1>;
                      };
                  };
              };

I can now use libargus to show a preview of sensor id 1. However, sensor id 0 still yields this error message in dmesg:

[  103.371894] [RCE] vi5_hwinit: firmware CL2018101701 protocol version 2.2
[  108.379902] tegra194-vi5 15c10000.vi: no reply from camera processor
[  108.380073] tegra194-vi5 15c10000.vi: uncorr_err: request timed out after 2500 ms
[  108.380308] tegra194-vi5 15c10000.vi: err_rec: attempting to reset the capture channel
[  108.386210] tegra194-vi5 15c10000.vi: err_rec: successfully reset the capture channel
[  108.425013] tegra194-vi5 15c10000.vi: corr_err: discarding frame 80, flags: 112, err_data 39845986
[  108.458371] tegra194-vi5 15c10000.vi: corr_err: discarding frame 81, flags: 112, err_data 39845986
[  108.491686] tegra194-vi5 15c10000.vi: corr_err: discarding frame 82, flags: 112, err_data 39845986
[  108.524980] tegra194-vi5 15c10000.vi: corr_err: discarding frame 83, flags: 112, err_data 39845986

I double checked and I can still see a CSI signal on the sensor which is yielding this message.

What else could be the problem?

Hi shoelick,

I can see in your device tree that the camera nodes you are using i2c@1/ i2c@2 instead of i2c@0/i2c@1, is there a reason for it? Could you try testing with the original values to see if you are able to capture from the first camera as well?

Best Regards,
Roberto Gutierrez
Embedded Software Engineer

Hi Roberto, thanks for your response!

It is intentional that our i2c addressing skips 0, as the 0 channel on our mux is not used on this board. You can see I added a second GPIO for the mux select, which enables up to four imagers with a BOM change. The mux select is two bits—channels 0 and 3 are not used, and imagers are on channels 1 and 2. It’s slightly confusing, but imager 0 is on mux channel 1 and imager 1 is on channel 2.

The configuration I have is based on the understanding that the the addresses you’re alluding to are actually used to dictate the state of the mux select signal, as documented in the Linux kernel documentation:

Whenever an access is made to a device on a child bus, the value set
in the relevant node’s reg property will be output using the list of
GPIOs, the first in the list holding the least-significant value.

Additionally, from the eLinux wiki:

In general, the unit address is the primary address used to access the device, and is listed in the node’s reg property.

Additionally, I’m confident the i2c muxing is correct because:

  • the i2c drivers bind correctly on boot, according to dmesg (see the output of dmesg in my first post)
  • When I use the v4l2-ctl command to test image acquisition on either imager, I can see activity on the CSI lines of whichever imager I select:
    • if I do v4l2-ctl -d /dev/video1 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=3, this command works as expected. The imager on mux select 2 connects and I can even capture images through libargus gstreamer plugins.
    • If I instead use /dev/video0 (i.e., the imager which is not yet working: v4l2-ctl -d /dev/video0 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=3), while the command hangs and I get the error messages listed in the above dmesg output, I can still probe and see the camera being started over i2c, and I can see the offending imx477 (cam 0 / mux channel 1) sending data by probing its CSI data lines.

For these reasons I don’t think it’s necessary to change my i2c addressing, but if you see a flaw in my reasoning I will still try it. My greater suspicion continues to lie with the port-index values of the video pipeline elements.

Hi,

Thanks for the detailed explanation, seems like your reasoning is right.

Some tests I would do to try and characterize the issue better, could be:

  • Replacing the second port with a 6 again (leave 2 and 6), and check that the second camera is not working as expected.
  • Replace the first port with a 0, just to check that there is no data coming from that port.
  • Another test you could be doing is just test the second camera only (the one that working) alone with the first connected, and then move on to the first one alone.

I have worked in the past with NX that have the CAM0 port use the port index 2, and the CAM1 using the port index 0, so they are kind off swapped. This also makes me suspicious of the port idx as well.

Hope this gives some insight

Regards,
Roberto

Thanks Roberto, sorry for over-explaining, I am new to this platform and want to make sure I’m not missing anything. :-)

The first test you proposed went as expected: both drivers still bound, and upon running the v4l2-ctl command, both (separately) still give no reply from camera processor in dmesg and have data moving on their respective CSI data lines.

The second test you proposed also went as expected–having cam0’s vi port-index as 0 yields the same no reply from camera processor in dmesg. I went ahead and tried 1, 3, 5 for vi port-index for the h*ck of it and had no different result.

I will go ahead and try some variants of the third test you’re proposing, making sure CAM1 works in isolation and then move on to trying CAM0 in isolation. While I do that, I’m dying to understand the relationship between the port index parameters of each of the video pipeline elements (driver, nvcsi, and vi).

The current diagram from r35.1 looks to have missing/incorrect labels relative to past diagrams. Can I assume the port layout is the same between Xavier NX and AGX Xavier?

The diagram back from r32.7.1 has a few more helpful labels, but so far I haven’t been able to consistently map it to my own experience of what works. For example, right now I’ve confirmed Serial E works with port-index 4 in all three device tree components, which is consistent with the diagram. However, the same pattern for serial C doesn’t seem to be working, and additionally the devkit device tree puts serial C through driver port-index 2, nvcsi port-index 2, and then vi port-index 4 (see footnote [1] to my first post for the sources I’m referencing) … Is there a pattern to any of this?

Is your observation reflected in any documentation that I’ve maybe missed? Is it possible there’s some kind of conflict between vi port-index values, considering the devkit uses vi 4 for serial c and I have serial E working for port index 4?

Thanks, I really, really appreciate your time.

Just following up, I confirmed CAM1 works alone with the same port configuration. CAM0 continues to not work, with neither the port configuration recommended by @ShaneCCC or with the port configuration matching that of the Jakku device tree. That is, CAM0 doesn’t seem to work with vi port-index 4, so my theory about some kind of conflict doesn’t seem to hold water.

Hi again, following up with trying to get the second IMX477 running on lanes CSI2 D0 and D1.

Firstly I’ve confirmed the sensor isn’t faulty by swapping the sensors and observing the imager on CSI2 persists. Second, I realized that running with the port-index values that Shane recommended did change the the error messages I’m receiving for this CSI port.

First, running sudo bash -c "echo 'file camera_common.c +p' > /sys/kernel/debug/dynamic_debug/control" and then following dmesg gets me:

[  833.286349] imx477 9-001a: camera_common_mclk_enable: enable MCLK with 24000000 Hz
[  833.286391] imx477 9-001a: camera_common_dpd_disable: csi 2
[  833.627869] [RCE] vi5_hwinit: firmware CL2018101701 protocol version 2.2
[  833.733390] tegra194-vi5 15c10000.vi: corr_err: discarding frame 1, flags: 112, err_data 39845986
[  833.766745] tegra194-vi5 15c10000.vi: corr_err: discarding frame 2, flags: 112, err_data 39845986
[  833.800056] tegra194-vi5 15c10000.vi: corr_err: discarding frame 3, flags: 112, err_data 39845986
[  833.833380] tegra194-vi5 15c10000.vi: corr_err: discarding frame 4, flags: 112, err_data 39845986
[  856.355334] imx477 9-001a: camera_common_dpd_enable: csi 2
[  856.355343] imx477 9-001a: camera_common_mclk_disable: disable MCLK

Notably, the no reply from camera processor is gone, and after those first four frames, the corr_err message stops and does NOT output continuously.

Next, going back and enabling the same debug trace output with:

sudo bash -c "echo 1 > /sys/kernel/debug/tracing/tracing_on 
echo 30720 > /sys/kernel/debug/tracing/buffer_size_kb
 echo 1 > /sys/kernel/debug/tracing/events/tegra_rtcpu/enable
 echo 1 > /sys/kernel/debug/tracing/events/freertos/enable
 echo 2 > /sys/kernel/debug/camrtc/log-level 
echo 1 > /sys/kernel/debug/tracing/events/camera_common/enable 
echo > /sys/kernel/debug/tracing/trace”

and then sudo cat /sys/kernel/debug/tracing/trace gives:

     kworker/1:0-8634  [001] ....   983.156616: rtcpu_nvcsi_intr: tstamp:31128915432 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006                                                                                                                                                         [9465/9485]
     kworker/1:0-8634  [001] ....   983.156616: rtcpu_nvcsi_intr: tstamp:31128915432 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156616: rtcpu_nvcsi_intr: tstamp:31128916044 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156617: rtcpu_nvcsi_intr: tstamp:31128916044 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156617: rtcpu_nvcsi_intr: tstamp:31128916656 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156617: rtcpu_nvcsi_intr: tstamp:31128916656 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156617: rtcpu_nvcsi_intr: tstamp:31128917270 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156617: rtcpu_nvcsi_intr: tstamp:31128917270 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156618: rtcpu_nvcsi_intr: tstamp:31128917884 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156618: rtcpu_nvcsi_intr: tstamp:31128917884 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156618: rtcpu_nvcsi_intr: tstamp:31128918495 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156618: rtcpu_nvcsi_intr: tstamp:31128918495 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x00000002
     kworker/1:0-8634  [001] ....   983.156618: rtcpu_nvcsi_intr: tstamp:31128918495 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156619: rtcpu_nvcsi_intr: tstamp:31128918495 class:CORRECTABLE_ERR type:PHY_INTR phy:1 cil:0 st:0 vc:0 status:0x00000002
     kworker/1:0-8634  [001] ....   983.156619: rtcpu_nvcsi_intr: tstamp:31128919461 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156619: rtcpu_nvcsi_intr: tstamp:31128919461 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156619: rtcpu_nvcsi_intr: tstamp:31128920073 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156619: rtcpu_nvcsi_intr: tstamp:31128920073 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156620: rtcpu_nvcsi_intr: tstamp:31128920689 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156620: rtcpu_nvcsi_intr: tstamp:31128920689 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x00000002
     kworker/1:0-8634  [001] ....   983.156621: rtcpu_nvcsi_intr: tstamp:31128920689 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156621: rtcpu_nvcsi_intr: tstamp:31128920689 class:CORRECTABLE_ERR type:PHY_INTR phy:1 cil:0 st:0 vc:0 status:0x00000002
     kworker/1:0-8634  [001] ....   983.156621: rtcpu_nvcsi_intr: tstamp:31128921656 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156621: rtcpu_nvcsi_intr: tstamp:31128921656 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156622: rtcpu_nvcsi_intr: tstamp:31128922270 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156622: rtcpu_nvcsi_intr: tstamp:31128922270 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156622: rtcpu_nvcsi_intr: tstamp:31128922884 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156622: rtcpu_nvcsi_intr: tstamp:31128922884 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156622: rtcpu_nvcsi_intr: tstamp:31128923495 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156623: rtcpu_nvcsi_intr: tstamp:31128923495 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156623: rtcpu_nvcsi_intr: tstamp:31128924107 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156623: rtcpu_nvcsi_intr: tstamp:31128924107 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156623: rtcpu_nvcsi_intr: tstamp:31128924719 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156623: rtcpu_nvcsi_intr: tstamp:31128924719 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156624: rtcpu_nvcsi_intr: tstamp:31128925331 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156624: rtcpu_nvcsi_intr: tstamp:31128925331 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156624: rtcpu_nvcsi_intr: tstamp:31128925943 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156624: rtcpu_nvcsi_intr: tstamp:31128925943 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156625: rtcpu_nvcsi_intr: tstamp:31128926597 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:0-8634  [001] ....   983.156625: rtcpu_nvcsi_intr: tstamp:31128926597 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x00000002

Based on @ShaneCCC’s recommendation in various posts and the eLinux wiki I went ahead and tried this again while boosting clocks. Reboot, run the previous command to enable trace logs, and now boost clocks to max:

sudo bash -c "echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked 
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked 
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked 
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate 
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee  /sys/kernel/debug/bpmp/debug/clk/isp/rate 
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate"

This output adds a few more new messages:
sudo cat /sys/kernel/debug/tracing/trace:

     kworker/1:3-2098  [001] ....    77.454435: rtcpu_nvcsi_intr: tstamp:2826656033 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000002
     kworker/1:3-2098  [001] ....    77.454436: rtcpu_nvcsi_intr: tstamp:2826656033 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x00000002
     kworker/1:3-2098  [001] ....    77.454437: rtcpu_nvcsi_intr: tstamp:2826656033 class:CORRECTABLE_ERR type:STREAM_NOVC phy:0 cil:0 st:2 vc:0 status:0x00000001
     kworker/1:3-2098  [001] ....    77.454438: rtcpu_nvcsi_intr: tstamp:2826656033 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:3-2098  [001] ....    77.454438: rtcpu_nvcsi_intr: tstamp:2826656033 class:CORRECTABLE_ERR type:PHY_INTR phy:1 cil:0 st:0 vc:0 status:0x00000002
     kworker/1:3-2098  [001] ....    77.454439: rtcpu_nvcsi_intr: tstamp:2826657331 class:GLOBAL type:STREAM_NOVC phy:0 cil:0 st:2 vc:0 status:0x00000001
     kworker/1:3-2098  [001] ....    77.454440: rtcpu_nvcsi_intr: tstamp:2826657331 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:3-2098  [001] ....    77.454441: rtcpu_nvcsi_intr: tstamp:2826657331 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x00000002
     kworker/1:3-2098  [001] ....    77.454441: rtcpu_nvcsi_intr: tstamp:2826657331 class:CORRECTABLE_ERR type:STREAM_NOVC phy:0 cil:0 st:2 vc:0 status:0x00000001
     kworker/1:3-2098  [001] ....    77.454442: rtcpu_nvcsi_intr: tstamp:2826657331 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:3-2098  [001] ....    77.454443: rtcpu_nvcsi_intr: tstamp:2826657331 class:CORRECTABLE_ERR type:PHY_INTR phy:1 cil:0 st:0 vc:0 status:0x00000002
     kworker/1:3-2098  [001] ....    77.454444: rtcpu_nvcsi_intr: tstamp:2826658641 class:GLOBAL type:STREAM_NOVC phy:0 cil:0 st:2 vc:0 status:0x00000001
     kworker/1:3-2098  [001] ....    77.454444: rtcpu_nvcsi_intr: tstamp:2826658641 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:3-2098  [001] ....    77.454445: rtcpu_nvcsi_intr: tstamp:2826658641 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x00000002
     kworker/1:3-2098  [001] ....    77.454446: rtcpu_nvcsi_intr: tstamp:2826658641 class:CORRECTABLE_ERR type:STREAM_NOVC phy:0 cil:0 st:2 vc:0 status:0x00000001
     kworker/1:3-2098  [001] ....    77.454447: rtcpu_nvcsi_intr: tstamp:2826658641 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:3-2098  [001] ....    77.454447: rtcpu_nvcsi_intr: tstamp:2826658641 class:CORRECTABLE_ERR type:PHY_INTR phy:1 cil:0 st:0 vc:0 status:0x00000002
     kworker/1:3-2098  [001] ....    77.454448: rtcpu_nvcsi_intr: tstamp:2826659932 class:GLOBAL type:STREAM_NOVC phy:0 cil:0 st:2 vc:0 status:0x00000001
     kworker/1:3-2098  [001] ....    77.454449: rtcpu_nvcsi_intr: tstamp:2826659932 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x00000002
     kworker/1:3-2098  [001] ....    77.454450: rtcpu_nvcsi_intr: tstamp:2826659932 class:CORRECTABLE_ERR type:STREAM_NOVC phy:0 cil:0 st:2 vc:0 status:0x00000001
     kworker/1:3-2098  [001] ....    77.454450: rtcpu_nvcsi_intr: tstamp:2826659932 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:3-2098  [001] ....    77.454451: rtcpu_nvcsi_intr: tstamp:2826659932 class:CORRECTABLE_ERR type:PHY_INTR phy:1 cil:0 st:0 vc:0 status:0x00000002
     kworker/1:3-2098  [001] ....    77.454452: rtcpu_nvcsi_intr: tstamp:2826661060 class:GLOBAL type:STREAM_NOVC phy:0 cil:0 st:2 vc:0 status:0x00000001
     kworker/1:3-2098  [001] ....    77.454453: rtcpu_nvcsi_intr: tstamp:2826661060 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:3-2098  [001] ....    77.454453: rtcpu_nvcsi_intr: tstamp:2826661060 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x00000002
     kworker/1:3-2098  [001] ....    77.454454: rtcpu_nvcsi_intr: tstamp:2826661060 class:CORRECTABLE_ERR type:STREAM_NOVC phy:0 cil:0 st:2 vc:0 status:0x00000001
     kworker/1:3-2098  [001] ....    77.454455: rtcpu_nvcsi_intr: tstamp:2826661060 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:3-2098  [001] ....    77.454456: rtcpu_nvcsi_intr: tstamp:2826661060 class:CORRECTABLE_ERR type:PHY_INTR phy:1 cil:0 st:0 vc:0 status:0x00000002
     kworker/1:3-2098  [001] ....    77.454456: rtcpu_nvcsi_intr: tstamp:2826662356 class:GLOBAL type:STREAM_NOVC phy:0 cil:0 st:2 vc:0 status:0x00000001
     kworker/1:3-2098  [001] ....    77.454457: rtcpu_nvcsi_intr: tstamp:2826662356 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:3-2098  [001] ....    77.454458: rtcpu_nvcsi_intr: tstamp:2826662356 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x00000002
     kworker/1:3-2098  [001] ....    77.454459: rtcpu_nvcsi_intr: tstamp:2826662356 class:CORRECTABLE_ERR type:STREAM_NOVC phy:0 cil:0 st:2 vc:0 status:0x00000001
     kworker/1:3-2098  [001] ....    77.454459: rtcpu_nvcsi_intr: tstamp:2826662356 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:3-2098  [001] ....    77.454460: rtcpu_nvcsi_intr: tstamp:2826662356 class:CORRECTABLE_ERR type:PHY_INTR phy:1 cil:0 st:0 vc:0 status:0x00000002
     kworker/1:3-2098  [001] ....    77.454461: rtcpu_nvcsi_intr: tstamp:2826663651 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
     kworker/1:3-2098  [001] ....    77.454462: rtcpu_nvcsi_intr: tstamp:2826663651 class:GLOBAL

Between some Shane’s past posts[3][4] and the Xavier technical reference, it seems like these are the main takeways from this output:

  • rtcpu_nvcsi_intr: tstamp:31128915432 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:2 vc:0 status:0x00000006
    • STREAM_VC is register NVCSI_STREAM_0_INTR_STATUS_VC0_0
    • Getting error bits 2 and 1 named intr_stat_pd_crc_err_vc0 and intr_stat_ph_ecc_single_bit_err_vc0
  • rtcpu_nvcsi_intr: tstamp:2826656033 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x00000002
    • PHY_INTRO is register NVCSI_PHY_0_CILA_INTR_0_STATUS_CILA_0
    • Bit 1 is intr_cil_data_lane_sot_sb_err0_a, which from Shane’s comments I assume sb means single bit?
  • rtcpu_nvcsi_intr: tstamp:2826661060 class:CORRECTABLE_ERR type:STREAM_NOVC phy:0 cil:0 st:2 vc:0 status:0x00000001
    • STREAM_NOVC is register NVCSI_STREAM_0_INTR_STATUS_NOVC_0
    • Bit 0 is intr_stat_ph_ecc_multi_bit_err

Clearly the SoC is unhappy about CRC/ECC issues. Any guidance for debugging this would be much appreciated.

Is the next step to mask these error bits as was recommended in Problem with capturing images by Video4Linux - #13 by ShaneCCC ? I’d like to understand why the integrity checks are failing…

Thanks again.

[3] How to interpret CSI debug information - #3 by ShaneCCC
[4] GMSL camera return “STREAM_NOVC" error and no image - #3 by ShaneCCC

I would suggest consulting with sensor vendor for the packet head ECC and Pay load data CRC error.

Thanks

Shane,

As I mentioned, if I swap the imagers between the working CSI lanes and the non-working lanes, the issue stays consistent with the CSI lanes, not the imagers. These are off-the-shelf Arducam imager boards with the IMX477—they are fairly tried and true. I see no reason to doubt the functionality of the sensor. Why should I go to the vendor for this information?

Instead, maybe you could answer some of my previous questions.

The port index section of the documentation is wrong compared to the working example. Why can a single vi port be made available to multiple CSI ports?

I don’t aware it’s IMX477, for that I would suspect it could be HW problem.

Which reference configure the “serial C through driver port-index 2, nvcsi port-index 2, and then vi port-index 4” ? It should be 2 instead of 4

Ah, it seems tegra194-camera-rbpcv3-imx477.dtsi has the wrong values but it is fixed with the overlay. in tegra194-p3668-all-p3509-0000-camera-imx477-dual.dts. Maybe you could get that fixed…

I will keep doing some more testing to see if I can find other hardware issues.

Below you’ll see a scope capture of one of the data lines that has some noise on it. Additionally, I found that using with nvgstcapture instead of v4l2-ctl, I can actually acquire a preview of a broken image. At this point it seems like the device tree is correct and that there is a signal integrity problem. Unless anyone has another recommendations, we can close with this topic concluding there’s a hardware issue.


The top capture looks fine but there’s weird noise on the lower one.


Pixelated capture, presumably an issue with the data. (The pink is an issue we’ve encountered previously and a bug somewhere in the camera stack. Somewhere it seems color components are getting swapped. Different issue with a known workaround.)

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.