rpi5: linux-rpi 6.18 boots without DRM (/dev/dri missing), HDMI stays black

[axju]

Describe the bug

After upgrading to linux-rpi 6.18 on a Raspberry Pi 5 (Arch Linux ARM), HDMI output stays black while the system boots normally and is accessible via SSH.

Key points:

1. /dev/dri is missing entirely
2. DRM is not available in the running kernel
3. vc4-drm fails to initialize

Steps to reproduce the behaviour

Just upgrade to 6.18.1

Device (s)

Raspberry Pi 5

System

Kernel: linux-rpi 6.18-1 (uname -r: 6.18.0-1-rpi)

Logs

vc4-drm axi:gpu: [drm] Couldn't stop firmware display driver: -22
vc4_hvs 107c580000.hvs: Couldn't get core clock

From journalctl:
Load Kernel Module drm was skipped because of an unmet condition check
(ConditionKernelModuleLoaded=!drm)

Additional context

Downgrading to linux-rpi 6.12.61 restores /dev/dri, vc4 DRM, and HDMI output, so this appears to be a regression in linux-rpi 6.18 affecting Raspberry Pi 5.

[GazzaC]

This issue is also apparent on the 16k kernel
$ uname -r
6.18.1-1-rpi-16k
$ ls /dev/dri
ls: cannot access '/dev/dri': No such file or directory

Screen freezes during boot sequence, system boots normally however.

[6by9]

I'm suspecting this is an Arch Linux issue, or possibly you have an old firmware (vcgencmd bootloader_version).

vc4 initialises fine on Raspberry Pi OS, and graysky as one of the ArchLinuxARM devs has reported no issues in https://forums.raspberrypi.com/viewtopic.php?p=2353688#p2353688

I'm running 6.18.1 on a Pi5 now, so there's nothing fundamentally broken about rpi-6.18.y.

[graysky2]

I am not seeing this on my RPi5B running Arch ARM. Bootloader was recently updated. linux-rpi-16k 6.18.1-1

% ls /dev/dri
by-path  card0  card1  renderD128

% vcgencmd bootloader_version
2025/12/08 19:29:54
version 2226a853bb9f5fd80392e3a4a89e457aeca88008 (release)
timestamp 1765222194
update-time 1765472119
capabilities 0x0000007f

config.txt
kodi.config.txt

[GazzaC]

@6by9 was spot on with the firmware, i upgraded my firmware and the issue is gone.

[matscalia]

@GazzaC, I am facing the same issues. I upgraded the firmware through pacman but nothing changed and the drm is not initialized. Am I missing something?

[graysky2]

@matscalia - does the output of vcgencmd bootloader_version match mine above? Are your files diffed against Arch ARM defaults (/boot/config.txt and possibly /boot/kodi.config.txt)?

[matscalia]

Ok, this is the output of vcgencmd bootloader_version and it doesn't look good:

ioctl_set_msg failed:-1
bootloader_version

and this is my config.txt file:

# For more options and information see:
# http://rptl.io/configtxt

initramfs initramfs-linux.img followkernel

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Additional overlays and parameters are documented
# /boot/firmware/overlays/README

# Automatically load overlays for detected cameras
camera_auto_detect=1

# Automatically load overlays for detected DSI displays
display_auto_detect=1

# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2
gpu_mem=512
disable_overscan=1

# Uncomment if hdmi display is not detected and composite is being output
hdmi_force_hotplug=1

# Uncomment if you want to disable wifi or bluetooth respectively
#dtoverlay=disable-wifi
#dtoverlay=disable-bt

# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18

# Run as fast as firmware / board allows
arm_boost=1

[cm5]
dtoverlay=dwc2,dr_mode=host

[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

[all]

Before the update to 6.18 the setup was working perfectly fine. I can't wrap my head around what would be causing the issue

[GazzaC]

@GazzaC, I am facing the same issues. I upgraded the firmware through pacman but nothing changed and the drm is not initialized. Am I missing something?

To make it clear, what I did was grab latest raspbian on uSD. Boot from uSD and used raspi-config -> advanced -> bootloader update. Remove uSD, let system boot as normal.

[blacklight]

Same issue here, running linux-rpi-16k.

TL;DR: Downgrading to linux-rpi-16k 6.12.61-1 fixes the issue.

Configuration

❯ cat /boot/config.txt
initramfs initramfs-linux.img followkernel

dtparam=i2c_arm=on
dtparam=i2c0=on
dtparam=i2c1=on
dtparam=i2s=on
dtparam=spi=on
dtparam=i2c1_baudrate=400000

camera_auto_detect=1
display_auto_detect=1

dtoverlay=vc4-kms-v3d
max_framebuffers=2
arm_boost=1

[cm4]
otg_mode=1

[all]
❯ cat /boot/cmdline.txt
root=/dev/mmcblk0p2 rw rootwait console=serial0,115200 console=tty1 fsck.repair=yes

Info from the broken kernel (6.18.1-1-rpi-16k):

❯ uname -a
Linux myhost 6.18.1-1-rpi-16k #1 SMP PREEMPT Tue Dec 16 00:49:35 UTC 2025 aarch64 GNU/Linux
❯ pacman -Q linux-rpi-16k
linux-rpi-16k 6.18.1-1
❯ sudo journalctl -b -k
# NOTE: In the kernel logs I can see the clock starting from December 19th 5PM and suddenly jumping to
# December 20th 11PM, accompained by:
# raspberrypi-clk soc@107c000000:firmware:clocks: probe with driver raspberrypi-clk failed with error -22
# Not sure if related
https://paste.manganiello.tech/?2f54dac5065610dd#Her4CQCgQUc4cqsLu5Yf213ve5L97bgMtebcJBCcihy2
❯ dmesg -T | grep -E 'vc4|v3d|drm|bcm2712|rp1|clk|clock|firmware|mailbox'
[Sat Dec 20 23:53:50 2025] raspberrypi-firmware soc@107c000000:firmware: Request 0x00038087 returned status 0x00000000
[Sat Dec 20 23:53:50 2025] raspberrypi-firmware soc@107c000000:firmware: Request 0x00030087 returned status 0x00000000
[Sat Dec 20 23:53:50 2025] raspberrypi-firmware soc@107c000000:firmware: Request 0x00038087 returned status 0x00000000
[Sat Dec 20 23:53:50 2025] raspberrypi-firmware soc@107c000000:firmware: Request 0x00030087 returned status 0x00000000
[Sat Dec 20 23:53:50 2025] raspberrypi-firmware soc@107c000000:firmware: Request 0x00038087 returned status 0x00000000
...
❯ ls -l /dev/dri
ls: cannot access '/dev/dri': No such file or directory

Info from the working kernel (6.12.61-1-rpi-16k):

❯ uname -a
Linux myhost 6.12.61-1-rpi-16k #1 SMP PREEMPT Mon Dec  8 20:19:29 UTC 2025 aarch64 GNU/Linux
❯ pacman -Q linux-rpi-16k
linux-rpi-16k 6.12.61-1
❯ sudo journalctl -b -k
# NOTE: No issues with "timestamp jumps", no mailbox flooding and no clock firmware errors
https://paste.manganiello.tech/?0d66c481cfb34db0#qZebYjRbj8XPg7vYDsr43fSNwpYXyVbfvbjAFmReCcz
❯ dmesg -T | grep -E 'vc4|v3d|drm|bcm2712|rp1|clk|clock|firmware|mailbox'
# NOTE: All expected messages are present, unlike in the broken kernel
https://paste.manganiello.tech/?06e3763a5c80de76#9w8gAgNK9FpkkUTLVLKzyLdskTX8XL4zeRBgw4rusebZ
❯ ls -l /dev/dri
total 0
drwxr-xr-x  2 root root        100 Dec 20 23:59 by-path
crw-rw----+ 1 root video  226,   0 Dec 20 23:59 card0
crw-rw----+ 1 root video  226,   1 Dec 20 23:59 card1
crw-rw-rw-  1 root render 226, 128 Dec 20 23:59 renderD128

[GazzaC]

Yep, that's the same thing. Upgrade your bootloader.

Here is my Pi5 now

$ vcgencmd bootloader_version
2025/12/08 19:29:54
version 2226a853bb9f5fd80392e3a4a89e457aeca88008 (release)
timestamp 1765222194
update-time 1765889322
capabilities 0x0000007f

$ uname -r
6.18.1-1-rpi-16k

$ ls -la /dev/dri
total 0
drwxr-xr-x 3 root root 120 Dec 18 20:49 .
drwxr-xr-x 16 root root 4340 Dec 18 20:49 ..
drwxr-xr-x 2 root root 100 Dec 18 20:49 by-path
crw-rw----+ 1 root video 226, 0 Dec 18 20:49 card0
crw-rw----+ 1 root video 226, 1 Dec 18 20:49 card1
crw-rw-rw- 1 root render 226, 128 Dec 18 20:49 renderD128

In summary, the 6.18.1-1-rpi-16k kernel is not broken. Your raspberry pi bootloader is out of date.

Here is some TL;DR

The technical term for the bootloader stored in the Raspberry Pi's EEPROM is the "bootloader" or "eeprom". This firmware is responsible for initializing the system during power-on and is located on an on-board EEPROM chip starting with the Raspberry Pi 4. It is also referred to as the "bootcode.bin" in older models, but since the Raspberry Pi 4, this has been moved to the EEPROM. The bootloader is managed through tools like rpi-eeprom-update and is critical for the boot process.

The bootloader is not directly responsible for video output via VC4, but it plays an indirectly critical role.

Here’s how:

The bootloader (in the EEPROM) initializes the SoC and loads the VideoCore firmware, which is essential for GPU operation, including VC4 (VideoCore IV) graphics and video processing.
Without a proper bootloader, the VideoCore GPU won't start, and thus VC4-based graphics, HDMI output, and GPU acceleration will not function.
The actual VC4 driver (vc4-kms-v3d) is loaded later by the operating system, but it depends on the GPU being initialized by the firmware loaded after the bootloader stage.
So, while the bootloader itself doesn't handle VC4 video, it is critical for starting the chain that enables it.