Meet a CHANSEL_NOMATCH issue when driving imx577 on Jetson Orin Nano

Autonomous Machines Jetson & Embedded Systems Jetson Orin Nano
1

Hi！
I am trying to to driver a imx577(almost the same with sony arducam imx477), Currently I am using CSI2+3 and CSI4, and I can detect both camera in i2c

image
image1000×156 7.13 KB

But when I use nvgstcapture to get the video, issue comes like that:

image
image1051×515 87.2 KB

I check whether v4l2 standard IOCTLs works with:

v4l2-ctl -d /dev/video0 --set-fmt-video=width=4056,height=3040,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100

And I got this, seems that the standard IOCTLS works :

image
image1334×96 4.85 KB

The kenel log when I execute the v4l2 commands show s:

image
image1128×112 3.3 KB

I use the command below to boost all the VI/CSI/ISP clocks for testing:

sudo su
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
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/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
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate

And enable the VI tracing logs:

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 > /sys/kernel/debug/tracing/trace
cat /sys/kernel/debug/tracing/trace

Then gather the vi tracing logs when access the stream via gstreamer:
gst-launch-1.0 nvarguscamerasrc sensor-id=0 ! ‘video/x-raw(memory:NVMM),width=4056, height=3040, framerate=39/1, format=NV12’ ! nvvidconv ! ‘video/x-raw(memory:NVMM),format=I420’ ! fpsdisplaysink text-overlay=0 video-sink=fakesink sync=0 -v

The vi log I get is here:
VI.log (433.7 KB)

I have tries everything that may help me to enable the imx577 but all failed, really need help, thanks!

3

Does the trace log show CHANSEL_NOMATCH when using v4l2-ctl command too?
If not could you try smaller sensor size and adjust the pix_clk_hz depen on below NOTE.

Skew calibration is required if sensor or deserializer is using DPHY, and the output data rate is > 1.5Gbps.
An initiation deskew signal should be sent by sensor or deserializer to perform the skew calibration. If the deskew signals is not sent, the receiver will stall, and the capture will time out.
You can calculate the output data rate with the following equation:

Output data rate = (sensor or deserializer pixel clock in hertz) * (bits per pixel) / (number of CSI lanes)

Thanks

4

The trace log when using v4l2-ctl command doesn’t show the CHANSEL_NOMATCH
VITRACING.log (299.4 KB)

Do you mean smaller active_w and active_h ？

According to this:

image
image1404×338 20.8 KB

If I set active_w to1920 and active_h to 1080, framerate to 60 fps. Is the pix_clk_hz equal to 1920108060=124,416,000

5

RIght, check the data rate > 1.5G base on pix_clk_hz

6

According to this:

image
image1420×295 33.1 KB

I have two csi 4 lanes channel and the min_bits_per_pixel I set is 10.

image

So the output data rate= pixel_clk_hz * 10 / 8 = 493,209,600 x 10 /8 = 616,512,000

Does this make sense?

7

Should be the csi_pixel_bit_depth csi_pixel_bit_depth instead of for the calculation min_bits_per_pixel

8

csi_pixel_bit_depth is also 10

9

So in my device tree, the parameter of sensor mode 0 is here:

            mclk_khz = "24000";
  			num_lanes = "4";
  			tegra_sinterface = "serial_c";
  			phy_mode = "DPHY";
  			discontinuous_clk = "no";
  			dpcm_enable = "false";
  			cil_settletime = "0";

  			active_w = "4056";
  			active_h = "3040";
  			mode_type = "bayer";
  			pixel_phase = "rggb";
  			csi_pixel_bit_depth = "10";
  			dynamic_pixel_bit_depth = "10";
  			readout_orientation = "90";
  			line_length = "4512";
  			inherent_gain = "1";
  			mclk_multiplier = "25";
  			pix_clk_hz = "600000000";

  			gain_factor = "10";
  			min_gain_val = "0"; /* dB */
  			max_gain_val = "300"; /* dB */
  			step_gain_val = "3"; /* 0.3 */
  			default_gain = "0";
  			min_hdr_ratio = "1";
  			max_hdr_ratio = "1";
  			framerate_factor = "1000000";
  			min_framerate = "2000000";
  			max_framerate = "40000000";
  			step_framerate = "1";
  			default_framerate = "40000000";
  			exposure_factor = "1000000";
  			min_exp_time = "59"; /*us, 2 lines*/
  			max_exp_time = "33333";
  			step_exp_time = "1";
  			default_exp_time = "33333";/* us */
  			embedded_metadata_height = "2";

output data rate = pixel_clk_hz * csi_pixel_bit_depth / number of CSI lanes = 4056 * 3040 * 40 * 10 /8 = 616,512,000

Does the figure make sense? Seems it’s 0.616 Gbps and lower than 1.5Gbps

10

nums of lanes is totally 8，so I guess for each camera channel is 4.
And the output data rate may change to 4056 * 3040 * 40 * 10 / 4 = 1,233,024,000
1.23 Gbps still lower than 1.5 Gbps

11

I my device tree I am setting pix_clk_hz larger than what I caculate.
In sensor mode 0 the current output data rate =600000000 * 10 / 4 = 1.5 Gbps.
No sure what is the influence

12

BTW, according to this, how can I set the initiation deskew signal

13

Suppose need sensor send out the deskew word for it, however you were able get frame data via v4l2-ctl that could be argus issue that will fix in J5.1.2, you can wait for it or try lower data rate.

Thanks

14

Actually the driver and device tree can run perfectly in Jetson Xaver NX with jetpack 5.1.1

So Im confuse why is the failure comes up in Orin nano, I have compared that the hardware for mipi and CSI is almost the same

15

Due to v4l2-ctl working that tell the HW and sensor configure without problem, that’s why I suggest to wait next release that have fix the deskew sequence problem.

Thanks

16

So if my output data rate is lower than 1.5gbps, the deskew sequence will make no influence to me right?

17

Does this deskew sequence problem exist with a particular jetpack version or a specific hardware like orin serials?

18

Still can’t get the poinot why xavier nx is good but Orin is not, since everything is the same expect the platform

19

This only happen on r35.x release for Orin, not sure if impact Xavier.

20

Okay got it.

One other thing I found is strange that, even I disconnect all the camera and i2c failed to bound any camera, the output of nvgstcapture is not a “no camera availiable”, but the dmabuf_fd -1 issue, is that normal？

21

If the video node still there then it’s normal.
/dev/video*

Thanks