GMSL2 camera not working on Jetson: 5 failure modes

A GMSL2 camera that is not producing frames on Jetson fails in a small number of specific ways — and each failure mode has a distinct signature in the kernel logs and at the hardware level. The problem is that several different failure modes produce similar symptoms on the surface. This post covers the five most common root causes and how to tell them apart.

Key Insights

• GMSL2 failures on Jetson fall into 5 distinct modes — each has a different root cause and a different fix
• Link lock failure is always the first thing to rule out; nothing else works until the link is established
• I2C address conflicts on multi-camera designs are silent — no error message, just wrong register writes
• uncorr_err from the NVCSI with a locked GMSL2 link means MIPI parameter mismatch, not a hardware fault
• Custom carrier boards break devkit GMSL2 setups in specific, predictable ways: wrong I2C bus, wrong GPIO, wrong NVCSI port

Failure mode 1: link never locks

Link lock is the foundation. If the MAX9296A and MAX9295A cannot complete physical link training, nothing else — I2C tunnel, sensor initialization, MIPI output — will work.

Read register 0x0013 on the MAX9296A after at least 200 ms of power-on. Bit 3 should be 1. If it is 0, the link is not locked.

Root causes:

• MAX9295A serializer not powered. Check the VDD rail on the camera board. The serializer needs stable power before link training starts.
• Wrong termination resistor. The coaxial cable needs a 100-ohm termination at each end. Wrong value (or missing resistor) prevents the differential signal from settling correctly.
• PWDNB not asserted on MAX9296A. If the deserializer is in power-down, it does not attempt link training. Verify the PWDNB pin is driven high (or pulled high).
• Damaged cable or connector. A cold solder joint on the SMA or FAKRA connector, or a kinked coax, is enough to prevent lock at 3 Gbps.

# Check link lock register
sudo i2cget -y <bus> 0x48 0x13
# Expected: 0x09 (LOCK bit set) or similar — bit 3 = 1

Failure mode 2: I2C address conflicts on multi-camera designs

All MAX9295A serializers power up at the same default I2C address (0x40). When multiple cameras are connected to one deserializer, the host cannot talk to each one individually until addresses are reassigned.

If the reassignment sequence fails — or if the kernel driver has wrong default addresses in the DTS — all I2C writes go to the wrong chip. The result: sensors appear to initialize but are never actually configured. Frames either do not start or come out with incorrect format or color.

The correct sequence for a two-camera setup:

1. Disable link 1 (talk to link 0 only through the deserializer’s link-specific I2C address)
2. Reassign link 0 serializer from 0x40 to 0x42
3. Enable link 1, disable link 0
4. Reassign link 1 serializer from 0x40 to 0x44
5. Now both serializers are at unique addresses and can be configured independently

This sequence is handled by the GMSL2 deserializer kernel driver if the DTS specifies the target addresses correctly. Verify your DTS has the right address assignments in the serializer child nodes.

Failure mode 3: MIPI lane count or data rate mismatch

With the link locked and sensors initialized, the MAX9296A’s MIPI output must be configured to exactly match what the Jetson NVCSI expects. The critical parameters are:

• Number of data lanes — if the DTS says 4 lanes but the deserializer is configured for 2, every frame is corrupt
• Link frequency — must match the sensor’s actual output rate, which the deserializer is forwarding
• Virtual channel assignment — each camera in a multi-sensor setup must be on a unique virtual channel

A mismatch produces uncorr_err from tegra-camrtc-capture-vi in dmesg. The link is locked, the sensor is streaming, but the NVCSI sees garbage.

# Check for uncorr_err
sudo dmesg | grep -E "uncorr_err|tegra-camrtc"

# Verify MIPI link frequency in device tree matches sensor mode
cat /proc/device-tree/i2c@31c0000/max9296@48/max9295@40/imx390@1a/sensor_modes/mode0/link_freq_hz

For more on uncorr_err from the NVCSI in general, see V4L2 uncorr_err on Jetson: what it means and how to fix it.

Failure mode 4: wrong NVCSI port in device tree

On custom carrier boards, the GMSL2 deserializer’s MIPI output lanes are often routed to a different NVCSI port than on the devkit. The device tree must reflect the actual PCB routing — if the DTS says NVCSI port 0 but the lanes are physically connected to port 2, the capture engine arms the wrong port and produces zero frames.

Trace the MIPI lanes from the MAX9296A MIPI output pads to the Jetson SoM connector pins. Cross-reference the SoM pin assignments with the Orin TRM to determine which NVCSI port those pins belong to. Then update the DTS.

This failure is silent — no error message in dmesg, just zero frames and a timeout in the capture path.

Failure mode 5: ERRB pin not handled

The MAX9296A and MAX9295A have an ERRB pin that asserts (active-low) when the chip detects a link error, parity error, or internal fault. If this pin is connected to a Jetson GPIO that is configured as an interrupt, the kernel driver uses it for error detection. If the GPIO is tristated or configured incorrectly in the DTS, ERRB errors are silently ignored.

On custom carrier boards, the ERRB routing is sometimes left unconnected or pulled to the wrong level. Check your schematic for the ERRB signal path, and verify the GPIO configuration in the DTS matches the physical connection.

For the complete GMSL2 bring-up sequence, see GMSL2 camera bring-up on Jetson Orin: MAX9295/MAX9296 setup. If your symptoms point specifically to a custom carrier board, see GMSL2 cameras on a custom carrier board: what’s different from the devkit.

The MAX9296A error register map is in the Analog Devices MAX9296A datasheet. NVIDIA’s camera bring-up troubleshooting guidance is in the Jetson Linux Sensor Driver Programming Guide.

---