Hi Andrej,
We shall avoid adding IDE specific workarounds to the code.
I see many possible better solutions to this problem: 1. All IDEs are capable to "ignore" files present in the working copy but not part of the build. You could try this feature. 2. Irrelevant files can be deleted from the workspace by using a script. 3. Using a different generator of CMake could allow to generate a project format which your IDE can import. (See https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html) 4. Using CMAKE_EXPORT_COMPILE_CMMANDS will make CMake to generate a json file listing all C files part of the build with the build command needed to compile them. It could be relative simple to write a Python script to create an IDE project or to update an existing one with build settings. (See: https://cmake.org/cmake/help/latest/variable/CMAKE_EXPORT_COMPILE_COMMANDS.h...) 5. Long term a generators could be up streamed to CMake to add Support for you IDE. Please contact the IDE vendor with this request. 6. The IDE could be updated to co-operate with "cmake server" to allow integration with cmake based build systems. Again please contact the IDE vendor with this request.
/George
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Andrej Butok via TF-M Sent: 18 June 2019 08:23 To: Miklos Balint Miklos.Balint@arm.com; Thomas Törnblom thomas.tornblom@iar.com Cc: tf-m@lists.trustedfirmware.org Subject: Re: [TF-M] Feature request
Hi Miklos,
One more feature request: 3) Using separate files in TFM without #ifdef is causing issues for IDE projects, and requires creation of separate projects/targets (with different file set) per each feature combination. We are using IDEs (IAR, MCUx, Keil), so we have to add missing #ifdef to the original TFM source code. Please use #if/#ifdef in TFM, everywhere were it is needed.
Thanks, Andrej
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Miklos Balint via TF-M Sent: Monday, June 17, 2019 5:31 PM To: Thomas Törnblom thomas.tornblom@iar.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] Feature request
Hi Thomas,
I see no major issue with either suggestion, I think it makes sense to introduce improvements in these matters.
For issue #1 it makes very much sense to have a shared header file for all components that rely on these definitions. I don't recall any reason why that should not be possible, it's simply something that hasn't been done due to limited bandwidth for such clean-up of the code. For issue #2 we have had some internal discussions on the best way to handle compiler dependencies, and the suggestion I liked the most is similar to your suggestion below, but instead of having a single header file, having a compiler folder with each supported toolchain as a separate sub-folder, each defining their own version of tfm_compiler.h to provide the definitions required by TF-M. The compiler-specific cmake file can then simply point to the appropriate location for the compiler-specific inclusion, avoiding compiler-specific ifdef:s.
Let me know your thoughts on this approach
Thanks and kindest regards Miklos
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Thomas Törnblom via TF-M Sent: 13 June 2019 16:11 To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Feature request
While working on porting TF-M to the IAR toolchain, I've run into a couple of issues I'd like to discuss.
1) The duplicated REGION/REGION_NAME/REGION_DECLARE macros. Why are these not defined in an include file instead of being defined in eight different c files?
I see that they are also defined in spm_db.h, but that is only included in spm related files.
2) I suggest adding a toolchain related include file that should be included in every source file that is part of TF-M. This could be something similar to cmsis_compiler.h, where a toolchain vendor could add stuff that only relates to a specific toolchain. In our case that could include things like: --- #ifdef __ICCARM__ #define $$ZI$$Limit $$Limit #define $$ZI$$Base $$Base #define Image$$ #endif ---
Ideas?
/Thomas
Let's do life more easier for ALL, and apply the approach used by ARM MbedTLS, CMSIS or any other mature project, when you are able to import the whole source directory, so a feature set is defined by a configuration file or project parameters, without excluding/including files or additional scripts.
-----Original Message----- From: Gyorgy Szing Gyorgy.Szing@arm.com Sent: Tuesday, June 18, 2019 10:59 AM To: Andrej Butok andrey.butok@nxp.com; Miklos Balint Miklos.Balint@arm.com; Thomas Törnblom thomas.tornblom@iar.com Cc: tf-m@lists.trustedfirmware.org; nd nd@arm.com Subject: RE: [TF-M] Feature request
Hi Andrej,
We shall avoid adding IDE specific workarounds to the code.
I see many possible better solutions to this problem: 1. All IDEs are capable to "ignore" files present in the working copy but not part of the build. You could try this feature. 2. Irrelevant files can be deleted from the workspace by using a script. 3. Using a different generator of CMake could allow to generate a project format which your IDE can import. (See https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org%...) 4. Using CMAKE_EXPORT_COMPILE_CMMANDS will make CMake to generate a json file listing all C files part of the build with the build command needed to compile them. It could be relative simple to write a Python script to create an IDE project or to update an existing one with build settings. (See: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org%...) 5. Long term a generators could be up streamed to CMake to add Support for you IDE. Please contact the IDE vendor with this request. 6. The IDE could be updated to co-operate with "cmake server" to allow integration with cmake based build systems. Again please contact the IDE vendor with this request.
/George
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Andrej Butok via TF-M Sent: 18 June 2019 08:23 To: Miklos Balint Miklos.Balint@arm.com; Thomas Törnblom thomas.tornblom@iar.com Cc: tf-m@lists.trustedfirmware.org Subject: Re: [TF-M] Feature request
Hi Miklos,
One more feature request: 3) Using separate files in TFM without #ifdef is causing issues for IDE projects, and requires creation of separate projects/targets (with different file set) per each feature combination. We are using IDEs (IAR, MCUx, Keil), so we have to add missing #ifdef to the original TFM source code. Please use #if/#ifdef in TFM, everywhere were it is needed.
Thanks, Andrej
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Miklos Balint via TF-M Sent: Monday, June 17, 2019 5:31 PM To: Thomas Törnblom thomas.tornblom@iar.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] Feature request
Hi Thomas,
I see no major issue with either suggestion, I think it makes sense to introduce improvements in these matters.
For issue #1 it makes very much sense to have a shared header file for all components that rely on these definitions. I don't recall any reason why that should not be possible, it's simply something that hasn't been done due to limited bandwidth for such clean-up of the code. For issue #2 we have had some internal discussions on the best way to handle compiler dependencies, and the suggestion I liked the most is similar to your suggestion below, but instead of having a single header file, having a compiler folder with each supported toolchain as a separate sub-folder, each defining their own version of tfm_compiler.h to provide the definitions required by TF-M. The compiler-specific cmake file can then simply point to the appropriate location for the compiler-specific inclusion, avoiding compiler-specific ifdef:s.
Let me know your thoughts on this approach
Thanks and kindest regards Miklos
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Thomas Törnblom via TF-M Sent: 13 June 2019 16:11 To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Feature request
While working on porting TF-M to the IAR toolchain, I've run into a couple of issues I'd like to discuss.
1) The duplicated REGION/REGION_NAME/REGION_DECLARE macros. Why are these not defined in an include file instead of being defined in eight different c files?
I see that they are also defined in spm_db.h, but that is only included in spm related files.
2) I suggest adding a toolchain related include file that should be included in every source file that is part of TF-M. This could be something similar to cmsis_compiler.h, where a toolchain vendor could add stuff that only relates to a specific toolchain. In our case that could include things like: --- #ifdef __ICCARM__ #define $$ZI$$Limit $$Limit #define $$ZI$$Base $$Base #define Image$$ #endif ---
Ideas?
/Thomas
Hi,
Let's address this request with a professional attitude. (The "Eat shit, millions of flies can't be wrong." type of argument is not rally convincing.) I created a ticket here https://developer.trustedfirmware.org/T410 to capture your request and further discussions about it. Please extend the ticket if I missed something.
/George
-----Original Message----- From: Andrej Butok andrey.butok@nxp.com Sent: 18 June 2019 11:10 To: Gyorgy Szing Gyorgy.Szing@arm.com; Miklos Balint Miklos.Balint@arm.com; Thomas Törnblom thomas.tornblom@iar.com Cc: tf-m@lists.trustedfirmware.org Subject: RE: [TF-M] Feature request
Let's do life more easier for ALL, and apply the approach used by ARM MbedTLS, CMSIS or any other mature project, when you are able to import the whole source directory, so a feature set is defined by a configuration file or project parameters, without excluding/including files or additional scripts.
-----Original Message----- From: Gyorgy Szing Gyorgy.Szing@arm.com Sent: Tuesday, June 18, 2019 10:59 AM To: Andrej Butok andrey.butok@nxp.com; Miklos Balint Miklos.Balint@arm.com; Thomas Törnblom thomas.tornblom@iar.com Cc: tf-m@lists.trustedfirmware.org; nd nd@arm.com Subject: RE: [TF-M] Feature request
Hi Andrej,
We shall avoid adding IDE specific workarounds to the code.
I see many possible better solutions to this problem: 1. All IDEs are capable to "ignore" files present in the working copy but not part of the build. You could try this feature. 2. Irrelevant files can be deleted from the workspace by using a script. 3. Using a different generator of CMake could allow to generate a project format which your IDE can import. (See https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org%...) 4. Using CMAKE_EXPORT_COMPILE_CMMANDS will make CMake to generate a json file listing all C files part of the build with the build command needed to compile them. It could be relative simple to write a Python script to create an IDE project or to update an existing one with build settings. (See: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org%...) 5. Long term a generators could be up streamed to CMake to add Support for you IDE. Please contact the IDE vendor with this request. 6. The IDE could be updated to co-operate with "cmake server" to allow integration with cmake based build systems. Again please contact the IDE vendor with this request.
/George
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Andrej Butok via TF-M Sent: 18 June 2019 08:23 To: Miklos Balint Miklos.Balint@arm.com; Thomas Törnblom thomas.tornblom@iar.com Cc: tf-m@lists.trustedfirmware.org Subject: Re: [TF-M] Feature request
Hi Miklos,
One more feature request: 3) Using separate files in TFM without #ifdef is causing issues for IDE projects, and requires creation of separate projects/targets (with different file set) per each feature combination. We are using IDEs (IAR, MCUx, Keil), so we have to add missing #ifdef to the original TFM source code. Please use #if/#ifdef in TFM, everywhere were it is needed.
Thanks, Andrej
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Miklos Balint via TF-M Sent: Monday, June 17, 2019 5:31 PM To: Thomas Törnblom thomas.tornblom@iar.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] Feature request
Hi Thomas,
I see no major issue with either suggestion, I think it makes sense to introduce improvements in these matters.
For issue #1 it makes very much sense to have a shared header file for all components that rely on these definitions. I don't recall any reason why that should not be possible, it's simply something that hasn't been done due to limited bandwidth for such clean-up of the code. For issue #2 we have had some internal discussions on the best way to handle compiler dependencies, and the suggestion I liked the most is similar to your suggestion below, but instead of having a single header file, having a compiler folder with each supported toolchain as a separate sub-folder, each defining their own version of tfm_compiler.h to provide the definitions required by TF-M. The compiler-specific cmake file can then simply point to the appropriate location for the compiler-specific inclusion, avoiding compiler-specific ifdef:s.
Let me know your thoughts on this approach
Thanks and kindest regards Miklos
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Thomas Törnblom via TF-M Sent: 13 June 2019 16:11 To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Feature request
While working on porting TF-M to the IAR toolchain, I've run into a couple of issues I'd like to discuss.
1) The duplicated REGION/REGION_NAME/REGION_DECLARE macros. Why are these not defined in an include file instead of being defined in eight different c files?
I see that they are also defined in spm_db.h, but that is only included in spm related files.
2) I suggest adding a toolchain related include file that should be included in every source file that is part of TF-M. This could be something similar to cmsis_compiler.h, where a toolchain vendor could add stuff that only relates to a specific toolchain. In our case that could include things like: --- #ifdef __ICCARM__ #define $$ZI$$Limit $$Limit #define $$ZI$$Base $$Base #define Image$$ #endif ---
Ideas?
/Thomas
--
*Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom@iar.com mailto:thomas.tornblom@iar.com Website: https://eur01.safelinks.protection.outlook.com/?url=www.iar.com&data=02%... https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.iar.com&data=02%7C01%7Candrey.butok%40nxp.com%7Cdc31aef0293c42710ab608d6f3cb40da%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636964451657002613&sdata=GDgVwlcAHvJBeDUdVSK%2FWzh%2FPBreuNnMeqXyO6nEwcw%3D&reserved=0 Twitter: https://eur01.safelinks.protection.outlook.com/?url=www.twitter.com%2Fiarsys... https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitter.com%2Fiarsystems&data=02%7C01%7Candrey.butok%40nxp.com%7Cdc31aef0293c42710ab608d6f3cb40da%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636964451657002613&sdata=VR4HNamOHyuGfDqEzBI1fvAge7ylnbyqUOiy0%2BJX%2FI0%3D&reserved=0 -- TF-M mailing list TF-M@lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus... -- TF-M mailing list TF-M@lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus... -- 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
-
Andrej Butok -
Gyorgy Szing