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