Hi,
In TF-M v2.0, Initial_attestation.h says:
* The initial attestation token is planned to be aligned with future version of
* Entity Attestation Token format:
* https://tools.ietf.org/html/draft-mandyam-eat-01
But that spec is expired and superceded with the following.
Is the implementation aligned with the following spec? If so, what version of this spec is actually supported?
https://datatracker.ietf.org/doc/draft-ietf-rats-eat/02/
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
Hello Everyone,
We are currently working on TF-M for the firmware of our Cortex-M55 based core, part of a bigger platform
including a cortex-A based application processor, a bit like the corstone1000.
We use the RAM_LOAD boot mode of TF-M/MCUBoot and we want to implement an upgrade strategy based on
2 banks, and a switch to decide which bank to boot from. I have a few questions regarding some design choices.
I hope someone can answer them. Please correct me if some of my assumptions are wrong.
*
For the generic Firmware Upgrade partition, are there plans to support the RAM_LOAD mode ? Do you have
suggestions about what is missing or how it should be done ?
*
Currently, MCUBoot in RAM_LOAD mode only supports booting the slot with the highest version.
Do you think it is realistic to try and integrate another boot mode in MCUBoot that matches our needs ?
I'm asking this because I noticed that the corstone1000 platform has been developed working around
this limitation by changing the flash_map at platform initialization in order to abstract the problem from
MCUBoot completely.
Thank you and all the best,
Julien
