From: bugzilla-daemon@kernel.org
To: linux-bluetooth@vger.kernel.org
Subject: [Bug 221754] RTL8852BE Bluetooth (0bda:b853) fails to init: Opcode 0xfcf0 failed: -16, hci0 never registers with mgmt (BD Address 00:00:00:00:00:00)
Date: Tue, 04 Aug 2026 15:23:36 +0000 [thread overview]
Message-ID: <bug-221754-62941-LVZ0eCjtrm@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-221754-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221754
serge.brun@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |ANSWERED
--- Comment #6 from serge.brun@gmail.com ---
Update: this is fixed, and Adam's case is very likely the same root cause.
mihaits' repo (https://github.com/mihaits/rtl8852bd-bt-linux) nailed it. The
actual problem was never the Opcode 0xfcf0 failure we were all chasing — that
turned out to be a red herring. The real issue: this specific silicon cut
(rom_version=3, aka "RTL8852BD") needs a firmware patch at "eco 4", and
linux-firmware's rtl8852bu_fw.bin only ships eco 1/2 for this chip. It's a
missing-firmware-content problem, not a driver bug — no amount of driver
reloading, address reassignment, or rebuilding btusb was ever going to fix it,
since the firmware needed was never there to load in the first place.
The fix extracts the eco-4 firmware from the Windows Bluetooth driver package
(proprietary Realtek code, not redistributable, so each user has to pull it
from their own vendor's driver download) and feeds it to a patched btrtl that
knows how to apply it correctly — apparently the tricky part is that a specific
memory pointer (0x801200cc) has to be set before streaming the firmware
fragments, or they silently land in the wrong place and the patch never
launches even though every command still reports success.
What I did:
$ git clone https://github.com/mihaits/rtl8852bd-bt-linux
$ cd rtl8852bd-bt-linux
$ sudo ./install.sh ~/Downloads/<lenovo-bluetooth-driver>.exe
(Bluetooth driver .exe pulled from Lenovo's support site for my exact model —
support.lenovo.com > IdeaPad Pro 5 14AGP11 > Drivers & Software > Bluetooth
[https://support.lenovo.com/ca/en/downloads/DS579027])
Result:
$ hciconfig hci0
hci0: Type: Primary Bus: USB
BD Address: 14:B5:CD:7D:92:86 ACL MTU: 1021:6 SCO MTU: 255:12
UP RUNNING
$ sudo hcitool -i hci0 cmd 0x04 0x01
... fw 0x3C91950E (patched), HCI 5.4
Bluetooth is fully working now — paired and streaming audio to headphones
without issue, survives a reboot.
Jeremy — really appreciate you staying engaged on this even once it became
clear the fix wasn't going to be a Makefile/id_table change. Given this turned
out to be a firmware-content gap rather than something fixable in btusb.c, it
might be worth linking mihaits' repo from bluetooth-7.0's README for anyone
who lands there first with a rom_version=3 8852BE — could save the next person
a lot of the loop we all just went through.
Adam (comment #2) — worth checking `dmesg | grep -i "RTL: rom_version"` on
your machine; if I read your comment correctly it also reports version=3, so
this should fix yours too.
Thanks all & Claude — closing this out as resolved on my end.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
next prev parent reply other threads:[~2026-08-04 15:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 12:10 [Bug 221754] New: RTL8852BE Bluetooth (0bda:b853) fails to init: Opcode 0xfcf0 failed: -16, hci0 never registers with mgmt (BD Address 00:00:00:00:00:00) bugzilla-daemon
2026-07-15 12:12 ` [Bug 221754] " bugzilla-daemon
2026-07-17 11:07 ` bugzilla-daemon
2026-08-02 13:01 ` bugzilla-daemon
2026-08-04 8:12 ` bugzilla-daemon
2026-08-04 11:33 ` bugzilla-daemon
2026-08-04 15:23 ` bugzilla-daemon [this message]
2026-08-04 19:35 ` bugzilla-daemon
2026-08-06 5:01 ` bugzilla-daemon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-221754-62941-LVZ0eCjtrm@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@kernel.org \
--cc=linux-bluetooth@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox