IMX708 camera not detected on Raspberry Pi 4B – rpicam-still finds no cameras

Hi everyone, hoping someone can help me out here. I picked up a Raspberry Pi Camera Module 3 (IMX708) and installed it on my Pi 4B, but it’s never been detected — hasn’t worked once since I got it. I’m running Debian GNU/Linux 13 (trixie) with kernel 6.12.47+rpt-rpi-v8 aarch64.

I followed the Arducam troubleshooting guide and ran the basic checks:

rpicam-still --list-cameras gives me:

No cameras available!

And when I check the video devices:
ls /dev/video* only shows /dev/video10 through /dev/video31 — there’s no /dev/video0 for the camera at all.

Any ideas where I should start looking?

Welcome! Those are the right first steps to take. Let’s dig a bit deeper — can you check two things for us?

  1. Your /boot/firmware/config.txt — look for camera_auto_detect and any dtoverlay lines related to the camera.

  2. Run dmesg | grep -E "imx|arducam" and post the output. This will show us what the kernel is doing when it tries to load the camera driver.

Sure thing. Here’s the relevant part of my /boot/firmware/config.txt:

camera_auto_detect=0
dtoverlay=vc4-kms-v3d
max_framebuffers=2
arm_64bit=1
[all]
enable_uart=1
dtoverlay=imx708

And here’s the dmesg output:

[0.024539] /soc/csi@7e801000: Fixed dependency cycle(s) with /soc/i2c0mux/i2c@1/imx708@1a
[0.024618] /soc/i2c0mux/i2c@1/imx708@1a: Fixed dependency cycle(s) with /soc/csi@7e801000
[0.025633] /soc/csi@7e801000: Fixed dependency cycle(s) with /soc/i2c0mux/i2c@1/imx708@1a
[0.040959] /soc/i2c0mux/i2c@1/imx708@1a: Fixed dependency cycle(s) with /soc/csi@7e801000
[1.244383] /soc/csi@7e801000: Fixed dependency cycle(s) with /soc/i2c0mux/i2c@1/imx708@1a
[1.244426] /soc/i2c0mux/i2c@1/imx708@1a: Fixed dependency cycle(s) with /soc/csi@7e801000
[5.170147] imx708 10-001a: failed to read chip id 708, with error -5
[5.174067] imx708 10-001a: probe with driver imx708 failed with error -5

Those dependency cycle messages look concerning but I’m not sure if they’re the actual problem.

Thanks, that’s really helpful. Your config.txt looks correct — camera_auto_detect=0 with dtoverlay=imx708 under [all] is the right way to manually enable the camera overlay.

Now, the critical line in your dmesg is this:

imx708 10-001a: failed to read chip id 708, with error -5

Error -5 is EIO (I/O error). What this means is the kernel driver is loading and it’s attempting to communicate with the camera over the I2C bus (at address 10-001a), but it can’t even complete the most basic handshake — reading the chip identifier. The dependency cycle warnings around imx708 and csi are cosmetic and not the root cause here; those show up even on working setups with manual overlay config.

This almost always points to a physical connection problem — either the ribbon cable isn’t making good contact, there’s a bad crimp or damaged trace, or the module itself has a hardware fault.

Can you physically inspect and reseat the ribbon cable on both ends (the Pi side and the camera module side)? If you can post some close-up photos of both connections, that’ll help us check the alignment and insertion.

I’ve already checked and reseated the cable on both ends — it looks good to me. Here are photos of the Pi side and the camera module side connections:

Pi side connection

Another angle Pi side

Camera module side

Another angle camera side

Unfortunately I only have the one Raspberry Pi and this one camera module, so I can’t cross-test with another board or swap the cable with a known-good one.

Thanks for the photos — I’ve taken a close look at both ends. From what I can see, the ribbon cable appears to be inserted and the connectors look properly seated, though it’s sometimes hard to tell definitively from photos alone.

Let me summarise where we are with the evidence so far:

  • The imx708 driver does load — we can see it attempting to probe at I2C address 10-001a in dmesg.
  • Your overlay configuration (dtoverlay=imx708 under [all], with camera_auto_detect=0) is correct.
  • Your kernel version (6.12.47) and OS fully support the IMX708 module.
  • But the probe fails at step one: reading the chip ID over I2C. Error -5 (EIO) means the kernel sends the request and gets nothing back — this isn’t a version mismatch or a config rejection, it’s a complete electrical-level communication failure.

The dependency cycle warnings (Fixed dependency cycle(s) with /soc/i2c0mux/i2c@1/imx708@1a) are a secondary observation — they’re not contributing to this failure and are commonly seen even on working systems with manual overlay configuration.

This really narrows things down to the physical layer:

  • The ribbon cable — an internal break, a bad crimp, or worn contacts that aren’t visible externally
  • The connector seating — even if it looks good, a fraction of a millimetre misalignment can cause this
  • The camera module itself — a hardware defect on the board

Since you don’t have spare hardware to isolate whether it’s the cable or the module, and the software side all looks correct, the next logical step would be trying a replacement ribbon cable if you can get hold of one — cable issues are the more common failure point in these scenarios.