Hi David,
Please see my comments below:
2.2. I think this is misleading. Inter-Processor Communication is something provided by the platform. Mailbox mechanism is implemented using the Inter-Processor Communication supplied by the platform. So TF-M non-secure interface library notifies TF-M of the PSA client call request, via mailbox (and not via mailbox and IPC).
2.3. Again, this is misleading. I think we should mention once that mailbox is based on Inter-Processor Communication capabilities of the platform, and from that point mention only mailbox (and not Inter-Processor Communication). Same for 2.5.
3.1. Addition to the parameters list: minor version; input vector length; input vector length
4. I am not sure about the meaning of top / bottom half w.r.t PendSV. I think it should be better explained in the document. As far as I see it, the PendSV comes only at the end of the mailbox interrupt handler.
4.1. The recommendation to implement mailbox time-consuming operations like message copying in PendSV handle, has a price on the NSPE side. If we go for the mailbox design proposed on the workshop, then NSPE clients are block until the message is fully copied. For now, it seems to me more reasonable to do the mailbox work in the mailbox handler, unblock the client, and then assert PendSV for further handling in the SPM.
Regarding 4 and 4.1, I think we need further discussion to make sure we both have the same understanding.
4.2. I think we need further explanation here. What does it mean that the mailbox handling should be added to PendSV handler, and how it is going to be done. I think it is better to be explicit and add real function names.
4.2.1. 1. Please note that current mailbox design supports multiple mailbox requests handling in SPE, but only one request can be issued at a time (until request parameters are fully copied). So copying multiple messages is not relevant. 2. "Mailbox handling parses the mailbox message copied in SPE and fetch the information of the PSA client call type, including the PSA client call type." - Please rephrase.
4.3.1. A compilation flag is mentioned. I assume you mean a twin-cpu-system flag. This is general and maybe better mentioned first in another section and not in the replying routine section.
5. Between mailbox handling and PSA client call handlers, I miss the TF-M function that mailbox should call to pass the client message.
Thanks, Danny
-----Original Message----- From: David Hu (Arm Technology China) David.Hu@arm.com Sent: Wednesday, March 27, 2019 06:41 To: tf-m@lists.trustedfirmware.org; Christopher Brand chris.brand@cypress.com; Danny Shavit Danny.Shavit@arm.com Cc: nd nd@arm.com Subject: [twin-cpu]Dual core communication design document for review
Hi all,
I've posted a design document for dual core communication in twin cpu project. Could you please review it at https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/communication_p... Any comment is welcome.
Thank you.
Best regards, Hu Ziji
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.