Problem
linux-raspberrypi_6.12.bb on scarthgap currently pins:
SRCREV_machine = "3dd2c2c507c271d411fab2e82a2b3b7e0b6d3f16" # 6.12.25, April 2025
This SRCREV predates raspberrypi/linux PR #7023 ("ARM: dts: Select the PL011 platform driver"), which was merged into rpi-6.12.y on 2025-09-25.
The result is that every fresh Yocto build using meta-raspberrypi scarthgap + the 6.12 recipe on a Raspberry Pi 4 / CM4 ships a bcm2711-rpi-cm4.dtb with the BCM2711 PL011 UARTs bound through the AMBA bus path with arm,primecell-periphid = 0x00341011 (r1p5). In that configuration the in-kernel hci_uart_bcm driver cannot complete the initial baud-rate negotiation with the internal BCM43455 Bluetooth chip on the CM4, so BT never comes up:
Bluetooth: hci0: command 0xfc18 tx timeout
Bluetooth: hci0: BCM: failed to write update baudrate (-110)
Bluetooth: hci0: Failed to set baudrate
Bluetooth: hci0: BCM: Reset failed (-110)
WiFi (SDIO side of the same chip) is unaffected. PR #7023 fixes this by routing the UARTs through pl011_axi_platform_driver via the arm,pl011-axi compatible. Pi OS Lite Bookworm (2026-04-21) ships the fix already; same symptom is also tracked in home-assistant/operating-system#3369, which appears to be the same root cause.
How to reproduce
- Build any image with
MACHINE = "raspberrypi4-64", DISTRO_FEATURES:append = " bluetooth", and PREFERRED_VERSION_linux-raspberrypi = "6.12%" on current scarthgap.
- Flash to a CM4 module on any carrier board.
- Boot.
hciconfig -a shows hci0 in DOWN state with BD Address: 00:00:00:00:00:00. dmesg | grep -i bluetooth shows the timeout pattern above.
Verify the DTB is pre-fix
$ dtc -I dtb -O dts ${DEPLOY_DIR_IMAGE}/bcm2711-rpi-cm4.dtb 2>/dev/null \
| grep -B1 -A3 'serial@7e201000 {'
serial@7e201000 {
compatible = "arm,pl011", "arm,primecell"; # <-- pre-fix
...
arm,primecell-periphid = <0x00341011>;
After the bump, the same dump should show:
compatible = "arm,pl011-axi", "arm,pl011", "arm,primecell";
Proposed fix
Bump SRCREV_machine to a recent rpi-6.12.y HEAD, and update SRCREV_meta to the matching yocto-6.12 HEAD. This pulls in PR #7023 plus ~14 months of stable point releases (6.12.25 → 6.12.93) including CVE backports that the original switch to the 6.12 recipe was meant to capture.
LINUX_VERSION : 6.12.25 -> 6.12.93
SRCREV_machine : 3dd2c2c5... -> d8ab4e90... (rpi-6.12.y HEAD as of 2026-06-12)
SRCREV_meta : 1f6ab68a... -> e66f4099... (yocto-6.12 HEAD)
Will follow up with a PR.
Problem
linux-raspberrypi_6.12.bbonscarthgapcurrently pins:This SRCREV predates
raspberrypi/linuxPR #7023 ("ARM: dts: Select the PL011 platform driver"), which was merged intorpi-6.12.yon 2025-09-25.The result is that every fresh Yocto build using
meta-raspberrypiscarthgap + the 6.12 recipe on a Raspberry Pi 4 / CM4 ships abcm2711-rpi-cm4.dtbwith the BCM2711 PL011 UARTs bound through the AMBA bus path witharm,primecell-periphid = 0x00341011(r1p5). In that configuration the in-kernelhci_uart_bcmdriver cannot complete the initial baud-rate negotiation with the internal BCM43455 Bluetooth chip on the CM4, so BT never comes up:WiFi (SDIO side of the same chip) is unaffected. PR #7023 fixes this by routing the UARTs through
pl011_axi_platform_drivervia thearm,pl011-axicompatible. Pi OS Lite Bookworm (2026-04-21) ships the fix already; same symptom is also tracked in home-assistant/operating-system#3369, which appears to be the same root cause.How to reproduce
MACHINE = "raspberrypi4-64",DISTRO_FEATURES:append = " bluetooth", andPREFERRED_VERSION_linux-raspberrypi = "6.12%"on current scarthgap.hciconfig -ashowshci0inDOWNstate withBD Address: 00:00:00:00:00:00.dmesg | grep -i bluetoothshows the timeout pattern above.Verify the DTB is pre-fix
After the bump, the same dump should show:
Proposed fix
Bump
SRCREV_machineto a recentrpi-6.12.yHEAD, and updateSRCREV_metato the matchingyocto-6.12HEAD. This pulls in PR #7023 plus ~14 months of stable point releases (6.12.25 → 6.12.93) including CVE backports that the original switch to the 6.12 recipe was meant to capture.Will follow up with a PR.