AR0234 4-lane RAW10 on Jetson Orin Nano: corrupted Argus image, V4L2 select timeout, vb2 active buffer warning

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
1

Hello,

I am bringing up an Onsemi AR0234 RAW10 MIPI CSI-2 camera on Jetson Orin Nano / Orin Nano Super with JetPack 6.x / L4T r36.x.

Configuration:

  • Sensor: Onsemi AR0234
  • Interface: 4-lane MIPI CSI-2
  • Resolution: 1920x1200
  • Format: RAW10 Bayer
  • Connector: CAM1
  • DTS: serial_c / port-index = 2
  • num_lanes = 4
  • pixel_phase = grbg
  • csi_pixel_bit_depth = 10
  • dynamic_pixel_bit_depth = 10
  • discontinuous_clk = no
  • cil_settletime = 0

Symptoms:

  1. If configured as 2-lane, V4L2 immediately gets select timeout.
  2. With 4-lane, nvarguscamerasrc can start and display an image, but the image is corrupted/scrambled.
  3. V4L2 sometimes streams at around 30 fps, but sometimes fails with select timeout.
  4. nvarguscamerasrc can run for around one minute and then fails with:
    “Failed socket read: Connection reset by peer”
  5. dmesg shows:
    “videobuf2_common: driver bug: stop_streaming operation is leaving buf … in active state”

Questions:

  1. For Jetson Orin Nano CAM1 4-lane, are tegra_sinterface = serial_c and port-index = 2 correct?
  2. Does CAM1 4-lane require lane_polarity = 6 on Orin Nano / Orin Nano Super?
  3. For AR0234 RAW10 1920x1200 30fps 4-lane, should pix_clk_hz be the real pixel clock, such as 90 MHz, or the MIPI link frequency, such as 450 MHz?
  4. Is the vb2 active buffer warning likely caused by VI not receiving complete frames?
  5. What trace/debug logs should I provide to identify whether this is a NVCSI/VI timing issue or a sensor/DTS issue?

Thank you.

5

hello miiikuuu,

just for confirmation, Jetson Orin Nano developer kit has only single camera slot support with 4-lane configuration.
that’s due to carrier board design, see-also.. Jetson Orin Nano Developer Kit Carrier Board Reference Design Files,
you may check [P3768_A04_Concept_schematics.pdf] of page-18 [CSI CAM CONNECTORS] for details.
hence.. if you’re testing with Jetson Orin Nano developer kit, please have your camera connect to J21/CAM1 slot, which utilize CSI-C/D for 4-lane configuration.

Q&As.
>> For Jetson Orin Nano CAM1 4-lane, are tegra_sinterface = serial_c and port-index = 2 correct?
yes, see-also above for details.

>> Does CAM1 4-lane require lane_polarity = 6 on Orin Nano / Orin Nano Super?
no, you should have lane_polarity = "0";, since CSI-C don’t need a polarity swap.

>> For AR0234 RAW10 1920x1200 30fps 4-lane, should pix_clk_hz be the real pixel clock, such as 90 MHz, or the MIPI link frequency, such as 450 MHz?
you may refer to developer guide, Sensor Pixel Clock.
FYI, I usually using sensor CSI lane output rate for calculation,
for instance, pix_clk_hz = sensor data rate per lane (Mbps) * number of lanes / bits per pixel

>> Is the vb2 active buffer warning likely caused by VI not receiving complete frames?
it could be.. since it expects the success capture state for fetching sensor frames.

>> What trace/debug logs should I provide to identify whether this is a NVCSI/VI timing issue or a sensor/DTS issue?
firstly, please check your sensor pixel clock, which must be set correctly to avoid potential issues.
secondly, you may follow 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

BTW,
could you please share a snapshot of the abnormal capture results.
it’ll help if you’ve a ground truth for reference.

6

Hi Jerry,

Thank you for your guidance.

I tested the VI/ISP/NVCSI/EMC clock boost as you suggested. I used an equivalent root shell command to lock the clocks and set them to max rate:

sudo sh -c '
for c in vi isp nvcsi emc; do
  p=/sys/kernel/debug/bpmp/debug/clk/$c
  echo 1 > "$p/mrq_rate_locked"
  cat "$p/max_rate" > "$p/rate"
done
'

After locking these clocks, V4L2 streaming became stable:

  • Test pattern: 5 rounds, 100 frames each, around 29.98 fps

  • Real image: 100 frames, around 29.98 fps

Current configuration:

  1. CAM1 4-lane uses serial_c / port-index = 2 / lane_polarity = "0".

  2. pix_clk_hz = "360000000", calculated from 900 Mbps/lane * 4 lanes / 10 bits.

  3. active_w = "1920" and active_h = "1200".

  4. line_length = "2448" gives stable V4L2 BA10 1920x1200 streaming at around 29.98 fps.

  5. Changing line_length to 1920 causes V4L2 timeout or incorrect frame rate, so the sensor timing seems to require line_length = 2448.

However, nvarguscamerasrc still shows a corrupted/incomplete image, and nvargus-daemon repeatedly reports:

PIXEL_SHORT_LINE
PIX_SHORT
ChanselFault 0x000200 / 0x020000

My understanding is that active_w should describe the effective image width, while line_length should describe the sensor horizontal timing / line period. So for AR0234 RAW10 1920x1200 4-lane, I currently keep:

active_w = "1920";
active_h = "1200";
line_length = "2448";
csi_pixel_bit_depth = "10";
dynamic_pixel_bit_depth = "10";
embedded_metadata_height = "0";

Questions:

  1. If V4L2 streaming is stable with line_length = 2448, why would Argus/VI still report PIXEL_SHORT_LINE?

  2. Does Argus/VI validate the expected CSI line payload width based on active_w, line_length, or another mode parameter?

  3. For AR0234 RAW10 1920x1200 4-lane, should active_w remain 1920 and line_length remain 2448?

  4. Could this error be caused by embedded metadata/statistics lines? Should I try setting embedded_metadata_height = "2" or disable embedded/statistics lines in the sensor register table?

  5. Are there additional DT properties or Argus mode parameters required to avoid PIXEL_SHORT_LINE?

I will also attach a snapshot of the corrupted Argus output.

Thank you.

7

hello miiikuuu,

please share a snapshot of the abnormal capture results. let’s have a look for triage the issue.

8

1000119980.jpg4096×3072 6.5 MB

Hi Jerry,

I attached a snapshot of the abnormal Argus output.

This snapshot was captured with the theoretical pixel clock setting:

pix_clk_hz = 360000000

calculated from:

900 Mbps/lane * 4 lanes / 10 bits = 360 MHz

Current test configuration:

CAM1 / J21 4-lane MIPI CSI-2 serial_c / port-index = 2 lane_polarity = “0” active_w = “1920” active_h = “1080” line_length = “2448” pix_clk_hz = “360000000” embedded_metadata_height = “0” RAW10 / Bayer

The image is still partially recognizable, but it has severe horizontal tearing/line shifting, repeated bands, and incomplete/corrupted lines. It does not look like only a Bayer color order issue.

With VI/ISP/NVCSI/EMC clocks locked to max, V4L2 streaming is stable at around 29.98 fps, but Argus still reports:

PIXEL_SHORT_LINE PIX_SHORT ChanselFault 0x000200 / 0x020000

Does this visual pattern suggest that the CSI line payload width is shorter than Argus/VI expects, or that there is still a sensor mode timing / MIPI timing register mismatch?

Please let me know what trace logs would be most useful.

Thank you.

JerryChang <notifications@nvidia.discoursemail.com> 于 2026年5月6日周三 10:02写道：

9

hello miiikuuu,

here’s one thing strange, let’s double check the sensor active region.
the image size should be 1080p per your device tree settings, active_w = “1920” active_h = “1080”.
however, it looks a 4K frame per your snapshot, the resolution shows 4096x3072.

10

Hi Jerry,

Thank you very much for your help and guidance.

Just to clarify one earlier point: the 4096x3072 resolution was only the resolution of the uploaded phone photo/screenshot, not the actual camera frame size. Sorry for the confusion.

I have made good progress now. I switched the bring-up target to a vendor-provided AR0234 1920x1080 RAW10 4-lane configuration first.

Current setup:

  • Jetson Orin Nano / P3767-P3768 devkit
  • AR0234 RAW10 / BA10
  • 1920x1080
  • 4-lane MIPI CSI-2
  • pix_clk_hz = 360000000
  • line_length = 2448
  • embedded_metadata_height = 0

For the devkit overlays:

  • CAM0: serial_b / port-index 1 / lane_polarity 6
  • CAM1: serial_c / port-index 2 / lane_polarity 0

With this configuration, V4L2 can now stream successfully at 1920x1080 RAW10 120fps.

So the main bring-up issue is mostly resolved now. I will continue doing some small stability tuning on my side, but there is no major blocking issue at the moment.

Your suggestions about the 4-lane port, lane polarity, and pixel clock calculation were very helpful.

Thank you again.