On Thu, Mar 14, 2019 at 06:51:04PM +0000, Christopher Brand via TF-M wrote:
I've posted a design document for bootloader changes to support twin cpu at https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/bootloader/
There are efforts underway to get the TF-M changes to the bootloader contributed back to the upstream MCUboot project.
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.
Are you expecting to be running the non-secure CPU before the secure CPU has finished verifying the images?
David
-----Original Message----- From: David Brown david.brown@linaro.org Sent: Thursday, March 14, 2019 4:25 PM To: Christopher Brand chris.brand@cypress.com Cc: tf-m@lists.trustedfirmware.org Subject: Re: [TF-M] [RFC] twin cpu bootloader design document
On Thu, Mar 14, 2019 at 06:51:04PM +0000, Christopher Brand via TF-M wrote:
I've posted a design document for bootloader changes to support twin cpu at https://developer.trustedfirmware.org/w/tf_m/design/twin-
cpu/bootloader
/
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?
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?
Are you expecting to be running the non-secure CPU before the secure CPU has finished verifying the images?
The plan is to add a call to start the non-secure CPU after both verifying the image and setting up any hardware protection.
David
Chris
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
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
-----Original Message----- From: David Brown david.brown@linaro.org Sent: Saturday, March 16, 2019 11:33 PM To: Christopher Brand chris.brand@cypress.com Cc: tf-m@lists.trustedfirmware.org Subject: Re: [TF-M] [RFC] twin cpu bootloader design document
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.
I didn't dig enough into where this stuff is being done now in TF-M.
In actual fact, this proposal means no change whatsoever to the mcuboot code. All the changes would be in tfm_core.c, which is only built into tfm_s.
I'll go through the document and make that clear - it's probably mostly a matter of replacing "bootloader" with "booting", or similar, and adding some words to clarify which binaries are affected, I think.
Thanks for leading me to this, David.
David
Chris
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
tf-m@lists.trustedfirmware.org
-
Christopher Brand -
David Brown