Re: [Touch-packages] [Bug 1903048] Re: [SRU] Bluetooth won't activate on the pi 400
On Fri, Nov 13, 2020 at 09:37:34AM -, Sebastien Bacher wrote: >@Matthieu, @Dave, thanks for the comments and details. > >I'm not blocking work to land, the 20.10 SRU could be accepted now and I >didn't revert in that serie. >The SRU team tries to ensure the fix is in the new serie so it doesn't get >forgotten/regress when next version is out but I think it's pretty clear we >are going to sort out the review details, that's not a blocker and SRU team >has been happy in the past to let things in with the understand than $newserie >is being sorted out Ah, my apologies - I had mis-interpreted the reversion as applying to the SRU. I've no issue with a reversion in hirsute, provided it doesn't delay existing users from using their Bluetooth hardware. >> If upstream say "yes" to the patches, without further discussion: that's >> great, but there'd presumably still be some delay before another version >> makes its way down to us, so we'd be applying *some* patch to make it work >> in the interim. > >Again I'm not asking for the patches to be reviewed or accepted upstream >before they are uploaded to Ubuntu, I'm just asking for them to be sent >upstream and the reference to the email/report/merge request to be added >to the patches. It would probably have been less work to just do it >rather than type a long explanation here on why we need to distro patch >in any case (which I never disagreed with) I estimate, as I think several others do judging by various comments, that the patches in their current state don't stand much chance of passing muster upstream, and I have no desire to waste their time with a premature submission. At the very least, some justification needs adding to the 1 second sleep: either a datasheet reference, which I've so far failed to find, or some empirical measurements that it's actually required (which I'm in the process of gathering; I've verified *a* delay is required but not the minimum, or whether it can be combined with the post-load nanosleep), along with evidence it doesn't break any existing platforms (I've found a datasheet reference to back that bit up, but tests are good too). Anyway, sorry I mis-interpreted the release your action applied to; I look forward to seeing the SRU land. In the meantime, rest assured a submission will be made upstream as soon as I think I've got a faint hope of it passing! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1903048 Title: [SRU] Bluetooth won't activate on the pi 400 Status in bluez package in Ubuntu: Triaged Status in bluez source package in Hirsute: Triaged 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1903048] Re: [SRU] Bluetooth won't activate on the pi 400
On Thu, Nov 12, 2020 at 11:11:23AM -, Sebastien Bacher wrote: >Sorry but I'm reverting that upload for now until the patches are >properly upstreamed. We have been bitten too often by unforwarded >changes that create issues or create maintainance burden over the years >and we currently don't have the team capacity to deal with extra cost. >If foundations would like to step up and take over bluez though that's a >discussion we could have... My apologies; I omitted to note in the patch that the Pi 400 is a certified platform, i.e. we're effectively committed to making it work as best we can, which makes the status of whether upstream accept the patches or not rather moot: If upstream say "yes" to the patches, without further discussion: that's great, but there'd presumably still be some delay before another version makes its way down to us, so we'd be applying *some* patch to make it work in the interim. If upstream say "with these changes" to the patches: again great, but in the interim, we'd again be applying *some* patch to make things work on a certified platform while working through changes upstream. If upstream say "not in a month of Sundays" to these patches: we'd be left carrying *some* patch, and we'd do it because it's a certified platform and we're committed to making it work. From our end user's perspective therefore, the application of this patch-set, whether via upstream or not, and whether in this form or not, is not a matter of "if", but "when". Given we have in our possession a patch-set that fixes the problem, I at least don't have a good answer to the hypothetical user's obvious follow-up question: "why not now?" Anyway, onto technical matters: >I'm not asking for the patches to be merged upstream but at least to be >sent there for review and have the appropriate tagging, it's easy to >unblock from your side. Also I would like to see if we can get for a >better way to probe for the system to be ready rather than relying on a >random sleep The following involves a certain amount of educated guessing. I haven't dug into this extensively, but I can offer some reasons for why sleep(1) is being used (and how this could be refined a bit, but not much): Consider the bcm43xx_load_firmware routine in hciattach_bcm43xx.c [1] which is being called prior to the apparently arbitrarily inserted sleep(1) line in the patch. It's a fairly typical firmware load routine by all accounts: 1. Calls write() with a command (0x2e 0xfc) to place the device into a state where it's read to receive new firmware 2. Calls read_hci_event() to check the device responded "okay!" 3. Calls nanosleep() to wait a short while (50ms) for the device to be ready 4. Calls read() and write() repeatedly to write the firmware blob from a file to the UART 5. Calls nanosleep() again to wait another short while (200ms) after the firmware load So the existing (pre-patch) firmware load routine already has a seemingly arbitrary post-firmware-load delay of 200ms. If we have a look at the BCM4334 datasheet [2], p.159 we can see "wait at least 150ms after [power on] before initiating SDIO accesses" (SDIO being one of several interfaces for this particular module). However, that's just for the BCM4334. There's also the BCM4330, BCM4329, and the Cypress 305 (on the Pi 400, which uses the BCM43xx interface; Cypress, incidentally, acquired Broadcom's wireless business which explains why their chips suddenly have Broadcom's interfaces). The bluez interface *could* presumably check precisely which device it was dealing with and adjust its post-firmware-load delay accordingly. Or it could simply go with a delay that's "long enough" to cover all the supported chipsets, and avoid all that logic (which appears to be what's favoured in the original code). Given it's a one-time setup delay, and it's likely to occur during boot-up (or system wake-up) when half a dozen other things are happening in parallel, it's unlikely the user will notice a difference between a 150ms, 200ms, or even 1.2s delay to their Bluetooth module becoming available. Hence one possibility for the sleep(1) delay is that the Cypress 305, being a later and more feature-rich device, requires a longer delay. I can't confirm that as I can't find the datasheet online; sadly, this isn't remotely surprising, but I could reasonably assume that the Pi Foundation *do* have access to it and thus the 1 second delay isn't *entirely* arbitrary. In some of the BCM43xx modules it does appear that the UART CTS line is asserted to indicate the device is "ready" (e.g. the BCM4330 datasheet mentions this under the Bluetooth PMU section). However, one of the configurations (not the default, but a supported configuration nonetheless) for the Bluetooth module on all Pi models is to be operated via the mini-UART instead of the PL011. The mini-UART, as noted previously, explicitly lacks any hardware flow-control ([3],
Re: [Touch-packages] [Bug 1903048] Re: [SRU] Bluetooth won't activate on the pi 400
I understand the logic of the of doing this and don't disagree. However, as this is an entry level device and I believe the only true 64bit O/S advertised for this device, the fact that it does not not work out of the box may impact on the perception of potential new Ubuntu users? Reading Tony's post the Mate website does not say it will work on the PI400 where as the Ubuntu site does. I think the main issue is that people think it is the same board as the Pi4 and it is not. Just my opinion. On Thu, 2020-11-12 at 11:11 +, Sebastien Bacher wrote: > Sorry but I'm reverting that upload for now until the patches are > properly upstreamed. We have been bitten too often by unforwarded > changes that create issues or create maintainance burden over the > years > and we currently don't have the team capacity to deal with extra > cost. > If foundations would like to step up and take over bluez though > that's a > discussion we could have... > > ** Changed in: bluez (Ubuntu Hirsute) >Status: Fix Released => Triaged > -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1903048 Title: [SRU] Bluetooth won't activate on the pi 400 Status in bluez package in Ubuntu: Triaged Status in bluez source package in Hirsute: Triaged 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1903048] Re: [SRU] Bluetooth won't activate on the pi 400
On Tue, Nov 10, 2020 at 03:12:30PM -, 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 Touch seeded packages, which is subscribed to bluez in Ubuntu. 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1903048] Re: [SRU] Bluetooth won't activate on the pi 400
Hi, I implemented the fix detailed in the test case yesterday and the bug still existed. I've double checked again this morning and done a full-upgrade just to check nothing new was waiting and the bug still exists on this Mate 20.10 install. Yesterday after applying the fix I started getting random "System problem detected, report this?" popups but none so far today. Blueman Applet is set as a startup item and both blueman-applet and blueman-tray appear as running processes but running blueman-manager or blueman-adapters from the command line both fail with the message 'Blueman applet needs to be running' The Bluetooth panel item isnt shown. OS: Ubuntu MATE 20.10 aarch64 Host: Raspberry Pi 400 Rev 1.0 Kernel: 5.8.0-1007-raspi Tony On 11/11/2020 04:32, Launchpad Bug Tracker wrote: > This bug was fixed in the package bluez - 5.55-0ubuntu2 > > --- > bluez (5.55-0ubuntu2) hirsute; urgency=medium > >* Added patches from the Raspberry Pi Foundation > - d/p/raspi-bcm43xx-load-firmware.patch > - d/p/raspi-bcm43xx-3wire.patch > - d/p/raspi-cypress-305-bdaddr.patch >* These patches fix Bluetooth operation on the Pi 400 (LP: #1903048) > > -- Dave Jones Thu, 05 Nov 2020 13:39:07 > + > > ** Changed in: bluez (Ubuntu Hirsute) > Status: Fix Committed => Fix Released > -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
