Camera don't stream after migration from Xavier NX to Orin NX on Jetpack 5.1.2

Autonomous Machines Jetson & Embedded Systems Jetson Orin NX
1

Hello. I’m migrating a camera driver from Xavier NX to Orin NX. Everything works fine on Xavier NX. But I’ve got no frames on Orin NX.

Dmesg fragment:

[ 7456.022713] bwmgr API not supported
[ 7456.031752] ar0233at 2-0061: _ar0233at_s_stream: mode: 1 linear START
[ 7456.039492] ub960 2-0030: ar0233at started a new stream; 1 active streams
[ 7456.039498] ar0233at 2-0061: _ar0233at_s_stream: set stream via I2C
[ 7458.568516] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 7458.577702] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 7458.588076] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 7458.595804] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 7458.606463] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 7458.614183] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 1
[ 7458.624932] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 7461.160442] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 7461.169613] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 7461.180079] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 7461.187833] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 7461.198498] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 7461.206219] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 1
[ 7461.216985] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 7461.226534] ar0233at 2-0061: _ar0233at_s_stream: mode: 1 linear STOP
[ 7461.226540] ub960 2-0030: ar0233at stopped a stream; 0 active streams
[ 7461.226544] ub960 2-0030: ar0233at notified end-of-stream, performing digital reset
[ 7461.232123] ar0233at 2-0061: _ar0233at_s_stream: set stream via I2C

Debug trace (/sys/kernel/debug/tracing/trace) consist of tag:VIFALC_TDSTATE and type:PHY_INTR0 messages. I attached it.

Hardware:
Xavier NX devkit (p3509) compatible board
Orin Nx module (p3567-0001) as the replace of Xavier NX module (p3668).
Deserializer board with ub954 and ub953 serializer with sensor ar0233at on the second end.

Sensor devicetree config:

	mclk_khz = "27000";							
	num_lanes = 4;					
	tegra_sinterface = serial_a;	
	phy_mode = "DPHY"; 							
	discontinuous_clk = "no";					
	dpcm_enable = "false";						
	cil_settletime = "0";						
	pixel_phase = "rggb";						
	readout_orientation = "0";					
	serdes_pix_clk_hz = "535000000";			
	set_mode_delay_ms = "800";					
	embedded_metadata_height = "8";

And I attached decompiled dts just in case.

Deserializer speed is 1600 MHz per lane, number of lanes is 4, 12 bit per pixel.

Jetpack version is 5.1.2

What I tried:

  1. Enable deskew_initial_enable and deskew_periodic_enable - nothing.
  2. Lower serdes_pix_clk_hz - nothing
  3. Add set_mode_delay_ms - nothing
  4. Update rtcpu firmware to debug version - nothing. I’ve got no new messages. I guess, it’s because I don’t gave QSPI flash on board and I need to try flash it another way.
    I repeated actions described in this thread Request debug RTCPU image for JP5.1.1

Thanks in advance!
trace.log (9.7 MB)
resulting.dts.txt (533.4 KB)

3

just for double confirmation. are they based-on the same release version?

4

BTW,
there’s known issue of cam0 slot when using Orin NX + Xavier NX carrier.
since it’s a 4-lane camera sensor, you may working with Orin NX developer kit with cam0 slot.

5

If you meant the Jetpack version, then for both devices it is 5.1.2.

6

Sadly, I don’t have the Orin NX devkit.
I learnt, that Orin NX devkit has some csi lanes swapped, but it’s not the case for Orin NX module. Or isn’t it?
Could you please clarify what is the problem with “Orin NX + Xavier NX carrier”?

7

hello g.peters,

please refer to Jetson Orin NX Series and Orin Nano Series Design Guide for [Figure 10-1. CSI 2-Lane Connection Options].
that’s on the module for polarity swap, i.e. CSI0 D1 and CSI1 D0 P/N always been swizzled for P/N.

please refer to below for test results with R35.4.1
for instance,
Orin-NX + Xavier-NX devkit (P3509+P3767)

  • IMX477
    cam1 (sensor-id=0) → working
    cam0 (sensor-id=1) → Fail
  • IMX219
    cam1 (sensor-id=0) → working
    cam0 (sensor-id=1) → Fail

Xavier-NX devkit (P3509+P3668)

  • IMX477
    cam0 & cam1 are working
  • IMX219
    cam0 & cam1 are working

Orin-NX devkit (P3767+P3768)

  • IMX477 with 4-Lane
    cam0 → working
    cam1 → Fail, known issue.
  • IMX477 with 2-Lane
    cam0 & cam1 are working
  • IMX219 with 2-Lane
    cam0 & cam1 are working
8

Yes, I’ve read that wrong.
But nothing changed when I added lane_polarity = "6"; to the camera config.

Sounds a bit vague. Is it related to lane polarity or is there another issue with this combination?
Is there a way to debug it? Or should we made another custom board with some adjustments?

9

it’s suggest to use developer kit, (i.e. P3767+P3768) for running camera use-case.
or… you may refer to design guide to develop your own board.

10

I got that there is some problem with the p3767+p3509 combination.
Could you please tell me what exactly the problem is?
What is the difference between p3509 and P3768 that breaks cameras? Some difference with schematic?
Jetson_OrinNano_OrinNX_XavierNX_Interface_Comparison_Migration_DA-11081-001_v1.0.pdf doesn’t specify any difference with CSI0 and CSI1 between modules. Or I missed it.
I learnt that some lanes are swapped, but nothing more.

By the way, is there any topic on p3767+p3509 problems?
I found this topic Video node available but data not streaming, but that doesn’t help.

11

we don’t further debug camera issue with p3767+p3509 since it’s suggest to use developer kit, (i.e. P3767+P3768) for running camera use-case.

12

I figured out what was wrong.
When I first tried lane_polarity option, I messed up.
I have a define macro AR0233AT_MODE_COMMON and everything was fine until I started experimenting with new options:

#define AR0233AT_MODE_COMMON					\
	mclk_khz = "27000";							\
	num_lanes = STR(CSI_LANES);					\
	tegra_sinterface = STR(TEGRA_SINTERFACE);	\
	phy_mode = "DPHY"; 							\
	discontinuous_clk = "no";					\
	dpcm_enable = "false";						\
	cil_settletime = "0";						\
	pixel_phase = "rggb";						\
	readout_orientation = "0";					\
	inherent_gain = "1";						\
	// serdes_pix_clk_hz = "500000000";			\
	serdes_pix_clk_hz = "535000000";			\
	// lane_polarity = "0";						\
	// lane_polarity = "6";						\
	lane_polarity = "9";						\
	// deskew_initial_enable = "true";				\
	// deskew_periodic_enable = "true";			\
	set_mode_delay_ms = "800";					\
	embedded_metadata_height = "8";				\
	vc_id = STR(PORT_VCID);

Thus, EVERYTHING starting from // serdes_pix_clk_hz was omitted. Even vc_id, which is very important.
You can see this eve in the markdown code block. But my IDE showed it as one-line comments, and device tree compiler didn’t say anything.

When I realized this mess, I rewrote it:

#define AR0233AT_MODE_COMMON					\
	mclk_khz = "27000";							\
	num_lanes = STR(CSI_LANES);					\
	tegra_sinterface = STR(TEGRA_SINTERFACE);	\
	phy_mode = "DPHY"; 							\
	discontinuous_clk = "no";					\
	dpcm_enable = "false";						\
	cil_settletime = "0";						\
	pixel_phase = "rggb";						\
	readout_orientation = "0";					\
	inherent_gain = "1";						\
	serdes_pix_clk_hz = "535000000";			\
	lane_polarity = "6";						\
	set_mode_delay_ms = "800";					\
	embedded_metadata_height = "8";				\
	vc_id = STR(PORT_VCID);

And now I have my frames! With p3767+p3509 and CSI0 in 4 lane mode.

Anyway, thanks for the help!

1 Like
14

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