Custom carrier board IMX219 bringup issues

KankenIkos · February 27, 2026, 9:31am

Greetings, I have been trying to bring up one of our carrier boards for the jetson orin NX by testing its CSI ports on pi cameras V2.1.

The board has an I2C mux (pca9548) to communicate with the 4 cameras from one bus on the SOC, as well as a GPIO mux to control their EN pins (so i didn’t have to wire jetson GPIOs directly), both of these work as excpected, i can communicate with 1->4 IMX219s and the driver probes them ok:

example with one here

... dmesg
[   10.377239] imx219 10-0010: tegracam sensor driver:imx219_v2.0.6
[   10.393743] tegra-camrtc-capture-vi tegra-capture-vi: subdev imx219 10-0010 bound
[   10.409122] nv_platform 13800000.display: Adding to iommu group 46
[   10.430652] platform 13800000.display:nvdisplay-niso: Adding to iommu group 47
...

tegra@tegra-ubuntu:~$ ls /dev/video*
/dev/video0

I have not modified the pinmux from the default which seems already configured for 2 lane mipi-csi. We’re using CSI A to D here.

We know the actual hardware is good as the pi camera modules respond over I2C (no flipped connectors, mipi lanes also look correct), and these modules have been tested on a PI4.

Upon running the V4L2 test however, the system times out on getting a frame:

tegra@tegra-ubuntu:~$ v4l2-ctl -d /dev/video0 --set-fmt-video=width=1640,height=1232,pixelformat=RG10 --stream-mmap --stream-count=1
[   67.045932] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[   67.045950] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[   67.046643] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[   69.605538] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[   69.605564] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[   69.607013] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel

So there is something wrong with the CSI part of this, we know this isn’t a clocking issue since the pi cam V2.1 has an onboard clock and doesn’t care about the MCLK pin. Also the EN pin is validated high so that’s not the issue either.

When we start the V4L2 command, we do observe some activity on the mipi lines of the selected port, and only on that port, hinting at a correct CSI port to physical port matching at least. (from the low speed mode between HS packets)

So there has to be something wrong on the SOC side, we did try to set the polarity mode of the ports to “6” to reverse them but that did not help either, polarity looks good on the schematics anyways.

The common debug script commands we used to use on the xavier:

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
export enableCamPclLogs=5
export enableCamScfLogs=5
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
#tests done here
cat /sys/kernel/debug/tracing/trace

root@tegra-ubuntu:~# cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 29/29   #P:4
#
#                                _-------=> irqs-off
#                               / _------=> need-resched
#                              | / _-----=> need-resched-lazy
#                              || / _----=> hardirq/softirq
#                              ||| / _---=> preempt-depth
#                              |||| / _--=> preempt-lazy-depth
#                              ||||| / _-=> migrate-disable
#                              |||||| /     delay
#           TASK-PID     CPU#  |||||||  TIMESTAMP  FUNCTION
#              | |         |   |||||||      |         |
        v4l2-ctl-3279    [002] .......  1684.413956: tegra_channel_open: vi-output, imx219 10-0010
        v4l2-ctl-3279    [002] .......  1684.447992: tegra_channel_set_power: imx219 10-0010 : 0x1
        v4l2-ctl-3279    [002] .......  1684.448093: camera_common_s_power: status : 0x1
        v4l2-ctl-3279    [002] .......  1684.458381: tegra_channel_set_power: 13e00000.host1x:nvcsi@15a00000- : 0x1
        v4l2-ctl-3279    [002] .......  1684.458384: csi_s_power: enable : 0x1
        v4l2-ctl-3279    [002] .......  1684.459018: tegra_channel_capture_setup: vnc_id 0 W 3280 H 2464 fmt c4
 vi-output, imx2-3280    [003] .......  1684.467697: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:0 pid:3280 tid:3280
 vi-output, imx2-3280    [003] .......  1684.467706: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:0 pid:3280 tid:3280
 vi-output, imx2-3280    [003] .......  1684.467707: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:0 pid:3280 tid:3280
 vi-output, imx2-3280    [003] .......  1684.467708: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:0 pid:3280 tid:3280
        v4l2-ctl-3279    [002] .......  1684.467728: tegra_channel_set_stream: enable : 0x1
        v4l2-ctl-3279    [002] .......  1684.469649: tegra_channel_set_stream: 13e00000.host1x:nvcsi@15a00000- : 0x1
        v4l2-ctl-3279    [002] .......  1684.469651: csi_s_stream: enable : 0x1
        v4l2-ctl-3279    [002] .......  1684.469954: tegra_channel_set_stream: imx219 10-0010 : 0x1
 vi-output, imx2-3281    [000] .......  1687.007205: tegra_channel_capture_setup: vnc_id 0 W 3280 H 2464 fmt c4
 vi-output, imx2-3280    [003] .......  1687.007542: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:0 pid:3280 tid:3280
 vi-output, imx2-3280    [003] .......  1687.007552: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:0 pid:3280 tid:3280
 vi-output, imx2-3280    [003] .......  1687.007553: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:0 pid:3280 tid:3280
 vi-output, imx2-3280    [003] .......  1687.007554: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:0 pid:3280 tid:3280
        v4l2-ctl-3279    [003] .......  1687.787767: tegra_channel_close: vi-output, imx219 10-0010
 vi-output, imx2-3281    [002] .......  1689.535253: tegra_channel_capture_setup: vnc_id 0 W 3280 H 2464 fmt c4
        v4l2-ctl-3279    [003] .......  1689.535382: tegra_channel_set_stream: enable : 0x0
        v4l2-ctl-3279    [003] .......  1689.535384: tegra_channel_set_stream: imx219 10-0010 : 0x0
        v4l2-ctl-3279    [003] .......  1689.535568: tegra_channel_set_stream: 13e00000.host1x:nvcsi@15a00000- : 0x0
        v4l2-ctl-3279    [003] .......  1689.535570: csi_s_stream: enable : 0x0
        v4l2-ctl-3279    [003] .......  1689.537057: tegra_channel_set_power: imx219 10-0010 : 0x0
        v4l2-ctl-3279    [003] .......  1689.537061: camera_common_s_power: status : 0x0
        v4l2-ctl-3279    [003] .......  1689.542249: tegra_channel_set_power: 13e00000.host1x:nvcsi@15a00000- : 0x0
        v4l2-ctl-3279    [003] .......  1689.542253: csi_s_power: enable : 0x0
root@tegra-ubuntu:~#

somehow didn’t yield any useful RTCPU errors for us to work off of either. I’ve attached our DTSI for this carrier here as well as a full boot log, any clue on what might be misconfigured here is welcome.

dtsi.zip (4.4 KB)
boot.log (95.0 KB)

PS: the imx sensor is definite in streaming mode as well:


i2ctransfer -f -y 10 w2@0x10 0x01 0x00 r1

0x01

carolyuu · February 27, 2026, 9:54am

*** Please note that this reply is generated by LLM automatically ***

Based on the provided information, it appears that you are experiencing issues with bringing up the CSI ports on your custom carrier board for the Jetson Orin NX. You have tested the I2C mux and GPIO mux, and they seem to be working as expected. However, when running the V4L2 test, the system times out on getting a frame.

Here are a few potential issues that could be causing the problem:

CSI port configuration: Although you mentioned that you didn’t modify the pinmux from the default, it’s possible that the CSI port configuration is not correct. You can try to verify the CSI port configuration using the jetson-io tool. This tool allows you to configure and verify the pinmux settings for the Jetson module.
CSI lane configuration: You mentioned that you are using CSI A to D, but you didn’t specify the lane configuration. Make sure that the lane configuration is correct for your camera module. You can try to use the csi-lane-config tool to verify and configure the CSI lane settings.
Clocking issue: Although you mentioned that the PI camera module has an onboard clock and doesn’t care about the MCLK pin, it’s possible that there is still a clocking issue. You can try to verify the clock settings using the jetson-io tool.
Polarity mode: You mentioned that you tried to set the polarity mode of the ports to 6 to reverse them, but it didn’t help. However, you also mentioned that the polarity looks good on the schematics. It’s possible that there is still a polarity issue. You can try to verify the polarity settings using the jetson-io tool.
DTSI configuration: You provided your DTSI file, but it’s not clear if it’s correct. You can try to verify the DTSI configuration using the dtc tool. This tool allows you to compile and verify the DTSI file.
Boot log analysis: You provided the boot log, but it’s not clear if there are any errors or warnings related to the CSI port configuration. You can try to analyze the boot log to see if there are any issues related to the CSI port configuration.

In comparison to the Xavier, the Jetson Orin NX has a different CSI port configuration. The Xavier has a single CSI port with 4 lanes, while the Jetson Orin NX has 4 CSI ports with 2 lanes each. This means that the CSI port configuration and lane configuration may be different between the two modules.

To troubleshoot the issue, you can try to use the following commands:

jetson-io: This tool allows you to configure and verify the pinmux settings for the Jetson module.
csi-lane-config: This tool allows you to verify and configure the CSI lane settings.
dtc: This tool allows you to compile and verify the DTSI file.
v4l2-ctl: This tool allows you to verify and configure the V4L2 settings.

You can also try to use the debugfs filesystem to verify the CSI port configuration and lane configuration. The debugfs filesystem provides a way to access and verify the CSI port configuration and lane configuration.

In summary, there are several potential issues that could be causing the problem, including CSI port configuration, CSI lane configuration, clocking issue, polarity mode, DTSI configuration, and boot log analysis. You can try to use the jetson-io, csi-lane-config, dtc, v4l2-ctl, and debugfs tools to troubleshoot the issue.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

KankenIkos · February 27, 2026, 10:03am

Edit: there was a copy mistake done in the …imx219.dtsi file in that zip, the port-index= were half set to 1/2/3/4 and half to 0/2/4/6; in the actual DTB they are all 1/2/3/4.

for some reason the a/b/c/d ports were a/c/e/g, i’ll fix this shortly…

KankenIkos · February 27, 2026, 10:26am

Here is the actual correct DTSi for the current setup, but this doesn’t change a thing as far as V4L2 working goes.
dtsi.zip (4.3 KB)

ShaneCCC · March 2, 2026, 3:17am

The trace log shows doesn’t receive any data from the sensor.

Try connect to CSI-C to try.

KankenIkos · March 2, 2026, 1:49pm

Seems like ports 1/0 don’t work, while port 2/3 work for some reason, (wired to the CSI inputs of the same number), i guess i must’ve swapped 1/0 in the dts, i’ll see if it helps…

All the previous tests were done on port 1 and 0

ShaneCCC · March 2, 2026, 3:05pm

For the CAM0 need set the port-index=1 and lane_polarity=6 for it.

KankenIkos · March 10, 2026, 7:29am

Indeed that was the issue, i had to set both of these for ports 1 and 0 and the video flow got restored, thanks!

Topic		Replies	Views
IMX219 streaming works on CSI port-0 but fails on port-1 (VI timeout) in JetPack 5.1.4 on Jetson Orin NX (2-lane) Jetson Orin NX camera , kernel , device-tree	14	28	March 2, 2026
Jetson Orin NX 16GB, problem with IMX219 cameras Jetson Orin NX camera	6	900	January 17, 2024
Second Raspberry Pi v2 (IMX219) camera not working on Orin NX 16GB Jetson Orin NX camera	5	228	November 25, 2024
Jetson orin nx16g jetpack 6.2 camera csi2 bus 1 not display Jetson Orin NX camera , kernel	17	193	September 10, 2025
Customized carrier board with two 4-lane ports unable to capture frame properly Jetson Orin NX camera , board-design	10	405	April 18, 2024
CSI Camera 0 Hangs When Trying to Collect an Image with v4l2-ctl Jetson Orin Nano camera	24	1491	October 10, 2023
Change the CSI port Jetson Orin NX csi	28	936	August 30, 2024
Custom Xavier NX board: `no reply from camera processor` Jetson Xavier NX camera , device-tree	14	1737	November 16, 2022
Jetson NX Orin IMX477 CSI input 1 doesn't work however 0 and 2 do work Jetson Orin NX camera	8	1201	June 16, 2023
Orin NX 16GB + IMX540 on custom carrier: corr_err: discarding frame … err_data 4194402 Jetson Orin NX camera , hw , level2	16	220	September 23, 2025

Custom carrier board IMX219 bringup issues

Related topics