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: 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.
1 of 1 people found this helpful
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: 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 <path to .hcd file> /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!!
Thanks a lot for sharing this information with the community, it will be of much help for other users that decide to use Debian on their boards.
I hope we see you again in the community!