IMX477 hangs through Multi Camera Adapter V2.2 on Pi 5, works direct — I2C/GPIO confirmed fine

Raspberry Pi Cameras
1

  1. Where did you get the camera module(s)?
    Authorized reseller - will specify if necessary

  2. Model number of the product(s)?

  • Multi Camera Adapter Module V2.2 (B012001)
  • 3x Official Pi HQ Camera / Arducam IMX477 CS-Mount
  1. What hardware/platform were you working on?
  • Raspberry Pi 5 (4GB)
  • Raspberry Pi OS, kernel 6.12.93+rpt-rpi-2712
  • libcamera v0.5.2+99-bfd68f78, libpisp v1.2.1
  1. Instructions you have followed. (link/manual/etc.)
  • Quick Start Guide for Multi-Camera Adapter Board (Arducam Wiki)
  • config.txt: dtoverlay=camera-mux-4port,cam0-imx477,cam1-imx477,cam2-imx477
  1. Problems you were having?
    A single IMX477 wired directly to the Pi 5’s own CSI connector (no mux, plain dtoverlay=imx477) captures correctly. The same camera, same cable type, connected through Camera Port A on the Multi Camera Adapter V2.2 hangs indefinitely on every capture attempt. This happens with only that one camera physically connected and only cam0-imx477 declared in config.txt, as well as with 3 (so this isn’t the declared-vs-connected-camera-count mismatch reported in an earlier thread on this board: Multi Camera Module V2.2 Not Working With Four IMX477 Cameras).

rpicam-still hangs after “Selected sensor format” and repeatedly reports:

WARN V4L2 v4l2_videodevice.cpp:2155 /dev/video4[50:cap]: Dequeue timer of 1000000.00us has expired!
ERROR RPI pipeline_base.cpp:1346 Camera frontend has timed out!

This happens identically:

  • With each of the 3 physical cameras selected individually (--camera 0/1/2)
  • At full resolution (4056x3040) and at low res (1332x990), so it doesn’t appear to be a bandwidth/signal-margin issue that scales with data rate
  1. The dmesg log from your hardware?
[    1.090923] /axi/pcie@1000120000/rp1/i2c@80000/pca@70/i2c@0/imx477@1a: Fixed dependency cycle(s) with /video-mux
[    2.960087] pca954x 11-0070: registered 4 multiplexed busses for I2C mux pca9544
[    4.442631] gpio-mux mux-controller: 8-way mux-controller registered
[    4.534869] rp1-cfe 1f00128000.csi: found subdevice /video-mux
[    4.534885] rp1-cfe 1f00128000.csi: Using sensor video-mux for capture
[    4.660946] imx477 15-001a: Device found is imx477

No EBUSY, no probe-deferral failures, no dependency-cycle errors that didn’t self-resolve — the control plane looks clean.

  1. Troubleshooting attempts you’ve made?
  • I2C control path: confirmed working. Sensor mode negotiation succeeds every time; pca954x 11-0070 registers correctly with 4 multiplexed busses; each camera enumerates on its own pca@70/i2c@N sub-bus.
  • GPIO switching: confirmed working. pinctrl get 4,17,18 shows three distinct, reproducible drive patterns corresponding to --camera 0/1/2, matching what’s expected of this overlay’s gpio-mux control.
  • Media graph construction: confirmed working. dmesg shows rp1-cfe 1f00128000.csi: found subdevice /video-mux and Using sensor video-mux for capture, so the CFE driver correctly recognizes and uses the mux.
  • Cable/connector: confirmed correct. Mux output is on CAM/DISP1 (this overlay’s default), and disturbing/misconnecting even one camera-to-mux cable causes total camera loss (all ports), which is not what’s happening here.
  • Sensor/cable in isolation: confirmed good, per the direct-connection test above.
  • Verified all 3 cameras individually enumerate and negotiate modes correctly via I2C
  • Verified GPIO mux-select lines change correctly and distinctly per camera
  • Tested full-res and lowest-binned-mode capture; both hang identically
  • Confirmed single camera works when bypassing the mux entirely (direct to Pi 5 CSI connector)
  • Confirmed cable is in the CAM/DISP1 connector (this overlay’s default)
  • Ruled out an earlier Pi5 CFE driver bug (raspberrypi/linux pull 5744) as inapplicable to this kernel version

Given all of that, this looks like the analog CSI switch itself failing to pass MIPI data on the Pi 5, regardless of control-plane correctness or data rate.

  1. What help do you need?
    Is this board (V2.2 / B012001) confirmed to work on Raspberry Pi 5 with the current rp1-cfe/PiSP stack, given the analog switch was originally designed against the Pi 4/CM4-era Unicam receiver? If Pi 5 compatibility is established for this revision, is there a known cause for the switch passing I2C/GPIO control correctly but not CSI data at any resolution? I’m trying to establish whether this is something I’ve overlooked, a defective unit, or a platform incompatibility.