Hi David,
Let's go further. The main goal of the proposal should be to have the all TFM portable code in one place as much as possible - so the top folder is named as "port".
New proposed structure: port |-- platform | | | |-- Partner ABC | | |-- common | | |-- target_abc_1 | | |-- target_abc_2 | | | |-- Partner XYZ | | |-- common | | |-- target_xyz_1 | | |-- target_xyz_2 | |-- ... | -- arch | -- include
Thanks, Andrej
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Wednesday, November 20, 2019 4:20 AM 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
Hi Andrej,
Thanks a lot for the feedback.
My purpose is to address the urgent issue of duplicated files among targets belonging to the same partner platform. Thus, my proposal tries to "abstract" the partner specific common part from the targets belonging to the same platform. It can be the base for further structure adjustment.
According to my own understanding, the "further" proposal is going to gather the common part from all the partner platforms. But I guess CMSIS can cover this common part now. I'd suggest to discuss it in another email thread as a separated proposal.
Best regards, Hu Ziji
-----Original Message----- From: Andrej Butok andrey.butok@nxp.com Sent: Wednesday, November 20, 2019 4:19 PM To: David Hu (Arm Technology China) David.Hu@arm.com Cc: tf-m@lists.trustedfirmware.org Subject: RE: [RFC] Re-organize the TF-M platform folder structure
Hi David,
Let's go further. The main goal of the proposal should be to have the all TFM portable code in one place as much as possible - so the top folder is named as "port".
New proposed structure: port |-- platform | | | |-- Partner ABC | | |-- common | | |-- target_abc_1 | | |-- target_abc_2 | | | |-- Partner XYZ | | |-- common | | |-- target_xyz_1 | | |-- target_xyz_2 | |-- ... | -- arch | -- include
Thanks, Andrej
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Wednesday, November 20, 2019 4:20 AM 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus... 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.
tf-m@lists.trustedfirmware.org