IMX219 doesn't stream on CAM0 port on Orin Nano DevKit

Autonomous Machines Jetson & Embedded Systems Jetson Orin Nano
,
1

Hi,

There seems to be an issue with the CAM0 CSI port on Orin Nano Devkit. With the original JetPack 5.1.1, the IMX219 Raspi Camera works fine on the CAM1 CSI port but not on the CAM0 port. On CAM0, the camera can be initialized, but no streaming packets are received by the host. It seems that no VI channel is detected. I’ve attached below some logs from when trying to stream the camera on CAM0 port. Hope that it might help someone address the issue. Thanks!

Logs from calling 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=test.raw --verbose:

VIDIOC_QUERYCAP: ok
VIDIOC_S_EXT_CTRLS: ok
VIDIOC_G_FMT: ok
VIDIOC_S_FMT: ok
Format Video Capture:
Width/Height : 3280/2464
Pixel Format : ‘RG10’ (10-bit Bayer RGRG/GBGB)
Field : None
Bytes per Line : 6560
Size Image : 16163840
Colorspace : sRGB
Transfer Function : Default (maps to sRGB)
YCbCr/HSV Encoding: Default (maps to ITU-R 601)
Quantization : Default (maps to Full Range)
Flags :
VIDIOC_REQBUFS returned 0 (Success)
VIDIOC_QUERYBUF returned 0 (Success)
VIDIOC_QUERYBUF returned 0 (Success)
VIDIOC_QUERYBUF returned 0 (Success)
VIDIOC_QUERYBUF returned 0 (Success)
VIDIOC_QBUF returned 0 (Success)
VIDIOC_QBUF returned 0 (Success)
VIDIOC_QBUF returned 0 (Success)
VIDIOC_QBUF returned 0 (Success)
VIDIOC_STREAMON returned 0 (Success)
cap dqbuf: 0 seq: 0 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq: 0 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq: 1 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq: 2 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq: 3 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq: 0 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq: 0 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq: 1 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq: 2 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq: 3 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq: 0 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq: 0 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq: 1 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq: 2 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq: 3 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)

Logs from dmesg:

[ 495.743133] bwmgr API not supported
[ 498.418470] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 498.431214] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 498.442011] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 498.449743] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 498.460431] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 498.468166] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 0
[ 498.479038] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 501.234635] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 501.243773] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 501.253934] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 501.261668] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 501.272332] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 501.280060] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 0
[ 501.290897] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 504.050423] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 504.059568] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 504.069899] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 504.077614] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 504.088277] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 504.095996] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 0
[ 504.106797] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 506.866431] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 506.875569] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 506.885880] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 506.893603] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 506.904269] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 506.911984] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 0
[ 506.922763] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel

Logs from /sys/kernel/debug/tracing/trace:

v4l2-ctl-2710 [001] … 495.703252: tegra_channel_open: vi-output, imx219 9-0010
v4l2-ctl-2710 [001] … 495.728804: tegra_channel_set_power: imx219 9-0010 : 0x1
v4l2-ctl-2710 [001] … 495.728829: camera_common_s_power: status : 0x1
v4l2-ctl-2710 [001] … 495.738968: tegra_channel_set_power: 13e40000.host1x:nvcsi@15a00000- : 0x1
v4l2-ctl-2710 [001] … 495.738972: csi_s_power: enable : 0x1
v4l2-ctl-2710 [001] … 495.740182: tegra_channel_capture_setup: vnc_id 0 W 3280 H 2464 fmt c4
v4l2-ctl-2710 [001] … 495.741674: tegra_channel_set_stream: enable : 0x1
v4l2-ctl-2710 [001] … 495.752901: tegra_channel_set_stream: 13e40000.host1x:nvcsi@15a00000- : 0x1
v4l2-ctl-2710 [001] … 495.752904: csi_s_stream: enable : 0x1
v4l2-ctl-2710 [001] … 495.753290: tegra_channel_set_stream: imx219 9-0010 : 0x1
kworker/1:3-124 [001] … 495.790416: rtcpu_vinotify_event: tstamp:16447376025 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:526306026272 data:0x719d580010000000
kworker/1:3-124 [001] … 495.790417: rtcpu_vinotify_event: tstamp:16447376367 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:526306036000 data:0x0000000031000001
kworker/1:3-124 [001] … 495.790417: rtcpu_vinotify_event: tstamp:16447376709 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:526306134592 data:0x719d550010000000
kworker/1:3-124 [001] … 495.790418: rtcpu_vinotify_event: tstamp:16447376998 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:526306144448 data:0x0000000031000002
vi-output, imx2-2712 [005] … 498.478883: tegra_channel_capture_setup: vnc_id 0 W 3280 H 2464 fmt c4
kworker/1:3-124 [001] … 498.538426: rtcpu_vinotify_event: tstamp:16532882994 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:529043738112 data:0x719d580010000000
kworker/1:3-124 [001] … 498.538430: rtcpu_vinotify_event: tstamp:16532883252 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:529043747872 data:0x0000000031000001
kworker/1:3-124 [001] … 498.538430: rtcpu_vinotify_event: tstamp:16532883544 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:529043838944 data:0x719d550010000000
kworker/1:3-124 [001] … 498.538431: rtcpu_vinotify_event: tstamp:16532883788 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:529043848832 data:0x0000000031000002
vi-output, imx2-2712 [005] … 501.290726: tegra_channel_capture_setup: vnc_id 0 W 3280 H 2464 fmt c4
kworker/1:3-124 [001] … 501.346415: rtcpu_vinotify_event: tstamp:16620774305 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:531855587072 data:0x719d580010000000
kworker/1:3-124 [001] … 501.346418: rtcpu_vinotify_event: tstamp:16620774563 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:531855596832 data:0x0000000031000001
kworker/1:3-124 [001] … 501.346419: rtcpu_vinotify_event: tstamp:16620774852 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:531855688480 data:0x719d550010000000
kworker/1:3-124 [001] … 501.346420: rtcpu_vinotify_event: tstamp:16620775096 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:531855698368 data:0x0000000031000002
vi-output, imx2-2712 [001] … 504.106655: tegra_channel_capture_setup: vnc_id 0 W 3280 H 2464 fmt c4
kworker/1:3-124 [001] … 504.150412: rtcpu_vinotify_event: tstamp:16708488763 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:534671497152 data:0x719d580010000000
kworker/1:3-124 [001] … 504.150413: rtcpu_vinotify_event: tstamp:16708489025 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:534671506880 data:0x0000000031000001
kworker/1:3-124 [001] … 504.150413: rtcpu_vinotify_event: tstamp:16708489316 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:534671590464 data:0x719d550010000000
kworker/1:3-124 [001] … 504.150414: rtcpu_vinotify_event: tstamp:16708489567 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:534671600320 data:0x0000000031000002
vi-output, imx2-2712 [001] … 506.922627: tegra_channel_capture_setup: vnc_id 0 W 3280 H 2464 fmt c4
kworker/1:3-124 [001] … 506.958410: rtcpu_vinotify_event: tstamp:16796489174 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:537487467808 data:0x719d580010000000
kworker/1:3-124 [001] … 506.958411: rtcpu_vinotify_event: tstamp:16796489435 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:537487477568 data:0x0000000031000001
kworker/1:3-124 [001] … 506.958411: rtcpu_vinotify_event: tstamp:16796489721 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:537487553600 data:0x719d550010000000
kworker/1:3-124 [001] … 506.958411: rtcpu_vinotify_event: tstamp:16796489969 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:537487563488 data:0x0000000031000002
vi-output, imx2-2712 [001] … 509.738672: tegra_channel_capture_setup: vnc_id 0 W 3280 H 2464 fmt c4
kworker/1:3-124 [001] … 509.762404: rtcpu_vinotify_event: tstamp:16884721473 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:540303526400 data:0x719d580010000000
kworker/1:3-124 [001] … 509.762404: rtcpu_vinotify_event: tstamp:16884721740 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:540303536160 data:0x0000000031000001
kworker/1:3-124 [001] … 509.762405: rtcpu_vinotify_event: tstamp:16884722032 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:540303612768 data:0x719d550010000000
kworker/1:3-124 [001] … 509.762405: rtcpu_vinotify_event: tstamp:16884722280 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:540303622656 data:0x0000000031000002
v4l2-ctl-2710 [003] … 512.498699: tegra_channel_close: vi-output, imx219 9-0010
vi-output, imx2-2712 [001] … 512.554728: tegra_channel_capture_setup: vnc_id 0 W 3280 H 2464 fmt c4
v4l2-ctl-2710 [005] … 512.564413: tegra_channel_set_stream: enable : 0x0
v4l2-ctl-2710 [005] … 512.564416: tegra_channel_set_stream: imx219 9-0010 : 0x0
v4l2-ctl-2710 [005] … 512.564636: tegra_channel_set_stream: 13e40000.host1x:nvcsi@15a00000- : 0x0
v4l2-ctl-2710 [005] … 512.564639: csi_s_stream: enable : 0x0
v4l2-ctl-2710 [005] … 512.576270: tegra_channel_set_power: imx219 9-0010 : 0x0
v4l2-ctl-2710 [005] … 512.576298: camera_common_s_power: status : 0x0
v4l2-ctl-2710 [005] … 512.581405: tegra_channel_set_power: 13e40000.host1x:nvcsi@15a00000- : 0x0
v4l2-ctl-2710 [005] … 512.581411: csi_s_power: enable : 0x0
kworker/1:9-143 [001] … 518.275067: rtcpu_string: tstamp:17151220121 id:0x04010000 str:“VM0 deactivating.”

3

hello zhuda,

are you using the Rbpcv2-imx219? we’ve tested locally to verify the camera functionality.

4

Hi JerryChang,

Thank you for the feedback! Yes, it is the camera that we are using. Did you verify the camera’s functionality on both CAM ports? Because I’ve tested on two Orin Nano DevKits so far, both of them behave the same: CAM1 works, CAM0 not.

Cheers
zhuda

5

hello zhuda,

please double confirm you’re already using the latest L4T release version, i.e. l4t-r35.3.1
you may check release tag, such as… $ cat /etc/nv_tegra_release for confirmation.

furthermore,
on Orin, the CSI0 D1 and CSI1 D0 P/N will always been swizzled for P/N.
it’s configured by device tree property, i.e. lane_polarity, the settings is already included in l4t-r35.3.1 release version.
please see-also below for description,

                                * lane_polarity
                                * Based on the camera connector pin.
                                * CSIx_D0 | CSIx_D1 | CSI(X+1)_D0 | CSI(X+1)CSIx_D1
                                *    LSB  |   BIT1  |     BIT2    |      MSB
                                * if there is a polarity swap on any lane, the bit corrsponding
                                * to the lane should be set
                                * e.g. polarity swap on CSIx_D0 only -> lane_polarity = "1"; 0001
                                * e.g. polarity swap on CSIx_D1 and CSI(X+1)_D0 -> lane_polarity = "6"; 0110
6

Dear @JerryChang,

Yes, we are using the latest L4T i.e. R35.3.1. See $ cat /etc/nv_tegra_release:

# R35 (release), REVISION: 3.1, GCID: 32827747, BOARD: t186ref, EABI: aarch64, DATE: Sun Mar 19 15:19:21 UTC 2023

We didn’t modify the device tree or the kernel, so the lane_polarity for IMX219 is set to 6 by default.

Thank you for looking into this!

Cheers, zhuda

8

Hi zhuda,

Confirmed imx219 is working on our Orin Nano devkit + r35.3.1 with cam0 and cam1.
Please enable imx219 from Jetson-IO before test.

$ sudo /opt/nvidia/jetson-io/jetson-io.py
-> Configure Jetson 24pin CSI Connector 
-> Configure for compatible hardware 
-> Camera IMX219 Dual 
-> Save pin changes 
-> Save and reboot to reconfigure pins
1 Like
9

Hi @carolyuu,

Thank you for your reply! Yes, applying the Dual-IMX219 DT-overlay via jetson-io.py works. But since the DT-overlay for IMX219 specifies the port-index for the first camera to be 1 instead of 0, it means that (with some further debugging):

  1. 2-Lane streaming at port-index = <0> doesn’t work. It only works when port-index = <1>, why so? On Orin NX (with custom carrier board), both ports work however just fine!

  2. The re-definition of port-index = <1> in t23x/p3768/kernel-dts/cvb/tegra234-p3768-0000-a0.dtsi also doesn’t take effect. I’d assume that re-defining port-index = <1> in t23x/p3768/kernel-dts/cvb/tegra234-p3768-0000-a0.dtsi is meant to avoid the streaming problem at port-index = <0>, but still, it has no impact in the final device tree. Why?

I am looking forward to your answer. @JerryChang: FYI. Thank you very much!

Cheers, zhuda

10

hello zhuda,

1st camera sensor now streams on CSI-B instead of CSI-A due to CSI-A will only be supported with A03.
note, CSI0 D1 and CSI1 D0 P/N will always been swizzled for P/N.

11

Hi @JerryChang,

Thanks for the confirmation! But what exactly is A03? The new revision of the Orin Nano module?

Cheers, zhuda

12

you may examine the TNSPEC of your target for confirmation. such as… $ cat /etc/nv_boot_control.conf
you may also check flash configuration file, jetson-orin-nano-devkit.conf, looking for board_sku to understand how software side to distinguish the different platform SKUs.

13

Hi JerryChang,

Thank you for the hint. I checked the config file that you mentioned but got a bit more confused:

  1. What does “SKU” actually mean?
  2. What is the “A03” that you mentioned above?

Cheers, zhuda

14

hello zhuda,

that A03 mentioned is used internally, you may check the naming of device trees files for reference.

hence,
you may check TNSPEC of your target for confirmation. such as… $ cat /etc/nv_boot_control.conf, that give you the target SKU info.
please see-also FAQ page for this section… What are the Part Numbers for Jetson products?

15

Hi JerryChang,

That means that the A03 version will be released in the future, right?

Cheers, zhuda

16

HI @JerryChang,

Could you please address the problem I mentioned above?

That means that the A03 version will be released in the future, right?

Thanks!

17

hello zhuda,

just forget about the board version. for any of the Orin modules, such as Orin NX 16GB, Orin NX 8GB, Orin Nano 8GB, Orin Nano 4GB…etc will all have this swizzle.
i.e. CSI0 D1 and CSI1 D0 P/N will always been swizzled for P/N.

18

Hi @JerryChang,

I understand that about the CSI lane swizzle. What I wanted to know is when will the CSI_A port be supported on Orin Nano since you mentioned before:

1st camera sensor now streams on CSI-B instead of CSI-A due to CSI-A will only be supported with A03.

Currently on the CAM0 port, CSI-A is NOT working, which limits the number of lanes on the CAM0 port to 2 instead of 4.

19

Hi @zhuda, @JerryChang

I also encountered the same issue, and today I tried the following, and it worked successfully.

hardware/nvidia/platform/t23x/p3768/kernel-dts/cvb/tegra234-p3768-0000-a0.dtsi

	host1x@13e00000 {
		nvcsi@15a00000 {
- 			csi_chan0 {
+			channel@0 {
				ports {
					port@0 {
						endpoint@0 {
							port-index = <1>;
						};
					};
				};
			};
		};
	};

I think there is a wrong in the configuration values of L4T35.3.1.
tegra234-p3768-0000-a0.dtsi overrides the value so that it is routed to CSI-B, but the specification of nvcsi@15a00000/channel@0 is not as intended (csi_chan0 is symbol), which seems to have prevented the reception of CSI data.

I hope that this will be fixed in next version.

20

hello fumiya.fujinaka,

are you using Jetson-IO to re-configure the CSI channel to enable IMX219 camera support?
or, you’re testing with default Jetpack release image?

21

Hi @JerryChang,

I use default Jetpack release image. L4T35.3.1

The device tree where IMX219 works on CAM0 is also using the one built from the source with the above changes, without re-configure by JetsonIO.

22

@fumiya.fujinaka: great, that’s a nice finding! Yes, i was wondering why the hardware/nvidia/platform/t23x/p3768/kernel-dts/cvb/tegra234-p3768-0000-a0.dtsi doesn’t route the CSI port to CSI-B as it is supposed to do. Now you found why. Thanks!
@JerryChang: it is an error in the JetPack L4T35.3.1. Btw, will the hardware with functional CSI-A released in the future?

1 Like