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.