Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TF-M PSA template: Lock Approtect in network core #17093
TF-M PSA template: Lock Approtect in network core #17093
Changes from all commits
84df01f
c83fad1
2779930
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One second seems a long time to wait for core to boot.
If we already have a delay in the for-loop, can we combine these to delays and just poll the core to see it booted, instead of waiting blindly one second before start to poll?
This is just an optimization... I don't really think there is anything wrong, other than it might be unnecessary slow to boot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whilst not needed for this PR (or any future PRs), I assume this could fail to write e.g. if the device is purposely ran from too low a voltage that flash writing is available at or a clock/voltage glitch is used to skip the write, and it does not check that the write was successful before booting
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that your point holds. If you could pass the writing to the the UICR part, and still hit the pcd_done, it could be problematic. However, this particular piece of code should still be run by the manufacturer so that the device will transition form provisioning to secure life-cycle-state.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't the MCUBOOT_NRF_CLEANUP_NONSECURE_RAM be also y here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is supposed to call this:
before passing ctrl to application.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for pointing out this configuration option and apologies for slow response.
It seems that the SB_CONFIG_MCUBOOT_USE_ALL_AVAILABLE_RAM that we are setting in here, already sets the
CONFIG_MCUBOOT_NRF_CLEANUP_NONSECURE_RAM for bootloader in:
https://github.com/nrfconnect/sdk-nrf/blob/main/sysbuild/CMakeLists.txt#L164-L167
So it should be unnecessary to add CONFIG_MCUBOOT_NRF_CLEANUP_NONSECURE_RAM for the bootloader.