-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upload firmware to module #21
Comments
Hi @fhuneth! Thank you for the information provided in this issue. I am currently interested in the possibility of
Unfortunately the link isn't available yet and I tried to get an archived snapshot but there isn't anyone available (Wayback Machine is resumed 😢).
Excuse me if I paraphrase you, it is to know if I am understanding you correctly. Linux figures out the required firmware to load automatically depending of the system, so I understand it does the same in the case of a Nerves system. But it seems sometimes it doesn't work in the case of a Nerves system so to not depend on Linux, this issue is to try to implement a way that could be handled by Nerves, automatically in the startup pipeline or manually using I could try to research a bit more about this issue if in the current project in which I am working still want to use Nerves and/or a Raspberry Pi 4 CM after I report them the state of the art of bluetooth in Nerves. Thanks in advance for your attention and for all your contributions to Elixir/Nerves ecosystem ❤️ . |
I know it has been many years since this issue and since you read this link but, do you remember if the link was the same than the one I paste below? At least date matches ("Jul 10, 2019" and the last part of the URL is similar. |
Currently,
blue_heron
relies on the Bluetooth module having working firmware on boot or on side effects from desktop Linux kernel modules loading firmware. Since the goal is to work without assistance from the Linux kernel's Bluetooth stack, it needs to be able to upload firmware too.Bluetooth module firmware seems to universally be distributed as
.hcd
files. These files are effectively scripts containing HCI commands. Each HCI command should be sent to the module andblue_heron
should wait for an acknowledgment. It's probably fine to have multiple commands in flight to improve performance if that is an issue. Note that the C code has a limit of 4 commands in flight at a time. That could be changed.Some more information is at https://community.cypress.com/community/software-forums/wiced-studio-bluetooth/wiced-studio-bluetooth-forums/blog/2019/07/10/cypress-bluetooth-soc-programming.
As you can see here, https://github.com/LibreELEC/brcmfmac_sdio-firmware-rpi/tree/master/firmware/brcm,
.hcd
files are named based on the module. Somehow Linux figures out the name automatically. I assume that there's some HCI command or something that gives the name to use, but I don't know. I believe, but don't know for sure, that the other files from that link are completely handled by the WiFi driver and that we can ignore them forblue_heron
.The text was updated successfully, but these errors were encountered: