It seems as if the arm compiler can does not care about whether the bootloader symbols are undefined if the default() function is never used. The x64 compiler does care however, so this change ensures that we can instantiate the types from tests.
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.
