Direct XIP support #106
Merged
Direct XIP support #106
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The new Direct XIP feature allows to boot a device with an image from a non-primary slot.
Before
Each image had to be compiled to be run from a primary slot. An update was sent to the secondary slot for given code, confirmed and on next reset the MCUboot would swap the two slots, so what was initially on the primary slot would end up on the secondary, and what was on secondary out end on primary. The device could then be started with an updated image run from the primary slot.
Issue
Depending on a device, the swap took ~20 seconds in addition to the upload time.
Direct XIP
The new feature allows to build an image for both slots. When compiling, two binaries are generate, each for one slot (addresses in hex are different). The ZIP packet contains both images.
Such ZIP is given to the nRF Connect Device Manager app, which reads the current image state on the connected device, picks the image for the available slot and uploads it. No swap is used, as the image can be directly booted from where it was saved making the first slot available for future updates.