vclog not working on all models of Raspberry Pi

[lurch]

I was told that vclog is the "replacement" for the old vcdbg - see raspberrypi/documentation@bf82ac6

However it seems that vclog isn't yet working on all models of Pi. I booted the same microSD card (with a fully up-to-date 32-bit Bookworm image) on a Pi Zero, a Pi 2B, a Pi 3B+, a Pi 4B and a Pi5; and ran sudo vclog -m on each of them.

• Pi Zero, Pi 4B and Pi 5 all worked fine
• Pi 2B and Pi 3B+ say:

Could not map VC memory: Device or resource busy
Fatal error: Cannot access logs

[popcornmix]

Yeah - that was on my list to investigate. I'll have a look.

[popcornmix]

Okay, the dma mechanism to read is failing (possible kernel config issue).
And the mmap mechanism doesn't work with 1GB parts (the log is in the top 16M, which is inaccessible to arm due to peripheral mapping).

total_mem=1008 in config.txt is a current workaround for this second route.

@pelwell looks like you added the dma copy path here for pi2/3.
The dma copy uses the bcm2708_fb driver, I believe. Is that actually used with kms on bookworm?
dmesg | grep fb shows:

[    1.960642] simple-framebuffer 3d402000.framebuffer: fb0: simplefb registered!
[   22.006849] vc4-drm soc:gpu: [drm] fb0: vc4drmfb frame buffer device

There's no better way of getting at the dma hardware from userspace?
It feels like an ioctl interface to a dma driver, rather than through the fb driver would be a better scheme, but I accept that may not actually exist.

[popcornmix]

Ah - this commit won't help: raspberrypi/linux@8150f78

(although possible this isn't the only issue).

[pelwell]

I think that probably is the only issue. I don't remember seeing that go past.

[popcornmix]

Reverting the kernel commit alone doesn't fix it. (I'll fix that up - it shouldn't really have been merged like that).
I also need to remove dtoverlay=vc4-kms-v3d to make vclog work (so the bcm2708_fb driver is actually used).

[pelwell]

There's no better way of getting at the dma hardware from userspace?
It feels like an ioctl interface to a dma driver, rather than through the fb driver would be a better scheme, but I accept that may not actually exist.

There is no other existing mechanism that could be used. Perhaps we could hang it off the vc_mem driver instead?

[pelwell]

@lurch note that vcdbg would fail in exactly the same way.

[lurch]

I've never actually run vcdbg on Bullseye; I've only run vclog on Bookworm in the process of updating the documentation. raspberrypi/documentation#3053
So I've got no opinion on how important this is to get working properly. (of course it's even less important if vcdbg didn't work either)

[popcornmix]

I've just tested vcdbg on bullseye. Out of the box vclog and vcdbg both fail on pi3:

pi@pi3:~ $ sudo vclog -m
pi@pi3:~ $
pi@pi3:~ $ sudo vcdbg log msg
Failed to allocate -1716518942 bytes for message buffer

Removing the kms driver, or setting total_mem=1008 allows them to work.

So I think the only regression on bookworm is the kernel hack breaks vclog when kms is disabled (which should be fixed, but running without kms isn't recommended).

Moving the dma ioctl away from bcm2708_fb (which is not typically available), perhaps to vc_mem is probably worthwhile.
But, as on bullseye, setting total_mem=1008 is currently the best workaround for capturing a VC log on Pi2/3.

[pelwell]

I'll take a look at the possibility of the vc_mem change.

[lurch]

But, as on bullseye, setting total_mem=1008 is currently the best workaround for capturing a VC log on Pi2/3.

Is that something that we ought to add to the documentation, or is the "problem" likely to get fixed in future?

[popcornmix]

Unless @pelwell reports some issue with the "vc_mem change", I'd expect this to be working again soon.

[pelwell]

The vc_mem change has been in the last few rpi-update releases, but hasn't made it to stable yet.

[lurch]

sudo vclog -m now works successfully on a Pi2 updated from our internal APT repo; so closing this issue on the assumption that the fixes in the internal repo will be making their way to the public APT repo in due course.