I recently discovered that it was possible to build Debian Jessie for the Intel Edison using the official BSP sources, so I followed the instructions from here: https://jakehewitt.github.io/custom-edison-image/ Building a Custom Debian Image for the Intel Edison and actually ended up with a bootable, functional image. However, I can't seem to get Bluetooth working correctly.
After surfing the net and trying various solutions such as using rfkill to unblock the bluetooth device, apt-get install'ing bluetooth and bluez-firmware, it still doesn't work. Specifically, running hcitool dev which should ordinarily display a list of local bluetooth adapters shows nothing. Any command issued within a bluetoothctl session states that no default controller is found. Rfkill list shows the WiFi and Bluetooth radios (the latter which is currently hardware and software unblocked), but still doesn't show a hci0 device which, as I understand it, is necessary to get anything bluetooth actually working.
Can anyone help with this please?
I will try to help you. Ubilinux support is handled by Emutex and they own its support. I suggest you to contact them ( https://emutex.com/about-us/contact-us) in order to get a more accurate response for Ubilinux.
In case you are interested in using the official Yocto image, you can find information about its Bluetooth interface in the following document:
I hope this is helpful.
Thanks for the response. I'm not actually using Ubilinux - this Debian Jessie distribution is being built by a script within the Edison BSP itself. I'm currently trying to avoid using Yocto if I can help it. That said, that document seems to have highlighted my problem. As stated in the document:
"Since the Bluetooth* controller connects to the UART, hciattach does not launch automatically, even after starting
Bluetooth* with rfkill. To support the functionalities of hciattach, the Intel® Edison image has a built-in service
called Bluetooth_rfkill_event that starts at bootup and runs in the background, listening for Bluetooth* interface
rfkill events. If Bluetooth_rfkill_event identifies an event intended for BCM43340, it calls the Broadcom download
utility, which does the same job as hciattach (along with some Broadcom-specific functions). Whenever you are
enabling or testing Bluetooth* functionality, make sure Bluetooth_rfkill_event is running in the background"
However, the Debian rootfs being built apparently does not include this Bluetooth_rfkill_event or the Broadcom download utility. This thread: /thread/57254 Bluetooth ubilinux also sheds some light on the problem and seems to provide a functional workaround. I will test it out and report my findings back here.
Thanks alot for the tip!
Sorry, I thought you were using Ubilinux. Please keep us aware of your findings, they might be of help for other users. Anyhow, please be aware that since you are not using the official Yocto image we might not be of much help as other OS are not supported on this community but we'll do our best to help you.
No worries. After following the instructions in that thread, I obtained a hci0 device instance and the associated tools (hciconfig, hcitool, bluetoothctl, etc) now function as expected. Specifically, there is a program called brcm_patchram_plus included in Yocto, which downloads firmware to the Bluetooth radio over the UART interface called /tty/MFD0. It is normally triggered by another program called bluetooth_rfkill_event, which is triggered by rfkill unblocking the Bluetooth radio. On the Debian image, these binaries do not exist. To get the hci0 interface, one simply needs to find some way to download the firmware to the radio. From that forum post, the necessary files were provided - all that is really needed is the brcm_patchram_plus file and the firmware file, called bcm43341.hcd (which was sadly not uploaded, but which I obtained separately from here: https://github.com/LGSInnovations/edison-yocto-image/blob/master/edison-image-edison-ext4/etc/firmwa... edison-yocto-image/bcm43341.hcd at master · LGSInnovations/edison-yocto-image · GitHub
Once that was done, all that was necessary was to run the brcm_patchram_plus binary (need to make it executable first - chmod u+x ...) as follows:
sudo ./brcm_patchram_plus --use_baudrate_for_download --no2bytes --enable_lpm --enable_hci --baudrate 3000000 --patchram /dev/ttyMFD0 &
In my particular case, the .hcd file was placed in the same directory as the binary, so my invocation looked like this:
sudo ./brcm_patchram_plus --use_baudrate_for_download --no2bytes --enable_lpm --enable_hci --baudrate 3000000 --patchram ./bcm43341.hcd /dev/ttyMFD0 &
And a sudo rfkill list should display a hci0 device.
When this is done for the first time, the hci0 device may be shown as being blocked. rfkill must be used to unblock all bluetooth devices once again, as follows:
sudo rfkill unblock bluetooth
This should not be necessary for subsequent invocations of the brcm_patchram_plus binary. Hence, after running brcm_patchram_plus subsequent times, running sudo rfkill list should always show the hci0 device as being hard and soft unblocked.
For purposes of ease, it'd probably best to add this invocation to the startup process, perhaps by writing a systemd unit file to do this, as well as place the firmware file in a more standard location, like /lib/firmware or /etc/firmware
Thanks Peter, you're awesome!!