rtl_bt: RTL8852BU rom_version 3 has no matching in rtl8852bu_fw.bin

rtl_bt: RTL8852BU rom_version 3 has no matching in rtl8852bu_fw.bin

[deniz]

Hello there, forwarding this report to people in the linux-firmware repo working on realtek devices.

A similar report was filed here: https://lore.kernel.org/linux-firmware/CAP9emj2-8hXB3t3SFD6RU2ZsttsiOtJ6W4Bto4jXSw+dB==TmA@mail.gmail.com It looks to be a widespread problem.

The current rtl_bt/rtl8852bu_fw.bin (Release Version 0x127C_FD78, commit"rtl_bt: Update RTL8852B BT USB FW to 0x127C_FD78", 2026-03-26) contains no
firmware patch matching the ECO revision of the RTL8852BU controller in Lenovo IdeaPads shipping today. Bluetooth is completely non-functional as a result.

Could an rom version 3 (eco 4) patch be added for RTL8852B BT USB?

I have provided diagnostic details below, please feel free to reach out for more.

Happy to test any candidate firmware and report back.
Thanks,

Deniz


-------Hardware--------------


  Machine         : Lenovo IdeaPad  BT controller   : 0bda:b853 "Bluetooth Radio", Realtek (USB)
  WiFi (same M.2) : RTL8852BE, rtw89_8852be, PCIe 01:00.0 - works normally
  Driver          : btusb + btrtl
  linux-firmware  : linux-firmware-realtek 20260622-1 (Arch Linux)

Controller reports:
  Bluetooth: hci0: RTL: examining hci_ver=0b hci_rev=000b lmp_ver=0b lmp_subver=8852
  Bluetooth: hci0: RTL: rom_version status=0 version=3
  Bluetooth: hci0: RTL: btrtl_initialize: key id 0

This matches the intended IC table entry in drivers/bluetooth/btrtl.c, so the correct firmware file is being selected:

  { IC_INFO(RTL_ROM_LMP_8852A, 0xb, 0xb, HCI_USB),
    .config_needed = false,
    .has_rom_version = true,
    .has_msft_ext = true,
    .fw_name  = "rtl_bt/rtl8852bu_fw",
    .cfg_name = "rtl_bt/rtl8852bu_config",
    .hw_info  = "rtl8852bu" },


-------Problem-------

btrtl_parse_section() accepts only subsections whose ECO revision matches the
controller:

  /* drivers/bluetooth/btrtl.c */
  if (common_subsec->eco != btrtl_dev->rom_version + 1)
          continue;

The controller reports rom_version = 3, so only an eco 4 patch is accepted.
Parsing the shipped firmware with an exact replica of the kernel parser gives:

  fw_len       : 129733
  signature    : RTBTCore          (RTL_EPATCH_SIGNATURE_V2)
  num_sections : 2

  section[0]: opcode=0x01 (RTL_PATCH_SNIPPETS) len=129686
      section_hdr.num = 2 subsections
      [ 0] skip   eco=0x01 prio=15 len=67133    eco 1 != rom_version+1 (4)
      [ 1] skip   eco=0x02 prio=15 len=62533    eco 2 != rom_version+1 (4)
      -> contributed 0 bytes
  section[1]: opcode=0x08 (not handled by the switch) len=0
      -> contributed 0 bytes

  total len accumulated = 0

Only eco 1 and eco 2 are present; eco 3 is absent as well. Both subsections are skipped, so no patch data is collected.

I also downloaded rtl_bt/rtl8852bu_fw.bin directly from upstream linux-firmware and confirmed it is byte-identical to the packaged copy, so this is not a distribution packaging artifact:


------- Consequence -------

With zero bytes collected, rtlbt_parse_firmware_v2() returns -ENODATA, no firmware is downloaded to the controller, btrtl_setup_realtek() fails, and hci_dev_open() fails. HCI_SETUP is therefore never cleared and mgmt_index_added() never fires, so bluetoothd never sees a controller at all:

  $ bluetoothctl list                 # empty
  $ sudo btmgmt info
  Index list with 0 items
  $ sudo btmgmt config
  Unconfigured index list with 0 items

The controller itself responds correctly from stock ROM firmware. btmon shows every identification and setup command succeeding - vendor 0xfc61 (twice), Read Local Version Information, vendor 0xfc6d, MSFT Read Supported Features, and the AOSP vendor command 0xfd53 all return Status: Success. The only command that does not is the MSFT LE Set Advertisement Filter Enable, which returns Command Disallowed (0x0c) - expected, given no patch firmware was ever loaded.

Reproduced identically on kernels 6.18.40-2-lts and 7.1.4-arch1-1.

------- Note on diagnosability -------

Both error paths involved are silent, which made this very hard to track down:

  rtlbt_parse_firmware_v2():   if (!len) return -ENODATA;   /* no message */
  btrtl_setup_rtl8723b():      if (ret < 0) goto out;       /* no message */

The only kernel output is the firmware being loaded from disk, followed by nothing at all - no download, no error. A single rtl_dev_err() naming the required versus available ECO revisions would make this diagnosable in seconds. I am happy to send a separate patch for that to linux-bluetooth if useful.


------- ECO coverage across the family -------

For reference, ECO revisions present in linux-firmware-realtek 20260622-1:

  rtl8852au_fw.bin      eco 2
  rtl8852bu_fw.bin      eco 1, 2      <- this machine needs eco 4
  rtl8852btu_fw.bin     eco 1
  rtl8852cu_fw_v2.bin   eco 1, 2
  rtl8851bu_fw.bin      eco 1
  rtl8922au_fw.bin      eco 2

RE: rtl_bt: RTL8852BU rom_version 3 has no matching in rtl8852bu_fw.bin

[Hilda Wu]

Hi Deniz,

Thank you for the detailed analysis and the parser trace — it clearly pinpoints the issue.

Root cause:
The RTL8852BU eco version 4 variant on this device is currently not yet supported in the released firmware. The existing firmware does not cover this eco version, which is why the kernel parser cannot find a matching image and returns -ENODATA.

Current status:
Firmware support for eco 4 is currently in preparation and is targeted for release by end of November 2026. Once available, it will be submitted to linux-firmware accordingly.

In the meantime, if you'd like to test early with a pre-release firmware binary, we are happy to provide one — your validation feedback would be very much appreciated.

We also agree with your suggestion to improve the error message in btrtl_parse_section() to make this kind of failure easier to diagnose. We'll follow up with a separate patch for that.

Sorry for the wait, and thank you again for the thorough investigation.

Best regards,
Hilda

-----Original Message-----
From: deniz <denizgu@protonmail.ch> 
Sent: Sunday, August 2, 2026 8:31 PM
To: Hilda Wu <hildawu@realtek.com>; Ping-Ke Shih <pkshih@realtek.com>; Timlee <timlee@realtek.com>; Zong-Zhe Yang <kevin_yang@realtek.com>; linux-bluetooth@vger.kernel.org
Subject: rtl_bt: RTL8852BU rom_version 3 has no matching in rtl8852bu_fw.bin


External mail : This email originated from outside the organization. Do not reply, click links, or open attachments unless you recognize the sender and know the content is safe.



Hello there, forwarding this report to people in the linux-firmware repo working on realtek devices.

A similar report was filed here: https://lore.kernel.org/linux-firmware/CAP9emj2-8hXB3t3SFD6RU2ZsttsiOtJ6W4Bto4jXSw+dB==TmA@mail.gmail.com It looks to be a widespread problem.

The current rtl_bt/rtl8852bu_fw.bin (Release Version 0x127C_FD78, commit"rtl_bt: Update RTL8852B BT USB FW to 0x127C_FD78", 2026-03-26) contains no firmware patch matching the ECO revision of the RTL8852BU controller in Lenovo IdeaPads shipping today. Bluetooth is completely non-functional as a result.

Could an rom version 3 (eco 4) patch be added for RTL8852B BT USB?

I have provided diagnostic details below, please feel free to reach out for more.

Happy to test any candidate firmware and report back.
Thanks,

Deniz


-------Hardware--------------


  Machine         : Lenovo IdeaPad  BT controller   : 0bda:b853 "Bluetooth Radio", Realtek (USB)
  WiFi (same M.2) : RTL8852BE, rtw89_8852be, PCIe 01:00.0 - works normally
  Driver          : btusb + btrtl
  linux-firmware  : linux-firmware-realtek 20260622-1 (Arch Linux)

Controller reports:
  Bluetooth: hci0: RTL: examining hci_ver=0b hci_rev=000b lmp_ver=0b lmp_subver=8852
  Bluetooth: hci0: RTL: rom_version status=0 version=3
  Bluetooth: hci0: RTL: btrtl_initialize: key id 0

This matches the intended IC table entry in drivers/bluetooth/btrtl.c, so the correct firmware file is being selected:

  { IC_INFO(RTL_ROM_LMP_8852A, 0xb, 0xb, HCI_USB),
    .config_needed = false,
    .has_rom_version = true,
    .has_msft_ext = true,
    .fw_name  = "rtl_bt/rtl8852bu_fw",
    .cfg_name = "rtl_bt/rtl8852bu_config",
    .hw_info  = "rtl8852bu" },


-------Problem-------

btrtl_parse_section() accepts only subsections whose ECO revision matches the
controller:

  /* drivers/bluetooth/btrtl.c */
  if (common_subsec->eco != btrtl_dev->rom_version + 1)
          continue;

The controller reports rom_version = 3, so only an eco 4 patch is accepted.
Parsing the shipped firmware with an exact replica of the kernel parser gives:

  fw_len       : 129733
  signature    : RTBTCore          (RTL_EPATCH_SIGNATURE_V2)
  num_sections : 2

  section[0]: opcode=0x01 (RTL_PATCH_SNIPPETS) len=129686
      section_hdr.num = 2 subsections
      [ 0] skip   eco=0x01 prio=15 len=67133    eco 1 != rom_version+1 (4)
      [ 1] skip   eco=0x02 prio=15 len=62533    eco 2 != rom_version+1 (4)
      -> contributed 0 bytes
  section[1]: opcode=0x08 (not handled by the switch) len=0
      -> contributed 0 bytes

  total len accumulated = 0

Only eco 1 and eco 2 are present; eco 3 is absent as well. Both subsections are skipped, so no patch data is collected.

I also downloaded rtl_bt/rtl8852bu_fw.bin directly from upstream linux-firmware and confirmed it is byte-identical to the packaged copy, so this is not a distribution packaging artifact:


------- Consequence -------

With zero bytes collected, rtlbt_parse_firmware_v2() returns -ENODATA, no firmware is downloaded to the controller, btrtl_setup_realtek() fails, and hci_dev_open() fails. HCI_SETUP is therefore never cleared and mgmt_index_added() never fires, so bluetoothd never sees a controller at all:

  $ bluetoothctl list                 # empty
  $ sudo btmgmt info
  Index list with 0 items
  $ sudo btmgmt config
  Unconfigured index list with 0 items

The controller itself responds correctly from stock ROM firmware. btmon shows every identification and setup command succeeding - vendor 0xfc61 (twice), Read Local Version Information, vendor 0xfc6d, MSFT Read Supported Features, and the AOSP vendor command 0xfd53 all return Status: Success. The only command that does not is the MSFT LE Set Advertisement Filter Enable, which returns Command Disallowed (0x0c) - expected, given no patch firmware was ever loaded.

Reproduced identically on kernels 6.18.40-2-lts and 7.1.4-arch1-1.

------- Note on diagnosability -------

Both error paths involved are silent, which made this very hard to track down:

  rtlbt_parse_firmware_v2():   if (!len) return -ENODATA;   /* no message */
  btrtl_setup_rtl8723b():      if (ret < 0) goto out;       /* no message */

The only kernel output is the firmware being loaded from disk, followed by nothing at all - no download, no error. A single rtl_dev_err() naming the required versus available ECO revisions would make this diagnosable in seconds. I am happy to send a separate patch for that to linux-bluetooth if useful.


------- ECO coverage across the family -------

For reference, ECO revisions present in linux-firmware-realtek 20260622-1:

  rtl8852au_fw.bin      eco 2
  rtl8852bu_fw.bin      eco 1, 2      <- this machine needs eco 4
  rtl8852btu_fw.bin     eco 1
  rtl8852cu_fw_v2.bin   eco 1, 2
  rtl8851bu_fw.bin      eco 1
  rtl8922au_fw.bin      eco 2

Re: rtl_bt: RTL8852BU rom_version 3 has no matching in rtl8852bu_fw.bin

[Blc Dragon]

Hi Hilda,

I can confirm the exact same issue on my hardware, and I'd be glad to
take you up on the offer to test a pre-release firmware binary.

  Machine        : Lenovo IdeaPad
  BT controller  : 0bda:b853 (Realtek, USB), rom_version = 3
  Wi-Fi (same M.2): RTL8852BE, rtw89_8852be - works fine
  Driver         : btusb + btrtl
  linux-firmware : 20260622 (Fedora)
  Kernel         : 7.1.x

Same symptom as Deniz's report: rtl8852bu_fw.bin only carries eco 1/2,
the controller needs eco 4, so no patch is applied, BD_ADDR stays
00:00:00:00:00:00 and no controller is registered.

If you can share a candidate rtl8852bu_fw.bin with the eco 4 patch, I'll
install it and report back with dmesg / btmon and confirmation that the
controller enumerates and pairs. Happy to test as many revisions as
needed.

Thanks a lot for the quick turnaround and the fix!

Best regards,
Pavel

Re: rtl_bt: RTL8852BU rom_version 3 has no matching in rtl8852bu_fw.bin

[Veysi Özgün]

Hi Hilda, all,

Thanks for confirming that eco 4 firmware is planned. I have the same
controller (0bda:b853, rom_version 3) and got it working with the patch
from the Windows driver. Along the way I found something that may matter
for the Linux release: for this ROM revision, the Windows driver sends an
extra vendor command before each patch segment. The current btrtl
download path never sends it.

Hardware / software
-------------------
  Machine   : Lenovo LOQ 15ARP10E (83S0)
  BT        : 0bda:b853, hci_rev 0x000b, lmp_subver 0x8852, rom_version 3
  Wi-Fi     : RTL8852BE (rtw89_8852be), works fine
  Kernel    : 7.1.5 (Kali), BlueZ 5.87
  Windows   : Realtek driver 18.4032.0.3008 (rtkbtfilter.inf),
              patch file rtl8852bd_mp_chip_new.dat

What Windows sends (USBPcap capture of a radio off/on cycle)
------------------------------------------------------------
  HCI_Read_Local_Version
  for each of the 3 segments:
    0xfc62 plen 9: 21 | le32 0x801200cc | le32 <segment addr>  -> status 0
    0xfc20 fragments of 252 bytes, index 1..0x7f then wraps to 1,
      index restarts at 1 for every segment,
      no 0x80 flag at the end of a segment
  then one 0xfc20 with index 0x80 and no data -> status 0

  segment addr    size
  0x8010f720      61552
  0x8010e990        568
  0x801084e0       2900

Afterwards Read_Local_Version returns hci_rev 0x3c91 and lmp_subver 0x950e.

The fragments are byte-identical to the payload of each BTNIC003 entry
(chip_id 0x14, eco 4). In each entry, the two addresses are at +0x3df and
+0x3e7, the payload length is at +0x400, and the payload starts at +0x408.
The first segment has the same layout as the eco 1/2 subsections in
rtl8852bu_fw.bin (code starts with f8630f62 and ends with the 07072db1
trailer).

What does NOT work
------------------
1. Adding the eco 4 payload as an extra RTBTCore subsection and loading it
   through the existing v2 path (without 0xfc62). The controller stops
   responding in the middle of the download ("command 0xfc20 tx timeout",
   "download fw command failed (-110)"). After that, even 0xfc61 times out
   and usbcore keeps resetting the device. Only a full power-off recovers it.

2. Loading the patch from userspace (libusb) with the Windows sequence
   before btusb binds. The patch itself is accepted (lmp_subver becomes
   0x950e), but then btrtl_initialize() finds no ic_info for 0x950e, sets
   drop_fw, sends 0xfc66 and the controller goes back to ROM.

What works
----------
I added a small path to btrtl_setup_rtl8723b() for
8852A-id / hci_rev 0xb / USB / rom_version 3. It uses request_firmware() on
the BTNIC003 file and replays the sequence above. With it, the controller
comes up with its real BD_ADDR, registers with mgmt and scans normally.
This is only a proof of concept and not meant for merging (it parses the
vendor Windows file). I'm happy to share the diff and the pcapng if they
help.

Question
--------
Will the upcoming eco 4 firmware work with the existing RTBTCore download
path, or does this ROM revision also need 0xfc62 (or similar) on the
driver side? Either way, I can test pre-release firmware or driver patches
on this hardware.

Thanks,
Veysi Özgün