This driver works, but it’s locked to Raspberry Pi kernel 5.4
We’re building a medical imaging proof-of-concept and kernel 5.4 is just too old — it’s blocking continued development. We really need to move to kernel 6.x but the existing driver has zero support for anything beyond 5.4.
Has anyone successfully migrated a UC-512 + OV9281 setup to kernel 6? Is there an alternative driver path that works with the Camarray HATs on newer kernels?
Thanks for the detailed post. The OBISP MIPI driver you’re on is indeed legacy and tied to the older kernel fork, so you’re right — there’s no direct upgrade path from that repo.
Have you had a chance to try our newer V4L2-based driver? It’s here:
That’s the current development target and it does support kernel 6.x on Raspberry Pi. I’d be interested to see if it works with your UC-512 + OV9281 configuration. I know the Camarray HAT introduces some extra complexity with the multi-camera muxing, so it may not be straightforward.
Can you give it a shot on a test SD card with a newer kernel and report back what happens?
Alright, gave the Pivariety V4L2 driver a try. Here’s what I tested:
Raspberry Pi OS Bullseye
Kernel 6.1.21
UC-512 Camarray HAT with 4× OV9281 cameras attached
Unfortunately, no luck. The driver doesn’t work. I’m attaching a screenshot of the error output from picamera2:
It looks like the V4L2 device isn’t being created properly or the driver isn’t binding to the cameras through the HAT. The OBISP driver on kernel 5.4 handles the Camarray muxing just fine, but this V4L2 driver doesn’t seem to recognize the setup at all.
That’s useful, thank you for testing and sharing the screenshot. The error does suggest the driver isn’t probing the camera array correctly through the Camarray HAT.
Before we dig deeper — can you also try this on a more recent OS/kernel combination? Bullseye with 6.1.21 is getting a bit dated now, and there have been some V4L2 subsystem changes in newer kernels that might affect how the driver interacts with the HAT’s I2C mux and CSI switching.
I’d recommend testing with:
Raspberry Pi OS Trixie
Kernel 6.12.x (latest available)
Same hardware, just a fresh OS image. Let’s see if the behavior changes at all.
Same result unfortunately. The error is essentially identical to what I saw on Bullseye/6.1.21. The driver loads but can’t properly enumerate or access the cameras behind the Camarray HAT.
At this point I’ve tested the Pivariety V4L2 driver on two different kernel 6.x versions across two different OS releases, and both fail the same way. The only configuration that actually works is the old OBISP driver on kernel 5.4.
Okay, I’ve dug into this and I can now confirm what’s happening here. This is a known gap in our current driver lineup:
Arducam_OBISP_MIPI_Camera_Module (your current driver) — this is the only driver with full UC-512 Camarray HAT support, including the multi-camera channel switching and I2C addressing logic for the OV9281 array. But it’s hard-forked from an older kernel tree and there’s no path to kernel 6.x.
Arducam-Pivariety-V4L2-Driver — this is our current-generation V4L2 driver and it does support kernel 6.x, but it does not currently implement the Camarray HAT multiplexing protocol needed for the UC-512 with multiple OV9281 cameras.
So you’re stuck in a gap: the driver that supports your hardware can’t run on kernel 6, and the driver that runs on kernel 6 doesn’t support your hardware configuration.
I’m escalating this internally. The Product & Solutions team needs to assess what it would take to add UC-512 + OV9281 Camarray support into the V4L2 driver (or provide an alternative migration path). This isn’t something I can resolve with a quick config change or patch, unfortunately.
While we’re looking into this internally, a few things that would help us assess the priority and feasibility:
Could you share some sample captures or output from your current working setup (kernel 5.4 + OBISP driver)? This helps us understand exactly how you’re using the camera array — frame rates, resolutions, sync requirements, etc.
Are there any other issues you’re running into beyond the kernel upgrade? Anything else that needs attention with the current setup?
What’s your rough deployment timeline for the kernel 6 migration? Just trying to gauge urgency on our side.
Feel free to send anything sensitive through private message if needed.
Thanks for the detailed analysis — that confirms what I was starting to suspect. Frustrating gap but I appreciate the straight answer.
To answer your questions:
This is for an experimental breast cancer detection proof-of-concept, so the imaging pipeline is fairly demanding. We’re running all 52 cameras (13 HATs × 4 OV9281) and need consistent sync across the array. The current OBISP driver on kernel 5.4 handles the Camarray channel switching fine — we can capture from all four cameras per HAT sequentially without issues.
I’ll send some sample frames and capture parameters privately so you can see what we’re working with.
On timeline — we’re not in production yet, this is still PoC, but the kernel 5.4 limitation is becoming a real problem. Several libraries and tools we need to integrate now require kernel 6.x features, and staying on 5.4 means we’re accumulating technical debt. I’d say we have a few months before this becomes critical.
Really hoping there’s a path forward here — happy to test any experimental builds or patches if that helps move things along.
.jpeg)