| View previous topic :: View next topic |
| Author |
Message |
Jarodiv
n00b
Joined: 17 Jan 2020
Posts: 38
|
 Posted: Tue Aug 04, 2020 8:45 pm Post subject: [SOLVED] Bluetooth 5.0 on RPI4 (64-Bit) |
 |
|
Hello everyone.
I've managed to get my Pi4 mostly running on a custom build 64-Bit Gentoo. One of the few things I am still struggling with is Bluetooth. It generally is working (devices are found and can be connected) but even though the SoC of the Pi4 (CYW43455) supports Bluetooth v5.0 I only get v4.1 while a quick boot into Raspberry Pi OS (32/64-Bit) resulted in a perfectly fine working v5.0
Gentoo 64 (my own setup as well as Genpi64):
| Code: | $ hciconfig -a
hci0: Type: Primary Bus: UART
BD Address: AA:AA:AA:AA:AA:AA ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING PSCAN
RX bytes:850 acl:0 sco:0 events:60 errors:0
TX bytes:4723 acl:0 sco:0 commands:60 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'Heisenberg'
Class: 0x1c0000
Service Classes: Rendering, Capturing, Object Transfer
Device Class: Miscellaneous,
HCI Version: 4.1 (0x7) Revision: 0x0
LMP Version: 4.1 (0x7) Subversion: 0x6119
Manufacturer: Broadcom Corporation (15)
|
Raspberry Pi OS (32/64-Bit):
| Code: | $ hciconfig -a
hci0: Type: Primary Bus: UART
BD Address: DC:A6:32:67:DC:8D ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:2095 acl:0 sco:0 events:99 errors:0
TX bytes:3729 acl:0 sco:0 commands:99 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'raspberrypi'
Class: 0x480000
Service Classes: Capturing, Telephony
Device Class: Miscellaneous,
HCI Version: 5.0 (0x9) Revision: 0x13b
LMP Version: 5.0 (0x9) Subversion: 0x6119
Manufacturer: Cypress Semiconductor Corporation (305)
|
I already validated the firmware files with Sakakis latest live CD (v1.6) and the Raspberry Pi OS but all md5 match (Raspberry Pi OS seems to use different ones but no clue which). Also the firmware seems to be the same for 32 and 64-Bit so no problem there too.
Did anyone manage to get Bluetooth 5 working or knows, if it even is possible with 64-Bit? I will perform some more tests with the 64-Bit beta Raspberry Pi OS once I have time again.
--- edit ---
I quickly tested with the 64-Bit beta of Raspberry Pi OS and it too has Bluetooth 5.0 (updated the post). Haven't yet validated the firmware files but don't expect much new here, to be honest.
Last edited by Jarodiv on Wed Aug 05, 2020 5:21 pm; edited 1 time in total |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54578
Location: 56N 3W
|
| Posted: Tue Aug 04, 2020 10:12 pm Post subject: |
|
|
Jarodiv,
I have my own arm64 install on Pi4. I get
| Code: | $ hciconfig -a
hci0: Type: Primary Bus: UART
BD Address: DC:A6:32:B4:3E:69 ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:1115 acl:0 sco:0 events:58 errors:0
TX bytes:3021 acl:0 sco:0 commands:58 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'BlueZ 5.54'
Class: 0x480000
Service Classes: Capturing, Telephony
Device Class: Miscellaneous,
HCI Version: 5.0 (0x9) Revision: 0x122
LMP Version: 5.0 (0x9) Subversion: 0x6119
Manufacturer: Cypress Semiconductor Corporation (305) |
Is BlueZ 5.54 a hint?
What version of bluez do you have?
My arm64 installs are all testing.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Jarodiv
n00b
Joined: 17 Jan 2020
Posts: 38
|
| Posted: Tue Aug 04, 2020 10:21 pm Post subject: |
|
|
Good to know, that it seems to be possible somehow.
My Bluez is latest in Portage
| Code: | [I] net-wireless/bluez
Verfügbare Versionen: 5.54(0/3)^t {btpclient cups debug deprecated doc experimental extra-tools +mesh midi +obex +readline selinux systemd test test-programs +udev user-session ABI_MIPS="n32 n64 o32" ABI_RISCV="lp64 lp64d" ABI_S390="32 64" ABI_X86="32 64 x32" KERNEL="linux" PYTHON_SINGLE_TARGET="python3_6 python3_7 python3_8"}
Installierte Versionen: 5.54(0/3)^t(16:40:06 29.05.2020)(cups deprecated mesh obex readline systemd udev -btpclient -debug -doc -experimental -extra-tools -midi -selinux -test -test-programs -user-session ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 -lp64d" ABI_S390="-32 -64" ABI_X86="-32 -64 -x32" KERNEL="linux" PYTHON_SINGLE_TARGET="python3_7 -python3_6 -python3_8")
Startseite: http://www.bluez.org
Beschreibung: Bluetooth Tools and System Daemons for Linux |
Not sure if you noticed it but your BT device is detected as "Manufacturer: Cypress Semiconductor Corporation (305)". That's the actual manufactor (the chip is CYW43455). I already tried to find if there are special drivers available but with no success. |
|
| Back to top |
|
|
ross_cc
n00b
Joined: 29 Jul 2020
Posts: 17
Location: Manila
|
| Posted: Wed Aug 05, 2020 2:08 pm Post subject: |
|
|
I built my vanilla arm64 gentoo from scratch on my pi4 but my bluetooth is working perfectly:
| Code: | $ hciconfig -a
hci0: Type: Primary Bus: UART
BD Address: DC:A6:32:87:EC:16 ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:3886 acl:0 sco:0 events:388 errors:0
TX bytes:60266 acl:0 sco:0 commands:388 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'raspberrypi4'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 5.0 (0x9) Revision: 0x13b
LMP Version: 5.0 (0x9) Subversion: 0x6119
Manufacturer: Cypress Semiconductor Corporation (305)
|
I never tried on sakara's image so I have no idea where its configuration goes awry, but I assume it's probably because of the firmware mismatch. Check the following firmware files are present:
| Code: | ls /lib/firmware/brcm/ -l
total 718
-rw-r--r-- 1 root root 29925 Jul 25 03:46 BCM43430A1.hcd
-rw-r--r-- 1 root root 56979 Jul 25 03:47 BCM4345C0.hcd
-rw-r--r-- 1 root root 624943 Jul 25 03:52 brcmfmac43455-sdio.bin
-rw-r--r-- 1 root root 14036 Jul 25 03:52 brcmfmac43455-sdio.clm_blob
-rw-r--r-- 1 root root 1863 Jul 25 11:57 brcmfmac43455-sdio.raspberrypi,4-model-b.txt |
|
|
| Back to top |
|
|
Jarodiv
n00b
Joined: 17 Jan 2020
Posts: 38
|
| Posted: Wed Aug 05, 2020 2:46 pm Post subject: |
|
|
My firmware is up to date. What catched my attention is you saying, that you didn't use his repo and its a vanilla Gentoo. Did you follow any guides in the wiki and install any additional firmware files for the BT chip and is your Gentoo 32-Bit or 64-Bit?
I followed the Pi4 one and used the following firmware:
| Code: | emerge --ask --verbose sys-kernel/linux-firmware
wget --directory-prefix=/etc/firmware https://raw.githubusercontent.com/RPi-Distro/bluez-firmware/master/broadcom/BCM43430A1.hcd
wget --output-document /lib/firmware/brcm/brcmfmac43455-sdio.clm_blob https://github.com/RPi-Distro/firmware-nonfree/raw/master/brcm/brcmfmac43455-sdio.clm_blob
wget --output-document /lib/firmware/brcm/brcmfmac43455-sdio.txt https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt
|
Some time later I switched to the "sys-kernel/linux-firmware" and "sys-firmware/brcm43430-firmware" packages from Sakakis "genpi64" overlay (following his steps to get the fixed firmware).
My relevant firmware files (for completeness):
| Code: | ls /lib/firmware/brcm/ -l
total 16920
-rw-r--r-- 1 root root 29925 4. Aug 18:14 BCM43430A1.hcd
-rw-r--r-- 1 root root 624943 4. Aug 17:38 brcmfmac43455-sdio.bin
-rw-r--r-- 1 root root 14036 4. Aug 17:38 brcmfmac43455-sdio.clm_blob
-rw-r--r-- 1 root root 1863 4. Aug 17:31 brcmfmac43455-sdio.raspberrypi,4-model-b.txt
-rw-r--r-- 1 root root 2074 4. Aug 17:38 brcmfmac43455-sdio.txt |
The "BCM4345C0.hcd" afaik only is for the Pi3B+ but not the Pi4 but doesn't hurt to try it, Did you download it directly from the bluez repo?
--- edit ---
I downloaded the "BCM4345C0.hcd" from the bluez repo, did a reboot but no change, still BT 4.1
Here the md5sum of my files above:
| Code: | 29e5f31d5f039b122cac09abecb7dd39 /lib/firmware/brcm/BCM43430A1.hcd
051e46937fa2831766322feb2cccd187 /lib/firmware/brcm/BCM4345C0.hcd
9d5d7f1953769b5ded866217c9afc437 /lib/firmware/brcm/brcmfmac43455-sdio.bin
c5aeca0e33de4ae870986c517963fef7 /lib/firmware/brcm/brcmfmac43455-sdio.clm_blob
33ad683f22dc4bd4b398629821d7a3de /lib/firmware/brcm/brcmfmac43455-sdio.MINIX-NEO Z83-4.txt
62d3e3bad57b074d6853f02270a8610e /lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt
2c1dc81266ac61dfc0a809cc48fffbfb /lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt
0ed2738fb42c392c60e34dedb74d0510 /lib/firmware/brcm/brcmfmac43455-sdio.txt |
Last edited by Jarodiv on Wed Aug 05, 2020 3:21 pm; edited 1 time in total |
|
| Back to top |
|
|
ross_cc
n00b
Joined: 29 Jul 2020
Posts: 17
Location: Manila
|
| Posted: Wed Aug 05, 2020 3:17 pm Post subject: |
|
|
| Jarodiv wrote: |
The "BCM4345C0.hcd" afaik only is for the Pi3B+ but not the Pi4 but doesn't hurt to try it, Did you download it directly from the bluez repo?
|
I actually downloaded it from there, but since I saw you had the same firmware installed, I guess it shouldn't be the problem.
So the other possibilities may be the kernel configuration or how you pass the argument to btattach.
Did you build the kernel using upstream's pi4 config? ('make ARCH=arm64 bcm2711_defconfig')?
Did you pass any arguments to btattach command? |
|
| Back to top |
|
|
Jarodiv
n00b
Joined: 17 Jan 2020
Posts: 38
|
| Posted: Wed Aug 05, 2020 3:33 pm Post subject: |
|
|
I too had the kernel in mind but didn't find there anything fishy too. The command I used to build my kernel:
| Code: | git clone --depth=1 --branch rpi-5.4.y https://github.com/raspberrypi/linux.git /usr/src/linux-5.4.y-rpi
cd /usr/src/linux-5.4.y-rpi && make bcm2711_defconfig && make -j4 && make modules_install |
My corresponding kernel config (no additional changes made):
| Code: |
[*] Networking support --->
<M> Bluetooth subsystem support --->
[*] Bluetooth Classic (BR/EDR) features
<M> RFCOMM protocol support
[*] RFCOMM TTY support
<M> BNEP protocol support
[*] Multicast filter support
[*] Protocol filter support
<M> HIDP protocol support
[*] Bluetooth High Speed (HS) features
[*] Bluetooth Low Energy (LE) features
[M] Bluetooth 6LoWPAN support
[ ] Enable LED triggers
[ ] Bluetooth self testing support
[*] Export Bluetooth internals in debugfs
Bluetooth device drivers --->
<M> HCI USB driver
<M> HCI UART driver
<M> RF switch subsystem support --->
___ Device Drivers --->
HID support --->
<*> User-space I/O driver support for HID subsystem |
btattach could also be an idea, as I am using hciattach (as described in the wiki):
| Code: | [Unit]
Description=Broadcom BCM43455 bluetooth HCI
ConditionPathIsDirectory=/proc/device-tree/soc/gpio@7e200000/bt_pins
Before=bluetooth.service
After=dev-ttyAMA0.device
[Service]
Type=simple
ExecStart=/usr/bin/hciattach -n /dev/ttyAMA0 bcm43xx 3000000 flow -
[Install]
WantedBy=multi-user.target |
--- edit ---
I switchted for a test to btattach but the results are even less promosing
| Code: | | ExecStart=/usr/bin/btattach -B /dev/ttyAMA0 -P bcm -S 921600 -N |
| Code: | hci0: Type: Primary Bus: UART
BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0
DOWN
RX bytes:0 acl:0 sco:0 events:0 errors:0
TX bytes:4 acl:0 sco:0 commands:1 errors:0
Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Packet type: DM1 DH1 HV1
Link policy:
Link mode: SLAVE ACCEPT |
Last edited by Jarodiv on Wed Aug 05, 2020 4:03 pm; edited 1 time in total |
|
| Back to top |
|
|
ross_cc
n00b
Joined: 29 Jul 2020
Posts: 17
Location: Manila
|
| Posted: Wed Aug 05, 2020 4:02 pm Post subject: |
|
|
| Jarodiv wrote: | | I too had the kernel in mind but didn't find there anything fishy too. |
Then it should bare no problem. I tried changing the paremeter on btattach but didn't notice any difference on bluetooth stack version either. So unless you changed some quirky parameter on config.txt, there shouldn't be anything wrong.
I guess i will dig out a spare sdcard and try out sakaka's image by myself, see if i can recreate the problem. |
|
| Back to top |
|
|
ross_cc
n00b
Joined: 29 Jul 2020
Posts: 17
Location: Manila
|
| Posted: Wed Aug 05, 2020 4:15 pm Post subject: |
|
|
systemd has its own btattach service. just run
| Code: |
systemctl start btattach-bcm@soc-fe201000.serial-tty.service
|
|
|
| Back to top |
|
|
Jarodiv
n00b
Joined: 17 Jan 2020
Posts: 38
|
| Posted: Wed Aug 05, 2020 4:19 pm Post subject: |
|
|
Ok, I have good news and bad news.
The good news: I had the feeling that something was fishy and just went with a restart. Using btattach, the device now is recognized correctly, thanks a lot!
| Code: | hci0: Type: Primary Bus: UART
BD Address: DC:A6:32:67:DC:8D ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:3232 acl:0 sco:0 events:358 errors:0
TX bytes:61544 acl:0 sco:0 commands:358 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'Heisenberg'
Class: 0x1c0000
Service Classes: Rendering, Capturing, Object Transfer
Device Class: Miscellaneous,
HCI Version: 5.0 (0x9) Revision: 0x13b
LMP Version: 5.0 (0x9) Subversion: 0x6119
Manufacturer: Cypress Semiconductor Corporation (305) |
The bad news: When I now connect my bluetooth speakers, the sound stutters a lot, which it didn't do when using hciattach.
--- edit ---
Using the service "btattach-bcm@soc-fe201000.serial-tty.service" results in the same stuttering. Also this service seems to be not meant for direct use, at least I get the following message when trying to enable it:
| Code: | # systemctl enable btattach-bcm@soc-fe201000.serial-tty.service
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified. |
|
|
| Back to top |
|
|
ross_cc
n00b
Joined: 29 Jul 2020
Posts: 17
Location: Manila
|
| Posted: Wed Aug 05, 2020 4:28 pm Post subject: |
|
|
| Jarodiv wrote: | | The bad news: When I now connect my bluetooth speakers, the sound stutters a lot, which it didn't do when using hciattach |
You can mess around with the parameter passed to btattach. Maybe changing the command to this can work out the problem.
| Code: |
/usr/bin/btattach -B /dev/ttyAMA0 -P bcm -S 3000000
|
This ramps up the baud rate for the bluetooth device, thus should improve its bandwidth.
Add the baudrate parameter into /usr/libexec/bluetooth/btattach-bcm-service.sh then execute 'systemctl edit btattach-bcm@soc-fe201000.serial-tty' and add the following lines:
| Code: |
[Install]
WantedBy=multi-user.target
|
Then you can enable this systemd service. |
|
| Back to top |
|
|
Jarodiv
n00b
Joined: 17 Jan 2020
Posts: 38
|
| Posted: Wed Aug 05, 2020 4:55 pm Post subject: |
|
|
| Quote: | | You can mess around with the parameter passed to btattach. Maybe changing the command to this can work out the problem. |
Did that but attaching "-S 3000000" didn't improve it. I also did some research but everything I found so far regarding similar issues for the older PI generations, e.g. updates to the NVRAM files (the "brcmfmac43455-sdio*.txt" files), has already been applied and the issue still persists.
Regarding changing the service file, I don't think that this is a feasible solution since that file will be changed back with the next update (same with the shell script). Since the command is the same, my "own" service will do the job for now. |
|
| Back to top |
|
|
Jarodiv
n00b
Joined: 17 Jan 2020
Posts: 38
|
| Posted: Wed Aug 05, 2020 5:20 pm Post subject: |
|
|
I found a solution!
At the end of this bug report a solution was described that worked perfectly for me.
In /boot/config.txt add:
| Code: | # Set to "on" to enable autoprobing of Bluetooth driver without need of hciattach/btattach
# Default: off
#
dtparam=krnbt=on |
All modifications to existing services as well as any additionally created ones can be rolled back. After a reboot the bluetooth firmware now will is loaded automatically and connected devices worked flawless for me so far.
The parameter is quite new and described in the README of the Raspberry Firmware overlways.
Thanks for your help!
Last edited by Jarodiv on Wed Aug 05, 2020 5:39 pm; edited 1 time in total |
|
| Back to top |
|
|
ross_cc
n00b
Joined: 29 Jul 2020
Posts: 17
Location: Manila
|
| Posted: Wed Aug 05, 2020 5:25 pm Post subject: |
|
|
Congrats! someone should write this solution on the gentoo wiki.
I tried on this method myself, and I noticed that hci0 was enabled automatically and it works perfectly, also /dev/ttyAMA0 doesn't exist anymore.
One thing to point out is that this overlay is only added by this PR to rpi-5.7.y and newer kernel version, and has not been backported to older kernel branches so far. |
|
| Back to top |
|
|
Jarodiv
n00b
Joined: 17 Jan 2020
Posts: 38
|
| Posted: Wed Aug 05, 2020 6:10 pm Post subject: |
|
|
I've added a note to the wiki pages Raspberry Pi 3 64 bit Install and Raspberry Pi
--- edit ---
| Quote: | | One thing to point out is that this overlay is only added by this PR to rpi-5.7.y and newer kernel version, and has not been backported to older kernel branches so far. |
I'm actually running 5.4.y with the latest firmware and it is working flawlessly. It at least is present in the firmware since the 5.4.50 bump and works fine for me ¯\_(ツ)_/¯ |
|
| Back to top |
|
|
luno
n00b
Joined: 18 Aug 2021
Posts: 1
|
| Posted: Wed Aug 18, 2021 9:22 pm Post subject: |
|
|
I'm not a gentoo-user, but I had the same problem driving me nuts, and this was the solution.. So I've just registered here to say thank you! 
| Jarodiv wrote: | I found a solution!
At the end of this bug report a solution was described that worked perfectly for me.
In /boot/config.txt add:
| Code: | # Set to "on" to enable autoprobing of Bluetooth driver without need of hciattach/btattach
# Default: off
#
dtparam=krnbt=on |
|
|
|
| Back to top |
|
|
|
Gentoo on ARM
