https://bugzilla.kernel.org/show_bug.cgi?id=221754
[email protected] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |ANSWERED
--- Comment #6 from [email protected] ---
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.