1324: Add MCO support for L4 and F4 families r=Dirbaio a=m-dupont
Add MCO support for L4 and F4 as already done in F7.
When the 'HSI' source is selected as MCO source, 'HSI' is activated (`set_hsion(true)`) . This is done to operate the MCO in case 'MSI' is chosen as the clock source for the CPU. The same applies to PLL, etc.
1327: Avoid write before erase r=Dirbaio a=rmja
This introduces an additional marker to the state partition right after the magic which indicates whether the current progress is valid or not. Validation in tests that we never write without an erase is added.
There is currently a FIXME in the FirmwareUpdater. Let me know if we should take the erase value as a parameter. I opened a feature request in embedded-storage to get this value in the trait. Before this, the assumption about ERASE_VALUE=0xFF was the same.
I have made some thoughts about whether this is a breaking change between the app and firmware, i.e. whether adding the "Progress valid" field is breaking. My conclusion is that it is not a breaking change. For the case where an app uses this new FirmwareUpdater together with an old bootloader, what it now does, is that it:
1. Writes the progress valid field to all zeros. This field is not known in the old bootloader, so it actually writes a "current progress" index.
2. The entire state partition is erased - effectively removing any trace of 1.
3. Set magic
This should be compatible.
Co-authored-by: Mathieu Dupont <mdupont@cppm.in2p3.fr>
Co-authored-by: Rasmus Melchior Jacobsen <rmja@laesoe.org>
This introduces an additional marker to the state partition right after the magic which indicates whether the current progress is valid or not. Validation in tests that we never write without an erase is added.
There is currently a FIXME in the FirmwareUpdater. Let me know if we should take the erase value as a parameter. I opened a feature request in embedded-storage to get this value in the trait. Before this, the assumption about ERASE_VALUE=0xFF was the same.
FirmwareWriter currently has a "max-write-size" parameter, but this is a limitation that should be handled by chunking inside the NorFlash driver, and not "up here" in user code. In case that the driver (e.g. qspi driver) is unaware of any max-write limitations, one could simply add an intermediate NorFlash adapter providing the chunk'ing capability.
This commit provides a method to verify that firmware has been signed with a private key given its public key. The implementation uses ed25519-dalek as the signature verifier. An "ed25519" feature is required to enable the functionality. When disabled (the default), calling the firmware updater's verify method will return a failure.
Fixes a bug in the partition assertions that ensures that the state
page(s) have enough space for 2x active partition range.
Add unit test to verify that panic is observed.
Compiler will infer a different lifetime for BootFlash than for the
borrowed flash, which makes it require more type annotations than if it
was just owning the type. Since it doesn't really matter if it owns or
borrows in practical use, change it to own so that it simplifies usage.
* Remove the need for generic const expressions and use buffers provided in the flash config.
* Extend embedded-storage traits to simplify generics.
* Document all public APIs
* Add toplevel README
* Expose AlignedBuffer type for convenience.
* Update examples
It currently contains whoever was first to write some code for the crate,
even if many more people have contributed to it later.
The field is "sort of" deprecated, it was made optional recently:
https://rust-lang.github.io/rfcs/3052-optional-authors-field.html
Due the the reasons listed there I believe removing it is better than
setting it to generic fluff like "The Embassy contributors".
* Less generics on bootloader. Keep PAGE_SIZE as a common multiple of
DFU and ACTIVE page sizes.
* Document restriction
* Add unit tests for different page sizes
* Add flash drivers for L0, L1, L4, WB and WL. Not tested for WB, but
should be similar to WL.
* Add embassy-boot-stm32 for bootloading on STM32.
* Add flash examples and bootloader examples
* Update stm32-data
* Add FlashProvider and FlashConfig traits to define flash
characteristics
* Use traits in bootloader to retrieve flash handles and for
copying data between flash instances
* Add convenience implementations for using a single flash instance.
Embassy-boot is a simple bootloader that works together with an
application to provide firmware update capabilities with a minimal risk.
The bootloader consists of a platform-independent part, which implements
the swap algorithm, and a platform-dependent part (currently only for
nRF) that provides addition functionality such as watchdog timers
softdevice support.
