Hi Qixiang,
It is a very reasonable suggestion. I will write it down as a further improvement. Thanks a lot.
Best regards, Hu Ziji
-----Original Message----- From: Qixiang Xu (Arm Technology China) Sent: Tuesday, November 26, 2019 2:18 PM To: David Hu (Arm Technology China) David.Hu@arm.com; Edison Ai (Arm Technology China) Edison.Ai@arm.com; Andrei Narkevitch Andrei.Narkevitch@cypress.com; tf-m@lists.trustedfirmware.org. Cc: nd nd@arm.com Subject: RE: [RFC] Re-organize the TF-M platform folder structure
Hi David,
When we add a platform into the TF-M, we need modify the top makefile to add it into build the system build, maybe we can consider to fix this issue at the same time. My proposal has changed a little from your proposal:
├── ext │ ├── arm │ │ ├── common │ │ │ └── arm_common.c │ │ ├── mps2 │ │ │ ├── an519 │ │ │ │ ├── an519.c │ │ │ │ └── plat.cmake │ │ │ ├── an521 │ │ │ │ ├── an521.c │ │ │ │ └── plat.cmake │ │ │ ├── an539 │ │ │ │ ├── an539.c │ │ │ │ └── plat.cmake │ │ │ ├── mps2.cmake │ │ │ └── mps2_common.c │ │ ├── mps3 │ │ │ ├── an524 │ │ │ │ ├── an524.c │ │ │ │ └── plat.cmake │ │ │ ├── mps3.cmake │ │ │ └── mps3_common.c │ │ └── musca │ │ ├── a │ │ │ ├── a.c │ │ │ └── plat.cmake │ │ ├── b1 │ │ │ ├── b1.c │ │ │ └── plat.cmake │ │ ├── musca.cmake │ │ ├── musca_common.c │ │ └── s1 │ │ ├── plat.cmake │ │ └── s1.c │ └── vendor1 │ ├── board1 │ │ ├── board1.cmake │ │ ├── board1_common.c │ │ ├── var1 │ │ │ ├── plat.cmake │ │ │ └── var1.c │ │ └── var2 │ │ ├── plat.cmake │ │ └── var2.c │ ├── board2 │ │ ├── board1.cmake │ │ ├── board1_common.c │ │ ├── var1 │ │ │ ├── plat.cmake │ │ │ └── var1.c │ │ └── var2 │ │ ├── plat.cmake │ │ └── var2.c │ └── common │ └── vendor1_common.c
In the different vendor, we have different boards and the board have different variants, so the plat.cmake can include the boardx.cmake and the boardx.cmake can include the vendorx.cmake.
To build the TF-M, we change the command line from PLAT=xxxx to PLAT=vendorX/boardY/varZ. The top makefile finds the plat.cmake from the platform directory with PLAT variable which passed by command line. So we don't need touch the top makefile when we add a new platform.
Thanks.
Best Regards, Qixiang Xu
-----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 26, 2019 11:05 AM To: Edison Ai (Arm Technology China) Edison.Ai@arm.com; Andrei Narkevitch Andrei.Narkevitch@cypress.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure
Hi Edison,
IMO, `target` folder is still required to separate the platforms from common files and drivers.
Best regards, Hu Ziji
-----Original Message----- From: Edison Ai (Arm Technology China) Edison.Ai@arm.com Sent: Monday, November 25, 2019 11:48 AM To: David Hu (Arm Technology China) David.Hu@arm.com; Andrei Narkevitch Andrei.Narkevitch@cypress.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: RE: [RFC] Re-organize the TF-M platform folder structure
Hi David,
Support the idea to support more different platforms and common drivers.
One suggestion for your proposal, is it necessary to add the "target" folders? It looks like we can short the folder depth. What about this? Platform |-- ext | |--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 | |-- ... |--include
Thanks, Edison
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Monday, November 25, 2019 10:33 AM To: Andrei Narkevitch Andrei.Narkevitch@cypress.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure
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:
Z`
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. -- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m
-- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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.