Arducam IMX519 autofocus lens fails to initialize on Raspberry Pi – ak7375 driver error

Raspberry Pi Cameras
1

Having a really frustrating time with an Arducam IMX519 autofocus camera (model B0371). The autofocus lens motor never moves at all. The camera streams images just fine — picture quality is good — but focus is completely static. None of the autofocus options do anything.

Environment: Raspberry Pi (tried two different ones), using the ribbon cable connection. Running latest Pi OS.

Here’s what I’m seeing in dmesg:

ak7375 10-000c: Failed to open V4L2 device '/dev/v4l-subdev1'
Lens initialization failed, lens disabled

And when I try to set controls:

Unable to set controls: Device or resource busy

/dev/v4l-subdev1 does show up, but nothing can actually use it.

What I’ve already tried:

  • Verified dtoverlay=imx519 is set in config.txt
  • Confirmed I²C is enabled and working — both imx519@1a and ak7375@0c show up when I scan the bus
  • Tested with libcamera-hello, libcamera-still, rpicam-still
  • Tried --autofocus-mode auto, --autofocus-mode continuous, and normal range — all ignored, no lens movement
  • Reflashed the SD card from scratch, reinstalled all packages
  • Tried multiple ribbon cables
  • Tried on two different Raspberry Pis

Here’s the kicker — this is actually a replacement unit. The first one had the exact same problem. I’m starting to wonder if this is a broader compatibility issue or a bad batch. Anyone else seen this? The ribbon cable I’m using now works perfectly with an Arducam Hawkeye 64MP camera, so I’m pretty confident it’s not a cabling problem.

2

Thanks for the detailed report — that’s really helpful. Let me go through what we know so far.

Based on everything you’ve described, you’ve done a thorough job isolating the problem:

  • Multiple ribbon cables ruled out (plus the same cable works with a Hawkeye 64MP)
  • Multiple Raspberry Pi units ruled out
  • Software and config all look correct (overlay, I²C addresses visible)
  • Imaging works fine — the sensor itself is functional
  • The issue is specifically the ak7375 VCM driver / lens initialization, which fails every time

Given that two separate units exhibit identical behavior, I understand the concern about a batch issue. Before we jump to conclusions though, let’s gather a bit more data.

Could you do two things for me:

1. Connection photos — Can you post photos of:

  • The ribbon cable connection at the camera board
  • The ribbon cable connection at the Raspberry Pi

2. Diagnostic log — I’d like you to run a diagnostic script that collects all the relevant system info in one go. Run these commands in order:

sudo reboot
wget -O arducam-camera-bug-report https://github.com/Dion4cen/arducam-camera-bug-report/releases/download/Tool/arducam-camera-bug-report
chmod +x ./arducam-camera-bug-report
./arducam-camera-bug-report

That’ll generate arducam-bug-report.txt in your current directory. Please attach that along with the photos and we’ll dig in from there.

3

Alright, here are the photos and the bug report as requested.

Photos of the connections:

Bug report: arducam-bug-report.txt

Just to reiterate — same errors, same behavior, nothing changed. The ak7375 still fails to open the v4l-subdev1 device, lens initialization fails, and autofocus is completely non-functional. I’ve now confirmed across two separate Pis and multiple ribbon cables, including the one that runs my Hawkeye 64MP without any issues.

At this point I’ve exhausted everything I can think of on my end.

6

Apologies for the delay — I’ve reviewed the photos and the diagnostic log you provided. The connections look correct, and the log confirms the same ak7375 initialization failure pattern without pointing to an obvious software or configuration issue.

At this stage, since we’ve ruled out cabling, the Pi itself, OS configuration, and the software stack, I’d like to move to a live remote session so I can inspect what’s happening on your device in real time. This would let me check a few low-level things that are hard to capture in a static log.

I’ve sent you the remote access details and scheduling information through private message. Please check your messages — it covers how to set things up and how to book a time slot. The important thing to note is that my timezone is UTC+8, and the 10:00 PM slot on the booking page isn’t available for support sessions (that’s reserved for something else).

Just let me know once you’ve got that set up and we’ll get to the bottom of this.

7

I appreciate the follow-up, but I’m not comfortable installing third-party remote access software on my systems. I’ve spent a lot of time on this already across two different units showing the exact same failure, and I’ve tested across multiple Pis and cables to rule out my own hardware.

I’m going to reach out to the vendor I purchased from and pursue a refund at this point. Thanks for the help you were able to provide.