Having trouble getting the Arducam Hat 477 (B0397) — the 4× IMX477 sensor array — working on a Jetson Orin NX 16GB with a Seeed Studio A603 carrier board. JetPack 6.2, fresh flash.
We have an older setup with a Jetson Xavier NX 16GB + Seeed A203 carrier that works fine with the arducam-nvidia-l4t-kernel-t194 driver package. Followed the same general approach from the Arducam multi-camera guide for channel selection.
/dev/video0 shows up:
$ ls /dev/video0
/dev/video0
But as soon as I try to pull frames with GStreamer:
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: Pipeline construction is invalid, please add queues (gstbasesink.c:1249)
Got EOS from element "pipeline0"; Execution ended after 0:00:00.273944450
Tried both over SSH with -Y and directly connected HDMI — same result. Anyone else run into this with the A603 carrier?
That CaptureSession error usually means the camera sensor isn’t initialising properly at the kernel level. Can you run sudo dmesg | grep imx477 and paste the output? That’ll show us what’s happening during probe.
Interesting — one sensor at 10-001a binds fine, but the one at 9-001a fails with -121. The board setup / i2c read probe is dying on that first address.
For context, our working Xavier NX rig uses a Seeed A203 carrier with t194 kernel drivers and everything probes cleanly there.
That -121 error on i2c address 9-001a is the smoking gun. It’s an i2c communication failure — the driver’s imx477_board_setup tries to read from the sensor over i2c and gets no response at all.
Here’s what’s going on: the Arducam IMX477 driver (imx477_v2.0.6) was developed and tested against the official NVIDIA carrier board. The Seeed Studio A603 has different i2c bus routing and pin mapping compared to the reference design. So while the sensor at 10-001a happens to land on a correctly-routed i2c bus, the one at 9-001a doesn’t — hence probe succeeds on one and fails on the other.
This isn’t a faulty camera or a general JetPack 6.2 incompatibility. The driver simply doesn’t know about the A603’s i2c layout.
I’ve sent you the driver source package via private message. You’ll need to adapt the i2c bus / pin mapping in the device tree and board setup code to match the A603 carrier’s routing. Check the attached document in the PM as well — it walks through the adaptation points.
The key areas to look at are the i2c adapter numbering and the regulator / reset GPIO mappings that imx477_board_setup relies on. Once both 9-001a and 10-001a probe cleanly, the GStreamer pipeline should come up.
Received the source package, thanks. Just to make sure I’m looking in the right place — is this purely a device tree change, or does the imx477_board_setup function itself need modification for the A603? Also, roughly how involved is this kind of port? We haven’t done a sensor driver adaptation on Orin before.
It’s mostly on the device tree side, but you may need to touch the board setup callback depending on how the A603 wires things.
Specifically:
Device tree — You’ll need to verify/correct the i2c bus numbers assigned to each camera slot. The A603 almost certainly maps the four IMX477 sensors to different i2c adapters than the NVIDIA devkit does. The 9-001a vs 10-001a addresses in dmesg tell you the i2c bus numbers (9 and 10), but whether those correspond to the physical CSI lanes you expect is the question. You need to trace which i2c bus each sensor lands on and align that with the A603’s pinout.
Board setup (imx477_board_setup) — If the A603 uses different GPIOs for camera reset/power-down, or if the regulator tree is different, you’ll need to adjust those mappings. The -121 error at the read probe stage often means the sensor isn’t powered up or isn’t out of reset at the moment the driver tries to talk to it.
Power sequencing — Check whether the A603 powers the camera rails in the order the IMX477 expects. Sometimes a third-party carrier brings up power domains in a different sequence, and the sensor needs a small delay or explicit regulator enable before i2c becomes usable.
Start by dumping the A603’s full i2c topology (sudo i2cdetect -l and then probe each bus) and compare it to what the working Xavier NX + A203 setup looks like. That’ll tell you a lot about what’s different.
Good pointers, thanks. I’ll start with the i2c topology comparison between the A203 and A603 and go from there. Will post back once I’ve made some progress — might be useful for anyone else running into this on third-party Orin carrier boards.