Jetson Orin NX + MAX9296: DES VIDEO_LOCK=1 but no CSI frames / VI timeout on L4T R35.4.1

TheSevaOne · July 24, 2026, 12:12pm

I am trying to capture video from two GMSL cameras on a Jetson Orin NX 16GB. MAX9296-GMSL-Camera-Board - Waveshare Wiki

i have two MAX9295 serializers, IMX390 + AR0233 camera modules, GMSL board CSI0 connected to Jetson CAM0

i am using ONXA_SY.IMX390.AR0233_L4TR35.4.1

elinux-camera-bringup-trace.txt (10.4 KB)

JerryChang · July 27, 2026, 1:56am

hello TheSevaOne,

this looks like a carrier board which utilize the CAM0 slot from Orin NX developer kit.
please note that, J20/CAM0 has CSI1_CLK, only a x2 camera interface is supported.
you may dig into the sensor device tree to ensure it’s running with 2-lane mode only.

TheSevaOne · July 27, 2026, 11:55pm

fzcam_1a@1a {
    mode0 {
        num_lanes = "2";
        tegra_sinterface = "serial_b";
        lane_polarity = "6";
        vc_id = "0";
        serdes_pix_clk_hz = "187500000";
    };

    ports {
        port@0 {
            endpoint {
                vc-id = <0>;
                port-index = <1>;
                bus-width = <2>;
            };
        };
    };
};

fzcam_1b@1b {
    mode0 {
        num_lanes = "2";
        tegra_sinterface = "serial_b";
        lane_polarity = "6";
        vc_id = "1";
        serdes_pix_clk_hz = "187500000";
    };

    ports {
        port@0 {
            endpoint {
                vc-id = <1>;
                port-index = <1>;
                bus-width = <2>;
            };
        };
    };
};

nvcsi@15a00000 {
    channel@0 {
        ports {
            port@0 {
                endpoint@0 {
                    port-index = <1>;
                    bus-width = <2>;
                };
            };
        };
    };

    channel@1 {
        ports {
            port@0 {
                endpoint@2 {
                    port-index = <1>;
                    bus-width = <2>;
                };
            };
        };
    };
};

tegra-capture-vi {
    ports {
        port@0 {
            endpoint {
                vc-id = <0>;
                port-index = <1>;
                bus-width = <2>;
            };
        };

        port@1 {
            endpoint {
                vc-id = <1>;
                port-index = <1>;
                bus-width = <2>;
            };
        };
    };
};

After a cold boot with the GMSL hardware powered, initialization succeeds:

serdes 9-0048: /dev/video0 is connected!

serdes 9-0048: /dev/video1 is connected!

serdes 9-0048: Deser_probe: success

Both serializers are accessible:

MAX9295 0x41 DEV_ID=0x91

MAX9295 0x42 DEV_ID=0x91

MAX9296 CTRL3=0xFA

MAX9296 pipe Y VIDEO_LOCK=1

However, the Waveshare driver still programs the MAX9296 pipe for four lanes:

MAX9296 register 0x044A = 0xC0

I manually changed 0x044A from 0xC0 to 0x40 to select two data lanes. After this change NVCSI started reporting corrupted frames, which did not occur before:

tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 256

tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 131072

The following errors still occur:

tegra-capture-vi: uncorr_err: request timed out after 2500 ms

nvcsi: csi5_stream_close: Error in closing stream_id=1, csi_port=1

nvcsi: csi5_stream_open: VI channel not found for stream-1 vc-0

nvcsi: csi5_stream_open: VI channel not found for stream-1 vc-1

V4L2 reports buffers with the error flag, but no frame is written:

bytesused: 4147200

(error, ts-monotonic, ts-src-eof)

output RAW file size: 0 bytes

JPEG output is still a solid green frame.

JerryChang · July 28, 2026, 6:18am

hello TheSevaOne,

you may also contact with sensor vendor for the updated timing settings,
normally, the sensor mode, especially the clock settings should be different between 2-lane/4-lane configuration.

TheSevaOne · July 29, 2026, 11:13am

Also, I got this

JerryChang · July 29, 2026, 2:10pm

hello TheSevaOne,

it seems you’ve receive partial frame?
please follow the steps to enable VI tracing logs.

modprobe rtcpu_debug
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

let me also share some VI tracing logs with a success image capture as an example.
here must be one pair of CHANSEL_PXL_SOF/CHANSEL_PXL_EOF to indicate a frame has detected by VI engine.
afterwards, it’s ATOMP_FRAME_DONE to indicate it’s complete writing a frame to memory.
for instance,

rtcpu_vinotify_event: tstamp:4058867917 cch:-1 vi:0 tag:CSIMUX_STREAM channel:0x00 frame:0 vi_tstamp:129874754944 data:0x0000000000000001
rtcpu_vinotify_event: tstamp:4059206674 cch:0 vi:0 tag:ATOMP_FS channel:0x00 frame:1 vi_tstamp:129891804896 data:0x0000000800000000
rtcpu_vinotify_event: tstamp:4059206818 cch:0 vi:0 tag:CHANSEL_PXL_SOF channel:0x23 frame:1 vi_tstamp:129891808928 data:0x0000000000000001
rtcpu_vinotify_event: tstamp:4059206976 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:1 vi_tstamp:129891815424 data:0x0000000008020001
rtcpu_vinotify_error: tstamp:4060164160 cch:0 vi:0 tag:CSIMUX_FRAME channel:0x00 frame:1 vi_tstamp:129925171392 data:0x00000000000000a0
rtcpu_vinotify_event: tstamp:4060166846 cch:0 vi:0 tag:CHANSEL_PXL_EOF channel:0x23 frame:1 vi_tstamp:129923836800 data:0x0000000004370002
rtcpu_vinotify_event: tstamp:4060167015 cch:0 vi:0 tag:ATOMP_FRAME_DONE channel:0x23 frame:1 vi_tstamp:129923837312 data:0x0000000000000000

TheSevaOne · August 2, 2026, 12:22am

I was able to progress from no frames/green images to displaying real IMX390 frames.

The changes that made frames appear were:

The complete CAM0 device-tree path was changed to two lanes:

{

num_lanes = "2"

bus-width = <2>

tegra_sinterface = "serial_b"

port-index = <1>

vc-id = <0>

}

The Waveshare proprietary driver overwrote the MAX9296 output after boot and configured DPHY1 for four lanes and approximately 1.5 Gbps/lane:

MAX9296 0x044A = 0xC0

I corrected it after driver initialization:

MAX9296 0x044A = 0x40 # two lanes

Changing only the lane count was insufficient. The MAX9296 DPHY1 DPLL had to be reset while changing its rate:

MAX9296 0x1D00 = 0xF4   # DPLL reset

MAX9296 0x044A = 0x40   # two lanes

MAX9296 0x0320 = 0x28   # 800 Mbps/lane

MAX9296 0x1D00 = 0xF5   # release DPLL reset

example

sudo i2ctransfer -y -f 9 w3@0x48 0x04 0x4a 0x40 - two lanes mode

Without the 0x1D00 reset sequence, writing 0x0320 was unreliable and frames did not consistently reach VI.

Capture was corrected to the actual sensor mode:

1920x1080

UYVY/YUV422

30 FPS

/dev/video0

Earlier 1920x1536 capture attempts produced invalid or empty output.

The IMX390 was connected to GMSL Link A and detected through serializer 0x41, using MAX9296 pipe Y.

After these changes the input status remained:

MAX9296 link status  = 0xDA

MAX9296 VIDEO_LOCK Y = 0x01

MAX9295 PCLK detect  = 0x8A

Real frames then appeared, and VI tracing confirmed complete frames:

CHANSEL_PXL_SOF

CHANSEL_PXL_EOF

ATOMP_FRAME_DONE

The remaining issue is intermittent corruption:

CHANSEL_NOMATCH channel:0x02 data:0x3c9

CSIMUX_FRAME channel:0x00 data:0x400061

Therefore, the two-lane/DPLL correction solved the original “no frames” condition, but an intermittent VC/data-type or packet-format mismatch still remains.

But somtimes on normal videostream i get colorful line at random place of picture and gst crashes

tegra-camrtc-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 4194401

rtcpu_vinotify_error: … tag:CHANSEL_NOMATCH channel:0x02 … data:0x00000000000003c9

rtcpu_nvcsi_intr: … class:CORRECTABLE_ERR … status:0x00000004

rtcpu_vinotify_error: … tag:CSIMUX_FRAME channel:0x00 … data:0x0000000000400061

rtcpu_vinotify_event: … tag:ATOMP_FS
rtcpu_vinotify_event: … tag:CHANSEL_PXL_SOF channel:0x23
rtcpu_vinotify_event: … tag:CHANSEL_PXL_EOF channel:0x23
rtcpu_vinotify_event: … tag:ATOMP_FRAME_DONE channel:0x23

cam0-vi-trace-latest.txt (426.4 KB)

safe-probe-ser-latest.txt (10.5 KB)

The color bar corresponds to CHANSEL_NOMATCH + CSIMUX_FRAME 0x400061

I also need to operate both cameras simultaneously:

Link A: IMX390, serializer 0x41, sensor 0x1A, VC0

Link B: AR0233, serializer 0x42, sensor 0x1B, VC1

The current situation is:

IMX390 produces PCLK and valid frames.

AR0233 GMSL link is detected, but serializer 0x42 reports no sensor PCLK.

MAX9296 pipe X has no VIDEO_LOCK.

An I2C trace during /dev/video1 STREAMON showed no AR0233 initialization transactions.

The running kernel contains IMX390 driver symbols, but no AR0233 sensor symbols.

Therefore, it appears that the current Waveshare fzcam driver initializes only IMX390, despite the package being advertised for IMX390 and AR0233.

IMX390 → pipe Y → VC0

AR0233 → pipe X → VC1

Perhaps the deserializer needs to be configured in a specific way, change to cam1 slot ?

JerryChang · August 3, 2026, 3:04am

hello TheSevaOne,

according to the logs..
kworker/2:3-5541 [002] .... 1822.052564: rtcpu_nvcsi_intr: tstamp:57544756491 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:1 vc:0 status:0x00000004
kworker/2:3-5541 [002] .... 1822.052564: rtcpu_nvcsi_intr: tstamp:57544756491 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:1 vc:0 status:0x00000004
it indicates a CSI packet payload CRC failure. this can explain the intermittent colored lines, discarded frames, and why the stream later enters repeated CHANSEL_NOMATCH events.

let’s double check the sensor timing,
for instance, if the MAX9296 rate is now 800 Mbps/lane with two lanes and UYVY is 16 bits/pixel,
serdes_pix_clk_hz should be.. 800000000 * 2 / 16 = 100000000.

TheSevaOne · August 4, 2026, 9:59pm

CSI payload CRC (status:0x00000004) matches intermittent colored lines / err_data 4194401.

Tested your formula with DES forced to 2 lanes @ ~800 Mb/s (0x044A=0x40, 0x0320=0x28):

`serdes_pix_clk_hz`	Result
100000000 (`800e6×2/16`)	Worse — VI timeouts, often no full frames
187500000 (Waveshare default)	Works — stable UYVY 1080p stream

So on this Waveshare fzcam stack, DT=100M breaks capture; DT=187.5M + runtime DPHY 800×2 is OK.

Should serdes_pix_clk_hz still strictly follow the lane-rate formula when the proprietary driver programs MAX9296 DPHY at runtime, or is keeping the vendor 187500000 acceptable if VI is stable?

I didn’t figure out why GStreamer crashed with a random color bar during the stream. I just reconnected everything.

config for one imx390 on cam0 with GMSL0 FAKRA port

num_lanes 2
tegra_sinterface serial_b #cam0 on Waveshare carrier
cil_settletime 0
serdes_pix_clk_hz 187500000
pix_clk_hz 74250000
pixel_phase uyvy
active_w 1920
active_h 1080

The single-camera issue has been resolved, I should note. Thanks for the right tip. Now I’ll be connecting the AR0233 and IMX390. Should I close the thread, or keep posting updates?

JerryChang · August 5, 2026, 5:37am

hello TheSevaOne,

thanks for status update, glad to know you have a stable UYVY 1080p stream now,
let’s close this thread since the single-camera issue has been resolved.
you may start a new forum topic for issue following up.

Topic		Replies	Views
V4l2-ctl can't capture video data Jetson AGX Orin camera , board-design	43	4053	April 22, 2023
Jetson Xavier NX serdes camera streaming error Jetson Xavier NX camera , device-tree	11	1231	June 26, 2023
Jetson AGX Orin camera capture error Jetson AGX Orin camera , gstreamer	14	2484	August 10, 2022
GMSL Camera fail on Orin JatPack 5.1.2 Jetson AGX Orin camera , board-design	3	506	March 20, 2024
Driver GMSL1 cameras using MAX9296, preview the cameras failed? Jetson AGX Xavier camera	6	1583	April 10, 2021
Custom Carrier TX2 CSI Video problems Jetson TX2	19	1954	November 5, 2018
Camera is unable to produce images, could you please help to see what the reason is? Jetson Orin NX camera	22	848	March 15, 2024
Camera driver doesn't work over GMSL Jetson Xavier NX camera	5	692	March 8, 2023
CSI2 camera Can't open device by orin JetPack 5.0.2 Jetson AGX Orin camera , kernel , gstreamer	30	2070	May 31, 2023
Jetson agx xavier (MAX9295/MAX9296): one (AR0233) camera works, two cameras don't (CSI port too busy?) Jetson AGX Xavier camera	23	4852	July 23, 2021

Jetson Orin NX + MAX9296: DES VIDEO_LOCK=1 but no CSI frames / VI timeout on L4T R35.4.1

Related topics