feat(dfu_ble): add possibility to flash Pico W and nRF52840 via BLE - #998
feat(dfu_ble): add possibility to flash Pico W and nRF52840 via BLE#998Schievel1 wants to merge 1 commit into
Conversation
6378017 to
d5517f3
Compare
Size Report
|
b1c191a to
d580030
Compare
|
I'm not sure about the |
|
I understand, and I tried to use only the nRF tools in the first place as well. The problem is, unlike USB-DFU, DFU via bluetooth doesn't really have an industry standard and every company ships it's own. And they coin everything towards their own 'walled garden' of course. If we decide to keep bolt I will integrate it in RMK. As long as this PR is not ready and merged, I think it's better to wait with that. Maybe I need to change a thing or two in bolt still. |
Signed-off-by: Pascal Jäger <pascal.jaeger@leimstift.de>
|
If so, I'd like to create RMK's own bootloader + BLE OTA system, follow existing work. Maybe integrate it into the new Rynk system. |
|
Yes, this is what we are doing here I thought. Bolt as a CLI app is only the beginning. I want to add a GUI app and also a web application if possible. So you can build the firmware on a server and also flash it from there. |
|
Ah I agree! This is fully aligned with the goal of Rynk. It's designed to manage the keyboard from the host via CLI, GUI, etc. |
Overview
This adds firmware updates over the air for nRF52840 and Pico W.
We do this by utilizing the embassy-boot setup with ACTIVE and DFU partitions of the flash, we write new firmware into the DFU partitions during a running RMK firmware and after a reboot the embassy-boot bootloader swaps ACTIVE and DFU and then boots the new firmware.
It uses nrf_dfu_target for the protocol which is a Rust implementation of the Nordic nRF DFU protocol . This doesn't mean this PR is limited to nRF chips, I just wanted to use a battle tested and proven protocol instead of inventing my own.
This also means that it is possible to use some of nRF's tooling. I tested with the DFU app on my phone and it went smooth. (although my phones bluetooth chip seems to be very very slow) However, the problem with most of those tools is, that they expect the nrf mcuboot bootloader to be preset. They want to reboot the device into this bootloader to flash the firmware. We don't do that here, so every tool that is expecting the mcuboot bootloader to answer won't work. Some listen for a specific UUID and such. Only the sloppy tools, that don't care if they got the device into the bootloader, work. As you can imagine this is all very brittle.
So I made my own instead, B.O.L.T (Bluetooth OTA Loading Tool)
Bolt is using nrf_dfu_target to load firmware into the bootloader. It can also create zip files that the nRF DFU protocol expects from firmware files like
ELFand.bin. I will also create those zip files on the fly, so you can feed it.binfiles and evenELFfiles.If this PR goes well I would like to merge bolt into rmk at a later point.
Split keyboards
Normal keyboards and split keyboard's centrals just have an additional bluetooth service, bolt connects to them, sends firmware data, mark as updated for embassy-boot, device reboots, embassy-boot does the rest.
Split keyboard's peripherals don't advertise in bluetooth normally, so instead they have to be brought into "BLE DFU mode". They do so if they started up and cannot find their central for ten seconds. Then they start advertising as "$PRODUCT_NAME perN", where N is the number of the peripheral. So "My RMK Keyboard per0" for example.
They can then be flashed using bolt like the central and non split keyboards.
Security
Obviously this can be used to flash a keyboard without the user noticing. Keyboards still need to be paired with the host but with JustWorks pairing that doesn't require key input this is rather a inconvenience than an barrier.
It is rather unlikely this is a problem for you but if the feds are after you you shouldn't be using this. Maybe you shouldn't be using a quirky custom keyboard anyway.
However,
dfu_lockstill works for this, so if it's active the firmware can only be flashed when the keyboard is unlocked.To unlock you try to send the firmware once using bolt. Then the normal 10s unlock window opens. You press the keys to unlock, the LED (if configured) starts flashing D F U in Morse. The you have 10s to start another firmware send.
For added security, embassy-boot also supports compiling in your own public key and it then refuses to load any firmware that isn't signed by your private key. This is just a tip, I have no plans an implementing this, so you have to roll your own bootloader.
Speed
Speed wise this is at 6.5kb/s which could be better. I already switch to faster (more power hungry) bluetooth settings during the transmission of the firmware data. I think the flash writes themselves are the bottleneck now. Tips on how to speed this up are always welcome.
Effectively, with connection handshake and everything factored, in you can flash a typical 400kb firmware with this in about a minute.