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
Hello
I am implementing PSA Firmware Update API for our solution using various MCUBOOT update modes like SWAP, DIRECT-XIP and OVERWRITE_ONLY.
I am struggling how to clearly detect these two states mentioned below from context of booted application after successfull or failed mcuboot update:
FAILED - An update to a new image has been attempted, but has failed, or been cancelled for some reason. The failure reason is recorded in the firmware store. The second image needs to be cleaned before another update can be attempted.
UPDATED - The active trial image has been accepted. The second image contains the now-expired previous firmware image, which needs to be cleaned before another update can be started.
Both states leads to erasing staging area so the device is "READY" for an update.
I am aware that mcuboot has measured boot and data sharing funcionality but this doesn't suit for this use case as I don't see no report related to information that something like "update, rollback, image erase etc" happened . Or have I overlooked something?
I have an idea assuming there is downgrade prevention that I could check image version in both slots, evaluate trailer combinations or just its presence. Another option is storage of some record of expected action in RAM or FLASH before reboot.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello
I am implementing PSA Firmware Update API for our solution using various MCUBOOT update modes like SWAP, DIRECT-XIP and OVERWRITE_ONLY.
I am struggling how to clearly detect these two states mentioned below from context of booted application after successfull or failed mcuboot update:
FAILED - An update to a new image has been attempted, but has failed, or been cancelled for some reason. The failure reason is recorded in the firmware store. The second image needs to be cleaned before another update can be attempted.
UPDATED - The active trial image has been accepted. The second image contains the now-expired previous firmware image, which needs to be cleaned before another update can be started.
Both states leads to erasing staging area so the device is "READY" for an update.
I am aware that mcuboot has measured boot and data sharing funcionality but this doesn't suit for this use case as I don't see no report related to information that something like "update, rollback, image erase etc" happened . Or have I overlooked something?
I have an idea assuming there is downgrade prevention that I could check image version in both slots, evaluate trailer combinations or just its presence. Another option is storage of some record of expected action in RAM or FLASH before reboot.
Beta Was this translation helpful? Give feedback.
All reactions