vcdbg: unable to open /dev/fb0 (unbound framebuffer)

[blackshard83]

Hello,

I detatched the framebuffer using this command:

Code: Select all

echo "soc:fb" > /sys/bus/platform/drivers/bcm2708_fb/unbind

this detatches the framebuffer completely, so /dev/fb0 disappears.

In this state launching:

Code: Select all

vcdbg reloc

causes a lot of error rows like this:

Code: Select all

debug_sym: vc_mem_copy: Unable to open '/dev/fb0': No such file or directory(2)

but the tool still works fine. Redirecting stderr to /dev/null removes the messages and the tool is apparently working fine.

Why vcdbg is trying to access the framebuffer, and is it possible to avoid vcdbg access it?

kernel: 4.9.59-v7+
rasbpian: 2017-11-29
firmware: a3d7660e6749e75e2c4ce4d377846abd3b3be283 (clean) (release)

[6by9]

There is the 16MB section of the memory map that is unavailable to the ARM due to the peripherals all being mapped into that area. On a Pi0/1 that isn't an issue, but on a 2 or 3 that equates to 16MB of unaccesible RAM.
That block is accessible to the VPU, and is therefore used for various structures only relevant to the VPU. vcdbg wants to be able to view some of those so needs a mechanism to use dma to copy into an accessible buffer.

The frame buffer driver already had the FBIODMACOPY ioctl to do random dma copies, so it was quicker and easier to use that then invent a new kernel driver just to do it.

If that fails then it appears to fall back to using part of vc-mem and mmap'ing it. The associated comment is:

Code: Select all

// DMA allows memory to be accessed above 1008M and is more coherent so try this first

Yes it would be sensible to shut up the /dev/fb0 error as it isn't critical.

[blackshard83]

Got it, thanks for the detailed and interesting explanation!