Hi Andrei,
Thanks a lot for the positive feedback.
Adding another common layer for all the partners sounds similar to Andrej's proposal. In my very own opinion, currently CMSIS can cover the general arch features. The general multi-core mailbox code is kept in TF-M Core. But I won't be surprised if additional common features should be extracted and kept under platform folder. Apparently, we need more partners/platforms on TF-M to specify the requirements.
I'd suggest that we can discuss the additional common part as another topic in a separated email thread.
Best regards, Hu Ziji
-----Original Message----- From: Andrei Narkevitch Andrei.Narkevitch@cypress.com Sent: Saturday, November 23, 2019 3:49 AM To: David Hu (Arm Technology China) David.Hu@arm.com Cc: nd nd@arm.com Subject: RE: [RFC] Re-organize the TF-M platform folder structure
Hi David,
I support this idea as it is a quick and easy solution for the growing list of supported platforms. Perhaps, I would also add another common layer in platform/ext/target to keep platform code that can be reused by other partners in their platforms - for the multicore mailbox code, for example.
Thanks, Andrei
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 19, 2019 7:20 PM To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: [TF-M] [RFC] Re-organize the TF-M platform folder structure
Hi all,
I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful.
In current platform folder structure, all the targets are listed together at the same level under `target` folder.
Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- .
A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files.
To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following:
Platform |-- ext |-- target | |-- Partner ABC | |-- *common drivers and files* | |-- target_abc_1 | | |-- target_abc_1.cmake | |-- target_abc_2 | |-- Partner XYZ | |-- *common drivers and files* | |-- target_xyz_1 | | |-- target_xyz_1.cmake | |-- target_xyz_2 |-- ...
The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear.
Best regards, Hu Ziji -- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.