IMX462 camera not working on Pi Zero 2 Bullseye with arducam-pivariety overlay

Raspberry Pi Cameras
1

Hi everyone, I’m stuck getting an IMX462 camera working on a Pi Zero 2 running Bullseye. I followed the Pivariety quick start guide but libcamera doesn’t see the camera at all.

Environment:

  • Board: Pi Zero 2
  • OS: Bullseye
  • Kernel: Linux PiZero2 5.15.84-v7+ #1613 SMP Thu Jan 5 11:59:48 GMT 2023 armv7l GNU/Linux
  • FullKMS + Glamour enabled

My config.txt has:

dtparam=i2c_arm=on
dtparam=spi=on
dtparam=audio=on
camera_auto_detect=1
display_auto_detect=1
dtoverlay=vc4-kms-v3d
max_framebuffers=2
disable_overscan=1
enable_uart=1
gpu_mem=128
dtoverlay=arducam-pivariety

dmesg | grep arducam shows:

[   11.931340] arducam-pivariety 10-000c: pivariety_read: Reading register 0x103 failed
[   11.931390] arducam-pivariety 10-000c: probe failed

And libcamera-hello gives:

Made DRM preview window
[0:14:08.502836594] [2995]  INFO Camera camera_manager.cpp:299 libcamera v0.0.0+4225-74d023d8
ERROR: *** no cameras available ***

Anyone seen this before?

2

Welcome. The key line is this:

arducam-pivariety 10-000c: pivariety_read: Reading register 0x103 failed
probe failed

The arducam-pivariety overlay is trying to read from the sensor at I2C address 0x0c and failing, so the probe aborts and libcamera reports no cameras. That usually points to a physical connection problem (flex cable not fully seated, wrong connector, etc.) rather than software. Could you post a photo of how the camera is connected to the Pi?

3

The connection is correct, I’ve attached photos:
IMG_20230321_100633.jpg
IMG_20230321_100623.jpg

4

A bit more testing from my side: if I enable legacy camera support, the camera is detected but still doesn’t work. I also tested the ribbon cable with another sensor and it works fine, so the cable itself seems OK.

5

Update: I switched to dtoverlay=imx290 and the camera now comes up, but the image over RTSP is really bad. My command:

libcamera-vid -t 0 --inline --height 1080 --width 1920 --framerate 10 --level 4.2 --bitrate 500000 -o - | cvlc -vvv stream:///dev/stdin --sout '#rtp{sdp=rtsp://:8554/}' :demux=h264
6

Progress - if it previews with imx290, the sensor and cable are fine. For the RTSP quality, the Pi Zero is pretty limited for real-time 1080p H.264 encode, and the wrong overlay/driver could also be hurting quality. Do you have a Pi 3 or Pi 4 you could test the exact same command on? That would tell us whether it’s the board struggling or something with the stream settings/driver.

7

The board is a Pi Zero 2W, by the way.

8

Thanks, Pi Zero 2W confirmed. It’s faster than the original Zero but still not great for 1080p encode. If you can borrow a Pi 3 or Pi 4, run the same libcamera-vid command there. If the image is fine on the bigger Pi, it’s almost certainly the Zero 2W being the bottleneck. If it’s still bad there, then we should look more at the driver side.

9

So on Bullseye only the imx290 overlay works for me - arducam-pivariety never probes. I suspect the camera is running with the wrong driver. I’ve seen other people run this setup on a Pi Zero without issues.

10

Actually that’s an important clue. The newer IMX462 modules have been updated and no longer use the pivariety driver at all, so arducam-pivariety failing to probe may be expected for your module. The photo was a bit hard to identify - can you tell me the exact camera model, or check the silkscreen on the board (something like a B0xxx revision)? That’ll confirm which driver it should use.

11

It’s the Arducam 2MP ultra low light Starvis IMX462 motorized IR-cut camera. I swapped the lens for a motorized one, which is why it looks different from stock. It’s on the Pi Zero 2W under Bullseye, and it only works with dtoverlay=imx290 or dtoverlay=imx462.

12

That confirms it. That model uses the B0423 board, which doesn’t have a pivariety chip - so it needs the native Raspberry Pi camera driver, dtoverlay=imx290 or dtoverlay=imx462, and arducam-pivariety should not be used. So the imx290/imx462 overlay working is the correct behavior, not a wrong driver. For the RTSP quality, the most likely culprit is the Pi Zero 2W struggling with 1080p encoding; the driver itself should be fine. If you want to be sure, still worth running the same command on a Pi 3/4 to compare.