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
