What hardware/platform were you working on?
Raspberry Pi 5, Raspberry Pi OS Bookworm
Instructions you have followed. (link/manual/etc.)
Arducam Quick Start guide - installed via install_pivariety_pkgs.sh (libcamera_dev, libcamera_apps), then added dtoverlay=arducam-pivariety and camera_auto_detect=0 under [all] in /boot/firmware/config.txt
Problems you were having?
Camera is not detected. rpicam-hello --list-cameras reports “No cameras available!”
The dmesg log from your hardware?
arducam-pivariety 4-000c: pivariety_read: Reading register 0x103 failed
arducam-pivariety 4-000c: probe failed
rp1-cfe 1f00128000.csi: found subdevice /axi/pcie@120000/rp1/i2c@80000/arducam_pivariety@c
Troubleshooting attempts you’ve made?
Tested 3 different ribbon cables
Tested both CSI camera ports on the Pi 5
Tried both dtoverlay=arducam-pivariety and dtoverlay=imx462
Set CPU governor to “performance” and reinstalled libcamera_dev (in case of a firmware write issue during install)
Installed the official arducam-pivariety-sdk-dev package via apt and rebuilt
Same “Reading register 0x103 failed” / “probe failed” error persists through all of the above
What help do you need?
I’d like to know whether this is a known firmware issue with a fix, or whether this unit needs to be replaced. Happy to provide any additional logs or run diagnostic tools if needed.
Hey there, yes that’s correct, and no luck. With dtoverlay=imx290,clock-frequency=74250000, the camera is detected (rpicam-hello --list-cameras shows it), but rpicam-still fails with:
Failed to queue buffer: Remote I/O error
Failed to queue buffer for CFE image
To isolate whether this is a libcamera/rpicam-apps issue or lower-level, I tested raw V4L2 streaming directly, bypassing libcamera entirely:
Even with the format explicitly confirmed active (checked via --get-fmt-video), VIDIOC_STREAMON returns -1 (invalid argument) at the raw v4l2 level - no data is captured at all.
This suggests the failure is in the kernel driver/hardware handshake for starting the stream, not in libcamera’s configuration. Given that the native arducam-pivariety driver also fails during its initial register read (0x103), and the generic imx290 overlay gets past detection but fails to start streaming, I suspect there’s a mismatch between this board’s actual physical CSI lane/timing configuration and what the generic imx290 driver assumes - normally resolved by the pivariety firmware data that isn’t being read successfully.
Is there a way to verify or manually specify the correct lane count / timing parameters for this specific board (B0647), or does this confirm a firmware issue that needs to be addressed on Arducam’s end?
Then reboot the Raspberry Pi and test the camera again with rpicam-hello / rpicam-still .
Also, could you please send us a clear photo showing the hardware connection between the B0647 camera board and the Raspberry Pi, including the CSI cable orientation on both ends?
We would like to verify the physical connection before checking further into the driver or firmware side.
Changing the clock from 74250000 to 37125000 fixed the capture. 37125000 is the value in Arducam’s own quick-start guide for their low-light modules, and it matches the oscillator on the board. The wrong frequency let the driver load and report the camera as present, but the sensor couldn’t be configured for streaming, which produced the Remote I/O error on capture. At the current state we’re getting still capture, live video, and video recording. Thanks for the help!
Resolved. Posting the whole sequence in case it helps someone searching later.
Hardware: Arducam B0647 (board also marked LW-021_REV.A), Raspberry Pi 5, Raspberry Pi OS 64-bit.
What was actually wrong — two things:
1.I started from install_pivariety_pkgs.sh and dtoverlay=arducam-pivariety,
which gave:arducam-pivariety: pivariety_read:
Reading register 0x103 failed
arducam-pivariety: probe failed
The B0647 is not a Pivariety module. It uses the stock Raspberry Pi imx290 driver, so the Pivariety script and arducam-pivariety-sdk-dev were never needed.
3.After support pointed me to dtoverlay=imx290, the camera was detected but rpicam-still failed with:
Failed to queue buffer: Remote I/O error
Failed to queue buffer for CFE image
I was running clock-frequency=74250000, chosen because the Amazon listing I bought from describes the module as IMX462. The B0647 datasheet lists the sensor as IMX290, and your low-light quick start specifies 37125000.
The fix — in /boot/firmware/config.txt under [all]:
camera_auto_detect=0
dtoverlay=imx290,clock-frequency=37125000
Still capture, live preview and video all work now.
One correction to my own earlier post: the raw v4l2-ctl result (VIDIOC_STREAMON returned -1, invalid argument) was a red herring. On a Pi 5 the media pipeline has to be configured with media-ctl before streaming /dev/video0 directly, so that command fails even on a perfectly healthy camera. It wasn’t evidence of a hardware fault.
Two requests:
Could you confirm the intended config.txt line for the B0647 specifically on a Pi 5, and whether the onboard ISP needs anything beyond the imx290 overlay? I couldn’t find a B0647-specific quick start page, only the general low-light one.
The Amazon listing for this SKU describes it as IMX462, which is what sent me toward the wrong clock frequency. Might be worth correcting at the source.