- TF-M - lists.trustedfirmware.org

by Antonio Ken IANNILLO

I just add the verbosity (I initially tough was the cmake verbosity..) to the test libraries. This is the new output is somebody can help: https://pastebin.com/JNQ6TD0K In the specific the failure is at : ‘’’ TEST: 403 | DESCRIPTION: Insufficient space check Input id is 01030000 Input id is 01030000 Input id is 02020000 Input id is 02020000 [Info] Executing tests from non-secure [Info] Executing PS tests [Check 1] Overload storage space Setting 0x00000200 bytes for UID 5 Setting 0x00000200 bytes for UID 6 Setting 0x00000200 bytes for UID 7 Setting 0x00000200 bytes for UID 8 Setting 0x00000200 bytes for UID 9 Setting 0x00000200 bytes for UID 10 Setting 0x00000200 bytes for UID 11 Setting 0x00000200 bytes for UID 12 Setting 0x00000200 bytes for UID 13 UID 13 set failed due to insufficient space Remove all registered UIDs Removing UID 5 Removing UID 6 Removing UID 7 Removing UID 8 Removing UID 9 Removing UID 10 Removing UID 11 Removing UID 12 [Check 2] Overload storage again to verify all previous UID removed Setting 0x00000200 bytes for UID 5 Setting 0x00000200 bytes for UID 6 Setting 0x00000200 bytes for UID 7 Setting 0x00000200 bytes for UID 8 Setting 0x00000200 bytes for UID 9 [INF] Starting bootloader [INF] Swap type: none [INF] Swap type: none [INF] Bootloader chainload address offset: 0x80000 [INF] Jumping to the first image slot [Sec Thread] Secure image initializing! Booting TFM v1.2.0 [Crypto] MBEDTLS_TEST_NULL_ENTROPY is not suitable for production! *** Booting Zephyr OS build v2.5.0-rc1-209-g30634334a811 *** ‘’’ -- Antonio Ken Iannillo

5 years, 4 months

1
0
0 0

Re: [TF-M] Boot data usage

by Ken Liu

Thanks for your inputs. I am seeking if boot data is used for a specific service only - if that is true, this boot data actually can be bound to the specific services, and other could request boot data related services by API. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M Sent: Tuesday, February 9, 2021 8:53 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Boot data usage Hello, On STM platform, The boot data is also used to pass specific information to user different from attestation. For this support a specific Major is used. The actual implementation available in ST cube needs to be reworked so that each platform can customize it (Major value, and table checking access control on tfm core) Best regards 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: mardi 9 février 2021 11:52 To: 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] Boot data usage Hi Ken, AFAIK current implementation of FWU partition also relies on shared data received from bootloader. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 2021. február 9., kedd 10:47 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] Boot data usage Hi, Wondered if someone is expanding the boot data usage, as the default user is attestation only. Please provide your case if you are expanding boot data usage. Thanks! /Ken

5 years, 4 months

1
0
0 0

PSA-ARCH-TEST with zephyr

by Antonio Ken IANNILLO

Dear all, I’m running the PSA-ARCH-TEST (functional api tests) with Zephyr OS (for now emulated with QEMU 5). I followed the instructions to build the test libraries and linked successfully with an easy zephyr application (it just call the val_entry() function). When everything seems working smoothly with Storage tests, I realized that at a certain point the system fails and restarts. Repeatedly. Does any of you have already integrated these tests with zephyr? Did I forget something in the process? I tried also to understand the test that failed everything. It actually overload storage space (without any problem) and do it again (fails after 6 UIDS). Further, any of you know how to have a debug version of the psa-arch-test libraries? Or how to force them to print debug/test message as well… Terminal output is here: https://pastebin.com/ixmeB0kN Thank you very much for your help, -- Antonio Ken Iannillo 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 www.uni.lu/snt https://akiannillo.github.io/

5 years, 4 months

1
0
0 0

Re: [TF-M] Boot data usage

by Michel JAOUEN

Hello, On STM platform, The boot data is also used to pass specific information to user different from attestation. For this support a specific Major is used. The actual implementation available in ST cube needs to be reworked so that each platform can customize it (Major value, and table checking access control on tfm core) Best regards From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: mardi 9 février 2021 11:52 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Boot data usage Hi Ken, AFAIK current implementation of FWU partition also relies on shared data received from bootloader. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 2021. február 9., kedd 10:47 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] Boot data usage Hi, Wondered if someone is expanding the boot data usage, as the default user is attestation only. Please provide your case if you are expanding boot data usage. Thanks! /Ken

5 years, 4 months

1
0
0 0

Re: [TF-M] Boot data usage

by Tamas Ban

Hi Ken, AFAIK current implementation of FWU partition also relies on shared data received from bootloader. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 2021. február 9., kedd 10:47 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Boot data usage Hi, Wondered if someone is expanding the boot data usage, as the default user is attestation only. Please provide your case if you are expanding boot data usage. Thanks! /Ken

5 years, 4 months

1
0
0 0

Boot data usage

by Ken Liu

Hi, Wondered if someone is expanding the boot data usage, as the default user is attestation only. Please provide your case if you are expanding boot data usage. Thanks! /Ken

5 years, 4 months

1
0
0 0

Re: [TF-M] TF-M git repo normalization

by Kevin Peng

Hi, I'd like to give a brief introduction on the git normalization before merging this patch. @Anton Komlev<mailto:Anton.Komlev@arm.com>, can I reserve 15-20 minutes of the next tech forum? Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M Sent: Monday, February 8, 2021 10:56 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M git repo normalization Hi all, Would like to merge the below patch *tomorrow* if there were no objections. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M Sent: Friday, February 5, 2021 10:37 AM To: 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] TF-M git repo normalization This patch was generated by git command automatically: $ git add --renormalize . It does change any contents of the files, except the line-endings in the repository. Your existing local working tree should not be affected when you pick up it or later when it's merged. The only file maintained manually is the .gitattributes Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M Sent: Friday, February 5, 2021 9:53 AM 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] TF-M git repo normalization Hi all, Following the git normalization topic of the tech forum yesterday, I checked TF-M. It has not been enabled the git normalization feature. I've made a patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8283> to make this happen. Please check out or rebase your work upon this patch to see any issues. Your existing working tree should not be affected regarding the line-endings. What is the normalization? To be simple, different developers on different Host OS can have different line-endings in their local working tree and do not need to worry about interference with each other. Reference: https://git-scm.com/docs/gitattributes Best Regards, Kevin

5 years, 4 months

1
0
0 0

Re: [TF-M] TF-M git repo normalization

by Kevin Peng

Hi all, Would like to merge the below patch *tomorrow* if there were no objections. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M Sent: Friday, February 5, 2021 10:37 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M git repo normalization This patch was generated by git command automatically: $ git add --renormalize . It does change any contents of the files, except the line-endings in the repository. Your existing local working tree should not be affected when you pick up it or later when it's merged. The only file maintained manually is the .gitattributes Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M Sent: Friday, February 5, 2021 9:53 AM 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] TF-M git repo normalization Hi all, Following the git normalization topic of the tech forum yesterday, I checked TF-M. It has not been enabled the git normalization feature. I've made a patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8283> to make this happen. Please check out or rebase your work upon this patch to see any issues. Your existing working tree should not be affected regarding the line-endings. What is the normalization? To be simple, different developers on different Host OS can have different line-endings in their local working tree and do not need to worry about interference with each other. Reference: https://git-scm.com/docs/gitattributes Best Regards, Kevin

5 years, 4 months

1
0
0 0

[RFC] Platform data adjustment

by Ken Liu

Hi, I have created a couple of patches to change the way to assemble the partitions, and start with the platform data: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8288 The basic idea is we would avoid using pointer to link data between partitions, as mentioned in one of the past tech forum topics: https://www.trustedfirmware.org/docs/TF-M_partition_storage_arrangement.pdf Please help to review this patch, especially the platform owners, as this change modifies almost all platform sources. Also, I just use a direct 'find and replace' so some of the copyright years are not updated. Would update them in subsequent small patches. Thanks. /Ken

5 years, 4 months

1
0
0 0

Re: [TF-M] Ask for final review on physical attack mitigation design

by David Hu

Hi all, The design document is merged as planned. Thanks a lot for your review! Any further comment or suggestion is always comment. 😊 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Monday, February 1, 2021 4:01 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Ask for final review on physical attack mitigation design Hi all, I’d like to merge the design document of physical attack mitigation in TF-M this week if no further comment. May I ask you to take another look at the following document patch? https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7476 Best regards, Hu Ziji

5 years, 4 months

1
0
0 0

Re: [TF-M] TF-M git repo normalization

by Kevin Peng

This patch was generated by git command automatically: $ git add --renormalize . It does change any contents of the files, except the line-endings in the repository. Your existing local working tree should not be affected when you pick up it or later when it's merged. The only file maintained manually is the .gitattributes Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M Sent: Friday, February 5, 2021 9:53 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M git repo normalization Hi all, Following the git normalization topic of the tech forum yesterday, I checked TF-M. It has not been enabled the git normalization feature. I've made a patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8283> to make this happen. Please check out or rebase your work upon this patch to see any issues. Your existing working tree should not be affected regarding the line-endings. What is the normalization? To be simple, different developers on different Host OS can have different line-endings in their local working tree and do not need to worry about interference with each other. Reference: https://git-scm.com/docs/gitattributes Best Regards, Kevin

5 years, 4 months

1
0
0 0

TF-M git repo normalization

by Kevin Peng

Hi all, Following the git normalization topic of the tech forum yesterday, I checked TF-M. It has not been enabled the git normalization feature. I've made a patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8283> to make this happen. Please check out or rebase your work upon this patch to see any issues. Your existing working tree should not be affected regarding the line-endings. What is the normalization? To be simple, different developers on different Host OS can have different line-endings in their local working tree and do not need to worry about interference with each other. Reference: https://git-scm.com/docs/gitattributes Best Regards, Kevin

5 years, 4 months

1
0
0 0

Re: [TF-M] Technical Forum call - February 4

by Anton Komlev

Hi, Looks like we have an empty agenda for tomorrow's forum. Let's use the time for the free discussion on any TF-M topic. Please raise questions / issues / improvements worth to be discussed within the community. See you, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 28 January 2021 13:29 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - February 4 Hello, The next Technical Forum is planned on Thursday, Feb 4 at 7:00-8: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

5 years, 4 months

1
0
0 0

Re: [TF-M] NXP lpcxpresso55s69 appears broken

by Jamie Fox

Hi Thomas, Sorry about that. I have reproduced the issue on AN521 by copying over the lpcxpresso55s69 storage config. I'll investigate a fix on that platform, but will need you to verify it for me afterwards as I don't have that platform. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 03 February 2021 13:30 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] NXP lpcxpresso55s69 appears broken Looks like this is the commit that breaks the nxp/lpcxpresso55s69 support: --- PS C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m> git bisect good 6a3946aa017fa4da3953a825991f8ce755114637 is the first bad commit commit 6a3946aa017fa4da3953a825991f8ce755114637 Author: Jamie Fox <jamie.fox(a)arm.com><mailto:jamie.fox@arm.com> Date: Mon Dec 7 21:50:31 2020 +0000 Platform: TF-M ITS and PS HAL ... --- Den 2021-02-03 kl. 13:54, skrev Thomas Törnblom via TF-M: I have just fixed an IAR linking issue for the nxp/lpcxpresso55s69, see https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8251 I tried using the current sources, but it seems that there is some issues causing the board to run into a hard fault when built with GNUARM. Not sure what commit caused the breakage. Cheers, 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(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> -- 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(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>

5 years, 4 months

2
1
0 0

Re: [TF-M] NXP lpcxpresso55s69 appears broken

by Kevin Townsend

Hi Jamie, I’ll be happy to test here as well if you add me to the change request. Best regards, Kevin On Wed, 3 Feb 2021 at 16:10, Jamie Fox via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Hi Thomas, > > > > Sorry about that. I have reproduced the issue on AN521 by copying over the > lpcxpresso55s69 storage config. I’ll investigate a fix on that platform, > but will need you to verify it for me afterwards as I don’t have that > platform. > > > > Kind regards, > > Jamie > > > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of *Thomas > Törnblom via TF-M > *Sent:* 03 February 2021 13:30 > *To:* tf-m(a)lists.trustedfirmware.org > *Subject:* Re: [TF-M] NXP lpcxpresso55s69 appears broken > > > > Looks like this is the commit that breaks the nxp/lpcxpresso55s69 support: > --- > PS C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m> git bisect good > 6a3946aa017fa4da3953a825991f8ce755114637 is the first bad commit > commit 6a3946aa017fa4da3953a825991f8ce755114637 > Author: Jamie Fox <jamie.fox(a)arm.com> <jamie.fox(a)arm.com> > Date: Mon Dec 7 21:50:31 2020 +0000 > > Platform: TF-M ITS and PS HAL > ... > --- > > Den 2021-02-03 kl. 13:54, skrev Thomas Törnblom via TF-M: > > I have just fixed an IAR linking issue for the nxp/lpcxpresso55s69, see > https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8251 > > I tried using the current sources, but it seems that there is some issues > causing the board to run into a hard fault when built with GNUARM. > > Not sure what commit caused the breakage. > > Cheers, > 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(a)iar.com Website: www.iar.com > Twitter: www.twitter.com/iarsystems > > > > > > -- > > *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(a)iar.com Website: www.iar.com > Twitter: www.twitter.com/iarsystems > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

5 years, 4 months

1
0
0 0

Re: [TF-M] NXP lpcxpresso55s69 appears broken

by Thomas Törnblom

Looks like this is the commit that breaks the nxp/lpcxpresso55s69 support: --- PS C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m> git bisect good 6a3946aa017fa4da3953a825991f8ce755114637 is the first bad commit commit 6a3946aa017fa4da3953a825991f8ce755114637 Author: Jamie Fox <jamie.fox(a)arm.com> Date: Mon Dec 7 21:50:31 2020 +0000 Platform: TF-M ITS and PS HAL ... --- Den 2021-02-03 kl. 13:54, skrev Thomas Törnblom via TF-M: > I have just fixed an IAR linking issue for the nxp/lpcxpresso55s69, > see https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8251 > > I tried using the current sources, but it seems that there is some > issues causing the board to run into a hard fault when built with GNUARM. > > Not sure what commit caused the breakage. > > Cheers, > 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(a)iar.com <mailto:thomas.tornblom@iar.com> > Website: www.iar.com <http://www.iar.com> > Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> > -- *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(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

5 years, 4 months

1
0
0 0

NXP lpcxpresso55s69 appears broken

by Thomas Törnblom

I have just fixed an IAR linking issue for the nxp/lpcxpresso55s69, see https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8251 I tried using the current sources, but it seems that there is some issues causing the board to run into a hard fault when built with GNUARM. Not sure what commit caused the breakage. Cheers, 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(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

5 years, 4 months

1
0
0 0

Ask for final review on physical attack mitigation design

by David Hu

Hi all, I'd like to merge the design document of physical attack mitigation in TF-M this week if no further comment. May I ask you to take another look at the following document patch? https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7476 Best regards, Hu Ziji

5 years, 5 months

1
0
0 0

Re: [TF-M] Fatal error handler in secure FW - review request

by Kevin Townsend

Oyvind, Thanks for putting this together. Looks quite useful, and saves some monotony debugging. I put together a similar script but as a Python function for GDB: https://gist.github.com/microbuilder/1677a27e4566a28b36a79f954f1dede6 ... having this in C, however, means you don't need to have a Python-enabled version of GDB. Best regards, Kevin On Fri, 29 Jan 2021 at 11:33, Rønningstad, Øyvind via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Hi everyone > > I wanted to make it easier to debug HardFaults/BusFaults/SecureFaults in > TFM, since I’ve gotten quite a few of them while adding the nrf platforms. > > I have created a proposal in > https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7891 and > would like to get some comments on the general idea. > > The proposal gathers a number of different values, especially the ones > that are harder to retrieve in a debugger, like the fault status registers > in SCB. > > The values are placed in memory so they can be inspected in a debugger, > and if built with -DTFM_SPM_LOG_LEVEL=TFM_SPM_LOG_LEVEL_DEBUG they are also > printed. > > Here is an example of the printout: > > FATAL ERROR: HardFault > > Here is some context for the exception: > > EXC_RETURN (LR): 0xFFFFFFBD > > Exception came from non-secure FW in thread mode. > > MSP(_S): 0x200007F8 > > PSP(_S): 0x20000F28 > > Exception frame at: 0x200176D8 > > R0: 0x0000003E > > R1: 0x00000001 > > R2: 0x00000001 > > R3: 0xFFFFFFFF > > R12: 0x00000000 > > LR: 0x00050623 > > PC: 0x00050626 > > CFSR: 0x00000000 > > BFAR: Not Valid > > MMFAR: Not Valid > > HFSR: 0x40000000 > > SFSR: 0x00000000 > > SFAR: Not Valid > > > > BR, Øyvind Rønningstad > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

5 years, 5 months

1
0
0 0

Fatal error handler in secure FW - review request

by Rønningstad, Øyvind

Hi everyone I wanted to make it easier to debug HardFaults/BusFaults/SecureFaults in TFM, since I've gotten quite a few of them while adding the nrf platforms. I have created a proposal in https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7891 and would like to get some comments on the general idea. The proposal gathers a number of different values, especially the ones that are harder to retrieve in a debugger, like the fault status registers in SCB. The values are placed in memory so they can be inspected in a debugger, and if built with -DTFM_SPM_LOG_LEVEL=TFM_SPM_LOG_LEVEL_DEBUG they are also printed. Here is an example of the printout: FATAL ERROR: HardFault Here is some context for the exception: EXC_RETURN (LR): 0xFFFFFFBD Exception came from non-secure FW in thread mode. MSP(_S): 0x200007F8 PSP(_S): 0x20000F28 Exception frame at: 0x200176D8 R0: 0x0000003E R1: 0x00000001 R2: 0x00000001 R3: 0xFFFFFFFF R12: 0x00000000 LR: 0x00050623 PC: 0x00050626 CFSR: 0x00000000 BFAR: Not Valid MMFAR: Not Valid HFSR: 0x40000000 SFSR: 0x00000000 SFAR: Not Valid BR, Øyvind Rønningstad

5 years, 5 months

1
0
0 0

Technical Forum call - February 4

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, Feb 4 at 7:00-8: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

5 years, 5 months

1
0
0 0

Re: [TF-M] Is Musca-A deprecated already?

by Gyorgy Szing

Hi, Just a humble suggestion: capability could be added to cmake to generate a build environment manifest. This could be a JSON or simple text file listing the location and version of each dependency (tool or software). The manifest file could simplify tracking down similar issues. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 28 January 2021 08:38 To: Sherry Zhang <Sherry.Zhang2(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Is Musca-A deprecated already? Thanks Sherry, Appears the current "cysecuretools" has a dependency on imgtool 1.7.0a1, which is likely where it came from. I did build for musca_a last week and I may have updated cysecuretools since then as I had issues with flashing the psoc64, and that must have installed 1.7.0a1. I installed 1.7.1, which caused a dependency error on cysecuretools 3.0.0. Works now! Cheers, Thomas Den 2021-01-28 kl. 03:50, skrev Sherry Zhang: Hi Thomas, The issue is caused by the imgtool package itself. The version 1.7.0a1 is a pre-release version. If you check the line 378 of image.py of the imgtool package of version 1.7.0a1, it does not check the 'None' before accessing the custom_tlvs.items: [cid:image003.jpg@01D6F552.951E90A0] In the version of 1.7.1, it has added the 'None' check at line 389 in image.py: [cid:image004.jpg@01D6F552.951E90A0] In TF-M build system, the custom_tlvs should be 'None'. To solve your issue, I suggest you use a release version of the imgtool package, such as 1.7.1, other than a pre-release one. Please let me know how it goes. Regards, Sherry Zhang From: Thomas Törnblom <thomas.tornblom(a)iar.com><mailto:thomas.tornblom@iar.com> Sent: Wednesday, January 27, 2021 4:46 PM To: Sherry Zhang <Sherry.Zhang2(a)arm.com><mailto:Sherry.Zhang2@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: [TF-M] Is Musca-A deprecated already? Hi Sherry, Looks like I have version 1.7.0a1. PS C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\cmake_build_iar> imgtool version 1.7.0a1 Cheers, Thomas Den 2021-01-27 kl. 09:22, skrev Sherry Zhang: Hi Thomas, Can you share the version of the imgtool package you used? The recommended version is >=1.6.0. We run the build command on Linux locally and it works well. An alternative option is to use the imgtool script from the upstream MCUBoot repo. To achieve that you can copy the folder ./build_dir/lib/ext/mcuboot-src/scripts/imgtool to bl2/ext/mcuboot/scripts/wrapper/. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Tï¿½rnblom via TF-M Sent: Wednesday, January 27, 2021 12:28 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Is Musca-A deprecated already? I'm working on some IAR brokenness for the cypress/psoc64 and for comparison I'm attempting to build for my favorite board, the musca_a, but it seems builds fails now. I think it was working last week, but today I'm unable to build with any of the toolchains. I get the following errors frmo all of them. Here's a gcc build: --- [629/629] Generating tfm_s_ns_signed.bin FAILED: bl2/ext/mcuboot/tfm_s_ns_signed.bin cmd.exe /C "cd /D C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\cmake_build_armclang\bl2\ext\mcuboot && C:\Users\thomasto\AppData\Local\Programs\Python\Python39\python.exe C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/scripts/wrapper/wrapper.py -v 1.2.0 --layout C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/./signing_layout_s_ns.o -k C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/root-RSA-3072.pem --public-key-format full --align 1 --pad --pad-header -H 0x400 -s auto -d "(0, 0.0.0+0)" -d "(1, 0.0.0+0)" tfm_s_ns.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin && "C:\Program Files\CMake\bin\cmake.exe" -E copy C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bin" Traceback (most recent call last): File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 126, in <module> wrap() File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 829, in __call__ return self.main(*args, **kwargs) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 782, in main rv = self.invoke(ctx) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 1066, in invoke return ctx.invoke(self.callback, **ctx.params) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 610, in invoke return callback(*args, **kwargs) File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 121, in wrap img.create(key, public_key_format, enckey, dependencies, boot_record) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\imgtool\image.py", line 378, in create for tag, value in custom_tlvs.items(): AttributeError: 'NoneType' object has no attribute 'items' ninja: build stopped: subcommand failed. --- cmake line: cmake -GNinja -S .. -B . -DTFM_PLATFORM=musca_a "-DTFM_TOOLCHAIN_FILE=..\toolchain_GNUARM.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug -DMCUBOOT_LOG_LEVEL=DEBUG -DTFM_PSA_API=ON I've tested building for several of the other targets, which seems to work, but I don't have any of these here. Ideas? Thanks, 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(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> -- 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(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> -- 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(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>

5 years, 5 months

1
0
0 0

Re: [TF-M] Is Musca-A deprecated already?

by Sherry Zhang

Hi Thomas, Can you share the version of the imgtool package you used? The recommended version is >=1.6.0. We run the build command on Linux locally and it works well. An alternative option is to use the imgtool script from the upstream MCUBoot repo. To achieve that you can copy the folder ./build_dir/lib/ext/mcuboot-src/scripts/imgtool to bl2/ext/mcuboot/scripts/wrapper/. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Wednesday, January 27, 2021 12:28 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Is Musca-A deprecated already? I'm working on some IAR brokenness for the cypress/psoc64 and for comparison I'm attempting to build for my favorite board, the musca_a, but it seems builds fails now. I think it was working last week, but today I'm unable to build with any of the toolchains. I get the following errors frmo all of them. Here's a gcc build: --- [629/629] Generating tfm_s_ns_signed.bin FAILED: bl2/ext/mcuboot/tfm_s_ns_signed.bin cmd.exe /C "cd /D C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\cmake_build_armclang\bl2\ext\mcuboot && C:\Users\thomasto\AppData\Local\Programs\Python\Python39\python.exe C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/scripts/wrapper/wrapper.py -v 1.2.0 --layout C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/./signing_layout_s_ns.o -k C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/root-RSA-3072.pem --public-key-format full --align 1 --pad --pad-header -H 0x400 -s auto -d "(0, 0.0.0+0)" -d "(1, 0.0.0+0)" tfm_s_ns.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin && "C:\Program Files\CMake\bin\cmake.exe" -E copy C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bin" Traceback (most recent call last): File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 126, in <module> wrap() File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 829, in __call__ return self.main(*args, **kwargs) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 782, in main rv = self.invoke(ctx) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 1066, in invoke return ctx.invoke(self.callback, **ctx.params) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 610, in invoke return callback(*args, **kwargs) File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 121, in wrap img.create(key, public_key_format, enckey, dependencies, boot_record) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\imgtool\image.py", line 378, in create for tag, value in custom_tlvs.items(): AttributeError: 'NoneType' object has no attribute 'items' ninja: build stopped: subcommand failed. --- cmake line: cmake -GNinja -S .. -B . -DTFM_PLATFORM=musca_a "-DTFM_TOOLCHAIN_FILE=..\toolchain_GNUARM.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug -DMCUBOOT_LOG_LEVEL=DEBUG -DTFM_PSA_API=ON I've tested building for several of the other targets, which seems to work, but I don't have any of these here. Ideas? Thanks, 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(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>

5 years, 5 months

2
3
0 0

Re: [TF-M] Is Musca-A deprecated already?

by Minos Galanakis

Hi Thomas, I can also confirm that the build works on a system with the linked environment<https://review.trustedfirmware.org/plugins/gitiles/ci/dockerfiles/+/refs/he…> setup. I have tested your command, as well as the two methods listed in the documentation and all appear to be working. Given this opportunity I would like to share that in accordance to the TrustedFirmware.org project maintenance proposal<https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…>, the project should not be removing a platform in without fair notice. In TF-M we try to do so in three steps between releases: * Adding a deprecation warning patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6516> which will notify the users during compilation and runtime. * Marking is as soon to be deprecated in documentation. * Removing the files on or after the marked release. Back to your problem, I would also confirm that there are no environment variables setting a pre-downloaded repository for TF-M tests. Please let us know how it goes. Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 27 January 2021 08:46 To: Sherry Zhang <Sherry.Zhang2(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Is Musca-A deprecated already? Hi Sherry, Looks like I have version 1.7.0a1. PS C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\cmake_build_iar> imgtool version 1.7.0a1 Cheers, Thomas Den 2021-01-27 kl. 09:22, skrev Sherry Zhang: Hi Thomas, Can you share the version of the imgtool package you used? The recommended version is >=1.6.0. We run the build command on Linux locally and it works well. An alternative option is to use the imgtool script from the upstream MCUBoot repo. To achieve that you can copy the folder ./build_dir/lib/ext/mcuboot-src/scripts/imgtool to bl2/ext/mcuboot/scripts/wrapper/. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Wednesday, January 27, 2021 12:28 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Is Musca-A deprecated already? I'm working on some IAR brokenness for the cypress/psoc64 and for comparison I'm attempting to build for my favorite board, the musca_a, but it seems builds fails now. I think it was working last week, but today I'm unable to build with any of the toolchains. I get the following errors frmo all of them. Here's a gcc build: --- [629/629] Generating tfm_s_ns_signed.bin FAILED: bl2/ext/mcuboot/tfm_s_ns_signed.bin cmd.exe /C "cd /D C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\cmake_build_armclang\bl2\ext\mcuboot && C:\Users\thomasto\AppData\Local\Programs\Python\Python39\python.exe C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/scripts/wrapper/wrapper.py -v 1.2.0 --layout C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/./signing_layout_s_ns.o -k C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/root-RSA-3072.pem --public-key-format full --align 1 --pad --pad-header -H 0x400 -s auto -d "(0, 0.0.0+0)" -d "(1, 0.0.0+0)" tfm_s_ns.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin && "C:\Program Files\CMake\bin\cmake.exe" -E copy C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bin" Traceback (most recent call last): File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 126, in <module> wrap() File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 829, in __call__ return self.main(*args, **kwargs) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 782, in main rv = self.invoke(ctx) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 1066, in invoke return ctx.invoke(self.callback, **ctx.params) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 610, in invoke return callback(*args, **kwargs) File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 121, in wrap img.create(key, public_key_format, enckey, dependencies, boot_record) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\imgtool\image.py", line 378, in create for tag, value in custom_tlvs.items(): AttributeError: 'NoneType' object has no attribute 'items' ninja: build stopped: subcommand failed. --- cmake line: cmake -GNinja -S .. -B . -DTFM_PLATFORM=musca_a "-DTFM_TOOLCHAIN_FILE=..\toolchain_GNUARM.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug -DMCUBOOT_LOG_LEVEL=DEBUG -DTFM_PSA_API=ON I've tested building for several of the other targets, which seems to work, but I don't have any of these here. Ideas? Thanks, 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(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> -- 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(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>

5 years, 5 months

1
0
0 0

Is Musca-A deprecated already?

by Thomas Törnblom

I'm working on some IAR brokenness for the cypress/psoc64 and for comparison I'm attempting to build for my favorite board, the musca_a, but it seems builds fails now. I think it was working last week, but today I'm unable to build with any of the toolchains. I get the following errors frmo all of them. Here's a gcc build: --- [629/629] Generating tfm_s_ns_signed.bin FAILED: bl2/ext/mcuboot/tfm_s_ns_signed.bin cmd.exe /C "cd /D C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\cmake_build_armclang\bl2\ext\mcuboot && C:\Users\thomasto\AppData\Local\Programs\Python\Python39\python.exe C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/scripts/wrapper/wrapper.py -v 1.2.0 --layout C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/./signing_layout_s_ns.o -k C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/root-RSA-3072.pem --public-key-format full --align 1 --pad --pad-header -H 0x400 -s auto -d "(0, 0.0.0+0)" -d "(1, 0.0.0+0)" tfm_s_ns.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin && "C:\Program Files\CMake\bin\cmake.exe" -E copy C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bin" Traceback (most recent call last): File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 126, in <module> wrap() File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 829, in __call__ return self.main(*args, **kwargs) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 782, in main rv = self.invoke(ctx) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 1066, in invoke return ctx.invoke(self.callback, **ctx.params) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 610, in invoke return callback(*args, **kwargs) File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 121, in wrap img.create(key, public_key_format, enckey, dependencies, boot_record) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\imgtool\image.py", line 378, in create for tag, value in custom_tlvs.items(): AttributeError: 'NoneType' object has no attribute 'items' ninja: build stopped: subcommand failed. --- cmake line: cmake -GNinja -S .. -B . -DTFM_PLATFORM=musca_a "-DTFM_TOOLCHAIN_FILE=..\toolchain_GNUARM.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug -DMCUBOOT_LOG_LEVEL=DEBUG -DTFM_PSA_API=ON I've tested building for several of the other targets, which seems to work, but I don't have any of these here. Ideas? Thanks, 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(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

5 years, 5 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M