RTL8852BE WiFi non-functional — firmware/driver header version mismatch

Support & help
1

Summary

On the amd64-fydeos_apu board, the onboard Realtek RTL8852BE Wi-Fi 6 adapter fails to probe entirely. The kernel driver rtw89_8852be rejects the bundled firmware files with Unknown firmware header version 10, leaving the device with no wireless networking at all (Ethernet still works normally).

The root cause is a firmware/driver version mismatch: the firmware blobs shipped in this image use header format version 10, while the rtw89 kernel driver compiled into this build only recognizes older header versions (0/1). This is a known upstream class of bug — see “Prior art” below — where linux-firmware updates the RTL8852x binaries to a newer header format ahead of the corresponding driver update landing in a given kernel branch.

A working fix was found and verified (see below), but it requires manual intervention (developer mode, disabling rootfs verification, replacing a firmware file by hand). This should not be necessary for an end user with a stock, fully-supported Wi-Fi chipset.

Environment

Field Value
Device ASUS ExpertBook BM1503CDA
CPU AMD Ryzen 5 7535U
iGPU AMD Radeon 660M/680M (Rembrandt)
Board (CHROMEOS_RELEASE_BOARD) amd64-fydeos_apu-io
Builder path amd64-fydeos_apu/R20-16503.20.0
Release version 16503.20.22.10 (Release Build v22.1, stable-channel)
Chrome/Chromium version 144.0.7559.32
Kernel (uname -a) Linux localhost 6.6.99-09011-gfdc62122de5f-dirty #1 SMP PREEMPT_DYNAMIC Mon, 15 Dec 2025 23:20:34 -0800 x86_64 AMD Ryzen 5 7535U with Radeon Graphics AuthenticAMD GNU/Linux
Wi-Fi chip Realtek RTL8852BE (PCIe 802.11ax), lspci ID 02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8852BE PCIe 802.11ax Wireless Network Controller
Ethernet chip (working, used as fallback) Realtek RTL8111/8168/8211/8411
Bluetooth Works correctly — separate rtl8852bu_fw.bin / rtl8852bu_config.bin load fine, hci0 initializes and connects

Steps to reproduce

  1. Fresh install / boot of FydeOS on the hardware above.
  2. Ethernet connected and working. Attempt to use Wi-Fi.
  3. No wireless networks are shown / adapter does not appear to initialize.
  4. Enter developer mode, open a root shell (crosh → shell → sudo -i).
  5. Inspect kernel log:
dmesg | grep -i -E "rtw89|8852|firmware"

Observed log output (before fix)

[    5.975748] pci 0000:02:00.0: attach allowed to drvr rtw89_8852be [internal device]
[    6.007447] rtw89_8852be 0000:02:00.0: loaded firmware rtw89/rtw8852b_fw-1.bin
[    6.011302] rtw89_8852be 0000:02:00.0: Unknown firmware header version 10
[    6.011308] rtw89_8852be 0000:02:00.0: failed to recognize firmware
[    6.011311] rtw89_8852be 0000:02:00.0: failed to setup chip information
[    6.012276] rtw89_8852be: probe of 0000:02:00.0 failed with error -2

After manually removing rtw8852b_fw-1.bin to force fallback onto the secondary bundled file, the same error recurs against rtw8852b_fw.bin — both bundled firmware files in this image use the incompatible header version 10:

[  81.701824] pci 0000:02:00.0: attach allowed to drvr rtw89_8852be [internal device]
[  81.701969] rtw89_8852be 0000:02:00.0: Direct firmware load for rtw89/rtw8852b_fw-1.bin failed with error -2
[  81.755811] rtw89_8852be 0000:02:00.0: loaded firmware rtw89/rtw8852b_fw.bin
[  81.758714] rtw89_8852be 0000:02:00.0: Unknown firmware header version 10
[  81.758722] rtw89_8852be 0000:02:00.0: failed to recognize firmware
[  81.758725] rtw89_8852be 0000:02:00.0: failed to setup chip information
[  81.759896] rtw89_8852be: probe of 0000:02:00.0 failed with error -2

Firmware directory listing at time of testing (ls -la /lib/firmware/rtw89/):

-rw-r--r--. 1 root root   200744 May  6 09:31 rtw8851b_fw.bin.xz
-rw-r--r--. 1 root root  9459884 May  6 09:30 rtw8852a_fw.bin
-rw-r--r--. 1 root root   206612 May  6 09:31 rtw8852a_fw.bin.xz
-rw-r--r--. 1 root root  7866116 May  6 09:30 rtw8852b_fw-1.bin
-rw-r--r--. 1 root root   218428 May  6 09:31 rtw8852b_fw-1.bin.xz
-rw-r--r--. 1 root root  6869316 May  6 09:30 rtw8852b_fw.bin
-rw-r--r--. 1 root root   161168 May  6 09:31 rtw8852b_fw.bin.xz
-rw-r--r--. 1 root root 10217920 May  6 09:30 rtw8852c_fw.bin
-rw-r--r--. 1 root root   228852 May  6 09:31 rtw8852c_fw.bin.xz

Verified workaround / fix

Environment prep (required because rootfs is verified/read-only by default):

bash

# Enter developer shell
crosh
shell
sudo -i

# Determine active root partition
rootdev -s
# -> /dev/loop0p3

# On this image FydeOS root runs from a loop-mounted image file, not
# directly on a physical partition (nvme0n1 holds Windows + the FydeOS
# image file itself; confirmed nvme0n1p3 is untouched/unrelated — Windows
# partition — throughout this process).

# Disable rootfs verification on the kernel partition matching the
# active root (root=3 -> paired kernel partition=2 on this image layout)
/usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --partitions 2
reboot

After reboot:

bash

crosh
shell
sudo -i
mount -o remount,rw /

Replacing the firmware with a known-good build from the upstream rtw89 out-of-tree driver project (see Prior art, source 4 below), which ships firmware pinned to a version compatible with drivers up to and including the 6.6 kernel branch:

bash

cd /tmp
curl -L -o rtw8852b_fw_test.bin \
  "https://raw.githubusercontent.com/morrownr/rtw89/main/firmware/rtw8852b_fw-2.bin"

cp /tmp/rtw8852b_fw_test.bin /lib/firmware/rtw89/rtw8852b_fw.bin

rmmod rtw89_8852be
modprobe rtw89_8852be
dmesg | tail -20

Result — chip now probes successfully:

[  287.484387] pci 0000:02:00.0: attach allowed to drvr rtw89_8852be [internal device]
[  287.484464] rtw89_8852be 0000:02:00.0: Direct firmware load for rtw89/rtw8852b_fw-1.bin failed with error -2
[  287.485240] rtw89_8852be 0000:02:00.0: loaded firmware rtw89/rtw8852b_fw.bin
[  287.487491] rtw89_8852be 0000:02:00.0: Firmware version 0.29.29.18 (9e3d777f), cmd version 0, type 5
[  287.487498] rtw89_8852be 0000:02:00.0: Firmware version 0.29.29.18 (9e3d777f), cmd version 0, type 3
[  287.779979] rtw89_8852be 0000:02:00.0: chip rfe_type is 1
[  287.809019] rtw89_8852be 0000:02:00.0: Firmware element BB version: 00 28 00 00
[  287.809073] rtw89_8852be 0000:02:00.0: Firmware element radio A version: 00 32 00 00
[  287.809115] rtw89_8852be 0000:02:00.0: Firmware element NCTL version: 00 0a 00 00
[  287.809179] rtw89_8852be 0000:02:00.0: Firmware element TXPWR version: 00 43 00 00
[  287.809195] rtw89_8852be 0000:02:00.0: Firmware element PWR_TRK version: 00 32 00 00
[  287.814573] rtw89_8852be 0000:02:00.0: rfkill hardware state changed to enable

Network interface (wlan0) subsequently appears and scanning/associating works normally via the standard FydeOS network settings UI.

File used as replacement: rtw8852b_fw-2.bin from morrownr/rtw89 repository, firmware version 0.29.29.18 (build hash 9e3d777f), size 1,554,594 bytes. Verified as a legitimate binary firmware blob (not an HTML error page) via od -c header inspection before use.

Root cause analysis

  1. This is not a case of “unsupported chipset” — the RTL8852BE driver (rtw8852be.c) is present in the ChromiumOS kernel tree itself (see source 5), and the chip is recognized at the PCI level (attach allowed to drvr rtw89_8852be).
  2. The failure is purely a firmware container format mismatch: the rtw89 driver’s firmware parser expects header versions 0 or 1 (confirmed in an identical bug report against the upstream out-of-tree rtw89 driver, source 3), while both bundled .bin files in this FydeOS image use header version 10.
  3. This class of regression has occurred multiple times upstream in linux-firmware when a newer firmware format is pushed ahead of (or without) a corresponding driver update landing in a given distribution’s kernel branch — see sources 6 and 7 for two prior, separately-reported instances of the same failure mode on other distros (Debian, openSUSE) affecting the same file (rtw8852b_fw.bin/rtw8852b_fw-1.bin).
  4. Given the kernel build timestamp in this image (Mon, 15 Dec 2025), it’s likely the firmware package (chromeos-firmware-realtek or equivalent, dated May 6 per file timestamps) was updated independently and later than the kernel/driver pairing was last verified, breaking compatibility for this specific chipset without anyone necessarily testing RTL8852BE hardware in CI between those two updates.

Suggested fix for maintainers

Either of the following would resolve this for all affected users without requiring developer mode / manual firmware replacement:

  • Option A: Pin/downgrade rtw8852b_fw.bin and rtw8852b_fw-1.bin in the firmware package to a header-v0/v1-compatible version until the in-tree rtw89 driver is updated to parse header v10.
  • Option B: Backport/cherry-pick the upstream kernel commit(s) that add header v10 parsing support to rtw89 into the amd64-fydeos_apu kernel branch, matching the firmware version already being shipped.

Either fix should be validated specifically against RTL8852BE hardware in CI going forward, since the mismatch shipped silently (no bootup crash, just a silently-nonfunctional wireless adapter) and would not be straightforward for an average user to diagnose.

Sources / prior art referenced

  1. rtw89 kernel driver source (ChromiumOS tree) — confirms the driver for RTL8852BE (rtw8852be.c) is part of the ChromiumOS kernel: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/chromeos-6.1/drivers/net/wireless/realtek/rtw89/rtw8852be.c
  2. ChromiumOS third_party/linux-firmware repository — shows the rtw89/ firmware directory containing the affected files (rtw8852a_fw.bin, rtw8852b_fw-1.bin, rtw8852b_fw.bin, rtw8852bt_fw.bin, rtw8852c_fw.bin): https://chromium.googlesource.com/chromiumos/third_party/linux-firmware/+/refs/heads/master/rtw89/
  3. Identical bug report against upstream out-of-tree rtw89 driver (lwfinger/rtw89 issue #320) — same exact error string (Unknown firmware header version 10), confirms the driver code expects header version 0 or 1: https://github.com/lwfinger/rtw89/issues/320
  4. morrownr/rtw89 — actively maintained out-of-tree driver + firmware repository explicitly compatible with kernel 6.6+, source of the replacement firmware file used in the verified fix above: https://github.com/morrownr/rtw89 (firmware directory: https://github.com/morrownr/rtw89/tree/main/firmware)
  5. Linux Kernel Driver Database entry for RTL8852BE-VT — confirms PCI ID 10ec:b520 and driver config symbol CONFIG_RTW89_8852BTE are present in mainline kernel 6.12–6.19, 7.0, 7.1-rc+HEAD, i.e. the chip class is fully mainline-supported hardware, not a fringe/unsupported device: https://cateee.net/lkddb/web-lkddb/RTW89_8852BTE.html
  6. Debian User Forums thread — separate, independent report of the exact same error (Unknown firmware header version 10) against rtw8852b_fw-1.bin after a kernel/firmware package update, on different hardware, confirming this is a general firmware/driver-pairing regression and not something specific to this FydeOS build: https://forums.linuxmint.com/viewtopic.php?t=392752 and https://forums.debian.net/viewtopic.php?t=158892
  7. Linux kernel mailing list — prior regression report for the same firmware file (different header/version mismatch, 2023) — establishes that rtw8852b_fw.bin compatibility regressions have happened before and were fixed upstream by reverting/re-pinning the firmware version: https://lkml.iu.edu/hypermail/linux/kernel/2303.2/03051.html
  8. rtw89 firmware usage/versioning discussion (v1/v2 format transition precedent) — background on how the rtw89/btrtl ecosystem has handled firmware format version bumps in the past (fallback logic, format versioning conventions), useful context for whichever fix approach maintainers choose: https://lkml.iu.edu/hypermail/linux/kernel/2308.0/05421.html

Additional notes

  • Bluetooth on the same physical RTL8852BE package is unaffected — it uses a separate firmware file (rtl8852bu_fw.bin) and loads/works correctly, confirming the issue is isolated to the Wi-Fi firmware parsing path specifically.
  • Ethernet (RTL8111/8168 family) is unaffected and was used throughout this diagnosis as the primary network connection.
  • This report is filed against the amd64-fydeos_apu board/overlay since that is the board identifier reported by the affected system (platform_identity_model: amd64-fydeos_apu, CHROMEOS_RELEASE_BOARD: amd64-fydeos_apu-io).