Hi everyone, hoping someone here has run into this. I’m using Arducam 8 MP Sony IMX219 camera modules, the imx219 UC-350 (Rev.D), on a Raspberry Pi 4 4GB Model B together with an Arducam multicamera board running 4 cameras off one Pi, all under libcamera.
A few of them will run as a secondary camera, but I honestly can’t figure out why most of them have issues - it’s very intermittent and never stable. Is there any newer driver that fixes the Rev.D boards? Rev.C always worked fine for us, so I’m a bit stuck.
Sure. I’m currently trying to get 25 of 54 cameras to work on the Pi 4 running a 64-bit OS. Roughly one third of the Rev.D modules have unstable behavior, and the failures aren’t consistent - they show up in several different ways:
On boot, some cameras are simply not recognized by the OS at all.
Others get detected but cannot be initialized.
Others start streaming and then stop after a few frames in the live image.
Others run for a while and then throw an error after around 200-500 frames.
All of the faulty ones come from a single batch of Rev.D modules. The other 29 cameras appear to run fine. I’ve attached a couple of images of what’s happening:
That’s actually a very useful pattern - the fact that it’s clustered in one batch points somewhere specific. Two more things I need:
The raw dmesg output (and journalctl if you have it) at the moment a camera fails.
Your exact overlay/config lines for the multicamera board, plus the output of i2cdetect -y 10 (or whichever i2c bus the cameras sit on).
Have you monitored dmesg/journalctl live while streaming, or only after the failure? Seeing when the endpoint error appears relative to the first frame is helpful.
And i2cdetect -y 10 shows the modules that come up on addresses 0x10 and 0x11, but the dead ones don’t show at all. On a bad boot some addresses just never appear.
OK that lines up with what I suspected. The “Consider updating driver imx219 to match on endpoints” message is a known notice when the driver has to fall back and match the sensor differently than the overlay expects, and combined with probe failing at -5 before the addresses even appear, it usually means the sensor isn’t answering on the i2c bus at that point rather than a pure software fault.
Before we blame anything, let’s isolate hardware vs config:
Take one known-good camera and one known-bad camera.
Put each, by itself, on a single camera port with only one overlay enabled.
Swap them between two different ports and see whether the failure follows the module or stays with the port.
That tells us whether it’s the camera batch or the board/port wiring.
Known-good module: works on every port, single or on the board.
Known-bad module: fails on every port. Same behavior - sometimes probe fails at boot, sometimes it starts and dies after a few hundred frames.
So the failure follows the module, not the port. It really looks like the bad modules are hardware, tied to that one batch of Rev.D. Rev.C modules have been rock solid. The board itself and the Pi seem fine, and it’s intermittent on the bad ones - sometimes a reboot brings one up, then it drops out again.
Honestly, the affected ones have never worked properly. They work intermittently and are unstable - sometimes a module runs for a while, then throws one of the errors above and won’t come back until a reboot.
I’ve done a lot of tests and OS upgrades already. Same result on the newer builds I tried. I’ve been watching dmesg and journalctl the whole time. And to answer the last question - the endpoint message shows up on the failing modules, I don’t see it on the 29 that behave.
Given that it’s isolated to one batch and shows up regardless of OS version, this is looking like the known Rev.D IMX219 initialization issue on the Pi 4 with libcamera and the multicamera board - the unmatched endpoints message plus intermittent operation is the signature.
Before concluding anything hardware-side, there’s one more step worth doing, and it’s the one Arducam support usually recommends for exactly this: re-flash (reburn) a clean Bullseye OS image rather than upgrading in place. In-place upgrades can leave a mismatched libcamera/kernel/firmware stack, which makes the endpoint matching problems worse.
Steps:
Back up anything you need.
Re-flash a fresh Raspberry Pi OS Bullseye image to the card (64-bit is fine).
On first boot, run updates, then install libcamera and the multicamera board packages again from scratch.
Re-apply your config.txt overlays (camera_auto_detect=0 plus the four imx219 overlays).
Reboot and check dmesg | grep imx219 and libcamera-hello --list-cameras.
I’ve also sent a screenshot reference through private message - please check your messages. If you can, grab the fresh dmesg from the clean image and post it here.
Did a clean re-flash of Bullseye on a spare card, updated, reinstalled libcamera and the board packages, and re-applied the overlays. Result is mixed:
A few of the previously failing modules now detect and stream, which is more than before.
Several still don’t - I still get “Consider updating driver imx219 to match on endpoints” and the same probe failures (-5) on those, and one still dies mid-stream after ~300 frames with -110.
So the re-flash helped some, but it didn’t fix all of the bad batch modules. I’ll grab a fresh dmesg from the clean image and post it.
That matches what we’d expect. Current state of things, to summarise:
The behavior is tied to a specific batch of Rev.D IMX219 modules - a clean OS re-install changes nothing about the module’s physical behavior.
A clean Bullseye re-flash is the recommended step and it did bring back some modules, so it’s worth doing (in-place upgrades can leave a mismatched libcamera/kernel/firmware stack that aggravates the endpoint matching).
For the modules that still fail after a clean Bullseye image - i.e. still hitting “Consider updating driver imx219 to match on endpoints”, probe errors at -5, or a stream dropping at ~200-500 frames with -110 - there’s no driver change we can point to that fixes a batch-level failure.
So: re-flash Bullseye first, and if a module still fails on the clean image with the same endpoint/probe errors, that points back to those specific Rev.D units. Please post the fresh dmesg from the clean image so we can confirm how many are still affected after the re-flash.
