TF-M’s MCUboot wrapper.py currently does not expose imgtool’s --clear option.
This makes it difficult to generate clear-encrypted primary-slot images for factory/direct flashing while also generating encrypted secondary-slot OTA images through the same TF-M signing flow, as described in the MCUboot encrypted images documentation:
https://docs.mcuboot.com/encrypted_images.html#factory-programing-requirement
From what I understand, imgtool supports this use case via --clear, which is passed to:
img.create(..., clear=clear)
The requested behavior would be to add an opt-in --clear / -c argument to TF-M’s wrapper and pass it through accordingly.
I am not fully sure whether the current TF-M behavior is intentional, or whether a different factory-flashing flow is expected. However, for the flow documented by MCUboot, I currently cannot find a supported way in the standard TF-M signing wrapper to produce a clear-encrypted primary-slot image while also producing encrypted secondary-slot OTA images.
Could you clarify how this is intended to be handled in TF-M? If this use case is expected to go through the wrapper, would adding a pass-through --clear option be acceptable?
TF-M’s MCUboot wrapper.py currently does not expose imgtool’s
--clearoption.This makes it difficult to generate clear-encrypted primary-slot images for factory/direct flashing while also generating encrypted secondary-slot OTA images through the same TF-M signing flow, as described in the MCUboot encrypted images documentation:
https://docs.mcuboot.com/encrypted_images.html#factory-programing-requirement
From what I understand, imgtool supports this use case via
--clear, which is passed to:The requested behavior would be to add an opt-in
--clear/-cargument to TF-M’s wrapper and pass it through accordingly.I am not fully sure whether the current TF-M behavior is intentional, or whether a different factory-flashing flow is expected. However, for the flow documented by MCUboot, I currently cannot find a supported way in the standard TF-M signing wrapper to produce a clear-encrypted primary-slot image while also producing encrypted secondary-slot OTA images.
Could you clarify how this is intended to be handled in TF-M? If this use case is expected to go through the wrapper, would adding a pass-through
--clearoption be acceptable?