bluetooth on rpi3 not supported in devuan
The built-in bluetooth on the rpi3 is not supported in devuan. I wish I could propose a solution. However, I've been playing with this for a week, and ending up where I started. So, I'll describe where I started and what I tried in the hope that we'll be able to resolve this as a group effort.
I initially started out by installing bluetooth, bluez, and bluez-firmware. I found that hciconfig just came back with the shell prompt, and bluetoothctl showed no available devices.
Next, I did some research, and came up with this: https://github.com/raspberrypi/linux/issues/1314 Based on the discussion at the above URL, I grabbed the bluez sources from devuan (apt-get source bluez), grabbed raspbian's bluez source: http://archive.raspberrypi.org/debian/pool/main/b/bluez/ and applied debian/patches 0050-0053 from that to devuan's bluez source, which all applied cleanly and without issues. I had to play with debian/rules next to disable the systemd portions, but was eventually able to build the debs, bluetooth and bluez specifically, and install them.
Next, I grabbed /lib/firmware/BCM43430A1.hcd from raspbian's image, and got this:
root@devuan:~# hciattach /dev/ttyAMA0 bcm43xx 921600 noflow bcm43xx_init Flash firmware /lib/firmware/BCM43430A1.hcd Failed to load firmware, invalid HCI event Can't initialize device: Success root@devuan:~#
I halted the rpi, and tried again with 115200 baud, but same thing. Wondering if I maybe had a defective board, I wrote raspbian to my sd card, and booted up. I was able to run hciconfig literally out of the box, and saw the bluetooth adapter was indeed working. I ran systemctl disable hciuart, and halted the rpi. I brought it up, and just got back the shell prompt when running hciconfig, as I expected. I then ran hciattach by hand just as above with 921600 baud, the firmware was flashed without problems, and hciconfig listed the bluetooth adapter again.
Thinking I might be dealing with arm64 as the issue, I next wrote the devuan armhf image to my sd card, and built bluez and bluetooth packages for that. I copied the firmware into place, and got the same output as above on devuan arm64. Wondering if the issue may be specific to the way I built my hciattach, I copied hciattach from raspbian to my armhf devuan install, and tried using it, with the same results as the above output, so the problem wasn't with my build of hciattach.
I wanted to track down the source of the BCM43430A1.hcd firmware, so did some research. It turns out that it's a part of raspbian's bluez-firmware package: http://archive.raspberrypi.org/debian/pool/main/b/bluez-firmware/ So, I removed devuan's bluez-firmware package, moved BCM43430A1.hcd which I copied earlier to /lib/firmware out of the way, and installed raspbian's bluez-firmware since it is arch independent, and doesn't depend on systemd. I power cycled the rpi as before, and ran hciattach as before. The output I got back was the same is in my previous attempts on devuan.
Finally, I had a look at devuan's and raspbian's /proc/config.gz The kernel configuration regarding bluetooth is the same on both kernels as far as I could tell. The only other thing I haven't yet tried is to run the devuan armhf image but with raspbian's firmware and kernel.
It looks like the problem is happening as hciattach attempts to flash the firmware, possibly right when it tries to set the baud rate after the flash. Someone on the issue I mentioned at git.raspberrypi.org reported having that issue, but didn't mention what was specifically causing it, or how he/she got around it. The only other thing that comes to mind is that raspbian and fedora (mentioned in the above issue) are running systemd, I don't know if openrt does as well. There's something that systemd may be doing here that I'm not aware of. I do know it softlinks ttyAMA0 to /dev/serial1, and ttyS0 to /dev/serial0 in raspbian, but beyond that ... I did have a look at raspbian's /lib/systemd/system/hciuart.service. All that does is runs hciattach after a sanity check. I have also verified that nothing is using /dev/ttyAMA0, and removed console=serial0 entirely from my /boot/cmdline.txt. I'm open to ideas on what else to check for, because my list of ideas is exhausted at this point.
-
I just got the idea to look at hciattach_bcm43xx.c in the patched bluez source. Looks like the error I'm getting is when hciattach tries to put the bluetooth modem into download mode, and fails to get a response. So this happens even before hciattach starts flashing the firmware.
-
Seems my posting this opened the idea flood gates. I just got the idea to set enable_uart=1 in /boot/config.txt, and plug in my pl2303 cable. I tried setting enable_uart=1 in config.txt before, but didn't plug the pl2303 cable in that time. When I have enable_uart=1 in config.txt and my pl2303 cable pluged in, running hciattach does the job. It flashes the firmware, and I can run hciconfig and see the bluetooth adapter. This is clearly a conflict of some sort between the hardware and software uart. Now that I know the cause, I'll try digging deeper to get to the bottom of this. Stay tuned, and suggestions are still very much welcome.
-
Ok, the solution to the problem with hciattach failing was right under my nose! Turns out that at the very bottom of /etc/inittab, there was a getty being spawned on ttyAMA0. No wonder hciattach couldn't flash the firmware! I thought I had that commented out, but between writing images back and forth to my sd card, I must have written a devuan image where I didn't have that commented out.
So, to recap, here's what's needed to get the built-in bluetooth going on the rpi3. On arm64, the bluez package needs to have patch 0050/0053 applied from raspbian's package. At the very least, /lib/firmware/BCM43430A1.hcd needs to exist. I would actually recommend patching bluez-firmware with raspbian's patches. I tried installing raspbian's bluez, bluetooth, and bluetoothfirmware when running the armhf devuan image, and they installed without complaining about systemd being missing. So for armhf, I think we could actually just install raspbian's package directly, and either write a sysv init script to run hciattach at start, or just run it from rc.local.
I would also highly recommend adopting raspbian's /etc/udev/rules.d/99com.rules from raspberrypi-sys-mods http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-sys-mods/ That's what creates /dev/serial0 and /dev/serial1 links. The serial0 will always point to the console, and serial1 will always point at the bluetooth modem if running on a rpi3. This is still true even if the overlay putting the bluetooth on the mini uart is being used as far as I can tell. Once bluetooth/bluez/bluez-firmware with raspbian's patches can be gotten from devuan's archives, I think this issue can be closed.
-
This bug needs to be split up into it's respective parts relating to each package effected.
-
How do I do that? I just did a search for bluez and bluez-firmware, but didn't come up with results for those projects on gitlab. If we're simply installing debian's packages for bluez and bluez-firmware (which I suspect we are), then this will mean importing raspbian's patches (or their entire modified source), and compiling for arm64. What's the procedure for doing that? As far as armhf, installing raspbian's packages directly seems to be fine for now.
-
Another possibility on arm64 is to add armhf through dpkg --add-architecture, and simply install raspbian's armhf packages. I assume that would work. That's not an optimal solution, but it would make things a lot easier.
-
@gregn : we haven't had a reason to fork those packages yet but can do. I think we'd have to look at how to integrate raspbians patches rather then use their sourcecode as we build for all architectures from a single source tree. So if the fixes only need to be applied to the arm versions, then we need to do that in a way that doesn't break the other architectures. I'll probably look at it after the jessie release but if you want to have a crack at this yourself see https://talk.devuan.org/t/os-documentation-how-to-package-for-devuan/568/10 and https://talk.devuan.org/t/os-documentation-how-to-package-for-devuan/568/14 will get you started. If the VCS for those projects is not git, then let me know and I'll give you a hand on starting those.
-
mentioned in issue #4 (closed)
-
I have separated this issue into the following bugs: https://bugs.devuan.org/db/85/85.html https://bugs.devuan.org/db/86/86.html https://bugs.devuan.org/db/87/87.html Should this issue be closed?
-
I shall close this and attend to the bugs reported on the tracker.
-
closed
