You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 with 0x70 0x00000001 and getting it from mcuboot with
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: