Hi,
Even the ongoing HAL design abstracts all platform-specific operations, there are still some operations that need to be performed directly in TF-M, such as architecture-related operations.
These operations are common for all platforms, such as:
* generic assembler code for AAPCS based context management.
* assign attributes to specific functions.
These operations rely on compiler and architecture much instead of the platform. So, define a CORE-specific compiler configuration header file would be a straight requirement. With these unified headers, writing the architecture-specific code would be much safer because it won't involve hardcode compiler related changes. The minimal set of mandatory architecture registers is also planned to be defined.
Here send out a mail to collect for the feedbacks - is it worthy of doing this to decouple the architecture from the platform, or we can just re-use the platform provided headers?
Any comments are welcome:)
Best Regards,
Summer
Hi all,
I'd like to propose to add sub-folders under docs/design_documents to collect the documents on the same topic.
Currently, there are already 21 documents in total under docs/design_documents and the number may grow rapidly.
It can be more clear if we can organize the documents on the same topic into a dedicated sub-folder under docs/design_documents.
Please help review the patch set https://review.trustedfirmware.org/q/topic:%22design-doc-subdir%22+(status:… if the proposal sound interesting.
I move dual-cpu and TF-M Profiles related documents to their dedicated folder respectively in the patches.
Any comment is welcome!
In current patches, the html pages are still put in the same level during Sphinx build.
It is because design documents are grouped by document status, instead of document hierarchy. The html pages can be further organized as well if we switch to group html according to folder structures.
Best regards,
Hu Ziji
Hi all,
May I ask for a final round of review on symmetric initial attestation design document on https://review.trustedfirmware.org/c/trusted-firmware-m/+/3898?
The document has been reviewed for a long time and received many valuable comments. Thanks a lot.
If there is no further critical comment, I'd like to merge this design this Friday.
Best regards,
Hu Ziji
Hi,
There is an upcoming source structure adjustment for TF-M. The basic idea is to make the structure simple and easy to be understood by users.
The significant change would be a long term goal so no worry. In the beginning, there would be changes in core and platform to align with HAL changes.
Please help to put comments on the design documents - after aligned, this document would be a user guide document to describe the source structure of TF-M.
The patch is here:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/4112
And the issue link:
https://developer.trustedfirmware.org/T751
Feel free to put any comments or ask questions.
Thanks.
/Ken
Is Attestation already implemented?
Is there somewhere information on how Attestation is used.
I'm looking for user oriented information.
Thanks for your help.
Reinhard