I’m having trouble getting an Arducam 64MP Hawk Eye camera to show up on my CM4 setup. Running the latest RPi 32-bit Raspbian. libcamera-hello just says “No camera available” and vcgencmd get_camera also reports no camera. dmesg doesn’t show any camera connected at all. I’ve re-seated the ribbon cable a few times but no luck. Any ideas what I’m missing?
Thanks for the report. From what you’re describing it sounds like it could be a hardware connection issue, but let’s get some more info first. Can you post a couple of pictures of your hardware setup, showing both the camera and the Raspberry Pi/CM4 side?
In the meantime, make sure you’re on kernel 6.1.19 and that libcamera is installed and the camera is enabled in the config file. This guide covers the Hawk Eye 64MP:
https://docs.arducam.com/Raspberry-Pi-Camera/Native-camera/Quick-Start-Guide/#arducam-pi-hawk-eye-64mp-cameras
Also, could you reboot the device and then run this bug report script so I can see the full state of the system?
wget -O arducam-camera-bug-report https://github.com/ketai-dhr/arducam-camera-bug-report/releases/download/tools/arducam-camera-bug-report
chmod +x ./arducam-camera-bug-report
./arducam-camera-bug-report
It will drop an arducam-bug-report.txt in the current directory. Attach that here.
Here’s what I’ve got:
- Arducam_Setup.jpg — my hardware setup picture
- RPI_CAM_Setup.jpg — proof the CSI-2 port works, using the latest official Raspberry Pi camera
- arducam-bug-report_RPI_CAM.txt — bug report output from the official Pi camera run
- Arducam.jpg — close-up of the Arducam camera
One thing that worries me: there’s a red dot on the camera board that’s been there since I first opened the package. I read somewhere that can mean the hardware is dead. I verified the CSI-2 port itself is fine with the official camera, so it’s not the port.
Looking at your pictures, I can see you’re running this on a third-party carrier board. That’s likely the problem — compatibility between the 64MP camera and third-party carrier boards isn’t guaranteed.
Do you have a regular Raspberry Pi 4 you can test with? If so:
- Update the kernel to 6.1.19.
- Install libcamera and enable the camera in config.txt using the same guide:
Quick Start Guide - Arducam Wiki - Then try the libcamera command on the Pi 4.
That will tell us whether the camera itself is fine and the carrier board is the only issue.
Good news — I tested the Arducam on a normal Raspberry Pi 4 and it works. No issues there. So it does look like the third-party carrier board was the problem.
Great, thanks for confirming. That lines up with what we suspected: the camera works fine on a standard Pi 4, and the earlier issue was tied to the third-party carrier board. I’ll consider this one resolved. If anything else comes up, just post back here.
I’m back with a different problem. I transferred my image over to a Raspberry Pi Zero (the original Zero v1) and I’m getting error messages. The camera worked on the Pi 4 but won’t cooperate on the Zero. I’m guessing the 64MP camera may just not be compatible with the Pi Zero. I’ve attached the bug report from this setup.
The plan is to put the Pi + camera on a drone, so I really need a small board. If the Zero v1 is a no-go, would a Pi Zero 2 work?
Confirmed — the 64MP camera is currently incompatible with the Raspberry Pi Zero v1. The recommended small form-factor platform for this camera is the Pi Zero 2. If you can swap to a Zero 2, that’s the way to go.
I got a Pi Zero 2 and tried it. The camera is detected now, but capturing at full resolution fails with a buffer allocation error. Here’s the command I ran:
libcamera-still -t 1000 --autofocus-mode auto --width 9152 --height 6944 -o PiCam6.jpg
And the relevant output:
Preview window unavailable
[0:07:09.190292494] [1683] INFO Camera camera_manager.cpp:299 libcamera v0.0.0+4225-74d023d8
[0:07:09.217909007] [1685] WARN CameraSensorProperties camera_sensor_properties.cpp:243 No static properties available for ‘arducam_64mp’
[0:07:09.217998851] [1685] WARN CameraSensorProperties camera_sensor_properties.cpp:245 Please consider updating the camera sensor properties database
[0:07:09.275984796] [1685] WARN RPI raspberrypi.cpp:1357 Mismatch between Unicam and CamHelper for embedded data usage!
[0:07:09.277528962] [1685] INFO RPI raspberrypi.cpp:1476 Registered camera /base/soc/i2c0mux/i2c@1/arducam_64mp@1a to Unicam device /dev/media3 and ISP device /dev/media0
[0:07:09.278751879] [1683] INFO Camera camera.cpp:1028 configuring streams: (0) 4576x3472-YUV420
[0:07:09.279311567] [1685] INFO RPI raspberrypi.cpp:851 Sensor: /base/soc/i2c0mux/i2c@1/arducam_64mp@1a - Selected sensor format: 4624x3472-SRGGB10_1X10 - Selected unicam format: 4624x3472-pRAA
#0 (0.00 fps) exp 31727.00 ag 4.00 dg 1.00
#1 (10.00 fps) exp 31727.00 ag 4.00 dg 1.42
[0:07:10.851963551] [1683] INFO Camera camera.cpp:1028 configuring streams: (0) 9152x6944-YUV420 (1) 9152x6944-SRGGB10_CSI2P
[0:07:10.853815271] [1685] INFO RPI raspberrypi.cpp:851 Sensor: /base/soc/i2c0mux/i2c@1/arducam_64mp@1a - Selected sensor format: 9152x6944-SRGGB10_1X10 - Selected unicam format: 9152x6944-pRAA
[0:07:10.856929125] [1685] ERROR V4L2 v4l2_videodevice.cpp:1241 /dev/video14[16:cap]: Unable to request 1 buffers: Cannot allocate memory
ERROR: *** failed to allocate capture buffers ***
It gets as far as registering the camera and configuring the streams, then dies when it tries to allocate the capture buffers. Any workaround?
Saving the full 64MP resolution (9152x6944) requires a platform with enough memory/performance to allocate the capture buffers. The Pi Zero series just doesn’t have enough for full 64MP capture.
On the Pi Zero 2, the camera registers and the streams configure fine, but buffer allocation fails at full resolution — exactly what your log shows:
ERROR V4L2 v4l2_videodevice.cpp:1241 /dev/video14[16:cap]: Unable to request 1 buffers: Cannot allocate memory
ERROR: *** failed to allocate capture buffers ***
The workaround is to use 16MP resolution on the Pi Zero 2. That should work well for your drone setup. Full 64MP isn’t supported on the Zero series due to the memory/performance limits.