rtl8761_bu usb bluetooth download fw command failed #6141
Comments
|
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. 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:
Strengths:
Potential Improvements:
Uncertainties:
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:
However, I noticed a couple of potential issues or areas for improvement:
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. just thought this might be helpful in tracking down the issue. |
|
Same exact issue here. |
|
the latest firmware (raspberrypi/firmware@5c83250) seems to show some improvement on the pi5, sometimes rtl_bt/rtl8761bu now even loads succesfully at boot (about 30-40% succes rate). pi4 still loads the driver without problems, also with the same rpi-update. |
|
@sninaber I saw this same improvement just after my comment above. I updated firmware and also enabled usb_max_current_enable=1 at the same time, so I wasn't sure which change helped. But, still not good reliability. As a workaround, I can repeatedly power cycle USB power using uhubctl until the hci interface comes up successfully, but this isn't ideal. Have you found any way to reload the driver/module or device from software? Or, have you found any alternative Bluetooth chip that plays nicely on Pi 5? Thanks for the help! |
|
i have tried to modprobe, hcitool, rfkill and bluetoothctl (bluez) to no avail. i have some older bluetooth dongles that work with pi5 and some newer that don't have linux drivers yet. but i can't really recommend any for the pi5 as long as we don't know what causes the issue. |
Thanks for providing a comprehensive bug report. It's very useful.
Why would it? You've got a USB device, and the patch there only concerns a SoC:PCIe link.
This is interesting. Can you iterate through rpi-update versions before and after this date and see which lead to the improvement? Commit list here: https://github.com/raspberrypi/firmware/commits/master/ |
Whoa—uncalled for. I had no differentiating information to contribute at the time, but I'm following and interested. Thanks for the support through this issue. |
Okay. The problem started occurring in e632362—looks like 6.6.16 introduced the issue. I don't experience the issue whatsoever in 6.1.77. |
|
ok that was fast i was still typing my reply.. thank for looking in to this! |
i couldn't find this commit, did you mean revert back to raspberrypi/firmware@e7590ad to check?
my guess would be that on the pi5, RP1 is also connected to pcie, which among others holds the usb controller. (see latency considerations: https://datasheets.raspberrypi.com/rp1/rp1-peripherals.pdf ). so any pcie issues would affect RP1 devices. |
|
I was reverting using rpi-update, so I referenced the commits from rpi-firmware instead: https://github.com/raspberrypi/rpi-firmware/commits/master/ So, for example, the issue didn't manifest after reverting all the way back to 5fc4f64 (kernel 6.1.77): sudo rpi-update 5fc4f643d2e9c5aa972828705a902d184527ae3f |
|
That's a clue that it might be an upstream issue (compounded by whatever's different on Pi 5[1]). Does a Pi 4 exhibit the same when updated to either version? Note that running rpi-update on a Pi 4/5 will also update the bootloader, which has slightly changed XHCI behaviour over time. rpi-update won't downgrade it afterwards, so that should keep the same version for both 6.1 and 6.6. There's certainly scope for a regression given the commit logs... [1] On Pi 5, the device is directly connected to a root port. On Pi 1-4, all full-speed devices are accessed though at least one hub. |
must admit i expected the problem te have existed on the pi5 all along, but can confirm this completely resolves the issue, so my compliments to how quickly you found this. still, looking at the upstream changes to rtl, generic or specifically rtl8761bu, it doesn't really explain why the pi5 sometimes fails to load the firmware while others (including pi4) don't. i have tried different usb hubs on the pi5 (powered and nonpowered) which doesn't make a difference. can't comment on XHCI or the binary files in e632362 where the problem started, so i'm quite useless from here on.. firmware update today raspberrypi/firmware@f31d28d improves a bit further (about 80% succes loading rtl firmware), but still fails sometimes. |
|
i thought about what @P33M said earlier about xhci and the bootloader, so i wanted to see if the otg port behaved in the same way. so i added dtoverlay=dwc2,dr_mode=host to config.txt and connected the bluetooth adapter to the otg port.
this solves the problem and recognises the adapter without problems, at boot or multiple unplug/plug. does this help in any way in finding the cause? is the firmware for RP1 also held in eeprom? if so downgrading to kernel 6.1.77 would not change this. |
|
Thanks for the suggestion @sninaber - I ran into this problem running Home Assistant, and had had to revert the kernel version to keep using the dongles on USBA ports. Using the OSB OTG port in host mode, so far, is working fine on kernel 6.6.28 |
|
I'm insufficiently convinced this isn't a regression between Pi 4 and Pi 5 host controller hardware. @sninaber can you email info < at > raspberrypi.com to start a discussion about getting one of these shipped here? |
|
#5046 (comment) |
|
Apologies for the lag in response - I've received your BT adapter and had a first pass at reproducing your issue - which I can't. It's worked correctly for me 10/10 times. As a point of reference, can you re-run rpi-update as 6.6 has moved on several upstream revisions since then? |
|
interesting! i just tried flashing a fresh sdcard for Pi5 with 64bit Pi-OS networkinstall, full-upgrade and rpi-update. offical keyboard, mouse and powersupply. for me with both 4k/16k kernels the problem remains intermittent (20-30% succes) with all rtl8761 dongles directly attached. so that only leaves the pi5 units which are probably initial revisions. will look into replacing them after summer recess. /proc/cpuinfo uname -a last working firmware: af3ab905d42829d4ce860f19a0e049c3bcdbe35f (feb 8 2024). |
|
Do you have any other USB devices simultaneously plugged in, and if so what are they? (lsusb -v) |
|
I've tried sudo rpi-update to 6.6.40 and the issue still persist I then tried the Looking at the lsusb output, I take a wild guess that maybe something changed in the root_hub xhci-hcd driver that sometimes interferes with downloading firmware ? |
|
just a raspberry pi keyboard and mouse, but as requested: sudo lsusb -v lsusb output``` Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass 9 Hub bDeviceSubClass 0 bDeviceProtocol 3 bMaxPacketSize0 9 idVendor 0x1d6b Linux Foundation idProduct 0x0003 3.0 root hub bcdDevice 6.06 iManufacturer 3 Linux 6.6.40-v8-16k+ xhci-hcd iProduct 2 xHCI Host Controller iSerial 1 xhci-hcd.1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x001f bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 bMaxBurst 0 Hub Descriptor: bLength 12 bDescriptorType 42 nNbrPorts 1 wHubCharacteristic 0x0009 Per-port power switching Per-port overcurrent protection bPwrOn2PwrGood 50 * 2 milli seconds bHubContrCurrent 0 milli Ampere bHubDecLat 0.0 micro seconds wHubDelay 0 nano seconds DeviceRemovable 0x00 Hub Port Status: Port 1: 0000.02a0 5Gbps power Rx.Detect Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 0x000f bNumDeviceCaps 1 SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x02 Latency Tolerance Messages (LTM) Supported wSpeedsSupported 0x0008 Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 1 Lowest fully-functional device speed is Full Speed (12Mbps) bU1DevExitLat 10 micro seconds bU2DevExitLat 2047 micro seconds Device Status: 0x0001 Self PoweredBus 003 Device 003: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 04d9:0006 Holtek Semiconductor, Inc. Wired Keyboard (78/79 key) [RPI Wired Keyboard 5] Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub |
|
I can reproduce this. There's a dependency between Vbus being connected to the device and the time it takes for initialisation to complete. If the time is too long, the device will not respond to further HCI commands (usually this means failing to load firmware). If I plug the device in slowly (more likely to occur on a Pi 5, as connectors are quite tight) then I get a high failure rate. If I ram the device in quickly, it almost always works. My bet is there's some sort of watchdog inside the dongle that's initialised at start of day and is active, and the firmware blob deactivates it. |
|
ok, glad you could reproduce after all!. i guess we are slow pluggers. but timeout is indeed the issue. |
|
I tried to capture usb traffic on usbmon1 enabling usbmon by
Failed fw download (hci0: command 0xfc20 tx timeout)
Successfull fw download:
|
|
I'm using just the single USB device with rtl8761bu and observing the same issue. uname -a Revision : d04170 The issue happens also during restart of Rpi. Thus, it is not related to slow plug-in only. Sometimes, I have to un-plug and plug-in several times to get firware loaded successfully. |
|
Finally I've discovered why my Asus BT500 BT dongle doesn't work. I'm having the same issue. |
which rpi release are you using? |
Bought it 2 weeks ago, problem still present Linux raspberry 6.6.51+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.51-1+rpt2 (2024-10-01) aarch64 GNU/Linux |
This may assist in debugging raspberrypi#6141 The symptom is that the Interrupt endpoint for the dongle sometimes has one outstanding TRB, but the lack of USB bus activity suggests that the xHC didn't correctly register the TRB as valid when the doorbell ring happened. Adding this dummy read seems to fix it. Signed-off-by: Jonathan Bell <[email protected]>
This may assist in debugging raspberrypi#6141 The symptom is that the Interrupt endpoint for the dongle sometimes has one outstanding TRB, but the lack of USB bus activity suggests that the xHC didn't correctly register the TRB as valid when the doorbell ring happened. Adding this dummy read seems to fix it. Signed-off-by: Jonathan Bell <[email protected]>
|
I have a crude workaround that improves things for me. Please try This was always theoretically possible because of the race between a write coming across PCIe, DMA waking up and fetching the ring, and the TRB update making it to main memory late, but nothing so far has exposed this as a bug. |
|
@P33M thanks a lot for your effort. Just updated and the problem persists (USB device on bus 3; hci1): Also no dice with USB device on bus 1: Unfortunately, the device now also isn't able to retrieve the firmware download when being inserted after the system has booted: |
This may assist in debugging raspberrypi#6141 The symptom is that the Interrupt endpoint for the dongle sometimes has one outstanding TRB, but the lack of USB bus activity suggests that the xHC didn't correctly register the TRB as valid when the doorbell ring happened. Adding this dummy read seems to fix it. Signed-off-by: Jonathan Bell <[email protected]>
|
Can you re-run and attach the contents of dump.txt if the firmware download fails. |
|
Looks promising! What works:
What doesn't work:
The firmware download itself happens within a very short time frame of the dongle being inserted: Interesting enough, in the scenario where the dongle is available during boot, it gets hci0 assigned, instead of the onboard UART adapter. |
|
Hi, i still have the same issue, it sometimes does not download the firmware and times out after about 20 seconds
|
|
It seems there's multiple ways in which the dongle setup can fail. With the extra xhci doorbell read, I don't get broken endpoint polling. The firmware will almost always get fully loaded with the last, smaller chunk never reporting completion via the interrupt endpoint. This results in the same symptom (timeout) as not polling the endpoint. |
|
I am unfamiliar with xhci debugging, but I tried to grep "ep 3" /sys/kernel/debug/usb/xhci/xhci-hcd.0/event-ring. I was expecting packet length of 253 for all packets except the last which is 223 as reported by sudo btmon.
|
|
That's a consequence of the timeout error cleanup - the endpoint ring was stopped by the kernel but the USB controller has discarded any remaining transfer state as a result. It's not an error condition in itself. |
|
The last packet in the firmware download sequence is invariably corrupt. Here's two runs side-by-side done seconds apart with success on the left and failure on the right - on the bad run, there's a chunk of zeroes in the middle of the transfer. This won't appear in usbmon traces as the CPU's view of the world is correct. These are from a bus analyser. |
|
I've captured multiple runs and it appears multiple chunks can get corrupted. It's always 16 byte runs of zeroes replacing the real data. Only two offsets seem to be apparent - 104, 232, These are not multiples of 16 or 64 (cacheline size). The driver is re-using the same control buffer multiple times, doing a memcpy into it for each firmware chunk with command/index header prefixed. This buffer is again bounced into a freshly allocated sk_buff under the control of the hci layer. The sk_buff data segment actually passed to the hardware has an alignment of 0x8 and isn't re-used with any close temporal locality. Subtracting the alignment from the offsets above, they are thus multiples of 16 but not 64. These offsets also don't fall on multiples of the usual burst boundary for RP1 xhci DMA (8x16B), but I can't rule out RP1 doing smaller bursts at the start of the buffer. |
|
If the Buffer 000000100a21db88 is a memory address, I can see it reused each 4 packet in the log. btmon/usbmon writes correct bytes when it fails, so something is happening with the buffer at a later stage
|
|
With no USB devices plugged in (use UART or SSH), what happens if you repeat the plug/unplug after running: Note that this won't persist over reboot. |
|
A while back there was a bug in some ethernet drivers where a buffer was being corrupted. It was a shared buffer, and it needed a copy on write to be added to ensure when something wrote to it, grabbed its own copy first. Worked most of the time without but there were some specific circumstances where something else used the buffer and caused weird corruption. No idea if this might be a similar problem. |
|
@P33M I dont know what the commands does, but it works! I've tried multiple times in a row and no problems
henning@raspberrypi0:~ $ sudo bluetoothctl |
|
The failing transfers with bogus data have buffers that span a 4k boundary. Specifically, the last 16B in a 4k page ends up zeroed. There is a feature in RP1 that attempts to split DMA transfers that cross a 4k boundary, but it looks like it misfires on bursts that go up to but do not cross the boundary. The devmem writes disable that. |
|
The attached bootloader recovery zip updates the RP1 firmware to disable the DMA interference. Please test and report back. |
|
I've tested un/plug behaviour and bluetooth scanning in addition to rebooting without any trouble. Thank you all and in particular @P33M for resolving this ! |
|
You're welcome. As an aside, I did notice that there was pretty bad service latency for the Bulk IN endpoint (i.e. radio data) when connected directly to a root port - fiddling with some debug features, I get: For the top 3, this leaves over 85% of a 1ms frame where the endpoint is ignored and 70% for the last option. The same behaviour happens with debugprobe (which has an interrupt endpoint with a much longer interval). If either FS device is plugged into a hub, this oddness disappears with 84 evenly-spaced IN handshakes, presumably because the HS scheduler operates per-microframe instead of per-frame. |
But could this be a permanent fix, or is it just something to see if we can fix the issue temporary? |
|
The required change will be integrated into the next Pi 5 bootloader release. |
|
@sninaber Do you want your hardware returned? If so please email [email protected] referencing this issue number. |
|
@P33M Thanks for not giving up and finding the bug!. I still don't fully understand how downgrading to 6.1.77 would also fix this bug, so please keep the dongle just in case. |
|
Thanks for your work, @P33M - working without a hitch now, across multiple reboots etc. |
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 .h.DQ..@A..d0...
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 ....h..@A......G
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 .h.DQ..@A..d0...
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 ....h..@A......G
99 a4 25 d5 d6 22 d9 c6 df 55 ab 23 87 00 00 ..%.."...U.#...
Additional context
I have dtoverlay=disable-bt in /boot/firmware/config.txt and have disabled hciuart, since I dont need the internal adapter
The text was updated successfully, but these errors were encountered: