Cannot capture full-resolution PNG/Bayer on Raspberry Pi CM4 with Arducam 64MP, CMA allocation errors

nktu101 · August 14, 2022, 6:36am

Hi, I have a problem with my Arducam 64MP camera on a Raspberry Pi CM4. I can’t capture a picture in full resolution and store it as png or bayer frame. It fails with an error about allocating cma buffers. I’ve never gotten this to work, not even once.

Also, slightly off topic but I’m not getting the confirmation email for my forum.arducam.com account. I’ve been trying for 3 days in a row and no email hits my inbox (not even in spam).

Setup:

Raspberry Pi CM4 4GB
Arducam 64MP Ultra High Res Camera (the 64mp-ultra-high-res-camera-raspberry-pi one)
OS: Raspbian GNU/Linux 11 (bullseye)
CPU: armv7l, Cortex-A72

Happy to run whatever diagnostics you need.

Dion · August 14, 2022, 7:39am

Hi, thanks for the detailed report. Let’s start with the capture failure.

Can you run the capture with verbose output and paste the full result? Specifically:

libcamera-still -o test.png -v -n -e png --width 9152 --height 6944 -t 1000

Also, right after that command fails, please run dmesg | tail -50 and paste what you get. That will tell us whether it’s a CMA size issue or something in the driver itself.

nktu101 · August 14, 2022, 9:03am

Ok, here’s the capture output:

libcamera-still -o test.png -v -n -e png --width 9152 --height 6944 -t 1000

[18:30:00.796354520] [6864] ERROR V4L2 v4l2_videodevice.cpp:1211 /dev/video0[14:cap]: Unable to request 1 buffers: Cannot allocate memory
[18:30:00.796513703] [6864] ERROR RPI raspberrypi.cpp:1023 Failed to allocate buffers

And the dmesg right after:

[66601.553170] cma: cma_alloc: linux,cma: alloc failed, req-size: 19422 pages, ret: -12
[66601.553195] unicam fe801000.csi: dma_alloc_coherent of size 79552512 failed

So it looks like it wants a ~79MB contiguous buffer and fails with -12 (ENOMEM).

Dion · August 14, 2022, 9:16am

That confirms the CMA allocation is the failure point. The unicam driver needs a single contiguous DMA buffer of 79552512 bytes and it can’t get it.

Let’s check how much CMA you actually have available. Run:

cat /proc/meminfo | grep Cma

And also show us your boot config:

cat /boot/config.txt

That’ll show whether the cma-512 overlay applied correctly and whether anything else is eating the CMA region.

nktu101 · August 14, 2022, 10:49am

Here you go:

cat /proc/meminfo | grep Cma
CmaTotal:         524288 kB
CmaFree:          498948 kB

cat /boot/config.txt

[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1
dtoverlay=vc4-kms-v3d,cma-512
dtoverlay=arducam_64mp
dtoverlay=arducam_64mp, cam0
gpu_mem=64
arm_boost=1

So CmaTotal is 524288 kB and CmaFree is 498948 kB, which seems like plenty. That’s what’s confusing me.

Dion · August 14, 2022, 1:49pm

Right, this is the confusing part. CmaFree looking large doesn’t mean the contiguous allocation can succeed — the allocator has to find a single free chunk big enough, and fragmentation or the placement/size classes can make a request fail even when the total free count is high.

Let’s test the V4L2 device directly to see how the buffer requests behave:

v4l2-compliance -s -d /dev/video0

Paste the streaming section and the final summary.

nktu101 · August 15, 2022, 12:00am

Ran it. Streaming ioctls section is messy, lots of FAILs:

		fail: v4l2-test-buffers.cpp(793): (ret < 0 && err != EAGAIN && err != EBUSY && err != EINVAL) || ret > 1
	test read/write: FAIL
		fail: v4l2-test-buffers.cpp(2238): q.reqbufs(node, 2)
		fail: v4l2-test-buffers.cpp(2318): testBlockingDQBuf(node, q)
	test blocking wait: FAIL
		fail: v4l2-test-buffers.cpp(1269): q.reqbufs(node, 2)
	test MMAP (no poll): FAIL
		fail: v4l2-test-buffers.cpp(1269): q.reqbufs(node, 2)
	test MMAP (select): FAIL
		fail: v4l2-test-buffers.cpp(1269): q.reqbufs(node, 2)
	test MMAP (epoll): FAIL
	test USERPTR (no poll): OK (Not Supported)
	test USERPTR (select): OK (Not Supported)
		fail: v4l2-test-buffers.cpp(1709): exp_q.reqbufs(expbuf_node, q.g_buffers())
		fail: v4l2-test-buffers.cpp(1821): setupDmaBuf(expbuf_node, node, q, exp_q)
	test DMABUF (no poll): FAIL
		fail: v4l2-test-buffers.cpp(1709): exp_q.reqbufs(expbuf_node, q.g_buffers())
		fail: v4l2-test-buffers.cpp(1821): setupDmaBuf(expbuf_node, node, q, exp_q)
	test DMABUF (select): FAIL

Summary: Total for unicam device /dev/video0: 55, Succeeded: 47, Failed: 8, Warnings: 0

All the failures are around reqbufs, which lines up with the capture error.

Dion · August 15, 2022, 6:00am

Yes, that’s all the same buffer allocation failing. Can you grab dmesg once more right after that compliance run? The error code may be different this time, which is useful info.

nktu101 · August 15, 2022, 7:55am

Sure:

[65068.153537] cma: cma_alloc: linux,cma: alloc failed, req-size: 46547 pages, ret: -16
[65068.153556] unicam fe801000.csi: dma_alloc_coherent of size 190656512 failed

This time it wants 190656512 bytes and fails with -16 instead of -12. -12 would be ENOMEM and -16 is EBUSY, is that right?

Dion · August 15, 2022, 8:47am

Correct. -12 is ENOMEM and -16 is EBUSY. So depending on the scenario the driver asks for anywhere between ~79MB and ~190MB of contiguous DMA memory and can’t get it. The 190MB one is especially problematic.

Just to fully document your environment, can you also paste:

cat /etc/os-release
lscpu

Even though you already told us the basics, I want the exact output on record.

nktu101 · August 15, 2022, 11:17am

No problem.

cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

lscpu
Architecture:                    armv7l
Byte Order:                      Little Endian
CPU(s):                          4
On-line CPU(s) list:             0-3
Thread(s) per core:              1
Core(s) per socket:              4
Socket(s):                       1
Vendor ID:                       ARM
Model:                           3
Model name:                      Cortex-A72
Stepping:                        r0p3
CPU max MHz:                     1500.0000
CPU min MHz:                     600.0000
BogoMIPS:                        108.00
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Not affected
Vulnerability Spectre v1:        Mitigation; __user pointer sanitization
Vulnerability Spectre v2:        Vulnerable
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           half thumb fastmult vfp edsp neon vfpv3 tls vfpv3 idiva idivt vfpd32 lpae evtstrm crc32

One thing I already tried: bumping the CMA memory with dtoverlay=vc4-kms-v3d,cma-512. That’s what gave me the 512MB CmaTotal you saw, but it didn’t fix the capture. That’s partly why I’m stuck — the numbers look fine but it still fails.

nktu101 · August 16, 2022, 12:00am

So where do I go from here? Could you provide a patch for the arducam_64mp overlay/driver with the correct buffer allocation, or the source code of the driver so I can look at it myself? Changing the CMA size clearly isn’t enough.

Dion · August 16, 2022, 6:00am

Thanks — that’s all really useful and matches what we’re seeing. To summarize where we are:

Full-resolution capture (9152x6944) fails because unicam/arducam_64mp requests large single contiguous DMA buffers (~79MB and ~190MB).
The allocations fail even though CmaTotal is 524288 kB and CmaFree is 498948 kB, because a single contiguous block of that size can’t be satisfied (cma_alloc ret -12 ENOMEM and ret -16 EBUSY).
v4l2-compliance shows all the failures landing on reqbufs, consistent with the same allocation problem.
We’ve confirmed the platform: CM4 4GB, Raspbian 11 bullseye, armv7l, Cortex-A72, and cma-512 already applied via the vc4-kms-v3d overlay.

We’ve seen this behave inconsistently on 4GB boards — some will do it, some won’t — so we want to confirm with the Raspberry Pi folks and check our buffer allocation logic here. I don’t have a working patch for this yet, so I don’t want to hand you a fix that isn’t real. I’ll follow up once I have something concrete on the buffer allocation side.

Separately, for the missing forum confirmation email: can you tell me the email address you registered the account with? We’ll look into why the confirmation isn’t arriving.