linux
linux copied to clipboard
rtl8761_bu usb bluetooth download fw command failed
Describe the bug
Hi! I have a Trust usb stick that most of the time fails to download fw during boot on my raspberry pi 5. I have to plug/unplug it until it succeeds. From the btmon log it seems that fw loading stops after the last packet which fails to get HCI Event: Command Complete?
I have no issues with the usb stick on my laptop running fedora 40 with kernel 6.8.7-300.fc40, so maybe its related to the raspberry pi kernel?
Steps to reproduce the behaviour
dmesg --ctime --follow Plug/unplug usb stick Some times download fw fails
Device (s)
Raspberry Pi 5
System
Raspberry Pi reference 2024-03-15 Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, f19ee211ddafcae300827f953d143de92a5c6624, stage4 2024/04/20 11:53:30 Copyright (c) 2012 Broadcom version d1744d21 (release) (embedded) Linux raspberrypi0 6.6.28+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.28-1+rpt1 (2024-04-22) aarch64 GNU/Linux
Logs
dmesg --ctime --follow:
[Wed May 1 18:26:14 2024] usb 1-2: new full-speed USB device number 6 using xhci-hcd [Wed May 1 18:26:14 2024] usb 1-2: New USB device found, idVendor=0bda, idProduct=8771, bcdDevice= 2.00 [Wed May 1 18:26:14 2024] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [Wed May 1 18:26:14 2024] usb 1-2: Product: Bluetooth Radio [Wed May 1 18:26:14 2024] usb 1-2: Manufacturer: Realtek [Wed May 1 18:26:14 2024] usb 1-2: SerialNumber: 00E04C239987 [Wed May 1 18:26:14 2024] Bluetooth: hci3: RTL: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761 [Wed May 1 18:26:14 2024] Bluetooth: hci3: RTL: rom_version status=0 version=1 [Wed May 1 18:26:14 2024] Bluetooth: hci3: RTL: loading rtl_bt/rtl8761bu_fw.bin [Wed May 1 18:26:14 2024] Bluetooth: hci3: RTL: loading rtl_bt/rtl8761bu_config.bin [Wed May 1 18:26:14 2024] Bluetooth: hci3: RTL: cfg_sz 6, total sz 30210 [Wed May 1 18:26:17 2024] Bluetooth: hci3: command 0xfc20 tx timeout [Wed May 1 18:26:17 2024] Bluetooth: hci3: RTL: Failed to generate devcoredump [Wed May 1 18:26:17 2024] Bluetooth: hci3: RTL: download fw command failed (-110) [Wed May 1 18:26:18 2024] usb 1-2: USB disconnect, device number 6 [Wed May 1 18:26:18 2024] Bluetooth: hci3: RTL: RTL: Read reg16 failed (-19) [Wed May 1 18:26:29 2024] usb 1-2: new full-speed USB device number 7 using xhci-hcd [Wed May 1 18:26:29 2024] usb 1-2: New USB device found, idVendor=0bda, idProduct=8771, bcdDevice= 2.00 [Wed May 1 18:26:29 2024] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [Wed May 1 18:26:29 2024] usb 1-2: Product: Bluetooth Radio [Wed May 1 18:26:29 2024] usb 1-2: Manufacturer: Realtek [Wed May 1 18:26:29 2024] usb 1-2: SerialNumber: 00E04C239987 [Wed May 1 18:26:29 2024] Bluetooth: hci3: RTL: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761 [Wed May 1 18:26:29 2024] Bluetooth: hci3: RTL: rom_version status=0 version=1 [Wed May 1 18:26:29 2024] Bluetooth: hci3: RTL: loading rtl_bt/rtl8761bu_fw.bin [Wed May 1 18:26:29 2024] Bluetooth: hci3: RTL: loading rtl_bt/rtl8761bu_config.bin [Wed May 1 18:26:29 2024] Bluetooth: hci3: RTL: cfg_sz 6, total sz 30210 [Wed May 1 18:26:30 2024] Bluetooth: hci3: RTL: fw version 0xdfc6d922 [Wed May 1 18:26:30 2024] Bluetooth: MGMT ver 1.22
tail btmon-1.log of failed fw download:
< HCI Command: Vendor (0x3f|0x0020) plen 223 #245 [hci1] 6.804458
f7 68 01 44 51 02 00 40 41 06 00 64 30 08 00 b0 [email protected]...
00 66 00 59 40 0a 06 db 50 0c 06 f2 7b 10 06 8c [email protected]...{...
55 12 06 0a 28 14 06 27 01 00 f0 60 00 02 90 77 U...(..'......w f8 64 06 27 00 02 01 00 00 34 00 04 27 38 00 83 .d.'.....4..'8.. 80 00 20 11 50 01 20 00 02 02 20 00 3b 3f 20 28 .. .P. ... .;? ( 03 20 20 2c 90 02 01 20 00 40 00 00 80 42 00 00 . ,... [email protected].. 01 44 00 00 00 46 00 84 00 48 00 c0 00 4a 00 00 .D...F...H...J.. 00 4c 00 00 00 4e 00 28 00 50 00 40 cc 52 00 00 .L...N.([email protected].. 14 54 00 00 00 56 00 00 20 58 00 11 55 5a 00 00 .T...V.. X..UZ.. 80 5c 00 00 00 5e 00 05 28 0e 01 01 00 02 01 60 .\...^..(......
c0 02 01 22 c0 7c e1 64 00 02 01 20 00 30 06 26 ...".|.d... .0.&
67 34 06 7f c8 3a 06 d3 00 5a 03 45 00 42 02 bf g4...:...Z.E.B..
05 2e 01 00 68 02 00 40 41 08 00 b0 00 02 02 47 [email protected]
99 a4 25 d5 d6 22 d9 c6 df 55 ab 23 87 00 00 ..%.."...U.#...
= Close Index: 00:00:00:00:00:00 [hci1] 8.819086
same in fw download success btmon-2.log
< HCI Command: Vendor (0x3f|0x0020) plen 223 #245 [hci3] 7.428504
f7 68 01 44 51 02 00 40 41 06 00 64 30 08 00 b0 [email protected]...
00 66 00 59 40 0a 06 db 50 0c 06 f2 7b 10 06 8c [email protected]...{...
55 12 06 0a 28 14 06 27 01 00 f0 60 00 02 90 77 U...(..'......w f8 64 06 27 00 02 01 00 00 34 00 04 27 38 00 83 .d.'.....4..'8.. 80 00 20 11 50 01 20 00 02 02 20 00 3b 3f 20 28 .. .P. ... .;? ( 03 20 20 2c 90 02 01 20 00 40 00 00 80 42 00 00 . ,... [email protected].. 01 44 00 00 00 46 00 84 00 48 00 c0 00 4a 00 00 .D...F...H...J.. 00 4c 00 00 00 4e 00 28 00 50 00 40 cc 52 00 00 .L...N.([email protected].. 14 54 00 00 00 56 00 00 20 58 00 11 55 5a 00 00 .T...V.. X..UZ.. 80 5c 00 00 00 5e 00 05 28 0e 01 01 00 02 01 60 .\...^..(......
c0 02 01 22 c0 7c e1 64 00 02 01 20 00 30 06 26 ...".|.d... .0.&
67 34 06 7f c8 3a 06 d3 00 5a 03 45 00 42 02 bf g4...:...Z.E.B..
05 2e 01 00 68 02 00 40 41 08 00 b0 00 02 02 47 [email protected]
99 a4 25 d5 d6 22 d9 c6 df 55 ab 23 87 00 00 ..%.."...U.#...
HCI Event: Command Complete (0x0e) plen 5 #246 [hci3] 7.461497 Vendor (0x3f|0x0020) ncmd 3 Status: Success (0x00) f7 .
< HCI Command: Read Local Version... (0x04|0x0001) plen 0 #247 [hci3] 7.461506 HCI Event: Command Complete (0x0e) plen 12 #248 [hci3] 7.463502 Read Local Version Information (0x04|0x0001) ncmd 2 Status: Success (0x00) HCI version: Bluetooth 5.1 (0x0a) - Revision 57286 (0xdfc6) LMP version: Bluetooth 5.1 (0x0a) - Subversion 55586 (0xd922) Manufacturer: Realtek Semiconductor Corporation (93)
Additional context
I have dtoverlay=disable-bt in /boot/firmware/config.txt and have disabled hciuart, since I dont need the internal adapter
I've tried to trace down the source code responsible for downloading firmware, and found it in rtl_download_firmware https://github.com/torvalds/linux/blob/master/drivers/bluetooth/btrtl.c#L802
The function only tries 1 time to download a fragment before giving up.
/* Send download command */
skb = __hci_cmd_sync(hdev, 0xfc20, frag_len + 1, dl_cmd,
HCI_INIT_TIMEOUT);
if (IS_ERR(skb)) {
rtl_dev_err(hdev, "download fw command failed (%ld)",
PTR_ERR(skb));
ret = PTR_ERR(skb);
goto out;
}
In addition gemini AI/chatgpt gives :
gemini AI
The provided C code appears mostly correct for downloading firmware to an RTL Bluetooth controller. Here's a breakdown with some explanations and potential improvements:
Functionality:
- The code downloads firmware in fragments to the Bluetooth controller identified by
hdev
. - It iterates through the firmware data (
data
) in chunks ofRTL_FRAG_LEN
and sends them using HCI commands. - After successful download, it reads the local firmware version using another HCI command.
Strengths:
- The code uses kernel memory allocation (
kmalloc
) for the download command structure. - It checks for errors during command sending and data length verification.
- It logs debugging and informational messages using appropriate functions.
Potential Improvements:
-
Error Handling: Consider adding checks for
dl_cmd
allocation failures beyond just checking the return value. You can use a similar approach forskb
allocations. -
Loop Termination: The loop condition
i < frag_num
might be susceptible to overflow iffrag_num
is very large. Consider using a loop that iterates until all data is sent (data + frag_len > data
). -
Resource Management: Move the
kfree(dl_cmd);
outside the loop to ensure it's always freed even in error cases. -
Clarity: Adding comments within the loop to explain the purpose of setting
dl_cmd->index
and handling the last fragment could improve code readability.
Uncertainties:
- The code relies on undefined types like
struct rtl_download_cmd
andstruct rtl_download_response
. Without knowing their definitions, it's impossible to fully verify their usage. - The functions
rtl_dev_dbg
,rtl_dev_err
,rtl_dev_info
, andbtrtl_read_local_version
are assumed to be specific to the RTL Bluetooth driver and are not part of the standard Linux kernel API.
Overall:
The code seems like a reasonable implementation for downloading firmware to an RTL Bluetooth controller. However, for a complete review, the missing type definitions and specific driver functionalities would need to be analyzed. The suggested improvements can further enhance the code's robustness and readability.
chatgpt:
The code you provided appears to be a function for downloading firmware to a Realtek Bluetooth device. Here's a quick analysis:
-
Memory Allocation: The function allocates memory for a
struct rtl_download_cmd
usingkmalloc
. This allocation is later freed usingkfree
. -
Looping through Fragments: The function loops through the firmware data in fragments of size
RTL_FRAG_LEN
. It constructs astruct rtl_download_cmd
for each fragment and sends it using__hci_cmd_sync
. The loop also handles the case when the last fragment might be smaller thanRTL_FRAG_LEN
. -
Error Handling: The function properly handles errors by returning appropriate error codes and freeing allocated resources (
skb
,dl_cmd
) before returning. -
Verification: It verifies the length of the response received after sending the download command and also reads the local version information after downloading the firmware.
-
Correctness: The code appears logically correct, assuming
RTL_FRAG_LEN
is defined andrtl_dev_dbg
,rtl_dev_err
, andrtl_dev_info
are properly implemented for debugging and logging.
However, I noticed a couple of potential issues or areas for improvement:
-
Data Copying: Inside the loop,
memcpy(dl_cmd->data, data, frag_len);
appears to copy the same data (data
) intodl_cmd->data
in each iteration. It seems like it should copy a portion ofdata
corresponding to the current fragment. You might need to adjust the starting position indata
for each fragment. -
Unused Variables: The
skb
variable is declared twice inside the loop. You can remove the declaration inside the loop since it's already declared outside. -
Error Handling in Fragment Loop: In the fragment loop, if an error occurs during sending the download command (
__hci_cmd_sync
), the loop will break out early with an error code, but it's not clearing resources allocated before the error occurred (e.g., previously allocatedskb
). You should make sure to free resources properly before exiting the function.
Overall, the code seems structurally sound, but you might need to verify the details of the firmware download process and adjust the data copying logic accordingly.
hi hkskoglund,
i have the same issue with several aliexpress rtl8761bu dongles on the pi5, plug/unplug until firmware loads and then everything is fine. strange thing is that my pi4's dont have this problem at all. same raspberry pi os, all rpi-updated to 6.6.30 to be sure. overclocking doesn't seem to matter much. pi's are in flirc cases so external bluetooth is pretty much essential.
just thought this might be helpful in tracking down the issue.
Same exact issue here.