[Bug 1903048] Re: [SRU] Bluetooth won't activate on the pi 400
Dave Jones
1903048 at bugs.launchpad.net
Wed Nov 11 23:26:37 UTC 2020
On Tue, Nov 10, 2020 at 03:12:30PM -0000, Sebastien Bacher wrote:
>Thanks for the work but it there any work to upstream those changes? I'm
>not happy to carry a sleep(1) hack in our package unless there is a
>strong reason and we are working on a way to replace it by a better
>solution
The changes come from the Pi Foundation originally (though I've tidied
them up a tiny bit). They're not interested in upstreaming them
themselves, though they expressed no objections to my attempting to do
so when I raised the question.
I realize I'll probably have a bit of a battle on my hands with
something like the patch involving sleep(1), but I would note that the
sleep(1) hack is in the hciattach_bcm43xx module so it is not something
that would be applied to every single Bluetooth module, only to those
compatible with the BCM43xx line.
While 1 second is obviously a suspiciously round number for the delay, I
would further note that it's immediately after a firmware load over the
controlling UART and that that UART can (in certain configurations) be
the Pi's mini-UART which has some (minimal) buffering, but lacks any
hardware flow control. Finally, these patches were also intended to work
on the relatively slow, single core Pi Zero.
Obviously we don't support the Zero, and thus it's possible *we* might
be able to either do away with that sleep, or at least reduce the delay
required, but given this is one-off initialization, and the delay is all
of 1 second, I'm not convinced it's worth investing the time required to
figure out the minimum. Also, I would assume in the interests of
upstreaming the patch, the delay should be as widely applicable as
possible.
Anyway, I'll upstream what I can and we'll have to carry whatever's left
over.
--
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1903048
Title:
[SRU] Bluetooth won't activate on the pi 400
Status in bluez package in Ubuntu:
Fix Released
Status in bluez source package in Hirsute:
Fix Released
Bug description:
[Impact]
Without these patches, Bluetooth is inoperable on the recently
released Raspberry Pi 400.
[Test Case]
* Boot the Ubuntu Desktop for Pi image on a Pi 400.
* Start the Settings application and switch to the Bluetooth tab
* Verify that Bluetooth is not enabled and attempting to activate it fails
* sudo add-apt-repository ppa:waveform/pi-bluetooth
* sudo apt update
* sudo apt install bluez
* sudo reboot
* Start the Settings application and switch to the Bluetooth tab
* Verify that Bluetooth is active and that Bluetooth devices (e.g. mice, mobile phones, headphones, etc.) can connect and operate correctly
[Regression Potential]
Extremely low (on groovy in particular, this has the same version of
bluez as hirsute). The only significant risk is to non-Pi platforms or
dongles which also use the Broadcom 43xx (or Cypress 305) chips for
Bluetooth which might be inadvertently affected by these patches.
[Original Description]
The new Pi 400 has a slightly different Wifi/BT chip to the Pi4.
Whilst wifi works happily, Bluetooth fails to operate. This doesn't
appear to be an issue with either the firmware (the latest versions
from upstream Raspbian have been tried), or the kernel (a known-good
raspi kernel has been tested under Ubuntu), but with Bluez itself.
Specifically, tracing the initialization with btmon on Raspbian and
Ubuntu, the stack consistently fails when attempting to "Set Default
PHY" on the latter. Curiously, under Ubuntu the adapter also appears
to lack a MAC address.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1903048/+subscriptions
More information about the Ubuntu-sponsors
mailing list