Hi all,
I'm seeking some assistance in determining the correct fix for a difference in behavior between IPC and Library modes that cause the Crypto PSA Arch Tests to fail when using IPC. Specifically, I've been testing on a PSoC64 for IPC mode and Musca-B1 for Library mode. The problem I am encountering is related to this check in crypto (e.g. crypto_aead.c in secure_fw/partitions/crypto).
if ( !((in_len == 2) || (in_len == 3)) || (out_len > 1)) {
return PSA_ERROR_CONNECTION_REFUSED;
}
This is true for direct function call since in_len and out_len are sizes of in_vec[] and out_vec[]. However, in library mode, in_len and out_len is not based on the size of in_vec[] and out_vec[] but based on the contents. Specifically, out_len is determined via the following in tfm_crypto_call_sfn().
/* Check the number of out_vec filled */
while ((out_len > 0) && (msg->out_size[out_len - 1] == 0)) {
out_len--;
}
>From the above, if out_size (which is passed in by the user) is 0, the resultant out_len will be 0. The out_len is passed into the crypto function and PSA_ERROR_CONNECTION_REFUSED is returned due to the check above. PSA, on the other hand, expects PSA_ERROR_NOT_SUPPORTED to be returned. Btw, in_len suffers from the same issue.
I'm not sure if the check above is valid for IPC mode. I've removed the check temporarily to avoid the problem. However, if the check still makes sense, possibly it should return PSA_ERROR_NOT_SUPPORTED instead of PSA_ERROR_CONNECTION_REFUSED.
Thank you. I look forward to comments.
Ray
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,
The IRQ test part of the CORE_TEST is all conditioned on TFM_ENABLE_IRQ_TEST, and docs/reference/services/core_test_services_integration_guide.rst states that "A platform can skip IRQ handling test by setting ``TFM_ENABLE_IRQ_TEST`` to ``OFF`` in its cmake configuration file.", but doing so doesn't seem to actually work. I tried a number of options to the cmake command (including -DTFM_ENABLE_IRQ_TES=OFF, -U TFM_ENABLE_IRQ_TEST), too, but I can't figure out how to avoid that test.
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.
Hello,
The next Technical Forum is planned on Thursday, October 15 at 6:00-07:00 UTC (Asia time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi Raymond,
Could you test this fix, it worked for me:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6274
BR,
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M
Sent: 07 October 2020 09:26
To: Raymond Ngun <Raymond.Ngun(a)cypress.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Musca-B1 and new build system
Hi Raymond,
I propose the following way to debug:
* I will build and send you a Musca-B1 image based on current master (fc8d2f7 Build: Remove PSA arch tests patch) for testing on your board.
* Please send me both of your images, and if you have the corresponding *.axf files, and if you know the commit-id when they were built.
* I would like to test and debug in my environment.
* By the way do you have a debugger? Can you identify actually what does return an error during security counter init?
BR,
Tamas
From: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>>
Sent: 06 October 2020 23:53
To: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: Musca-B1 and new build system
Hi Tamas,
It didn't make a difference. I have an old muscb1 image around and that continues to work fine but the new images do not work.
I wrote 2MB of 0xFF btw.
Thanks,
Ray
From: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>>
Sent: Tuesday, October 6, 2020 8:40 AM
To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: Musca-B1 and new build system
Hi Raymond,
The build command and the hex creation are correct.
Could you try to erase the entire eFlash before programming it?
It can be done with Keil MDK, or you can create a hex file with srec_cat which only contains 0xFF bytes and program that one to the board.
Let me know whether does it solved the issue.
Tamas
From: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>>
Sent: 05 October 2020 23:07
To: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: Musca-B1 and new build system
Thanks Tamas.
Unfortunately, this did not work for me. Here is what I did to build. Let me know if I did something wrong.
cmake -DTFM_PLATFORM=musca_b1 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug -DTEST_NS=ON -DTEST_S=ON ../
cmake --build . --target install
srec_cat install/outputs/MUSCA_B1/bl2.bin -Binary -offset 0xA000000 install/outputs/MUSCA_B1/tfm_s_ns_signed.bin -Binary -offset 0xA020000 -o tfm.hex -Intel
The resultant output is the following.
Entering standby..
[INF] Starting bootloader
[ERR] Error while initializing the security counter
Thank you,
Ray
From: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>>
Sent: Thursday, October 1, 2020 3:05 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: Musca-B1 and new build system
Hi Raymond,
Here is the proposed fix:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6028
Could you verify on your board? Pls use at build -DCMAKE_BUILD_TYPE=Debug for full logging in bootloader.
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Tamas Ban via TF-M
Sent: 01 October 2020 10:37
To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] Musca-B1 and new build system
Hi Raymond,
Thanks for reporting the issue!
The observed behaviour has two reason:
- In the new build system the default CMAKE_BUILD_TYPE=Release. In this case the logging is disabled in MCUboot to get smaller binary. You can set manualy to Debug in the command line to enable logging from bootloader
* This commit 7d591a684b4abb0f61fbba8668dd6ea7b4b68698 introduced a crash in Musca S1/B1. Fix is ongoing.
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Raymond Ngun via TF-M
Sent: 30 September 2020 17:44
To: David Hu via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Subject: [TF-M] Musca-B1 and new build system
Hi all,
I am attempting to build Musca-B1 with the latest in master but I'm not able to get it to run (nothing shows on the UART). At a minimum, the User Guide is out of date in terms of how the final hex is created. So, I have a couple questions.
1. Is the latest tested with Musca-B1?
2. Can I obtain some updated information on how to build and create an image for Musca-B1?
Thank you,
Ray
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,
FIY this variable in the Linux world used to be called "CROSS_COMPILE" and both TF-A and OP-TEE is using the same convention. Would it be possible to align with this and rename the variable? For backwards compatibility it could be possible to use both for a while, and issue a warning when the with a deprecation message when the old one is sued.
/George
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M
Sent: 08 October 2020 11:03
To: tf-m(a)lists.trustedfirmware.org; Kumar Gala (kumar.gala(a)linaro.org) <kumar.gala(a)linaro.org>
Subject: Re: [TF-M] New build system missing GNUARM_PREFIX support
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
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi Raymond,
Here is the proposed fix:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6028
Could you verify on your board? Pls use at build -DCMAKE_BUILD_TYPE=Debug for full logging in bootloader.
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M
Sent: 01 October 2020 10:37
To: Raymond Ngun <Raymond.Ngun(a)cypress.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Musca-B1 and new build system
Hi Raymond,
Thanks for reporting the issue!
The observed behaviour has two reason:
- In the new build system the default CMAKE_BUILD_TYPE=Release. In this case the logging is disabled in MCUboot to get smaller binary. You can set manualy to Debug in the command line to enable logging from bootloader
* This commit 7d591a684b4abb0f61fbba8668dd6ea7b4b68698 introduced a crash in Musca S1/B1. Fix is ongoing.
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Raymond Ngun via TF-M
Sent: 30 September 2020 17:44
To: David Hu via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Subject: [TF-M] Musca-B1 and new build system
Hi all,
I am attempting to build Musca-B1 with the latest in master but I'm not able to get it to run (nothing shows on the UART). At a minimum, the User Guide is out of date in terms of how the final hex is created. So, I have a couple questions.
1. Is the latest tested with Musca-B1?
2. Can I obtain some updated information on how to build and create an image for Musca-B1?
Thank you,
Ray
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 Øyvind
Yes, you are right, we don't use wchar_t within TF-M and it does seem a trivial optimization without much benefit for TF-M other than introducing incompatibilities. Could you submit a patch to remove the same from GCC and ARMCLANG ?
Best Regards
Soby Mathew
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Rønningstad, Øyvind via TF-M
Sent: 05 October 2020 09:12
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] -fshort-wchar
Hi guys. I'm curious why -fshort-wchar is enabled for ARMCLANG and GNUARM (not IAR, interestingly). This should have little or no impact since wchar_t is so rarely used, and causes incompatibility when I try to link my Zephyr app with TF-M libs.
Øyvind
Hi Antonio,
Could you try to do a debug build? By default the build type is release and in this case the MCUboot does not log anything.
Set '-DCMAKE_BUILD_TYPE=Debug' in the command line when invoking the CMake generation phase.
Tamas
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio Ken IANNILLO via TF-M
Sent: 05 October 2020 16:13
To: Raef Coles <Raef.Coles(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Running Tests on Musca-A
Thank you.
However, it seems to flash without problem but after reset I don't get the expected output.
The most I can get from the UART is the message "Musca A Firmware Version 3.0" when I power off and on, but none of the logging message expected from tf-m.
Am I missing something?
--
Antonio Ken Iannillo
On 05/10/2020, 15:41, "Raef Coles" <Raef.Coles(a)arm.com> wrote:
Apologies for the difficulties that you're having. We've recently done an upgrade to the buildsystem and some of the documentation hasn't been properly updated to reflect the new files. There is a patch in review to rectify this.
For now, updated (plaintext) documentation can be found at https://review.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m/…. It should also be updated on the website sometime this week.
Raef
________________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 05 October 2020 14:06
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Running Tests on Musca-A
Dear all,
I’m a researcher exploring TF-M.
I have a Musca-A board, and I was able to build it with tests.
Now, it seems that the examples running the tests [1] are outdated: I simply do not have the same files.
My understanding is that I should merge two files (secure and non-secure) but it is not clear which ones and how the offset are computed.
Can somebody help me on this?
The output files in the /bin folder are: bl2, tfm_ns, and tfm_s in .axf, .bin, .elf, .hex, .map; tfm_s_ns.bin; and tfm_s_ns_signed.bin.
Best,
[1] https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-docs-nightly/lastSt…
--
Antonio Ken Iannillo, PhD
Research Scientist – SEDAN group
SnT – Interdisciplinary Centre for Security, Reliability and Trust
UNIVERSITÉ DU LUXEMBOURG
CAMPUS KIRCHBERG
29, avenue John F. Kennedy
L-1855 Luxembourg Kirchberg
T +352 46 66 44 9660 | antonioken.iannillo(a)uni.lu<mailto:antonioken.iannillo@uni.lu>
Join the conversation
News<https://wwwen.uni.lu/snt/news_events> | Twitter<https://twitter.com/SnT_uni_lu> | Linkedin<https://www.linkedin.com/school/snt-lu/>
www.uni.lu/snt<http://www.uni.lu/snt>
https://akiannillo.github.io/
P Please consider the environment before printing this e-mail
Apologies for the difficulties that you're having. We've recently done an upgrade to the buildsystem and some of the documentation hasn't been properly updated to reflect the new files. There is a patch in review to rectify this.
For now, updated (plaintext) documentation can be found at https://review.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m/…. It should also be updated on the website sometime this week.
Raef
________________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 05 October 2020 14:06
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Running Tests on Musca-A
Dear all,
I’m a researcher exploring TF-M.
I have a Musca-A board, and I was able to build it with tests.
Now, it seems that the examples running the tests [1] are outdated: I simply do not have the same files.
My understanding is that I should merge two files (secure and non-secure) but it is not clear which ones and how the offset are computed.
Can somebody help me on this?
The output files in the /bin folder are: bl2, tfm_ns, and tfm_s in .axf, .bin, .elf, .hex, .map; tfm_s_ns.bin; and tfm_s_ns_signed.bin.
Best,
[1] https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-docs-nightly/lastSt…
--
Antonio Ken Iannillo, PhD
Research Scientist – SEDAN group
SnT – Interdisciplinary Centre for Security, Reliability and Trust
UNIVERSITÉ DU LUXEMBOURG
CAMPUS KIRCHBERG
29, avenue John F. Kennedy
L-1855 Luxembourg Kirchberg
T +352 46 66 44 9660 | antonioken.iannillo(a)uni.lu<mailto:antonioken.iannillo@uni.lu>
Join the conversation
News<https://wwwen.uni.lu/snt/news_events> | Twitter<https://twitter.com/SnT_uni_lu> | Linkedin<https://www.linkedin.com/school/snt-lu/>
www.uni.lu/snt<http://www.uni.lu/snt>
https://akiannillo.github.io/
P Please consider the environment before printing this e-mail
Hi Antonio,
And welcome to the TF-M community. To get a better understanding of your issue it I would like to ask from some further details, such as the HEAD of the TF-M which you are trying to build, as well as the HEAD of the test branche.
There has been a large overhaul of several components on the TF-M project, including the build system, so it would be good to have a common point of reference /
By examples, do you refer to the official user guide?
https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-docs-nightly/lastSt…
For Musca_A you only need the hex file to flash it, which is generated using the srec_cat command mentioned above which utilises the platform specific offsets and merges the signed secure and non-secure binaries with the bootloader.
If you are facing any issues flashing the HEX file, make sure that you have an up-to date daplink firmware.
https://community.arm.com/developer/tools-software/oss-platforms/w/docs/554…
If your output folder contains the HEX file, you can try flashing it by dragging and dropping, and see if it runs the regression tests.
Regards,
Minos Galanakis
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 05 October 2020 14:06
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] Running Tests on Musca-A
Dear all,
I’m a researcher exploring TF-M.
I have a Musca-A board, and I was able to build it with tests.
Now, it seems that the examples running the tests [1] are outdated: I simply do not have the same files.
My understanding is that I should merge two files (secure and non-secure) but it is not clear which ones and how the offset are computed.
Can somebody help me on this?
The output files in the /bin folder are: bl2, tfm_ns, and tfm_s in .axf, .bin, .elf, .hex, .map; tfm_s_ns.bin; and tfm_s_ns_signed.bin.
Best,
[1] https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-docs-nightly/lastSt…
--
Antonio Ken Iannillo, PhD
Research Scientist – SEDAN group
SnT – Interdisciplinary Centre for Security, Reliability and Trust
UNIVERSITÉ DU LUXEMBOURG
CAMPUS KIRCHBERG
29, avenue John F. Kennedy
L-1855 Luxembourg Kirchberg
T +352 46 66 44 9660 | antonioken.iannillo(a)uni.lu<mailto:antonioken.iannillo@uni.lu>
Join the conversation
News<https://wwwen.uni.lu/snt/news_events> | Twitter<https://twitter.com/SnT_uni_lu> | Linkedin<https://www.linkedin.com/school/snt-lu/>
www.uni.lu/snt<http://www.uni.lu/snt>
https://akiannillo.github.io/
P Please consider the environment before printing this e-mail
Dear all,
I’m a researcher exploring TF-M.
I have a Musca-A board, and I was able to build it with tests.
Now, it seems that the examples running the tests [1] are outdated: I simply do not have the same files.
My understanding is that I should merge two files (secure and non-secure) but it is not clear which ones and how the offset are computed.
Can somebody help me on this?
The output files in the /bin folder are: bl2, tfm_ns, and tfm_s in .axf, .bin, .elf, .hex, .map; tfm_s_ns.bin; and tfm_s_ns_signed.bin.
Best,
[1] https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-docs-nightly/lastSt…
--
Antonio Ken Iannillo, PhD
Research Scientist – SEDAN group
SnT – Interdisciplinary Centre for Security, Reliability and Trust
UNIVERSITÉ DU LUXEMBOURG
CAMPUS KIRCHBERG
29, avenue John F. Kennedy
L-1855 Luxembourg Kirchberg
T +352 46 66 44 9660 | antonioken.iannillo(a)uni.lu
Join the conversation
News | Twitter | Linkedin
www.uni.lu/snthttps://akiannillo.github.io/
P Please consider the environment before printing this e-mail
Patches are now up for review.
for TF-M: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6095/1
for tf-m-tests: https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/6097
Any comments / reviews would be appreciated
Raef
________________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 01 October 2020 10:33
To: tf-m(a)lists.trustedfirmware.org; Christopher Brand
Subject: Re: [TF-M] CORE_TEST and the new build system
Yes, it seems like the core tests slipped through conversion. I've already had a report of this and got a patch together but it needs some thorough testing since it affects the linking order.
I'll notify here once the patch is submitted for review. Should be this morning.
Raef
________________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 30 September 2020 23:45
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] CORE_TEST and the new build system
It seems that docs/reference/services/core_test_services_integration_guide.rst hasn’t been updated to reflect the new build system (it says to build using ConfigCoreTest.cmake). That config isn’t mentioned in docs/getting_started/tfm_build_instruction.rst.
So how do I build the CORE_TEST stuff with the new build system (I’m particularly interested in the IRQ test).
Thanks,
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.
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi guys. I'm curious why -fshort-wchar is enabled for ARMCLANG and GNUARM (not IAR, interestingly). This should have little or no impact since wchar_t is so rarely used, and causes incompatibility when I try to link my Zephyr app with TF-M libs.
Øyvind
Would it be possible to know what commit hash of TF-M you are currently using Kevin?
I had thought there was now some error handling in place for this but it's possible that it doesn't work as it should.
Raef
________________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 03 October 2020 14:37
To: tf-m(a)lists.trustedfirmware.org
Cc: nd
Subject: Re: [TF-M] Following the TF-M build example
Hi,
I assume you are building under windows, if that is true, add a -G"Unix Makefiles" in the command line would make it work as a quick fix, since cmake treat the default build system under windows as MSVC.
We are trying to create a patch to enhance this part.
BR
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Kilzer via TF-M
Sent: Saturday, October 3, 2020 8:28 AM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Following the TF-M build example
I’m following the first build example in docs\getting_started\tfm_build_instruction.rst, for the mps2/an521.
cmake -S . -B cmake_build -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake
Building on Windows with gnu, it progresses pretty far then stops with the error shown below.
Any suggestions?
Kevin
-- Configuring done
CMake Error at toolchain_GNUARM.cmake:114 (add_library):
No SOURCES given to target: tfm_s_scatter
Call Stack (most recent call first):
platform/ext/target/mps2/an521/CMakeLists.txt:27 (target_add_scatter_file)
CMake Error at toolchain_GNUARM.cmake:114 (add_library):
No SOURCES given to target: tfm_ns_scatter
Call Stack (most recent call first):
platform/ext/target/mps2/an521/CMakeLists.txt:40 (target_add_scatter_file)
CMake Error at toolchain_GNUARM.cmake:114 (add_library):
No SOURCES given to target: bl2_scatter
Call Stack (most recent call first):
platform/ext/target/mps2/an521/CMakeLists.txt:63 (target_add_scatter_file)
CMake Generate step failed. Build files cannot be regenerated correctly.
Hi,
I assume you are building under windows, if that is true, add a -G"Unix Makefiles" in the command line would make it work as a quick fix, since cmake treat the default build system under windows as MSVC.
We are trying to create a patch to enhance this part.
BR
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Kilzer via TF-M
Sent: Saturday, October 3, 2020 8:28 AM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Following the TF-M build example
I'm following the first build example in docs\getting_started\tfm_build_instruction.rst, for the mps2/an521.
cmake -S . -B cmake_build -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake
Building on Windows with gnu, it progresses pretty far then stops with the error shown below.
Any suggestions?
Kevin
-- Configuring done
CMake Error at toolchain_GNUARM.cmake:114 (add_library):
No SOURCES given to target: tfm_s_scatter
Call Stack (most recent call first):
platform/ext/target/mps2/an521/CMakeLists.txt:27 (target_add_scatter_file)
CMake Error at toolchain_GNUARM.cmake:114 (add_library):
No SOURCES given to target: tfm_ns_scatter
Call Stack (most recent call first):
platform/ext/target/mps2/an521/CMakeLists.txt:40 (target_add_scatter_file)
CMake Error at toolchain_GNUARM.cmake:114 (add_library):
No SOURCES given to target: bl2_scatter
Call Stack (most recent call first):
platform/ext/target/mps2/an521/CMakeLists.txt:63 (target_add_scatter_file)
CMake Generate step failed. Build files cannot be regenerated correctly.
I'm following the first build example in docs\getting_started\tfm_build_instruction.rst, for the mps2/an521.
cmake -S . -B cmake_build -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake
Building on Windows with gnu, it progresses pretty far then stops with the error shown below.
Any suggestions?
Kevin
-- Configuring done
CMake Error at toolchain_GNUARM.cmake:114 (add_library):
No SOURCES given to target: tfm_s_scatter
Call Stack (most recent call first):
platform/ext/target/mps2/an521/CMakeLists.txt:27 (target_add_scatter_file)
CMake Error at toolchain_GNUARM.cmake:114 (add_library):
No SOURCES given to target: tfm_ns_scatter
Call Stack (most recent call first):
platform/ext/target/mps2/an521/CMakeLists.txt:40 (target_add_scatter_file)
CMake Error at toolchain_GNUARM.cmake:114 (add_library):
No SOURCES given to target: bl2_scatter
Call Stack (most recent call first):
platform/ext/target/mps2/an521/CMakeLists.txt:63 (target_add_scatter_file)
CMake Generate step failed. Build files cannot be regenerated correctly.
Hi,
With the new build system, TF-M downloads all dependant repositories to the BUILD folder as part of CMAKE configuration. CMake does provide `make clean` target to clean the build and rebuild but this doesn't track any config changes between the builds. Previously, the CMake workflow was to delete all contents in the BUILD folder before re-configuring for a new build but now this means the developer has to re-download all the dependant git repositories before the project can be build again. This can be a slow and cumbersome process for developers. Deleting the CMakecache.txt doesn't seem to solve the problem either.
The most obvious solution is to move the cloned repositories outside the BUILD/ folder , so we can follow the previous workflow of deleting the BUILD folder before re-build. The sample test sequence to reproduce the problem is given below:
/* Build secure regressions test suite */
$ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug; make install
/* reconfigure and build PSA Crypto API test suite */
$ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug -DTEST_PSA_API=CRYPTO; make install
Built binary is still for regression test suite.
There are multiple suggestions to solve the problem, One is to move the clone repositories outside the BUILD/ folder, or introduce a build target like `make cleanall` which does the equivalent of rm -rf !(lib) within the BUILD folder (i.e the build target will remove all folders except the lib folder which has the cloned repositories). Please let us know of your suggestions on this.
Best Regards
Soby Mathew
Hi All,
The agenda for the forum today:
1. New build system features, tricks and known issues.
See you,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: 28 September 2020 11:39
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] TF-M Technical Forum call – October 1
Hello,
The next Technical Forum is planned on Thursday, October 1 at 15:00-16:00 UTC (US time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Yes, it seems like the core tests slipped through conversion. I've already had a report of this and got a patch together but it needs some thorough testing since it affects the linking order.
I'll notify here once the patch is submitted for review. Should be this morning.
Raef
________________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 30 September 2020 23:45
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] CORE_TEST and the new build system
It seems that docs/reference/services/core_test_services_integration_guide.rst hasn’t been updated to reflect the new build system (it says to build using ConfigCoreTest.cmake). That config isn’t mentioned in docs/getting_started/tfm_build_instruction.rst.
So how do I build the CORE_TEST stuff with the new build system (I’m particularly interested in the IRQ test).
Thanks,
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 Raymond,
Thanks for reporting the issue!
The observed behaviour has two reason:
- In the new build system the default CMAKE_BUILD_TYPE=Release. In this case the logging is disabled in MCUboot to get smaller binary. You can set manualy to Debug in the command line to enable logging from bootloader
* This commit 7d591a684b4abb0f61fbba8668dd6ea7b4b68698 introduced a crash in Musca S1/B1. Fix is ongoing.
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raymond Ngun via TF-M
Sent: 30 September 2020 17:44
To: David Hu via TF-M <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] Musca-B1 and new build system
Hi all,
I am attempting to build Musca-B1 with the latest in master but I'm not able to get it to run (nothing shows on the UART). At a minimum, the User Guide is out of date in terms of how the final hex is created. So, I have a couple questions.
1. Is the latest tested with Musca-B1?
2. Can I obtain some updated information on how to build and create an image for Musca-B1?
Thank you,
Ray
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.
It seems that docs/reference/services/core_test_services_integration_guide.rst hasn't been updated to reflect the new build system (it says to build using ConfigCoreTest.cmake). That config isn't mentioned in docs/getting_started/tfm_build_instruction.rst.
So how do I build the CORE_TEST stuff with the new build system (I'm particularly interested in the IRQ test).
Thanks,
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 all,
I am attempting to build Musca-B1 with the latest in master but I'm not able to get it to run (nothing shows on the UART). At a minimum, the User Guide is out of date in terms of how the final hex is created. So, I have a couple questions.
1. Is the latest tested with Musca-B1?
2. Can I obtain some updated information on how to build and create an image for Musca-B1?
Thank you,
Ray
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 is excellent work and great news for both projects. Well done.
Best,
Adrian
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 30 September 2020 11:13
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Removal of MCUboot fork from TF-M
Hi,
In the last few quarter TF-M team have worked on actively to upstream the TF-M related features from the forked MCUboot repo to the original repository.
This activity has been finished recently and as a result the MCUboot fork has been removed from TF-M repo.
Currently TF-M exclusively relies on MCUboot project as a secure bootloader. From now on all new development will be directly contributed to the upstream repo.
List of feature which were upstreamed:
* HW rollback protection
* HW key integration
* Data exchange between MCUboot and runtime firmware
* RAM_LOAD boot mode
* DIRECT_XIP boot mode
BR,
Tamas Ban
Hi,
In the last few quarter TF-M team have worked on actively to upstream the TF-M related features from the forked MCUboot repo to the original repository.
This activity has been finished recently and as a result the MCUboot fork has been removed from TF-M repo.
Currently TF-M exclusively relies on MCUboot project as a secure bootloader. From now on all new development will be directly contributed to the upstream repo.
List of feature which were upstreamed:
* HW rollback protection
* HW key integration
* Data exchange between MCUboot and runtime firmware
* RAM_LOAD boot mode
* DIRECT_XIP boot mode
BR,
Tamas Ban
