1323: Add hash functions to FirmwareUpdater r=Dirbaio a=rmja
This adds support for computing any hash over the update in the dtu area by providing a closure to the hash update function.
Co-authored-by: Rasmus Melchior Jacobsen <rmja@laesoe.org>
The internal channels (vbat, vref, and temperature) are not real pins and do
not have the `set_as_analog` method. They must be read using the
`read_internal` method.
1297: feat(stm32): Support multiple flash regions r=Dirbaio a=rmja
This depends on https://github.com/embassy-rs/stm32-data/pull/176
This is a general overhaul of the flash module to support multiple erase sizes.
Overall this PR contains:
* Move complex sector computation to embassy-hal-common to allow for tests
* Implement `FlashRegion` trait for each available flash region
* Add Flash::into_regions() to get each region.
* Implement embedded-storage traits for each region to support different erase sizes
* Split family write operations into begin/do/end
* Protection against simultaneous writes/erases for each split region is done through a global mutex
Co-authored-by: Rasmus Melchior Jacobsen <rmja@laesoe.org>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
1329: Reduce bootloader memory usage r=rmja a=rmja
By not requiring that the provided buffer must be able to contain one "erase-size" bytes.
This PR is the successor of #1314 and replaces it entirely.
Co-authored-by: Rasmus Melchior Jacobsen <rmja@laesoe.org>
1321: executor: add Pender, rework Cargo features. r=Dirbaio a=Dirbaio
This introduces a `Pender` struct with enum cases for thread-mode, interrupt-mode and
custom callback executors. This avoids calls through function pointers when using only
the thread or interrupt executors. Faster, and friendlier to `cargo-call-stack`.
`embassy-executor` now has `arch-xxx` Cargo features to select the arch and to enable
the builtin executors (thread and interrupt).
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
1313: (embassy-stm32): rework bufferedUart to get rid of PeripheralMutex r=Dirbaio a=MathiasKoch
New implementation is very similar to the implementation of embassy-nrf & embassy-rp.
Also adds embedded-hal traits to bufferedUart.
**NB**: Still needs testing on actual hardware
Co-authored-by: Mathias <mk@blackbird.online>
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>
1328: Expose read/write/erase on partition r=Dirbaio a=rmja
This is needed now where FirmwareWriter is removed.
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.
