Can't install Arducam B0221 driver on reComputer J4011 - kernel version mismatch

Nvidia Jetson Cameras
1

Hey everyone, I’m trying to get an Arducam B0221 (OV2311 Jetvariety Camera) working with my reComputer J4011 carrier board. It’s the Seeedstudio 110110144 model with a Jetson Orin NX 8GB and a 128GB NVMe drive. I bought the camera from botland.pl.

I followed the official Arducam Quick Start Guide to install the drivers, but it’s failing. The installation script halts early on with a kernel version mismatch. I ran uname -r and my kernel is 5.10.192-tegra-35.5.0-20240613202628. The driver package names I can see available on the Arducam side top out at 5.10.192-tegra-35.5.0-20240219203809. Same base kernel, but the build timestamps don’t match and the installer refuses to proceed.

Has anyone run into this and found a way around it? I can’t see the camera in /dev at all right now, which I assume is because the drivers never loaded.

2

Welcome to the forum. That kernel version string is interesting — the 20240613202628 timestamp suggests a custom build, which is fairly common on third-party carrier boards like the reComputer J4011. Seeedstudio ships their own BSP with a modified kernel.

Just to be thorough, can you share the exact output of:

uname -a

And also whatever error message the Arducam install script throws? It would help to see whether it’s purely a version string check or if there’s a deeper module signing / vermagic mismatch happening. Also, have you tried ls /dev/video* before and after running the install to confirm no device nodes appear at all?

3

Sure, here’s the full uname output:

Linux recomputer 5.10.192-tegra-35.5.0-20240613202628 #1 SMP PREEMPT Thu Jun 13 20:26:28 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux

The installer error is basically:

Kernel version mismatch: expected 5.10.192-tegra-35.5.0-20240219203809, got 5.10.192-tegra-35.5.0-20240613202628
Aborting installation.

And no, ls /dev/video* returns nothing before or after. I even tried manually downloading the .deb package for the 20240219203809 kernel and forcing it with dpkg -i --force-depends, but it still rejects it because the vermagic string baked into the module doesn’t match the running kernel.

I poked around and I think I could edit the package’s control file or the version check in the install script to bypass it. The kernels are practically identical — same 5.10.192 base, same tegra-35.5.0 — just a different build timestamp. Is that safe to try? I’m a bit worried about bricking something or frying the camera sensor.

4

Good debugging so far. A few things to unpack here.

On the safety question: editing the vermagic or the version check won’t physically damage your camera sensor — the kernel module just won’t load if there’s an ABI incompatibility. Worst case, you get a kernel oops or the module simply refuses to insert. That said, the vermagic check exists for a reason. If Seeedstudio changed anything in the kernel’s V4L2 subsystem, media controller framework, or the Tegra ISP/VI drivers between their build and the stock NVIDIA L4T build that Arducam targets, you could end up with silent failures or weird behavior even if the module loads.

Now, the bigger issue: the reComputer J4011 uses a proprietary carrier board design. The camera interfaces (MIPI CSI lanes, I2C routing, clock lines, power sequencing) are entirely determined by the carrier board layout, not just the module. Arducam’s Jetvariety drivers assume a specific pin mapping and device tree structure. Seeedstudio’s BSP likely has its own device tree that may or may not expose the camera interfaces in a way Arducam expects.

Before you go down the rabbit hole of hacking the module version checks, can you share:

ls /sys/class/video4linux/

and also

dmesg | grep -i -E "camera|imx|ov|ar023|video|mipi|csi|vi[0-9]"

This will tell us whether the kernel even sees anything on the CSI bus at the hardware level.

5

Here’s what I get:

ls /sys/class/video4linux/ returns nothing — directory is empty.

And the dmesg grep:

[    5.241197] tegra-camrtc-capture-vi tegra-capture-vi: subdev tegra-vi2 not bound
[    5.242110] tegra-camrtc-capture-vi tegra-capture-vi: subdev tegra-vi4 not bound
[    5.243011] tegra-camrtc-capture-vi tegra-capture-vi: subdev tegra-vi5 not bound
[    5.243912] tegra-camrtc-capture-vi tegra-capture-vi: subdev tegra-vi6 not bound
[    5.244817] tegra-camrtc-capture-vi tegra-capture-vi: subdev tegra-vi7 not bound

And a bunch of lines like:

[    4.567890] vi4: vi capture driver initialized

But nothing referencing a camera sensor being detected — no OV2311, no Arducam, no sensor probe messages at all.

So the VI (Video Input) hardware is there but nothing is bound to it. That makes sense if the drivers aren’t installed, but I’m also wondering if the carrier board is even routing the CSI signals the way Arducam expects. The J4011 has a 22-pin camera connector but I have no idea if the pinout matches what the B0221 expects.

6

That dmesg output is very telling. The tegra-viX not bound messages mean the NVIDIA VI hardware blocks are initialized but no sensor subdevices are attaching to them. This could be a driver issue, but it could also be a device tree / hardware routing issue.

Here’s the core problem as I see it:

The reComputer J4011 carrier board from Seeedstudio ships with a custom kernel build (5.10.192-tegra-35.5.0-20240613202628). This kernel build timestamp differs from the closest Arducam-supported driver (5.10.192-tegra-35.5.0-20240219203809), and because it’s a proprietary third-party board, you’re effectively locked into Seeedstudio’s kernel releases. You can’t just flash a stock NVIDIA L4T kernel — the carrier board needs Seeedstudio’s device tree and board support package to function correctly (power management, pinmux, etc.).

So even if you bypass the vermagic check and force the Arducam module to load, there’s a strong chance the device tree on the J4011 doesn’t have the right camera sensor node defined with the correct I2C address, MIPI lane mapping, and clock configuration for the OV2311 on the B0221.

Here’s what I’d recommend as a next step to isolate the problem:

  1. If you have access to an official NVIDIA Jetson Orin dev kit (or an Arducam-supported carrier board), install the Arducam drivers there following the same Quick Start Guide. If the camera works, the issue is confirmed to be with the reComputer J4011 carrier board compatibility — not with the camera itself.

  2. If the camera also fails on an official dev kit with the correct kernel, then we’re looking at a different issue and can troubleshoot further.

In parallel, you might want to ask Seeedstudio whether their J4011 carrier board’s 22-pin camera connector follows the standard NVIDIA Jetson camera pinout and whether they expose the I2C bus and CSI lanes needed for third-party MIPI sensors. If their pinout is non-standard or the I2C isn’t routed to the camera connector, no amount of driver hacking will help.

7

That makes sense. I don’t have an official dev kit handy right now, but I can try to borrow one. In the meantime, is there any way to at least check whether the I2C bus is even reaching the camera connector on the J4011? Like, can I probe the I2C bus from userspace to see if the OV2311 responds at its expected address?

Also — you mentioned the device tree. Is there a way for me to dump the current device tree and see if any camera sensor nodes are defined? Maybe Seeedstudio included a compatible sensor node and it’s just a matter of the driver module not matching.

8

Great questions. Yes, you can do both of those things right now without any special hardware.

1. I2C probing:

The OV2311 typically sits at I2C address 0x60 or 0x30 (depending on how the sensor’s address pin is strapped on the B0221 module). First, figure out which I2C bus is routed to the camera connector:

sudo apt-get install i2c-tools
sudo i2cdetect -l

Look for buses that might be camera-related — on Jetson Orin they’re often /dev/i2c-6, /dev/i2c-7, /dev/i2c-8, or /dev/i2c-9 (the CAM I2C buses). Then probe each:

sudo i2cdetect -y -r 6
sudo i2cdetect -y -r 7
sudo i2cdetect -y -r 8
sudo i2cdetect -y -r 9

If you see a device at 0x30 or 0x60 (or any address other than UU and --), something is physically responding on that bus. If all addresses show --, chances are the camera isn’t powered or the I2C isn’t routed correctly.

2. Device tree inspection:

You can decompile the current device tree from the running system:

sudo dtc -I fs -O dts /sys/firmware/devicetree/base > current-dt.dts

Then search for camera-related nodes:

grep -A 20 -i -E "camera|sensor|ov|imx|ar0231|module" current-dt.dts | head -100

Or more specifically, look for any sensor nodes under the VI or CSI parent nodes. If Seeedstudio included placeholder sensor nodes, they’d show up here. If not, the device tree simply has no idea a camera should be there.

Run those and share what you find. That’ll give us a pretty clear picture of whether this is purely a driver version issue or a deeper hardware compatibility gap.

9

Okay, ran the checks.

i2cdetect: I went through i2c buses 0 through 9. Buses 6, 7, 8 looked promising but all addresses came back as --. Bus 0 and 1 had a couple of UU entries which I assume are system devices. Nothing at 0x30 or 0x60 anywhere. I double-checked the camera is properly seated in the connector — re-seated it twice. No change.

Device tree: Dumped it and searched. I see the tegra-vi and tegra-capture-vi nodes, but there are no child sensor nodes defined under any of them. No OV2311, no IMX, no camera module nodes at all. Just the bare VI hardware blocks with nothing attached.

So I think you were right — the carrier board’s device tree doesn’t have any camera sensor definitions, and the I2C scan suggests the camera isn’t even getting powered or the bus isn’t routed. This looks like a fundamental compatibility issue with the J4011.

10

That pretty much confirms it. Empty I2C scan across all buses combined with no sensor nodes in the device tree means this is a carrier board compatibility problem, not just a driver version mismatch.

To summarise where things stand:

  • The reComputer J4011 uses a proprietary Seeedstudio BSP with a custom kernel (5.10.192-tegra-35.5.0-20240613202628) that doesn’t match any Arducam driver build. Even if you bypassed the vermagic check, there are no camera sensor device tree nodes defined, which means the kernel has no way to know what sensor is connected, how to power it, or how to configure the MIPI lanes.
  • The I2C scan came up empty, which strongly suggests either the camera isn’t being powered by the carrier board’s camera connector, or the I2C lines aren’t routed to a bus that’s accessible from userspace. Either way, the sensor can’t be addressed.
  • This isn’t something you can fix with a driver hack. You’d need Seeedstudio to provide a BSP update that exposes the camera connector properly with a defined sensor node, or you’d need to modify and recompile the device tree yourself — which is non-trivial and still not guaranteed to work if the hardware routing is non-standard.

The recommended path forward: test the Arducam B0221 on an official NVIDIA Jetson Orin development kit (or any Arducam-listed compatible carrier board) using the standard Arducam Quick Start Guide. This will confirm whether the camera module itself is functional. If it works on the dev kit, the J4011 is the culprit and you may want to reach out to Seeedstudio about their camera connector pinout and whether they plan to support third-party MIPI sensors. If the camera also fails on the official kit, we can continue troubleshooting from there — but I suspect it’ll work fine on supported hardware.