Pi 5 Trixie: firmware mailbox property requests all return status 0x00000000 (vcgencmd broken, no cpufreq)

[dankorotin]

Description

On Raspberry Pi 5 running Pi OS Trixie (Debian 13), the firmware mailbox property interface does not process any requests. All requests return status 0x00000000 ("request not processed") instead of 0x80000000 ("success"). This breaks:

• vcgencmd — all commands fail with ioctl_set_msg failed:-1
• raspberrypi-clk — probe fails with error -22 at boot, disabling CPU frequency scaling
• vc4-drm — "Couldn't stop firmware display driver: -22"

System Info

Pi: Raspberry Pi 5 Model B Rev 1.1 (16GB)
OS: Debian GNU/Linux 13 (trixie)
Kernel: 6.12.62+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.62-1+rpt1
EEPROM: Wed  5 Nov 17:37:18 UTC 2025 (1762364238) — up to date
raspi-firmware: 1:1.20250915-1
raspi-utils-core: 20251120-1

Boot log evidence

All firmware property requests return status 0x00000000:

raspberrypi-firmware soc@107c000000:firmware: Request 0x00000001 returned status 0x00000000
raspberrypi-firmware soc@107c000000:firmware: Request 0x00000003 returned status 0x00000000
raspberrypi-firmware soc@107c000000:firmware: Request 0x00030046 returned status 0x00000000
raspberrypi-firmware soc@107c000000:firmware: Request 0x00010007 returned status 0x00000000

This causes the clock driver probe failure:

raspberrypi-clk soc@107c000000:firmware:clocks: probe with driver raspberrypi-clk failed with error -22
vc4-drm axi:gpu: [drm] Couldn't stop firmware display driver: -22

strace of vcgencmd

openat(AT_FDCWD, "/dev/vcio", O_RDONLY) = 3
ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x64, 0, 0x8), 0x7fffe7ae1770) = -1 EINVAL (Invalid argument)

Even sudo vcgencmd measure_temp and a custom C program opening /dev/vcio with O_RDWR produce the same EINVAL — the error comes from rpi_firmware_property_list() in the kernel because buf[1] != RPI_FIRMWARE_STATUS_SUCCESS.

What was ruled out

• Permissions: /dev/vcio is crw-rw---- root:video, user is in video group, sudo also fails
• EEPROM: Updated to latest (Nov 2025)
• Kernel: Upgraded from 6.12.47 to 6.12.62, no change
• Package conflict: raspi-utils-core 20251120-1 only, no libraspberrypi-bin
• ioctl encoding: Confirmed 0xC0086400 matches _IOWR(100, 0, char*) on aarch64

config.txt

Default config with one addition — Hailo AI HAT+ overlay:

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

[all]
dtoverlay=hailo-ai,cma_size=256

Symptoms

• No /sys/devices/system/cpu/cpufreq/ directory (cpufreq governor not loaded)
• No get_throttled in sysfs
• Continuous firmware request spam in dmesg: Request 0x00030087 returned status 0x00000000 and Request 0x00038087 returned status 0x00000000 (~2 per ms)
• Temperature reporting works via sysfs (/sys/class/thermal/thermal_zone0/temp), hwmon, and Hailo Python API — only the firmware mailbox path is broken

Expected behavior

vcgencmd measure_temp should return the SoC temperature. raspberrypi-clk should probe successfully, enabling CPU frequency scaling.

[pelwell]

This is not a common problem - I've not heard of it before - so there must be something different about your setup. What is in your config.txt?

[dankorotin]

Here's my /boot/firmware/config.txt:

# For more options and information see
# http://rptl.io/configtxt
# Some settings may impact device functionality. See link above for details

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

# Enable audio (loads snd_bcm2835)
dtparam=audio=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

# Automatically load initramfs files, if found
auto_initramfs=1

# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2

# Don't have the firmware create an initial video= setting in cmdline.txt.
# Use the kernel's default instead.
disable_fw_kms_setup=1

# Run in 64-bit mode
arm_64bit=1

# Disable compensation for displays with overscan
disable_overscan=1

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

[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

[cm5]
dtoverlay=dwc2,dr_mode=host

[all]
dtoverlay=hailo-ai,cma_size=256

This is the stock Trixie config.txt — I haven't modified it beyond adding the dtoverlay=hailo-ai,cma_size=256 line for the Hailo AI HAT+. Could disable_fw_kms_setup=1 be related to the firmware not processing mailbox property requests?

[dankorotin]

One more detail that may be relevant: I'm running non-standard Hailo packages from the Hailo Developer Zone, not the ones in the Pi repo:

ii  hailort                5.2.0    arm64    (Pi repo has 4.23.0)
ii  hailort-pcie-driver    5.2.0    all      (Pi repo has 4.23.0)

The hailort-pcie-driver 5.2.0 doesn't use DKMS, so after the kernel upgrade to 6.12.62 I had to manually rebuild the hailo1x_pci module from /usr/src/hailort-pcie-driver/linux/pcie/. The Hailo device itself works fine (/dev/hailo0 present, inference runs correctly).

The dtoverlay=hailo-ai,cma_size=256 line in config.txt was added for the Hailo AI HAT+. Could either the overlay or the 5.2.0 driver be interfering with the firmware mailbox?

Happy to test with the overlay removed or with the stock 4.23.0 packages from the Pi repo if that would help narrow it down.

[pelwell]

I'm wondering if the CMA carve-out is causing problems, but start by just commenting out the whole hailo-ai dtoverlay line and rebooting. You could also see if the output of sudo vclog -m contains any interesting information.