[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