GMSL2 SerDes explained: MAX9295 and MAX9296 for Jetson bring-up

The MAX9295A serializer and MAX9296A deserializer are the transport layer between a GMSL2 camera sensor and Jetson — and understanding what they do and how they fail is the foundation for any GMSL2 bring-up work. Most GMSL2 debugging sessions turn out to be SerDes configuration issues rather than sensor or Jetson problems. This post covers how the SerDes pair works.

Key Insights

• GMSL2 SerDes is a two-chip pipeline: MAX9295A serializer on the camera, MAX9296A deserializer on the host/carrier board
• The link must lock before any I2C communication with the camera sensor is possible — link lock is step zero
• I2C tunneling over the GMSL2 link means one coaxial cable carries both video and camera control traffic
• The deserializer’s output to the Jetson SoC is MIPI CSI-2 — the rest of the capture pipeline is standard
• Most bring-up failures happen at link lock or I2C address reassignment, not at the MIPI layer
• NVIDIA provides reference drivers for specific module/carrier combinations only — custom hardware needs custom driver work

What GMSL2 actually is

GMSL2 (Gigabit Multimedia Serial Link 2) is a serialization standard from Maxim Integrated (now Analog Devices) that transmits high-speed video, control data, and power over a single coaxial cable or shielded twisted pair. It operates at 3 Gbps or 6 Gbps per channel and supports cable runs of 15 meters at 3 Gbps, which is why it is the standard interface for automotive cameras and anything where the camera needs to be physically separated from the compute unit.

On Jetson, GMSL2 is almost always implemented with two chips: the MAX9295A serializer on the camera board and the MAX9296A deserializer on the carrier board. Some designs use the MAX96717 (serializer) or MAX96724 (quad deserializer) for different port counts, but the bring-up process is the same.

The signal path looks like this:

Camera sensor → MIPI CSI-2 → MAX9295A → GMSL2 link (coax) → MAX9296A → MIPI CSI-2 → Jetson NVCSI → VI → V4L2

From the Jetson’s perspective, the deserializer looks like any other MIPI CSI-2 source. The GMSL2 complexity is entirely on the serializer/deserializer side. If the SerDes is configured correctly, the rest of the Jetson camera pipeline behaves identically to a direct-attach CSI camera.

The link lock sequence

The link lock sequence is the first thing that has to work, and it is the most common point of failure. Nothing else matters until the GMSL2 link is established.

1. Power up the serializer side. The MAX9295A needs VDD (1.8V or 3.3V depending on variant) and its MIPI clock from the camera sensor or an external oscillator.
2. The deserializer initiates link training. The MAX9296A drives a lock signal on the coaxial cable. The MAX9295A responds. This exchange happens automatically at power-on — no software involvement.
3. Link lock is established. The MAX9296A LOCK bit (register 0x0013, bit 3) goes high. This takes 5–50 ms depending on cable length and electrical conditions.
4. I2C tunnel becomes active. Once locked, the deserializer’s I2C bus extends transparently to the serializer side. The host can now reach the MAX9295A and the camera sensor registers over I2C.
5. Address reassignment. If multiple cameras share one deserializer, each serializer must be reassigned to a unique I2C address before any sensor register access begins. This is done by communicating with each serializer one at a time through the deserializer’s per-link I2C gateway.

If the link never locks, you cannot proceed. Every subsequent step depends on it.

# Check link lock status on a running Jetson with working driver
sudo i2cget -y <bus> 0x48 0x0013  # Read MAX9296A register 0x0013
# Bit 3 = 1 means link locked

Why the I2C tunnel matters

The I2C tunnel is what makes GMSL2 practical for embedded systems. Without it, you would need a separate control wire from the host to each camera — defeating much of the purpose of a serialized link.

Through the tunnel, the Jetson can:

• Write initialization sequences to the camera sensor (IMX, OV, Sony)
• Read sensor status and configuration registers
• Control the MAX9295A serializer registers (crossbar, output format, sync signals)

The tunnel operates at standard I2C speeds (100 kHz, 400 kHz). It is transparent to Linux I2C drivers — the sensor appears as a normal I2C device on the I2C bus once the link is locked and the deserializer is configured to forward addresses.

One practical consequence: if the GMSL2 link is not locked, i2cdetect on the bus will show nothing. Engineers sometimes interpret this as a dead sensor, when the actual problem is link lock. The sensor is fine — it is just unreachable until the link is established.

Device tree structure on Jetson

The device tree for a GMSL2 camera on Jetson has three layers: the deserializer node, the serializer node (as a child), and the camera sensor node (as a child of the serializer).

&i2c_cam {
    /* MAX9296A deserializer */
    max9296@48 {
        compatible = "maxim,max9296";
        reg = <0x48>;
        reset-gpios = <&gpio TEGRA234_MAIN_GPIO(H, 3) GPIO_ACTIVE_LOW>;

        ports {
            port@0 {
                max9296_out0: endpoint {
                    remote-endpoint = <&nvcsi_in0>;
                    data-lanes = <1 2 3 4>;
                };
            };
        };

        /* MAX9295A serializer — reached via I2C tunnel */
        max9295@40 {
            compatible = "maxim,max9295";
            reg = <0x40>;

            /* Camera sensor — reached via serializer I2C tunnel */
            imx390@1a {
                compatible = "sony,imx390";
                reg = <0x1a>;
                /* sensor configuration */
            };
        };
    };
};

The NVCSI node references the deserializer output as its source. The capture pipeline is then identical to any other CSI camera from the Jetson’s perspective.

Most common bring-up failures

We have brought up GMSL2 cameras on Jetson Orin, AGX Xavier, and Orin NX across multiple custom carrier boards. The failures cluster into three areas:

Link never locks. Usually power or termination. The MAX9295A’s VDD must be within spec and stable before the link training can complete. The coaxial cable’s termination resistor (typically 100 ohm) must match the PCB design. A cold or intermittent solder joint on the coax connector is enough to prevent lock.

I2C address conflict. When multiple cameras are connected, all serializers start at the same default I2C address (0x40). Before the deserializer can address each one individually, you have to enable each link’s pipe independently, reassign the serializer address, then enable the next. Getting the reassignment sequence wrong means I2C writes collide and both serializers end up in an undefined state.

MIPI output misconfiguration. The deserializer’s MIPI output lane count, data rate, and format must match exactly what the NVCSI expects in the device tree. A mismatch here produces uncorr_err from the NVCSI — the link is locked, I2C works, but frames are corrupt or absent. Check that data-lanes in the DTS matches the physical lane count routed from the deserializer to the SoM.

For carrier board-specific GMSL2 bring-up issues, see GMSL2 cameras on a custom carrier board: what’s different from the devkit. For the full camera diagnostic stack on Jetson, see 5 signs your GMSL2 camera integration will miss your milestone.

GMSL2 and the MAX9295A/MAX9296A register maps are documented in the Analog Devices MAX9296A datasheet. The GMSL2 protocol specification is available through the Analog Devices partner portal.

---