-
Notifications
You must be signed in to change notification settings - Fork 76
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
Adding slot enforcement to TLV #152
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We are currently using the multi-image feature of mcuboot/mcumgr on a nordic nRF5340 SoC, this allows for uploading an image to update each of the cores in the module. This, however, has a major drawback in that if an image for a core is loaded to the wrong slot, as mcuboot uses the same key for both images, there is currently no way to differentiate if the image upgrade should be allowed or not and mcuboot will overwrite the application core with a network core image, this then leads to a dead device which faults when starting.
My proposal for fixing this would be to add a new (optional) protected TLV which contains the slot number that the upgrade is for, e.g. for the nRF5340 this would have a value of 0 for the application core and 1 for the network core, then when mcuboot starts - similar to how is currently performed when checking dependencies - if a slot TLV is present, mcuboot will check if it is in the correct slot and if not, erase the slot rather than upgrade the image in it.
Would such a proposal/pull request be accepted? I'm currently part the way implementing such a system, using 0x70 for the TLV index and manually adding the TLV to a test image using imgtool.py
One thing whilst doing this that I can't see being described is that TLV's should be little endian but when using
--custom-tlv
with0x70 0x00000001
and getting it from mcuboot withit seems to be in the wrong endian:
The text was updated successfully, but these errors were encountered: