Arducam B0249 camera i2c probe failed on Jetson Orin Nano, JetPack 6.1.2

Nvidia Jetson Cameras
1

Hey everyone, I’m struggling to get my Arducam B0249 (AR0234 global shutter) working on a Jetson Orin Nano 8GB SD Dev Kit. Running JetPack 6.1.2 with L4T 36.x and kernel 5.15. The camera has never worked properly since I got it.

There are no /dev/video* devices showing up at all. dmesg is showing:

  • i2c probe failed (-121)
  • ‘board setup failed’

It seems like the Jetson can see something on the CSI bus but can’t actually pull data from the module. I’m guessing this is a kernel-level driver incompatibility with the latest JetPack version. Has anyone gotten this camera working on JP 6.1.2?

2

Can you share a bit more about your setup? Specifically:

  • Which CSI port are you using?
  • Can you post the full dmesg output related to the camera (grep for arducam, imx, or video)?
  • What instructions or documentation did you follow for the driver installation?

The i2c probe failure at -121 usually indicates a communication problem on the I2C bus, which can be caused by a missing or incorrect device tree overlay. But with JP 6.1.2 being fairly new, there’s a good chance the existing driver packages haven’t been updated for kernel 5.15 yet.

3

Sure, here are the full environment details:

  • Platform: Jetson Orin Nano 8GB SD Dev Kit (also labeled as Jetson Nano Super 8GB Dev Kit)
  • JetPack 6.1.2, L4T 36.x, kernel 5.15
  • Camera: Arducam B0249 (AR0234 global shutter) over CSI-2
  • I followed a mix of the online docs, some YouTube videos, and AI-generated instructions

What I’ve tried so far:

  • Dug through kernel logs looking for clues
  • Multiple driver reinstall attempts
  • The camera has literally never produced a /dev/video node on this setup

I’m looking for a working driver + DT overlay that’s compatible with JP 6.1.2 — ideally a .deb package or install script, with the correct DTBO that has proper CSI mapping and lane_polarity configured. Also need a V4L2 validation recipe (expected /dev/videoX, media-ctl -p output, and a known-good gst-launch-1.0 pipeline).

As a fallback: is there a confirmed supported JetPack version for this camera? If I need to roll back, I’d need the SD image and flashing steps that work on Windows (Balena Etcher or similar).

4

Thanks for the detailed info. Here’s what I can tell you right now:

The root issue is that the Arducam B0249 drivers haven’t been updated for JetPack 6.1.2 (L4T 36.x, kernel 5.15) yet. The kernel-level errors you’re seeing — i2c probe failures and board setup failures — point directly to the driver not being compatible with the kernel interfaces in this L4T release.

A few things I’d suggest while we wait for updated drivers:

  1. Can you run the arducam-camera-bug-report-nvidia tool and share the output? That’ll give us a clearer picture of what the system is seeing.
  2. In the meantime, could you post the output of:
    • sudo dmesg | grep -E "arducam|imx|ar0234|video|tegra-cam"
    • ls /proc/device-tree/cam_i2cmux/i2c@*/*/compatible 2>/dev/null

This will help confirm whether the DT overlay is loading at all and what the kernel is actually probing on the I2C bus.

5

Okay so something weird happened. A few days ago the B0249 was actually being recognized — ls /dev/video* was showing devices. But then I installed and configured a new Arducam camera with an imx219 sensor, and now the B0249 stopped being recognized on cam port 1.

I’ve since unplugged the imx219 module and reinstalled the Arducam drivers, but it still won’t come back. Spent about 24 hours trying to re-register the camera module with the old Arducam drivers and nothing worked.

I think there might be device tree overlay conflicts from when I configured the imx219 (which is natively supported). I messed with the python configuration scripts and now I’m worried there are leftover overlay fragments causing problems.

What I need:

  • A step-by-step guide to completely wipe and reinstall the B0249 drivers from scratch
  • How to clean up all device tree overlays — especially any adjustments the python configure tool made for the natively supported imx219 module
6

That’s an important clue. If the B0249 was working before and broke after adding the imx219, this sounds like a device tree conflict. The imx219 overlay may be claiming the CSI lanes or I2C bus that the B0249 was using, and remnants are sticking around even after unplugging.

Before we go nuclear on the overlays, let’s get some diagnostics first. Run the bug report tool:

sudo arducam-camera-bug-report-nvidia

Also, can you run these and post the output?

ls /boot/arducam/
cat /boot/extlinux/extlinux.conf | grep -A5 "overlays"
dmesg | grep -i "tegra-camera-platform\|pinctrl\|cam_gpio"

This will tell us exactly which overlays are being loaded and whether there’s a pinmux conflict between the two camera definitions.

7

Here’s what I’m getting when I try to use the camera now:

unknown arguments: open device /dev/video0, exiting.
height=Cannot open device /dev/video0, exiting.
pixelformat=RG10
WARNING: erroneous pipeline: syntax error

I also ran the bug report tool and it generated arducam-bug-report.txt.

But here’s the thing — I only ever tried to configure the driver with Y16 and BA10 pixelformats. I never used RG10. The bug report is claiming RG10 is invalid, but I never set that. Something seems off with the diagnostic output itself.

8

Good catch on the RG10 discrepancy. I think I know what’s going on.

I had an AI coding agent take a look at the arducam-camera-bug-report-nvidia diagnostic script, and it found a bug. The script uses Python’s cmd.split(' ') to parse GStreamer pipeline commands before running them. The problem is that GStreamer pipelines contain quoted arguments like 'video/x-raw(memory:NVMM),...' — and splitting on spaces breaks those quoted strings apart.

This means the commands being tested by the bug report tool are malformed, which causes the “erroneous pipeline: syntax error” false negatives you’re seeing. The tool makes it look like the camera or overlay is broken when the actual issue is just command string parsing inside the diagnostic script.

The RG10 thing is likely another symptom of this — the tool may be misreporting which pixelformat it’s testing.

Here’s the fix. Locate the script first:

which arducam-camera-bug-report-nvidia
readlink -f "$(which arducam-camera-bug-report-nvidia)"

Then apply these patches:

FILE="$(readlink -f "$(which arducam-camera-bug-report-nvidia)")"
sudo grep -q '^import shlex$' "$FILE" || sudo sed -i '0,/^import select$/s/^import select$/import select\nimport shlex/' "$FILE"
sudo sed -i "s/subprocess\.run(cmd\.split(' '))/subprocess.run(shlex.split(cmd))/g" "$FILE"

This adds import shlex and replaces the broken cmd.split(' ') with shlex.split(cmd), which properly handles quoted arguments. Run the bug report tool again after applying this and see if the output makes more sense.

That said — this is a diagnostic tool fix. Your underlying driver compatibility issue with JP 6.1.2 / kernel 5.15 is still the real problem, and we’re still waiting on updated driver packages for that L4T version.

9

Applied the shlex fix to the bug report script — that cleaned up the pipeline parsing errors. At least now the diagnostic output isn’t generating false negatives.

But yeah, the core issue remains: no /dev/video* on JP 6.1.2 kernel 5.15. And on top of that, I still have the leftover device tree mess from the imx219 experiment. Can you walk me through cleaning up the overlays so at least when proper JP 6.1.2 drivers do land, I’m starting from a clean slate?

10

Alright, let’s get you to a clean state. Here’s the overlay cleanup procedure:

First, check what Arducam overlays are currently registered:

ls /boot/arducam/
cat /boot/extlinux/extlinux.conf

Look for any FDT or OVERLAYS lines referencing arducam DTBOs. To wipe them clean:

  1. Remove Arducam overlay entries from extlinux.conf — edit the file and delete any lines under the OVERLAYS section that point to /boot/arducam/*.dtbo

  2. Remove the overlay files themselves:

sudo rm -f /boot/arducam/*.dtbo
  1. Also check for any leftover imx219-related overlays that may have been placed by Jetson-IO or the python config tool:
ls /boot/*.dtbo
ls /opt/nvidia/jetson-io/config-by-hardware/*/
  1. Once everything is cleaned, reboot:
sudo reboot
  1. After reboot, verify no camera overlays are loaded:
dmesg | grep -i "tegra-camera-platform"
cat /sys/kernel/debug/tegra_cam_i2c/status 2>/dev/null || echo "debugfs not mounted"

Now, regarding the JP 6.1.2 / kernel 5.15 driver situation: this is the real blocker. The B0249 driver package needs to be rebuilt against the kernel 5.15 headers that ship with L4T 36.x. I’ve flagged this with the engineering team. In the interim, if you absolutely need the camera working now, rolling back to JetPack 5.x (L4T 35.x, kernel 5.10) would be the path — the existing B0249 driver packages are confirmed working there. I can send you the SD image and flashing instructions via private message if you want to go that route.

For now, getting your overlay state cleaned up is the right move so there’s nothing conflicting when the updated packages drop.