On Fri, Mar 15, 2019 at 05:21:55PM +0000, Christopher Brand wrote:
There are efforts underway to get the TF-M changes to the bootloader contributed back to the upstream MCUboot project.
Is there a timeframe for this?
Not really. At this point, there are tests that demonstrate corruption if the power is interrupted during the update, and these will have to be address. These problems are likely in the code that is in TF-M as well, that code has just never been tested in the MCUboot simulator (which tests untimely powerdowns at all windows).
We should be trying to make sure that we continue this effort, as well as to make sure that any efforts to extend the bootloader are done upstream, and not in the TF-M-specific branch.
Ultimately, this is a single additional call into platform-specific code to start the non-secure CPU (the other changes will be in the early secure and non-secure TF-M code), so it's a small change. Seems to me that it makes sense to coordinate it with the upstreaming of the MCUboot changes - if the TF-M changes have already been merged into the upstream MCUboot project by the time the twin CPU support is merged then I'm happy to push this change there separately. If they haven't, then this change should be included with the other TF-M changes to MCUboot. Does that make sense?
However, I have a deeper concern: why is this being done by the bootloader, at all? The bootloader has no awareness of the MPUs. I would expect the non-secure image to be started after the secure image has finished setting up the MPUs.
Adding MPU support is definitely beyond scope of what MCUboot should be doing. This code is immutable, and should have no code that doesn't absolutely have to be present.
David