Hi Reinhard,
Sorry for making you confused. May I know which kind of documentation should be enhanced for dual-core?
Compared with single-Armv8-M scenario, the major difference is how NS side requests a secure service on a dual-core platform. Single-Armv8-M rely on SG instruction while dual-core transfers the request via Inter-Processor Communication based on mailbox. There are very few changes to other modules or behaviors in TF-M. How to add a secure partition, how SPM works, how to build the binaries. Neither of them is changes in dual-core.
I’d like to point it out that a dual Armv7-M platform is only an instance of TF-M dual-core support. TF-M dual-core is a general framework to support diverse dual-core topologies. It doesn’t depend on a specific CPU architecture. IMHO, porting and integration OS on Armv7-M may be out of the scope of dual-core general design.
Furthermore, the architecture, underlying hardware capabilities and use cases can change dramatically between different dual-core platforms. I’d like to avoid a general guideline about integration or use cases since it is unlikely to be one-sizes-fits-all.
But I’m very glad to add any document about dual-core support if it is required and can be helpful. 😊
There are several design documents about TF-M dual-core:
1. Communication prototype between NS and S in dual-core: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/design_docu... 2. Mailbox design: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/design_docu... 3. Memory access check in dual-core: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/design_docu...
Best regards, Hu Ziji
From: Reinhard Keil Reinhard.Keil@arm.com Sent: Monday, March 2, 2020 6:54 PM To: David Hu David.Hu@arm.com Cc: nd nd@arm.com; tf-m@lists.trustedfirmware.org Subject: RE: [TF-M] Call for a feedback on TF-M adaptation experience
David,
Q: “Do you require more documents or some improvement on code?”
A: I was looking at the documentation. Currently it unclear if the documentation refers to v8M or both v7M and v8M. The documentation is currently very dynamic (looks like you are doing a lot of changes) – this makes it not easy to keep up (however, I don’t mean this negative).
From the code itself: I’m using v8M with settings
* TFM_LVL=1 * TFM_PSA_API not defined = “SFN” (Secure Function Mode). This mode is still called “library model” in the documentation. I think we should seek for alignment with overall documentation, otherwise source and documentation are out of synch. * TFM_NS_CLIENT_IDENTIFICATION not defined
Reinhard
From: David Hu <David.Hu@arm.commailto:David.Hu@arm.com> Sent: Monday, March 2, 2020 11:20 AM To: Reinhard Keil <Reinhard.Keil@arm.commailto:Reinhard.Keil@arm.com> Cc: nd <nd@arm.commailto:nd@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Subject: RE: [TF-M] Call for a feedback on TF-M adaptation experience
Hi Reinhard,
Do you mind describing more details about separating single core v8M from dual core v7M? Do you require more documents or some improvement on code?
Best regards, Hu Ziji
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Monday, March 2, 2020 6:10 PM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: [TF-M] Call for a feedback on TF-M adaptation experience
Hi Anton, Hi Kevin,
Thanks for starting this discussion. Let me give you my view on it.
I think the problem can be structured in these parts:
* Give documentation a better overall structure * Clearly separate single core v8M from dual core v7M * Describe the overall structure of the files and configuration options of TF-M * Describe resource requirements of TF-M core * Describe platform interfaces and provide templates * Describe how a Service is added to TF-M * Describe the tools/utilities that are used for TF-M
While the debugging aspect raised by Kevin is relevant, it is a generic problem for all v8-M projects, not just for TF-M. I’m supportive to provide tools like pyOCD, but we need proper resourcing for it (maybe a separate project). It should be also noted that the industry works typically with tools like EWARM, MDK, or vendor specific tools like STCube or MCUxpresso. Hence we should not directly add too much tool-specific information to TF-M itself.
Now let me give more context to each of the above topics.
----
Give documentation a better overall structure
The Trusted Firmware-M documentation starts here: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBui...
While this is already a User’s Guide, it contains two more user’s guides https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBui...
https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBui...
For an outsider it is unclear where to start.
Clearly separate single core v8M from dual core v7M
This seems to be somewhat better now as it seems that below only refers to v8M single core: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBui...
Describe the overall structure of the files and configuration options of TF-M I was looking for something like this: https://arm-software.github.io/CMSIS_5/RTOS2/html/pDirectory_Files.html https://arm-software.github.io/CMSIS_5/RTOS2/html/config_rtx5.html
Describe resource requirements of TF-M core Take a look here to understand that request https://arm-software.github.io/CMSIS_5/RTOS2/html/pHardwareRequirements.html Important is also to document the interrupt behaviour (for both the secure and non-secure side). I know that this is tricky. For RTX we have this here: https://arm-software.github.io/CMSIS_5/RTOS2/html/cre_rtx_proj.html#cre_Usin... For TF-M this depends on a lot of other parameters.
Describe platform interfaces and provide templates What I mean by that are the functions itself that are called by TF_M core. This is an example of the OS_Tick interface that RTX is using. TF-M core has similar interfaces to setup MPC, PPC, SAU, etc. https://arm-software.github.io/CMSIS_5/RTOS2/html/group__CMSIS__RTOS__TickAP...
Describe how a Service is added to TF-M Assume I have functions currently used in NS. What would be the process to move this functions into TF-M as a service. How does the API interface change, what modifications do I need (ideally I would like to have the same API interface after it). Are the any rules for the API interface itself.
You could also provide an example for that, i.e. functions that read a PIN number from an secure keypad or open a DOOR depending on a verification.
I know making a good product is hard and takes time. CMSIS is not perfect either. Let me know if you have any questions. Reinhard