Hi Chris,
I've raised a ticket https://github.com/ARM-software/psa-arch-tests/issues/239 on PSA Arch test github repo. It will be fixed by PSA Arch test team later.
We will follow the fix status. Thanks again for reporting this issue.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: Tuesday, October 20, 2020 11:05 AM
To: Christopher Brand <chris.brand(a)cypress.com>
Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Another build issue
Hi Chris,
I agree with you. It looks like PSA arch test doesn't check the correct clone destination.
According to https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/CMakeL…, PSA arch test checks whether psa_qcbor exists.
However, the actual clone destination of psa_qcbor folder is under CMAKE_CURRENT_BINARY_DIR as https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/CMakeL… sets.
Therefore, I guess this issue will be triggered as long as CMake script execution is in the different directory as binary folder is.
I changed the destination to ${CMAKE_CURRENT_BINARY_DIR}/${PSA_TARGET_QCBOR} in check step and it looks like the issue is fixed.
IMOO, the quick workaround is to entirely remove the build directory.
I will discuss with Raef to determine a final solution.
Thanks a lot for reporting this issue!
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M
Sent: Tuesday, October 20, 2020 5:57 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Another build issue
This one is a failure when re-configuring the build (even though the configuration is the same):
$ mkdir build_GNUARM_Release
$ cmake -S . -B build_GNUARM_Release -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=INITIAL_ATTESTATION
(lots of output - eventually succeeds)
$ cmake -S . -B build_GNUARM_Release -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=INITIAL_ATTESTATION
(less output, eventually fails)
fatal: destination path 'psa_qcbor' already exists and is not an empty directory.
CMake Error at build_GNUARM_Release/lib/ext/psa_arch_tests-src/api-tests/CMakeLists.txt:324 (message):
git clone failed for https://github.com/laurencelundblade/QCBOR.git
I suspect that this might be due to the PSA stuff, rather than TFM per se, but it manifests when building TFM...
Chris Brand
Sr Prin Software Engr, MCD: WIRELESS
Cypress Semiconductor Corp.
An Infineon Technologies Company
#320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada
www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com>
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.
Hi Anton
If it's not possible to avoid a file generation now, it's good to have pre-generated files for a most typical configuration (l2, IPC etc.).
As I mentioned before, ideally to use TFM as a real component/framework without generation of any source code.
BUT If you believe, this requirement breaks a TFM concept, just tell us.
Thanks,
Andrej
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Tuesday, October 20, 2020 9:27 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Generated files location
Hi Andrej,
Essentially, do you mean to move the files back to code tree and synch them with templates manually as it was ?
Cheers,
Anton
From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>>
Sent: 19 October 2020 16:15
To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: Generated files location
Hi Anton,
Another option:
3. Avoid the mandatory on-the-fly generation.
Try to make TFM a component/framework, which is configurable by compile & run time parameters.
Thanks,
Andrej
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M
Sent: Monday, October 19, 2020 5:00 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] Generated files location
Hi,
Some source files in TF-M are templated and generated inside /<build_dir>/generated/ on the fly as a part of build process. This guaranty consistency between templates and generated but might make a trouble for IDE, where not all source files exist at the first run.
I see 2 options for solution:
1. Explicitly generate those files via cmake as a part of IDE project creation (1 time action)
2. Relay on CMSIS Pack for IDE, where generated files must be presents
Any alternative thoughts?
Anton
Hi Anton,
Another option:
3. Avoid the mandatory on-the-fly generation.
Try to make TFM a component/framework, which is configurable by compile & run time parameters.
Thanks,
Andrej
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Monday, October 19, 2020 5:00 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Generated files location
Hi,
Some source files in TF-M are templated and generated inside /<build_dir>/generated/ on the fly as a part of build process. This guaranty consistency between templates and generated but might make a trouble for IDE, where not all source files exist at the first run.
I see 2 options for solution:
1. Explicitly generate those files via cmake as a part of IDE project creation (1 time action)
2. Relay on CMSIS Pack for IDE, where generated files must be presents
Any alternative thoughts?
Anton
Hi Chris,
I agree with you. It looks like PSA arch test doesn't check the correct clone destination.
According to https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/CMakeL…, PSA arch test checks whether psa_qcbor exists.
However, the actual clone destination of psa_qcbor folder is under CMAKE_CURRENT_BINARY_DIR as https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/CMakeL… sets.
Therefore, I guess this issue will be triggered as long as CMake script execution is in the different directory as binary folder is.
I changed the destination to ${CMAKE_CURRENT_BINARY_DIR}/${PSA_TARGET_QCBOR} in check step and it looks like the issue is fixed.
IMOO, the quick workaround is to entirely remove the build directory.
I will discuss with Raef to determine a final solution.
Thanks a lot for reporting this issue!
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M
Sent: Tuesday, October 20, 2020 5:57 AM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Another build issue
This one is a failure when re-configuring the build (even though the configuration is the same):
$ mkdir build_GNUARM_Release
$ cmake -S . -B build_GNUARM_Release -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=INITIAL_ATTESTATION
(lots of output - eventually succeeds)
$ cmake -S . -B build_GNUARM_Release -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=INITIAL_ATTESTATION
(less output, eventually fails)
fatal: destination path 'psa_qcbor' already exists and is not an empty directory.
CMake Error at build_GNUARM_Release/lib/ext/psa_arch_tests-src/api-tests/CMakeLists.txt:324 (message):
git clone failed for https://github.com/laurencelundblade/QCBOR.git
I suspect that this might be due to the PSA stuff, rather than TFM per se, but it manifests when building TFM...
Chris Brand
Sr Prin Software Engr, MCD: WIRELESS
Cypress Semiconductor Corp.
An Infineon Technologies Company
#320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada
www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com>
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.
This one is a failure when re-configuring the build (even though the configuration is the same):
$ mkdir build_GNUARM_Release
$ cmake -S . -B build_GNUARM_Release -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=INITIAL_ATTESTATION
(lots of output - eventually succeeds)
$ cmake -S . -B build_GNUARM_Release -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=INITIAL_ATTESTATION
(less output, eventually fails)
fatal: destination path 'psa_qcbor' already exists and is not an empty directory.
CMake Error at build_GNUARM_Release/lib/ext/psa_arch_tests-src/api-tests/CMakeLists.txt:324 (message):
git clone failed for https://github.com/laurencelundblade/QCBOR.git
I suspect that this might be due to the PSA stuff, rather than TFM per se, but it manifests when building TFM...
Chris Brand
Sr Prin Software Engr, MCD: WIRELESS
Cypress Semiconductor Corp.
An Infineon Technologies Company
#320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada
www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com>
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.
Looks like that test is indeed not supported on PSoC64. The error message threw me because it says what the valid values are for -DTARGET (which does include one containing "psoc64"), but it doesn't tell me what -DTAREGT was actually set to.
Chris
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M
Sent: Monday, October 19, 2020 1:42 PM
To: David Hu <David.Hu(a)arm.com>
Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Build failure
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
We definitely used to be able to at least build ConfigPsaApiTestIPC.cmake (and the level 2 version) for PSoC64 under the old build system. It looks like we've always done so with one of the other PSA test suites also selected, which doesn't seem to be an option with the new build system.
Is there an example TEST_PSA_API=IPC build for another platform I can look at?
Chris
From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>
Sent: Sunday, October 18, 2020 11:10 PM
To: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: Build failure
Hi Chris,
Sorry for the trouble. May I know if the same configurations worked with the previous build system?
I checked a previous version of PSoC 64 specifics and it didn't explicitly claim to support FF compliance tests. Could you please confirm it with Alamy?
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M
Sent: Saturday, October 17, 2020 7:07 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Build failure
I'm experimenting with the new build system, and seeing an error.
Looking at docs/getting_started/tfm_build_instruction.rst, it mentions that TEST_PSA_API=IPC is a valid option ("Firmware Framework test suite"). When I try to configure for that build, though, I get an error:
$ cmake -S . -B build_GNUARM_Release '-GUnix Makefiles' -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=IPC
CMake Error at build_GNUARM_Release/lib/ext/psa_arch_tests-src/api-tests/CMakeLists.txt:119 (message):
[PSA] : Error: Unspported value for -DTARGET=, supported targets are :
common;tgt_dev_apis_stdc;tgt_dev_apis_tfm_an521;tgt_dev_apis_tfm_an524;tgt_dev_apis_tfm_an539;tgt_dev_apis_tfm_musca_a;tgt_dev_apis_tfm_musca_b1;tgt_dev_apis_tfm_musca_s1;tgt_dev_apis_tfm_psoc64;tgt_ff_tfm_an521;tgt_ff_tfm_musca_a;tgt_ff_tfm_musca_b1
I see the same error with and without "-DTFM_ISOLATION_LEVEL=2".
Chris Brand
Sr Prin Software Engr, MCD: WIRELESS
Cypress Semiconductor Corp.
An Infineon Technologies Company
#320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada
www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com>
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.
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.
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.
Hi Chris,
Sorry for the trouble. May I know if the same configurations worked with the previous build system?
I checked a previous version of PSoC 64 specifics and it didn't explicitly claim to support FF compliance tests. Could you please confirm it with Alamy?
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M
Sent: Saturday, October 17, 2020 7:07 AM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Build failure
I'm experimenting with the new build system, and seeing an error.
Looking at docs/getting_started/tfm_build_instruction.rst, it mentions that TEST_PSA_API=IPC is a valid option ("Firmware Framework test suite"). When I try to configure for that build, though, I get an error:
$ cmake -S . -B build_GNUARM_Release '-GUnix Makefiles' -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=IPC
CMake Error at build_GNUARM_Release/lib/ext/psa_arch_tests-src/api-tests/CMakeLists.txt:119 (message):
[PSA] : Error: Unspported value for -DTARGET=, supported targets are :
common;tgt_dev_apis_stdc;tgt_dev_apis_tfm_an521;tgt_dev_apis_tfm_an524;tgt_dev_apis_tfm_an539;tgt_dev_apis_tfm_musca_a;tgt_dev_apis_tfm_musca_b1;tgt_dev_apis_tfm_musca_s1;tgt_dev_apis_tfm_psoc64;tgt_ff_tfm_an521;tgt_ff_tfm_musca_a;tgt_ff_tfm_musca_b1
I see the same error with and without "-DTFM_ISOLATION_LEVEL=2".
Chris Brand
Sr Prin Software Engr, MCD: WIRELESS
Cypress Semiconductor Corp.
An Infineon Technologies Company
#320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada
www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com>
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.
Hi,
Some source files in TF-M are templated and generated inside /<build_dir>/generated/ on the fly as a part of build process. This guaranty consistency between templates and generated but might make a trouble for IDE, where not all source files exist at the first run.
I see 2 options for solution:
1. Explicitly generate those files via cmake as a part of IDE project creation (1 time action)
2. Relay on CMSIS Pack for IDE, where generated files must be presents
Any alternative thoughts?
Anton
Hi, yes apologies that seems to have been lost. I was doing my best to track changes in the original cmake but it seems this one got missed.
Can I ask - for the vendor triplet compilers (arm-etc-eabi-gcc), is it a compiler that the vendor is developing? In the new buildsystem, it might make sense to create a new compiler toolchain file that is almost identical to the GNU one, which would allow the two compilers to diverge slightly (in command-line options etc) if necessary.
Raef
________________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kumar Gala via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 07 October 2020 17:26
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] New build system missing GNUARM_PREFIX support
It looks like the GNUARM_PREFIX changes got dropped as part of the new build system.
Can someone look at restoring those changes?
- k
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
I'm experimenting with the new build system, and seeing an error.
Looking at docs/getting_started/tfm_build_instruction.rst, it mentions that TEST_PSA_API=IPC is a valid option ("Firmware Framework test suite"). When I try to configure for that build, though, I get an error:
$ cmake -S . -B build_GNUARM_Release '-GUnix Makefiles' -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=IPC
CMake Error at build_GNUARM_Release/lib/ext/psa_arch_tests-src/api-tests/CMakeLists.txt:119 (message):
[PSA] : Error: Unspported value for -DTARGET=, supported targets are :
common;tgt_dev_apis_stdc;tgt_dev_apis_tfm_an521;tgt_dev_apis_tfm_an524;tgt_dev_apis_tfm_an539;tgt_dev_apis_tfm_musca_a;tgt_dev_apis_tfm_musca_b1;tgt_dev_apis_tfm_musca_s1;tgt_dev_apis_tfm_psoc64;tgt_ff_tfm_an521;tgt_ff_tfm_musca_a;tgt_ff_tfm_musca_b1
I see the same error with and without "-DTFM_ISOLATION_LEVEL=2".
Chris Brand
Sr Prin Software Engr, MCD: WIRELESS
Cypress Semiconductor Corp.
An Infineon Technologies Company
#320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada
www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com>
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.
