Setup:
-
Jetson Orin Nano 8GB
-
Carrier: Seeed Studio reComputer J401
-
Capture card: Stereolabs ZED Link Duo
-
Cameras: 2x ZED X One GS (global shutter)
-
JetPack 6.1, L4T 36.4.0, kernel 5.15.148-tegra
-
Driver:
stereolabs-zedlink-duo— tested on both v1.4.0 and v1.4.3
Summary: GMSL link, I2C mux, deserializer, and serializer all initialize and correctly identify both cameras as “zedonegs.” Both sensors respond over I2C with valid serial numbers. But zedx_probe fails immediately after with -2 (“Video device id not found”), because sl_zedx.ko only contains a zedx_probe_ar0234 function — there is no GS-capable probe path in the compiled module, on either driver version.
1. Hardware/link layer — working correctly
sl_max96712 9-0029: Driver Version : v1.4.0
sl_max96712 9-0029: sl_max96712_get_camera_model: zedonegs camera connected to this port
sl_max96712 9-0029: sl_max96712_gmsl_pipeline_setup: GMSL #0 : Link Camera zedonegs (id: 4) to port-index 1
sl_max96712 9-0029: sl_max96712_gmsl_pipeline_setup: GMSL #3 : Link Camera zedonegs (id: 6) to port-index 2
sl_max96712 9-0029: sl_max96712_probe: success
sl_max9295 9-0066: probe_serializer: Serializer for zedonegs detect success
sl_max9295 10-0066: probe_serializer: Serializer for zedonegs detect success
pca9546 I2C mux also registers correctly (registered 4 multiplexed busses for I2C switch pca9546), and both GS sensor addresses respond on their respective mux channels.
2. Device tree — correctly configured
The reference overlay’s tegra-camera-platform module list correctly points at the physical GS sensor nodes:
module08 {
badge = "zedx_ar0234";
position = "front";
status = "okay";
orientation = "1";
drivernode0 {
pcl_id = "v4l2_sensor";
status = "okay";
sysfs-device-tree = "/sys/firmware/devicetree/base/bus@0/i2c@3180000/tca9546@70/i2c@0/zedxone_gs_0@10";
};
};
(and an equivalent entry for the second sensor at i2c@1/zedxone_gs_2@10). Note the sysfs-device-tree path is correct and does resolve to the right physical device — but badge is zedx_ar0234, not a GS-specific value. All four physical GS device-tree nodes (zedxone_gs_0 through _3) exist in the DTS and have module entries.
3. Sensor probe — fails
zedx 9-0010: Driver Version : v1.4.0
zedx 9-0010: tegracam sensor driver:video4_v2.0.6
tegra-camrtc-capture-vi tegra-capture-vi: subdev zedx 9-0010 bound
zedx 9-0010: ZED-X sensor initialisation done
zedx 9-0010: zedx_probe: Serial Number : 307323639
tegra-camrtc-capture-vi tegra-capture-vi: subdev zedx 9-0010 unbind
zedx 9-0010: zedx_probe: Video device id not found
zedx: probe of 9-0010 failed with error -2
Identical failure on the second sensor (10-0010). Both sensors are clearly detected, initialized, and their serial numbers read correctly over I2C — the failure happens one step later, in video device registration.
4. Root cause, confirmed via the compiled module
$ strings sl_zedx.ko | grep -iE "probe_"
zedx_probe
zedx_probe_ar0234
zedx_probe_count
Only zedx_probe_ar0234 exists. Checked across all installed Stereolabs kernel modules (zedx, zedxhdr, zedxone4k, max9295, max9296, max96712, bmi088) — none contain a GS-specific probe path. lsmod also shows no sl_zedxone_gs module, unlike e.g. sl_zedxone_uhd, which does exist as a separate module for that variant.
I upgraded from driver v1.4.0 → v1.4.3 specifically to check if this was already fixed — same result, same strings output, no GS probe function in either version.
Question: Per the “Third party devices” docs, the driver’s DTS is supposed to cover ZED X, ZED X Mini, ZED X One GS, and ZED X One 4K — and the DTS side does correctly define GS nodes. But the actual compiled sensor driver appears to only implement the AR0234 probe path. Is GS support meant to ship as a separate module I’m missing (similar to how UHD has its own sl_zedxone_uhd.ko), or is this a real gap in the current ZED Link Duo build for L4T 36.4.0?
This looks related to a couple of other open threads reporting GS detection issues (“ZED X One GS not detected,” “Does not detect ZED X Ones”) — possibly the same underlying cause.
Happy to provide full dmesg, decompiled device tree, or run any test on request.