Now that I have written up most of our proposed plan for flashing PineTime over Bluetooth (a.k.a. DFU)...
https://lupyuen.github.io/pinetime-rust-...ticles/dfu
...I realise that DFU may be difficult to implement across all PineTime firmwares.
(1) For Mynewt, Zephyr, RIOT and FreeRTOS: DFU seems easier to implement because they are already supported by NimBLE and MCUBoot.
(2) For other firmwares: Porting NimBLE and MCUBoot may be a challenge. Especially unusual ones like Rust Embedded and Tock OS.
Can we support DFU for (2)? Possibly...
(a) We shall support Firmware Rollback (according to the proposed design). And assume that we shall store the Standby Firmware in External SPI Flash (instead of hogging up precious Internal Flash).
(b) We shall also allow the user to initiate a Firmware Rollback manually. Say, by pressing and holding the watch button for 5 seconds when the watch boots up. (MCUBoot will wait 5 seconds before starting the watch firmware)
© Assume that PineTime will be shipped with a firmware that supports the standard DFU described in my article. Could be Mynewt, Zephyr, RIOT, FreeRTOS, ...
(d) If the user wishes to install another firmware, say, Tock OS, just do it with DFU. PineTime already supports DFU out of the box.
(e) What if the user decides to upgrade Tock OS? Or switch to another firmware? Solution: The user manually initiates Firmware Rollback: Press and hold the watch button for 5 seconds while it reboots.
(f) MCUBoot recovers the factory-installed firmware (because of the rollback). PineTime now supports DFU again, ready to be flashed via Bluetooth.
Yes this scheme sounds cumbersome, but it means we can support some kind of DFU for ANY firmware without having to port NimBLE. As long as the firmware satisfies these conditions...
(1) The firmware must occupy ROM address 0x8000 onwards (It shouldn't use addresses below 0x8000)
(2) The firmware must not modify the Standby Firmware Image in External SPI Flash
(3) The firmware should contain a 32-byte Image Header (described in my article). So that MCUBoot knows how to swap the firmware with the factory-shipped one.
Should we do this? Is there a better way? Please lemme know thanks [emoji3]
Sent from my Pixel 4 XL using Tapatalk
https://lupyuen.github.io/pinetime-rust-...ticles/dfu
...I realise that DFU may be difficult to implement across all PineTime firmwares.
(1) For Mynewt, Zephyr, RIOT and FreeRTOS: DFU seems easier to implement because they are already supported by NimBLE and MCUBoot.
(2) For other firmwares: Porting NimBLE and MCUBoot may be a challenge. Especially unusual ones like Rust Embedded and Tock OS.
Can we support DFU for (2)? Possibly...
(a) We shall support Firmware Rollback (according to the proposed design). And assume that we shall store the Standby Firmware in External SPI Flash (instead of hogging up precious Internal Flash).
(b) We shall also allow the user to initiate a Firmware Rollback manually. Say, by pressing and holding the watch button for 5 seconds when the watch boots up. (MCUBoot will wait 5 seconds before starting the watch firmware)
© Assume that PineTime will be shipped with a firmware that supports the standard DFU described in my article. Could be Mynewt, Zephyr, RIOT, FreeRTOS, ...
(d) If the user wishes to install another firmware, say, Tock OS, just do it with DFU. PineTime already supports DFU out of the box.
(e) What if the user decides to upgrade Tock OS? Or switch to another firmware? Solution: The user manually initiates Firmware Rollback: Press and hold the watch button for 5 seconds while it reboots.
(f) MCUBoot recovers the factory-installed firmware (because of the rollback). PineTime now supports DFU again, ready to be flashed via Bluetooth.
Yes this scheme sounds cumbersome, but it means we can support some kind of DFU for ANY firmware without having to port NimBLE. As long as the firmware satisfies these conditions...
(1) The firmware must occupy ROM address 0x8000 onwards (It shouldn't use addresses below 0x8000)
(2) The firmware must not modify the Standby Firmware Image in External SPI Flash
(3) The firmware should contain a 32-byte Image Header (described in my article). So that MCUBoot knows how to swap the firmware with the factory-shipped one.
Should we do this? Is there a better way? Please lemme know thanks [emoji3]
Sent from my Pixel 4 XL using Tapatalk
