Hey everyone, I’m trying to get the Arducam Hat 477 driver working on a Jetson Orin NX 16GB with a Seeed Studio A603 carrier board, running JetPack 6.2. I followed the docs at the Arducam multi-camera quick start guide for channel selection, but I’m hitting a wall.
I can see the camera at /dev/video0:
ls /dev/video0 /dev/video0
But when I try to run a GStreamer pipeline, it fails immediately:
libEGL warning: DRI3: failed to query the version
libEGL warning: DRI2: failed to authenticate
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute:805 Failed to create CaptureSession
WARNING: from element /GstPipeline:pipeline0/GstEglGlesSink:eglglessink0: Pipeline construction is invalid, please add queues.
../libs/gst/base/gstbasesink.c(1249): Not enough buffering available for the processing deadline of 0:00:00.015000000
Got EOS from element "pipeline0". EOS received - stopping pipeline...
Execution ended after 0:00:00.273944450
“Failed to create CaptureSession” seems like the core issue. Anyone seen this before on Orin NX? The EGL warnings might be unrelated but figured I’d include everything.
So the sensor at I2C address 9-001a is failing the board setup with error -121 (I2C read probe failure), but the sensor at 10-001a binds successfully. That would explain why nvarguscamerasrc can’t create a capture session.
For context, this exact camera + driver combo worked fine previously on a Jetson Xavier NX 16GB with a Seeed Studio A203 carrier board, using the driver package arducam-nvidia-l4t-kernel-t194-4.9.253-tegra-32.7.2-20220519061956_arm64_imx477-stereo-rpi.deb (product B0397).
This is the last thing blocking our migration from Xavier NX to Orin NX. The I2C failure on 9-001a feels like a device tree or pinmux issue specific to the A603 carrier. Anyone from Arducam able to chime in on whether the Hat 477 driver has known issues with the A603?
Thanks for the detailed logs. That dmesg output is very revealing.
Error -121 on the I2C read probe at 9-001a points to a communication failure between the Jetson and the sensor on that particular I2C channel. The fact that 10-001a binds fine suggests the driver itself loads correctly, but something about the physical I2C routing or pin configuration on the A603 carrier is preventing the first camera from responding.
We’ve tested the Hat 477 driver primarily against NVIDIA’s official developer kit carrier boards. With third-party carrier boards like the Seeed Studio A603, there can be minor deviations in I2C bus routing, GPIO assignments, or power sequencing that are enough to break camera initialization — even if the board generally works fine for other peripherals.
I’ve reached out to our engineering team to look into whether we can provide a customized driver build or device tree adaptation for the A603. I don’t have an immediate fix, but this is being reviewed.
Appreciate the quick response and for escalating to engineering. That makes sense about the carrier board differences — the A603 does have a different CSI and I2C layout compared to the A203 that was working before.
Is there anything I can try in the meantime? Like manually probing the I2C bus to confirm the sensor is actually present at 9-001a? Or any device tree tweaks I could attempt on my end while waiting for the engineering review?
You can definitely do some investigation on your side while we wait:
Check if the sensor appears on the I2C bus at all:
sudo i2cdetect -y -r 9
You should see something at 0x1a if the sensor is physically responding. If it’s missing entirely, that points to a power or routing issue on the carrier.
Compare against the working bus:
sudo i2cdetect -y -r 10
You could also try dumping the current device tree to see how the A603 is configuring those I2C and CSI channels relative to the Xavier NX setup.
That said, even if the sensor shows up on i2cdetect, the board_setup function in the driver may still be tripping over GPIO or regulator differences specific to the A603. That’s the part engineering needs to adapt. I’ll update this thread once I hear back from them — for any driver files or patches, I’ll send those through private message when they’re ready.
Interesting — both buses show UU at 0x1a, which means the address is reserved by a kernel driver. So the sensor at 9-001a is physically present and the driver has claimed it, but the board_setup is still failing during initialization. Definitely seems like a GPIO/regulator mapping issue in the driver’s board config for this carrier.
I’ll sit tight for the engineering review. Really hoping we can get this sorted — it’s the last piece of our Orin migration puzzle.
That i2cdetect result is actually helpful — it confirms the sensor at 9-001a is physically present and the driver has claimed the address, but then falls over during imx477_board_setup. That narrows things down significantly: the issue is likely in how the driver maps the A603’s GPIO pins for sensor reset/power-down, or how it configures the regulator supply for that camera port.
The A603 almost certainly has different GPIO assignments for camera control signals compared to both NVIDIA’s reference design and the older A203 carrier you were using. Our engineering team has the details now and is working on a device tree overlay or driver patch to accommodate the A603’s pin mapping.
No ETA yet, but I’ll send any files or test builds through private message as soon as they’re available. Appreciate your patience on this.