- TF-M - lists.trustedfirmware.org

Re: [TF-M] [EXTERNAL] Re: out of tree build

by Kevin Peng (Arm Technology China)

Hi all, I'm having issues on supporting the out of tree build. So I'd like to propose some additional changes. What does the out of tree build currently support is that: The user uses the tfm_parse_manifest_list.py with the custom manifests to generate the customized files to a directory out of TF-M. And the TF-M build system uses the customized files rather than the pre-generated ones in the TF-M for building. The problem is that some of the source files include the generated headers using the relative path to where the source itself is. And the directory of the source file is always searched first. This makes it impossible to use the generated files outside TF-M even the custom output directory is added to searching list. So I suggest to put the generated files to a dedicated directory in TF-M. Then for the default build, add the directory and its subdirectories to the search list for headers. For out of tree build, use the specified directory and its subdirectories instead. Then there would only one header file with the same name in all the directories for searching headers. Any concerns, thoughts or suggestions? Best Regards, Kevin -----Original Message----- From: Kevin Peng (Arm Technology China) Sent: Friday, November 22, 2019 3:45 PM To: DeMars, Alan <ademars(a)ti.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [EXTERNAL] Re: [TF-M] out of tree build Hi Alan, I've created a patch for the tfm_parse_manifest_list.py as the first step for the out of tree build support: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2606 The changes for build system is ongoing. The functionality changes for the tfm_parse_manifest_list.py is the same as your version. Please have a review and help verify it if possible. Comments from anyone else are also welcome. Best Regards, Kevin -----Original Message----- From: Kevin Peng (Arm Technology China) Sent: Thursday, November 14, 2019 3:31 PM To: DeMars, Alan <ademars(a)ti.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: RE: [EXTERNAL] Re: [TF-M] out of tree build OK. It's much clearer for me now. Thanks. Best Regards, Kevin -----Original Message----- From: DeMars, Alan <ademars(a)ti.com> Sent: Thursday, November 14, 2019 10:34 AM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: Re: [EXTERNAL] Re: [TF-M] out of tree build 1) I verified the tfm_parse_manifest.py script changes using the master branch’s version of the tfm_manifest_list.yaml and tfm_generated_file_list.yaml files. 2) Yes, I’m building using the unmodified master branch’s cmake build system. 3) Just as all other build artifacts are placed in the user’s build directory and NOT in the source tree, the generated files should also. Otherwise, the user is required to update the source tree’s tfm_manifest_list.yaml and tfm_generated_file_list.yaml files to build a custom SPE, with the generated files also ending up in the source tree. The files necessary to create a custom SPE should not be kept in the source tree. Nor should the generated content be inserted in the source tree. This creates headaches for maintaining the original source tree. Alan > On Nov 13, 2019, at 1:57 AM, Kevin Peng (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > I checked your modified tfm_parse_manifest_list.py. > It basically uses the input tfm_manifest_list.yaml and tfm_generated_file_list.yaml to generate the TF-M auto generated files to the third input. > > I'm sorry I was not in the workshop. So I have some questions. > 1. Do you have your own tfm_manifest_list.yaml and tfm_generated_file_list.yaml that is not upstreamed in TF-M? > 2. Are you using the TF-M provided CMake build system? > 3. Do you only need the files generated by tfm_parse_manifest_list.py to be out of the TF-M source directory? > > Could you provide some details about your requirements. Thanks. > > Best Regards, > Kevin > > -----Original Message----- > From: Kevin Peng (Arm Technology China) > Sent: Wednesday, November 13, 2019 10:27 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: RE: out of tree build > > Hi Alan, > > I'm following on this and will get you updated on any progress. > > Best Regards, > Kevin > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: Thursday, November 7, 2019 12:42 PM > To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> > Cc: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: Re: [TF-M] out of tree build > > Trying again after renaming tfm_parse_manifest_list.py to tfm_parse_manifest_list.txt so it wouldn't get deleted. > --- > > With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line: > > python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir> > > And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line: > > cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ > > The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage. > > Alan > > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M > Sent: Monday, November 4, 2019 4:36 PM > To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] Re: [TF-M] out of tree build > > Abishek, > > Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory. > A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files. > > I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible. > > Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise. > > Alan > > -----Original Message----- > From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com] > Sent: Monday, November 4, 2019 3:08 PM > To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] RE: out of tree build > > Hi Alan, > Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? > Thanks, > Abhishek > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: 01 November 2019 16:29 > To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] out of tree build > > Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. > > Alan > -- > TF-M mailing list > TF-M(a)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. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 10 months

1
0
0 0

Re: [TF-M] Coding guideline

by Abhishek Pandit

Hi Reinhard, We had a discussion in the TSC last week about coding standard. The general consensus was that there multiple possible standards that we can aim for but we need to decide our goal in order to decide the coding standard for the project. I believe Mark G is planning to look at the work ongoing in Zephyr project and provide some details to help us take the discussion forward for TF.org. The input below is helpful, we should take this into the unified effort for coding standard and tooling to enforce it. Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: 22 November 2019 07:59 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Coding guideline Hi all, I suggest to use industry standard coding rules. Here are the CMSIS coding rules: https://arm-software.github.io/CMSIS_5/General/html/index.html#CodingRules Simple, as we use MISRA. MISRA is an accepted set of coding standards, why invent something new? For wide acceptance of TF-M in automotive/industrial projects, you should publish also deviations like here: https://arm-software.github.io/CMSIS_5/RTOS2/html/misraCompliance5.html Reinhard 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 mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 10 months

1
0
0 0

Re: [TF-M] Coding guideline

by Reinhard Keil

Hi all, I suggest to use industry standard coding rules. Here are the CMSIS coding rules: https://arm-software.github.io/CMSIS_5/General/html/index.html#CodingRules Simple, as we use MISRA. MISRA is an accepted set of coding standards, why invent something new? For wide acceptance of TF-M in automotive/industrial projects, you should publish also deviations like here: https://arm-software.github.io/CMSIS_5/RTOS2/html/misraCompliance5.html Reinhard 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.

4 years, 10 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: out of tree build

by DeMars, Alan

1) I verified the tfm_parse_manifest.py script changes using the master branch’s version of the tfm_manifest_list.yaml and tfm_generated_file_list.yaml files. 2) Yes, I’m building using the unmodified master branch’s cmake build system. 3) Just as all other build artifacts are placed in the user’s build directory and NOT in the source tree, the generated files should also. Otherwise, the user is required to update the source tree’s tfm_manifest_list.yaml and tfm_generated_file_list.yaml files to build a custom SPE, with the generated files also ending up in the source tree. The files necessary to create a custom SPE should not be kept in the source tree. Nor should the generated content be inserted in the source tree. This creates headaches for maintaining the original source tree. Alan > On Nov 13, 2019, at 1:57 AM, Kevin Peng (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > I checked your modified tfm_parse_manifest_list.py. > It basically uses the input tfm_manifest_list.yaml and tfm_generated_file_list.yaml to generate the TF-M auto generated files to the third input. > > I'm sorry I was not in the workshop. So I have some questions. > 1. Do you have your own tfm_manifest_list.yaml and tfm_generated_file_list.yaml that is not upstreamed in TF-M? > 2. Are you using the TF-M provided CMake build system? > 3. Do you only need the files generated by tfm_parse_manifest_list.py to be out of the TF-M source directory? > > Could you provide some details about your requirements. Thanks. > > Best Regards, > Kevin > > -----Original Message----- > From: Kevin Peng (Arm Technology China) > Sent: Wednesday, November 13, 2019 10:27 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: RE: out of tree build > > Hi Alan, > > I'm following on this and will get you updated on any progress. > > Best Regards, > Kevin > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: Thursday, November 7, 2019 12:42 PM > To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> > Cc: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: Re: [TF-M] out of tree build > > Trying again after renaming tfm_parse_manifest_list.py to tfm_parse_manifest_list.txt so it wouldn't get deleted. > --- > > With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line: > > python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir> > > And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line: > > cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ > > The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage. > > Alan > > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M > Sent: Monday, November 4, 2019 4:36 PM > To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] Re: [TF-M] out of tree build > > Abishek, > > Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory. > A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files. > > I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible. > > Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise. > > Alan > > -----Original Message----- > From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com] > Sent: Monday, November 4, 2019 3:08 PM > To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] RE: out of tree build > > Hi Alan, > Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? > Thanks, > Abhishek > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: 01 November 2019 16:29 > To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] out of tree build > > Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. > > Alan > -- > TF-M mailing list > TF-M(a)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. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 10 months

2
2
0 0

Re: [TF-M] Call for review on header include update

by Abhishek Pandit

Hi Kevin, Yes my email was meant to be on the mailing list. Added back on. Thanks Abhishek -----Original Message----- From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Sent: 21 November 2019 09:13 To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> Subject: RE: Call for review on header include update Hi Abhishek, [I guess you are trying to reply to mailing list as well?] I think it's mostly about coding style. Most of the headers are included without any relative path in TF-M. So it's wired that lots of headers are included by a relative path, and relative to the project root make it even more unreasonable. The reason I didn't explain it in detail is that I didn't find any documents about this code style. Of course I had discussions with some team members and they are feeling the same. So I'd like to hear more feedbacks first. Best Regards, Kevin -----Original Message----- From: Abhishek Pandit <Abhishek.Pandit(a)arm.com> Sent: Thursday, November 21, 2019 4:54 PM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: Call for review on header include update Hi Kevin, Is there something that explains why this is required? Thanks Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng (Arm Technology China) via TF-M Sent: 21 November 2019 08:38 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Call for review on header include update Hi, I've proposed some patches to update the header includes in TF-M: https://review.trustedfirmware.org/q/topic:%22include_path_update%22+(statu… The idea is to remove the relative paths to TF-M root and add the necessary paths to include search list. Any kinds of comments are welcome. Best Regards, Kevin -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 10 months

1
0
0 0

Gerrit dashboard for TF-M

by Soby Mathew

Hi, I have created a dashboard for the TF-M project on tf.org to better visualize outstanding patches and the state of patch review : https://review.trustedfirmware.org/#/projects/trusted-firmware-m,dashboards… (old Gerrit UI) https://review.trustedfirmware.org/p/trusted-firmware-m/+/dashboard/site:ma… (new UI) Best Regards Soby Mathew

4 years, 10 months

1
0
0 0

Call for review on header include update

by Kevin Peng (Arm Technology China)

Hi, I've proposed some patches to update the header includes in TF-M: https://review.trustedfirmware.org/q/topic:%22include_path_update%22+(statu… The idea is to remove the relative paths to TF-M root and add the necessary paths to include search list. Any kinds of comments are welcome. Best Regards, Kevin

4 years, 10 months

1
0
0 0

Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure

by Andrej Butok

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(a)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(a)lists.trustedfirmware.org Cc: nd <nd(a)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(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

4 years, 10 months

2
1
0 0

Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure

by Ken Liu (Arm Technology China)

Hi David, The concept itself looks ok for me. So that the scope of vendor would be much clearer. And I think some structure change out of platform folder needs to happen to cooperate with this change, hope to see the detailed analysis result of the changes to be made. Thanks. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Wednesday, November 20, 2019 11:20 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)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(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 10 months

1
0
0 0

[RFC] Re-organize the TF-M platform folder structure

by David Hu (Arm Technology China)

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

4 years, 10 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M