vc3 / v3d kernel driver status and ACPI bindings

[baryluk]

So, I just got my first RPi4 few days ago, and went straight to update the pieeprom to version from 2021-01-16, then run RPi4 1.22 from microSD, and use Debian bullseye alpha3 arm64 (a DVD one, because my router is dead, so can't do online install) on USB pendrive, to install Debian into another USB drive (actually UAS drive). Everything was surprisingly smooth and fast, and refreshing to FINALLY be able to use vanilla Debian with REAL installer on ARM, and be in control of partitioning, user and package setup, passwords, hostnames, etc.

The only minor issue was that at the end of the install, the UEFI boot entries were somehow disordered / missing, so it didn't boot into grub by default, but the ability to do "Boot from file" in Boot Manager Maintenance, was kind of easy, and later I managed to add the entry so grub now boots. I think the issue might be with efivars, storing the boot entries somewhere else than UEFI is supposed to read them back from. Anyhow. That is offtopic.

I used mostly default settings in the UEFI, but it did use ACPI only. (I think it is a default actually). Ah, and I did enable full 8GB of memory in UEFI.

I noticed that the framebuffer does work, and uses efifb by default. Which is ok, and even X11 uses it and works, but then I would expect vc4 kms driver to kick in, which is faster, and is required for compositing and 3d/video acceleration, and to use more than fixed amount of memory for stuff, use two HDMI outputs, use hardware cursor, window blitting, moving, scrolling, change resolutions using xrandr, read EDID data from the monitor, use HDMI CEC, etc.

It didn't.

The Debian kernel from DI alpha3, was 5.9.11. But I also later upgraded to 5.10.9/5.10.12, again from Debian testing/unstable. No changes. The Debian kernel right now doesn't have CONFIG_DRM_V3D enabled ( https://bugs.debian.org/977441 ), but I cross-compiled my own kernel 5.11-rc6 with a minor patch from raspberrypi kernel (https://github.com/raspberrypi/linux/commit/24662c14b45852c2d5fc4721b1494bce8345319d - for some reasons it is not in upstream kernel yet), enabled it, enabled other things (mostly based on bcm2711_defconfig from raspberrypi repo), built deb packages, installed, and it boots (sometimes hangs, if I use ACPI + DT in UEFI, but works with ACPI), but still doesn't automatically load vc4 or v3d.

In fact, even if I then load the vc4 and/or v3d manually with modprobe, nothing happens. No messages in dmesg either.

I guess some bindings are missing to make that happen?

(The hangs with ACPI + DT, I think might be due to SD/MMC card issues, I don't have serial console to investigate it).

[TheMindVirus]

This is what I could see while trying to look for the V3D in Windows and BareMetal (only Linux disagreed): https://github.com/TheMindVirus/KMDF-X/blob/main/logs/KMDFDriver_V3D.log

I too have found that the framebuffer is working. However V3D/QPU is a bit of a weird one as it's lacking in Pi4 documentation from several perspectives (inc. mailbox). There is plenty of BareMetal code for it but a lot of it is broken due to reasons possibly viewable in my log file.

My guess is that Raspberry Pi OS is doing something a little differently to load in V3D compared to Debian, other distros, Windows etc...It's by no means automatic though, config.txt still has to be edited to add and configure the correct overlay. However, having had a look at the addresses it points to, I can't seem to find one that says Version 0.2 "V3D" anywhere.

Usually I would want to refer to the IP Block Diagram to see if it was connected, but official documents concerning VC6 have been a little scarce to say the least. There are some python libraries that look promising.

[baryluk]

I just done some extra googling, and on fedora-arm - https://www.spinics.net/linux/fedora/fedora-arm/msg13686.html - one user has same issue with Fedora kernel 5.10.7. He says that booting without UEFI with pi-specific dt stuff, makes vc4 / v3d just load automatically and work. So it doesn't need to be Raspberry Pi kernel specific stuff. It is just UEFI ACPI specific issue I think.

[TheMindVirus]

Found the V3D in Linux. I wouldn't be surprised if a small version change is to blame for the bindings not working etc. https://github.com/TheMindVirus/rpi-kmod/blob/70d14c9da58dad0faabbdd72c007b5f24d83e83d/v3dlog.txt#L3 That and I still need to see if I'm getting 0xDEADBEEF in Windows / Other OS.

UPDATE: I just switched on the V3D in Windows. Not sure if that's what's missing from UEFI+ACPI for Debian? https://github.com/TheMindVirus/KMDF-X/blob/main/logs/KMDFDriver_V3D_PWR.log

[Barborica-Alexandru]

Hi. This probably won't help that much, but I am running Fedora 33 with kernel 5.10.14-v8+ on DeviceTree no ACPI and the v3d driver loads fine. This is the raspberry pi kernel not the upstream.

[root@transdaemon mesh]# lsmod
Module                  Size  Used by
md4                    16384  0
aes_neon_blk           36864  5
crypto_simd            24576  1 aes_neon_blk
cryptd                 28672  1 crypto_simd
sha256_generic         16384  5
nls_utf8               16384  11
cifs                  806912  10
libarc4                16384  1 cifs
rfkill                 36864  1
vc4                   270336  0
cec                    57344  1 vc4
bcm2835_codec          49152  0
drm_kms_helper        245760  2 vc4
bcm2835_v4l2           45056  0
bcm2835_isp            32768  0
snd_soc_core          237568  1 vc4
snd_compress           20480  1 snd_soc_core
videobuf2_vmalloc      20480  1 bcm2835_v4l2
bcm2835_mmal_vchiq     32768  3 bcm2835_codec,bcm2835_v4l2,bcm2835_isp
snd_pcm_dmaengine      20480  1 snd_soc_core
v4l2_mem2mem           40960  1 bcm2835_codec
videobuf2_dma_contig    24576  2 bcm2835_codec,bcm2835_isp
videobuf2_memops       20480  2 videobuf2_vmalloc,videobuf2_dma_contig
videobuf2_v4l2         32768  4 bcm2835_codec,bcm2835_v4l2,v4l2_mem2mem,bcm2835_isp
videobuf2_common       61440  5 bcm2835_codec,videobuf2_v4l2,bcm2835_v4l2,v4l2_mem2mem,bcm2835_isp
snd_pcm               131072  4 vc4,snd_compress,snd_soc_core,snd_pcm_dmaengine
snd_timer              36864  1 snd_pcm
snd                   102400  4 snd_timer,snd_compress,snd_soc_core,snd_pcm
syscopyarea            16384  1 drm_kms_helper
sysfillrect            16384  1 drm_kms_helper
v3d                    81920  0
videodev              311296  6 bcm2835_codec,videobuf2_v4l2,bcm2835_v4l2,videobuf2_common,v4l2_mem2mem,bcm2835_isp
sysimgblt              16384  1 drm_kms_helper
gpu_sched              45056  1 v3d
raspberrypi_hwmon      16384  0
vc_sm_cma              36864  2 bcm2835_mmal_vchiq,bcm2835_isp
mc                     57344  6 videodev,bcm2835_codec,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem,bcm2835_isp
fb_sys_fops            16384  1 drm_kms_helper
rpivid_mem             16384  0
uio_pdrv_genirq        16384  0
uio                    24576  1 uio_pdrv_genirq
sch_fq_codel           20480  6
drm                   552960  5 gpu_sched,drm_kms_helper,v3d,vc4
fuse                  131072  1
drm_panel_orientation_quirks    20480  1 drm
backlight              20480  1 drm
zram                   28672  1
zsmalloc               32768  1 zram
ip_tables              32768  0
x_tables               40960  1 ip_tables
efivarfs               16384  1
ipv6                  532480  32

This is my config.txt:

arm_64bit=1
enable_uart=1
uart_2ndstage=1
enable_gic=1
armstub=RPI_EFI.fd
disable_commandline_tags=1
disable_overscan=1
device_tree_address=0x1f0000
device_tree_end=0x200000
dtoverlay=miniuart-bt

# Custom Led Blink modes
dtparam=pwr_led_trigger=none
dtparam=pwr_led_activelow=off
dtparam=act_led_trigger=cpu

# Load v3d Driver
dtoverlay=vc4-fkms-v3d
max_framebuffers=2

[baryluk]

Hi. This probably won't help that much, but I am running Fedora 33 with kernel 5.10.14-v8+ on DeviceTree no ACPI and the v3d driver loads fine. This is the raspberry pi kernel not the upstream.

Yes, that is expected to work fine. It also works with the Debian and non-UEFI non-ACPI rpi-specific kernel. The issue here is about ACPI and mainline kernel really.

I looked at the upstream kernel 5.11 and doesn't really see anything new in vc4 or v3d related to ACPI.

[TheMindVirus]

I have tried asking the mailbox for the framebuffer from bare-metal Raspberry Pi 4 code with two subsequent requests and it gives me the same framebuffer address and pitch space even though 2 monitors are connected. The Mailbox Property Interface and Mailbox Framebuffer Interface are unhelpful at the moment as far as second monitor is concerned. The HDMI controller and FIFO is not HDMI 1.3a standard as it tries to claim in the documentation and there is not a mention of TMDS in the source tree. If there is a second framebuffer address then it's probably locked away behind the closed-source VC4 source at Broadcom. I'll let you know if I manage to find it out after that (if there is still a Broadcom left to find it out from given their stance on this).

[EDIT]: At this stage the only hope looks like porting directly from Raspberry Pi OS seeing as it has a driver for this, its location in the source tree is as yet unclear.

[TheMindVirus]

Further to my investigation into the Linux source tree, it seems they have a more complete documentation of the Mailbox Property Interface than what is advertised to be the official documentation of said interface.

Could someone please confirm to me that this: https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface

...is an incomplete version of what is listed here: https://github.com/raspberrypi/linux/blob/rpi-5.10.y/include/soc/bcm2835/raspberrypi-firmware.h

[EDIT]: I have finally addressed the second framebuffer and second monitor from bare-metal Raspberry Pi 4 using the hidden interface from the Linux source tree. This has caused too much frustration for too long, I would very much like it seen to. PiX-iES gets a second monitor: https://github.com/TheMindVirus/PiX-iES/tree/second-monitor

[Zugschlus]

Stupid question and possible off-topic here, how would I make the Raspberry Pi 4 boot with ACPI AND Device Tree?

[jafd]

Stupid question and possible off-topic here, how would I make the Raspberry Pi 4 boot with ACPI AND Device Tree?

This is selectable right in the settings when you press Esc on boot. The same section where you unlock 8 GB. Doesn't help with this particular issue, though: for me, any boot where device tree is involved completely hoses USB like in this issue (although the boot screen looks gorgeous, I'll give it that).

[jlinton]

I modified/created a pile of ACPI/VC bindings for the HDMI/PVA/TXP/HVS devices nesting them under a parent GPU device a week or two back and hacked up the Linux driver enough to get it "starting" against the HW. It gets far enough along to discover that it can't change the CRTC clocks and appears to work, but of course, ends up eventually turning off the HDMI output. So there is hope & movement. I wanted to see if I could use some _DSM() to set the clock rates but have been wasting all my pi cycles trying to figure out how to get the PCIe/XHCI mailbox to reprogram the firmware when booted with a recent kernel+DT. If someone is interested it poking at it a bit I will push the DSDT+kernel patches somewhere, but otherwise will wait until it actually starts to work.

[0n0w1c]

Any movement here? v3d in the upstream kernel is desired.

[baryluk]

@anholt @nullr0ute Hi, sorry for pinging directly, but maybe you know better what are the plans, and who would be the best to discuss ACPI support for vc3 - vc5, v3d?

[nullr0ute]

I don't believe there are specific plans, I think it's basically a "patches welcome" level. Personally I don't actually particularly care.

[jlinton]

I've not spent a lot of cycles on the PI. Lately, There is a fairly large backlog of changes that need to be upstreamed for it, which have been getting stale for the past 6+ months. The ACPI bindings for the graphics were stalled when the DT driver wasn't working, and i've not revisited it. It looks like this was largely where I left the firmware https://github.com/jlinton/edk2-platforms/commit/8640cc7add6905ef0d85d8065067030d57fcce0d

But the kernel patches were never pushed anywhere.