Jetson Orin NX + SG4A-NONX-G2Y-A1 + Technextion GSML2

AI & Data Science Computer Vision & Image Processing
,
1

Good day,

I am using a Jetson Orin NX 16GB module connected to an SG4A-NONX-G2Y-A1 adapter board, which provides 4× GMSL2 outputs.
The SG4A-NONX-G2Y-A1 uses a MAX96712 deserializer, and the cameras I am using are TechNexion modules that feature the onsemi AR0521 image sensor paired with a MAX96717 serializer.

Issue Summary

I have successfully detected the MAX96712 deserializer at address 0x6b on I²C bus 9, and can read its chip ID values (0xD6 / 0xC8).
However, the deserializer does not appear to recognize or communicate with the MAX96717 serializers or the connected AR0521 sensors on any of the four GMSL2 links.

Despite correct power and coax connections, all serializer addresses (0x05, 0x40, 0x60, 0x62, 0x1A, etc.) return no ACK / remote I/O error, and the kernel repeatedly logs the following:

max96717 9-001a: read 0x0000 failed
max96717: probe of 9-001a failed with error -121

At boot, I also see these messages:

i2c i2c-9: Failed to register i2c client max96712_1 at 0x6b (-16)
i2c i2c-9: Failed to create I2C device for /bus@0/cam_i2cmux/i2c@1/max96712_1@6b

This suggests that the device tree overlay or driver binding for the MAX96712 is conflicting with an existing node created by the base BSP or camera stack.

System Details

  • Platform: Jetson Orin NX 16GB

  • JetPack / L4T: 6.2 (L4T R36.4.3)

  • Deserializer: Maxim MAX96712 (GMSL2, 4-link)

  • Serializer: Maxim MAX96717

  • Image Sensor: onsemi AR0521

  • Adapter Board: Sensing SG4A-NONX-G2Y-A1

The camera overlay structure is based on the cam_i2cmux node under /bus@0, and the deserializer node is located at:
/bus@0/cam_i2cmux/i2c@1/max96712_1@6b

Troubleshooting Steps Performed

  • Verified the deserializer responds correctly to I²C commands (0xD6 / 0xC8).

  • Enabled all four GMSL links via register 0x0006 = 0x0F.

  • Cleared and reprogrammed alias registers (0x004C–0x004F, 0x0054).

  • Reset the serializers using GPIO lines (SER0_RESET, SER1_RESET).

  • Confirmed correct GPIO mappings using gpioinfo.

  • Applied multiple device tree overlay variations based on maxim,max96712.yaml to define the MAX96712 → NVCSI → VI pipeline.

However, the system still fails to bring up the camera pipeline.
No /dev/video* devices are created, and media-ctl -p -d /dev/media0 only displays the default tegra-camrtc-ca node with no linked subdevices.

Assistance Requested

  1. Device Tree & Overlay Structure

    • Guidance on the correct device tree bindings and overlay configuration for a MAX96712 → NVCSI → VI connection under JetPack 6.2 (L4T R36.4.3).

  2. Driver Support

    • Clarification on whether the built-in NVIDIA kernel supports the MAX96712 / MAX96717 pair natively, or if additional driver modifications are required.

  3. Endpoint & I²C Binding

    • Advice on the correct way to define the cam_i2cmux and GMSL link endpoints to avoid I²C registration conflicts and enable serializer detection.

  4. Reverse Control Channel (RCCA)

    • Confirmation on whether reverse-channel communication between MAX96712 and MAX96717 is automatically handled by NVIDIA’s camera stack, or if it needs to be explicitly enabled.

I can provide complete dmesg logs, compiled DT overlays, and I²C register dumps from both the deserializer and serializer upon request.

Thank you for your assistance — I look forward to your guidance on resolving this issue.

2

Hello @perrinoneill,

Thanks for detailed report.

From my point of view, I think you have 3 separate challenges in your hands.
The good news is that we can debug them separately, which makes that task a little easier.

  1. We already know DES <—> SOM connection works, since you reported that you were able to read CHIP ID values (at least manually). Now we need to validate CAM <—> SER <—> DES connection.

  2. We need to figure out why the driver is failing to register the i2c device for your deserializer.

  3. We need to properly configure the media path between the deserializer and the Jetson board.

Now, to tackle those issues, I would suggest we try the following respectively:

  • For Issue #1. We can disable the deserializer module on the DTB so that the driver doesn’t load. Then, manually we can power on the SERDES interface via GPIO commands. This will allow us to manually use i2c commands to configure the deserializer and try to interact with the serializer. This way we isolate the SERDES communication issue to only register table configuration.

  • For Issue #2. I would check the output of i2cdetect on bus 9. If there is UU on the 0x6b address. That means that something is taking that address. If that is the case, I would disable the serializer node on the device tree and try again. So we can check if something is still taking ownership of that i2c address. If that is not the case, then we can focus on the driver power sequence and see if the deserializer is being properly powered or not.

  • For Issue #3. Instead of trying to get video from the camera, I would try to configure the deserializer in test pattern mode and start from there. That would reduce the variables in the equation and we could focus only on MIPI/CSI configuration.

Ok, now onto your questions (I will answer them in a different order):

  1. Yes, I believe NVIDIA Jetpack sources already have support for MAX96712:
~/nvidia/nvidia_sdk/JetPack_6.2_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra/source  $ ls nvidia-oot/drivers/media/i2c/max967*
nvidia-oot/drivers/media/i2c/max96712.c
  1. I believe there are a few device tree files that you could based on to create your own:
~/nvidia/nvidia_sdk/JetPack_6.2_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra/source  $ grep -r -n "nvidia,max96712" hardware/
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3737-camera-p3762-a00.dtsi:36:						compatible = "nvidia,max96712";
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3737-camera-p3762-a00.dtsi:109:						compatible = "nvidia,max96712";
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3737-camera-dual-hawk-ar0234-e3653-overlay.dts:239:								compatible = "nvidia,max96712";
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3740-camera-p3783-a00-overlay.dts:42:						compatible = "nvidia,max96712";
hardware/nvidia/t23x/nv-public/overlay/tegra234-p3740-camera-p3783-a00-overlay.dts:115:						compatible = "nvidia,max96712";

They all have a node with the compatible from the MAX96712 driver.

  1. You can also base on one of the device tree overlay files shared on answer #2. However, one thing we can try is that if you are only going to have 1 deserializer connected for now, instead of trying to use an i2c mux, I would directly use the bus instead just to keep it simple.

  2. The RCCA is managed at the driver level. You can see it like this:

  • The Jetson board configures the deserializer via i2c.
  • The Jetson board uses i2c commands to interact with the deserializer so that it configures the serializer.
  • The Jetson board uses i2c command to interact with the deserializer so it interacts with the serializer so that it configures the camera.

It all works like a chain, you need to first get the deserializer working before you can even think about getting the serializer and much less the camera working.

Hope that helps a bit. I know GMSL can be a bit overwhelming, although after the learning curve it all makes sense.

Please do not hesitate to reach out if you require further support, we would love to help.

best regards,
Andrew
Embedded Software Engineer at ProventusNova

3

Hi Andrew

Thank you very much for your detailed response and the structured breakdown — that’s extremely helpful.
I’ve reviewed your three recommended steps and would like to confirm progress and next actions.

1. SERDES Communication (CAM ↔ SER ↔ DES)

The MAX96712 deserializer responds correctly on I²C bus 9 at address 0x6B (chip ID 0xD6 / 0xC8), so the SOM ↔ DES link is good.

I will now disable the MAX96712 node in the device tree (to prevent the driver from taking ownership), keep the interface powered via GPIO, and manually program the deserializer registers over I²C to test whether any of the four MAX96717 serializers respond.

Could you please confirm which registers I should modify to enable GMSL2 link detection and reverse-channel communication (RCCA) manually?
I have dont have the MAX96712 datasheet available and cant find it on the net, but would like to verify the recommended register initialization sequence compatible with the Jetson driver (for example, 0x0006, 0x004C–0x004F, 0x0054, etc.).

2. I²C Device Registration

I ran i2cdetect -y 9 and confirmed that address 0x6B shows “UU”, meaning the kernel driver is already claiming the address.
When I disable the deserializer node in the DTB, it disappears from the map, confirming that the registration conflict is within the overlay.

Could you please confirm whether NVIDIA’s nvidia,max96712 driver (found in nvidia-oot/drivers/media/i2c/max96712.c) should be used instead of the maxim,max96712 binding from the open-source schema?
This would help ensure we’re referencing the correct compatible string and property set.

3. Media Path / Test Pattern Validation

Once the deserializer is configured, I plan to bring up test pattern mode to validate the MIPI/CSI path before connecting any physical cameras.

Could you please share a minimal example of how to configure the MAX96712 test pattern output (register sequence or DT snippet) that’s known to work with NVIDIA’s CSI input configuration?

Alternatively, if one of the overlay examples you mentioned
(tegra234-p3737-camera-p3762-a00.dtsi or tegra234-p3740-camera-p3783-a00-overlay.dts)
includes a reference to internal test pattern mode, please let me know which one I should base on.

Once I confirm serializer communication manually, I’ll proceed with the NVCSI/VI mapping using your suggested nvidia,max96712 reference.

Thank you again for your guidance — I appreciate your help getting this setup operational.
I’ll share the next test results (and any register dumps) after I complete the manual I²C setup.

Best regards,
Perrin O’Neill

4

Hello @perrinoneill,

Sure, it is a pleasure to help.

Unfortunately I don’t have a register configuration table for the deserializer to configure neither RCCA or test pattern. I was hoping you had it, as it is usually provided by the manufacturer upon request.

I think the best is for you to reach out to Maxim and request the data sheets and other related documentation.

If this is difficult for you, you can reach out to me via email (andres@proventusnova.com) and we could contact Maxim in your behalf.

The same way, if you continue experiencing issues and you would rather not focus on platform/driver stuff, just hit me up and we could give you a hand with that.

best regards,
Andrew
Embedded Software Engineer at ProventusNova

5

Hi Andrew,

Here’s the latest status update after a full clean setup on JetPack 6.2 (L4T R36.4.3):

  • The MAX96712 deserializer is now fully detected and bound at I²C address 0x6b (bus 9).
    → The device node /sys/bus/i2c/devices/9-006b exists, and dmesg confirms
    max96712 9-006b: max96712_probe: probe success.

  • The kernel correctly loads the following modules:
    sgx-yuv-gmsl2.ko, max96712.ko, nvhost-nvcsi-t194.ko, and tegra-camera.ko.

  • Four sub-clients (9-001a – 9-001d) are created under the same I²C bus, and the deserializer reports successful initialization for each port (dser_link_check values like 0x12).
    However, every port ends with a sensor_probe camera … detect error, which confirms that the Deserializer ↔ Jetson path is functional and that the issue now lies in the Serializer ↔ TechNexion camera stage (power, addressing, or mode configuration).

  • We’re using TechNexion YUV GMSL2 cameras on the SG4A-NONX-G2Y-A1 adapter, not the Sensing-brand cameras.
    The Sensing drivers were used only as a starting point for the deserializer bring-up.

  • Verified NVIDIA source already includes native MAX96712 support:

    ~/nvidia/nvidia_sdk/JetPack_6.2_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra/source/nvidia-oot/drivers/media/i2c/max96712.c

    Multiple DTS overlays in the public tree also reference "nvidia,max96712", confirming integration at the platform level.

Summary:
The deserializer and Jetson interface are now operational. We’re moving on to getting the MAX96717 serializer to communicate correctly with the deserializer and the TechNexion camera modules.

Question:
What would you recommend as the next step to get the MAX96717 serializer talking to the deserializer?
Should we manually configure the serializer registers over I²C, use test-pattern mode to verify the MIPI path first, or modify the DT to include the serializer nodes explicitly?

Best regards,
Perrin

6

Hi Andrew,

Here’s the current progress summary after today’s tests:

  • The MAX96712 deserializer is now fully operational on I²C bus 9 (/dev/i2c-9).

    • Device ID successfully reads as 0xD6 / 0xC8, confirming communication with the DES.

    • Native serializer detection reports Port A = 0x05, and the link status registers show activity on ports A, B, and D (1A=0x12, 1B=0x89, 1C=0x00, 1D=0x3C), so at least three lanes are alive electrically.

  • The deserializer is bound to the correct DT node (/bus@0/cam_i2cmux/i2c@1/max96712_1@6b) and the driver probe reports success.

  • The four sub-clients (9-001a through 9-001d) are all visible under /sys/bus/i2c/devices/, which matches the expected virtual channels.

At this stage, the reverse I²C (RCCA) channel is not responding yet — no ACKs from the serializer at its native address 0x05 or the typical alias addresses (0x60/0x62). This points to the MAX96717 serializer side not being powered up or released from reset.

The next step is to use the TechNexion modules to handle serializer power-up and initialization:

  • Load max96717.ko along with the appropriate camera driver (tevs.ko or vls3.ko).

  • Optionally run set_config.sh from the TechNexion package, which likely asserts PoC and releases serializer reset.

  • After that, re-probe the serializer at 0x05 and 0x60/0x62 via the deserializer’s reverse I²C channel.

Once we see an ACK from the serializer, we’ll confirm end-to-end communication across the link and can either:

  1. Enable a test-pattern on the MAX96712 to validate the CSI path, or

  2. Bring the actual camera sensor online via the TechNexion driver.

So in short — the deserializer is confirmed working, the physical GMSL links are active, and the current focus is to bring the MAX96717 serializer side out of reset to complete the communication loop. If you have any additional advice I would realy appreciate it!

Best regards,
Perrin