I'm planning to release binaries for wasp-os once I've finished the M2 features. I recently got OTA bootloader updates working (*don't* play with this feature just yet if you have glued the back on). There are a couple of features I might delay until M3 but I definitely want to get the device to remember the current time through reset.
mcuboot is an excellent place to start from.
However I think the flash layout would be dramatically better if it took advantage of the SPI flash. Only code that will be executed need go in the internal flash (e.g. bootloader and active firmware image) everything else can be offloaded to the SPI flash which will more than double the maximum application size. In the current proposal, 232KB is way to small for a real application. I'm sure there is tuning and weightloss possible but some of the littlevgl firmwares are already 250K code size *excluding* the BT stack.
The other thing about the flash layout that would be worth considering is whether it can be made softdevice compatible. The softdevice is linked to run at 0x1000 so the bootloader partition would likely have to be split into a vector table at 0x0 and a main bootloader at the end of the flash).
Supporting softdevice is clearly not required to run the free software BLE stacks. However a universal bootloader isn't actually universal would mean having to write "reloader" applications to to nuke the universal bootloader and replace it with a softdevice bootloader and vice versa so that users can experiment with any softdevice firmwares that are available.
(05-02-2020, 08:13 PM)lupyuen Wrote: Also in the doc is a proposed Flash ROM Layout that I hope all PineTime Developers will adopt, to make it easy to switch firmware platforms.
Here's the work in progress:
https://lupyuen.github.io/pinetime-rust-...ticles/dfu
mcuboot is an excellent place to start from.
However I think the flash layout would be dramatically better if it took advantage of the SPI flash. Only code that will be executed need go in the internal flash (e.g. bootloader and active firmware image) everything else can be offloaded to the SPI flash which will more than double the maximum application size. In the current proposal, 232KB is way to small for a real application. I'm sure there is tuning and weightloss possible but some of the littlevgl firmwares are already 250K code size *excluding* the BT stack.
The other thing about the flash layout that would be worth considering is whether it can be made softdevice compatible. The softdevice is linked to run at 0x1000 so the bootloader partition would likely have to be split into a vector table at 0x0 and a main bootloader at the end of the flash).
Supporting softdevice is clearly not required to run the free software BLE stacks. However a universal bootloader isn't actually universal would mean having to write "reloader" applications to to nuke the universal bootloader and replace it with a softdevice bootloader and vice versa so that users can experiment with any softdevice firmwares that are available.