Bluetooth Problem #29
Comments
|
@peterychuang The question is far from stupid: you're quite right, this looks very much like SPI stuff and it looks like it would benefit from the generic apple-properties work @l1k has done. However, on closer examination it turns out the issue is not the missing acpi serial-bus resource, but the missing interrupt information: there's neither an interrupt-resource in the _CRS, nor is there a _GPE name like there is for the SPI device, and hence we get these In fact, I can't find any interrupt info whatsoever for the bluetooth device in the DSDT. So the first thing to get bluetooth running is to figure out what interrupt it uses. After that, we'll need some small patches to set the oper_speed from the baud apple property, and probably something to call the power-down, power-up, etc acpi methods appropriately (however, I know next to nothing about bluetooth and their drivers in Linux, so take this with a large grain of salt). |
|
Yes I did mention in the commit message of l1k/linux@9ae5c93 that it'll be needed for Bluetooth as well. :-) Looking at the schematics of the MacBook8,1 I can't find a Bluetooth interrupt pin and apparently none is needed. A quick Google search turns up this: To a host system, the UART appears as an 8-bit input and output port that it can read from and write to. Whenever the host has data to be sent, it just sends these data to the UART in byte format (8-bit wide), whenever the UART receives data from another serial device it will buffer these data in its FIFO (again 8-bit wide), then it will indicate the availability of these data to the host through an internal register bit, or through a hardware interrupt signal. So the interrupt is coming from the UART on behalf of the Bluetooth device once data is received into the FIFO. What's much more interesting are the power management methods which could be used to extend battery life:
The MBP13,3 has an additional |
|
Ah looking at The Actually this looks fairly straightforward. |
|
Ah, silly me, didn't actually look at who was using the interrupt for what. Ok, that indeed simplifies things then. Regarding sleep and wakeup, the DSDT seems to indicate that BTLP should be called for both, at least on Windows: This seems a bit odd, though: I (probably naïvely) would expect the runtime PM ( And yes, I haven't been able to figure out what the BTRB method is supposed to be for either. |
|
I guess BTLP puts the device in a low power state and enables wakeup. Based on the DSDT snippet you included above it seems Apple also wants this to work in sleep state S3, e.g. to wake the system upon key press on a Bluetooth keyboard. Makes sense to me. For some reason BTLP is not called in the DSDT of the MacBook8,1, this might be a bug. In any case |
|
In my machine (14,1), I actually can't find the In case this helps, this is (maybe) all the bluetooth related stuff from DSDT in my machine. |
|
The behaviours seem to be a bit all over the map, then: Looking at MacBook8,1 and MacBook9,1 DSDT's I see that _PTS and _WAK call BTPD and BTPU on the 8, respectively, but on the 9 there are no calls to bluetooth there at all, like on the 14,1. @l1k I'm slightly confused by your 2nd paragraph about |
|
Sorry for not being clear, let me try again. :-) The combined WiFi/BT chip on these machines has 3 GPIO pins of interest for BT power management: power enable (toggled by BTPU/BTPD), device wake (toggled by BTLP, active low) and host wake (going out of the chip and into the SMC for system wake). I meant to say The driver seems to do the right thing by enabling device wake both for runtime suspend as well as system sleep, I wouldn't worry too much about presence or nonpresence of BTLP in _PTS and _WAK. It's possible that they're invoking it from their Bootcamp driver on newer models, or they just forgot to enable BT power saving on Windows. So all that's needed is to search for the BTPU/BTPD/BTLP methods in the ->probe hook if x86_apple_machine is true, cache them in And perhaps it's also necessary to fetch device properties and adjust baud rate etc. Let me know if my answer is still too cryptic. :-) |
|
Thanks for the elaboration. Ok, so that basically matches my thinking. |
|
I don't know if anyone has started working on this, but in case noone has I've cooked up this branch. Top-most commit adds support for Apple's Bluetooth ACPI methods, the three preceding commits are from the spi_properties material queued for 4.14. Perhaps someone can test if this works, I don't have one of the affected machines. Thanks. |
|
@l1k: I tried out your patch, but it still doesn't work. In fact it doesn't look different to the behavior before, printing the same error messages @roadrunner2 mentioned above. Any idea how to debug this? |
|
@l1k I can confirm the patch doesn't work. Below is part of the Edit: some additional error messages while running |
|
@Dunedan @peterychuang: Thanks for testing, looking at the code with a fresh pair of eyeballs I noticed that I had botched the return code of |
|
@l1k unfortunately it's still not working. Here are the error messages, including the new debug messages from your last commit: The |
|
@peterychuang: Looks good! The BTW I notice that the baud rate (3000000) was already reported by |
|
Lest I forget, for the folks with a MacBook8,1: There's a peculiarity on that machine where the UART0 is attached not only to the Bluetooth controller, but also to a debug serial port on the SSD. There's a mux to switch the UART lines between the two, controlled by GPIO36 on the PCH. There is no ACPI method to control this pin directly. I assume it's set by the BIOS but there's a possibility that this GPIO needs to be toggled before Bluetooth will work. This oddity is not present in the MBP13,3 ACPI dump. I don't have any others for these newer machines. |
|
I just tried the patch on a MBP13,1 and the platform error is gone. /sys/class/bluetooth is still empty though. I added my DSDT in #30 if that's any help. |
|
@l1k At the moment, I'm not sure. On the surface, the behaviour of the the machine remains more or less unchanged, though I guess we're on the right track. |
|
I had tried something like this a week ago (well, just disabled the check that caused the error) and also found that |
|
|
|
dmesg output from MacBook9,1 [root@mac ~]# btattach --bredr /dev/ttyS5 -P bcm it's failing on this function in hci_bcm.c : if you drill down a bit, the function it's actually failing on is the HCI reset function defined in btbcm.c **the purpose of this function is to switch the controller into full HCI mode |
|
I took another stab at this and got it mostly working, at least on my laptop - see l1k/linux#1. In addition to the above kernel patches, I am using the following patch (this assumes you have the systemd --- /usr/libexec/bluetooth/btattach-bcm-service.sh.orig 2017-09-12 07:27:30.000000000 -0700
+++ /usr/libexec/bluetooth/btattach-bcm-service.sh 2017-09-22 21:20:17.616533796 -0700
@@ -15,6 +15,12 @@
BT_DEV="$(readlink -f $BT_DEV)"
UART_DEV="$(dirname $BT_DEV)"
+# Handle intel-lpss UART devices
+DW_DEV=$(ls -d "$UART_DEV"/dw-apb-uart.* 2>/dev/null)
+if [[ -d "$DW_DEV" ]] ; then
+ UART_DEV="$DW_DEV"
+fi
+
# Stupid GPD-pocket has USB BT with id 0000:0000, but still claims to have
# an uart attached bt
if [ "$1" = "BCM2E7E:00" ] && lsusb | grep -q "ID 0000:0000"; thenWith this the bluetooth device is automatically attached on boot, and can be manually attached/detached via Of course, already noted by @leifliddy above, you can also just run this command: @leifliddy The reason for the timeout (-110 is -ETIMEDOUT) is the wrong baudrate being used, which is fixed by the 2nd commit in my pull request. Lastly, some issues I noticed so far:
|
|
@roadrunner2 To which kernel version am I supposed to apply the patches? I think because I am playing with linux-next, the patches aren't working just yet. |
|
@peterychuang The patches are on top of https://github.com/l1k/linux/tree/hci_bcm, which is based on 4.13.0-rc4. |
|
@christophgysin thanks. I've made some changes to this commit in order to apply it to linux-next, then I applied the patches by @roadrunner2. I guess I've done something wrong somewhere. |
|
@peterychuang, @christophgysin: I've been testing on 4.13.2 and 4.13.3. I also just pushed a hci_bcm-4.13 branch (currently based on v4.13.3) to make it easier to pull. There have been a few small changes in 4.14 which may affect these patches, besides the fact that the first three in the set from @l1k are not necessary (they are backporting the properties work that is now part of 4.14). I'm looking into redoing the patches for 4.14 and will push another branch when done. |
|
great work roadrunner2!!! It's working!!!! dmesg output from MacBook9,1 (running kernel 4.14-rc1 with l1k's and roadrunner2's bluetooth patches applied) If I unattach and reattach the bluetooth device. this error disappears: my bluetooth manager (blueberry --based on gnome-bluetooth) can now pair my bluetooth mouse + speaker without issue!! I'm experiencing the same audio stuttering issue while the bluetooth setting window is open. hciconfig doesn't show the controller for some reason |
|
I built and tested 4.14-rc2, and pushed as the hci_bcm-4.14 branch. Other than resolving some conflicts, nothing really needed changing. @peterychuang, I suggest resetting your tree and cherry-picking the last 6 commits (v4.14-rc..hci_bcm-4.14). If that still doesn't work, then we'll need at least to see the dmesg output from when you run @leifliddy Thanks for testing and feedback. Interesting that you don't see the DMA errors - which chipset exactly provides UART on your MB? ( Lastly, previous to your edit you were talking about firmware loading: I've been ignoring that so far, but I don't really know if there's anything critical there. |
|
thanks @roadrunner2, unfortunately it isn't working. The strange thing in linux-next, both with and without the patches, is that in I would think something like With the patches, If I run Perhaps I have unknowingly done something wrong when I compile the kernel, or perhaps the 2017 machines are slightly different. I haven't got time to investigate it yet. |
|
@peterychuang Maybe you are missing |
|
Thank you for the quick reply, @christophgysin ! At least getting further in now...getting these make errors at the end of the script: Looks like hci_uart.ko is not getting made due to "no rule to make target 'modules'"? |
|
Looks like you also need to install kernel headers: |
|
@christophgysin you are the man! My bad for not installing the kernal headers package in the first place as instructed originally by @leifliddy in his README. As there were no ARCHLinux instructions I stupidly ignored that part. So for ARCH we do:
and
With all the correct packages installed, the script works like a charm, bluetooth works! Thank you very much for the script @leifliddy, and thank you @christophgysin for being patient and responsive with a newbie. All the best! |
|
Please don't use this thread to discuss Linux distribution specific issues. This issue is about upstreaming Bluetooth support (as well as the whole project is about upstreaming hardware support). |
|
Something changed w/ kernel 5.5.x kernel 5.5.x kernel 5.4.x I'm not sure what changed, possibly something w/ the serdev or the 8250 driver.... |
|
commit 33364d63c75d is the cause for the breakage in 5.5. I've already submitted a patch - however, it looks like the kernel devs want more extensive cleanups first, and I don't know how long it'll take me to A) understand exactly what they want, and B) implement it, so it might take a bit before the patch is accepted and makes it into the stable tree(s) 😞 . |
|
I'm glad you're on top of this : ) It sucks that the root of this issue is Apple's non-conformance to established standards. It looks like Andy's patch will establish the framework for adding these sorts of quirks in a non-intrusive way. Hopefully, it gets accepted... |
|
The patch has made its way into 5.5.9 and 5.6-rc5 now, so your distro's next kernel update should get bluetooth working again. |
|
Hello again, gents - have done a reinstall and just tried to install this patch again, on my 2016 13,1 machine, it gave the same make error: Here is my relevant dmesg: I have all the latest headers, and am on 5.5.13-arch2-1 Sorry to beat a dead horse if I'm being an idiot. |
|
you have to create the |
|
Ok, but my path has arch2-1. not arch1-1:
Should I just create the arch1-1 path that the script wants or does the script need tweaking to point to the arch2-1 directory? |
|
It should match whatever's in your How is your |
|
If I am determining your script correctly: |
|
That's not the |
|
Ok, this is getting weird now. [dlg@gnuMBP131 bluetooth-5.5.13]$ cat Makefile But - this: uname -r So why do I have something else (5.5.13-arch2-1) in my /lib/modules ?? |
|
Normally |
|
Looks to me like he installed a new kernel and didn't boot it. |
|
Ok, I will look into it. Thanks for your time and help. Here's the latest linux headers: @DarkerMatter - you may be a genius for pointing out an obvious possibility! Be right back... |
|
....and it worked.... Thank you @DarkerMatter for your quick but insightful contribution, and thank you @leifliddy for helping. For future reference, should I be bringing script error messages somewhere else for help? It seems like this was just a discussion about how to get the script to run on my particular setup... |
|
This isn't a great question, but I want to know how to apply this patch. I don't really have wired earbuds anymore, and this is the only thing stopping me from using Linux a ton (storage, sound, etc are no longer issues). |
Did your find patch and how to apply it? I have same problem, and its also onсe moment that prevent migration to manjaro.. |
Have you tried https://github.com/leifliddy/macbook12-bluetooth-driver ? |
|
https://github.com/leifliddy/macbook12-bluetooth-driver worked perfectly for my MBP13,1. Thanks @leifliddy! |
|
uname -r -> 5.11.0-40-generic ubuntu 20 on macbook r12 early 2015 ..... contents of /lib/modules/5.11.0-40-generic/updates Any advice welcome . |
|
That question has already been answered here along with an explanation of why I'm not updating the installer script to accommodate this. leifliddy/macbook12-bluetooth-driver#15 You'll need install it like this until your Debian-based OS updates their kernel to 5.11.3 |
and others
So I was poking around the Bluetooth, and I noticed that the DSDT contains this:
This might be a stupid question, but isn't this bit the same as the SPI stuff that used to require patching to get the keyboard and touchpad working?
The text was updated successfully, but these errors were encountered: