- TF-M - lists.trustedfirmware.org

by David Hu

Hi all, Profile Medium design document has been uploaded for review on https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4775. I'd like to ask for review and comment. Any suggestion is welcome. Thanks in advance for any help. As part of TF-M Profiles, Profile Medium aims to connect devices to cloud services with asymmetric cipher support. Compared to Profile Small, Profile Medium contains more combabilities and requires more resource. Best regards, Hu Ziji

4 years, 3 months

1
0
0 0

Re: [TF-M] f58bd227, Build: Disable RAM FS by default, breaks Musca_A builds

by Thomas Törnblom

Build steps: --- cmake .. -G"Unix Makefiles" -DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m\configs\ConfigRegressionIPC.cmake -DTARGET_PLATFORM=MUSCA_A -DCOMPILER=GNUARM -DCMAKE_BUILD_TYPE=Debug PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m\cmake_build_gcc> ..\flash_musca.bat C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m\cmake_build_gcc>srec_cat bl2/ext/mcuboot/mcuboot.bin -Binary -offset 0x200000 tfm_sign.bin -Binary -offset 0x220000 -o tfm.hex -Intel C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m\cmake_build_gcc>xcopy tfm.hex g: C:tfm.hex --- terminal output: Adding "-DPS_RAM_FS=ON -DITS_RAM_FS=ON" to the cmake line makes it work again, but I assume that should not be needed. Thomas Den 2020-06-29 kl. 18:58, skrev Thomas Törnblom via TF-M: > I’ve tried with GNUARM, ARMCLANG and IARARM on Win 10. > > I builds fine, but the boot appears to get stuck when starting the > secure image. > > I can provide the exact terminal output tomorrow. > > Thomas > > *Thomas Törnblom*, /Product Engineer/ > IAR Systems AB > Box 23051, Strandbodgatan 1 <x-apple-data-detectors://6/1> > SE-750 23 Uppsala, SWEDEN <x-apple-data-detectors://6/1> > Mobile: +46 76 180 17 80 <tel:+46%2076%20180%2017%2080> Fax: +46 18 16 > 78 01 <tel:+46%2018%2016%2078%2001> > 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> > >> 29 juni 2020 kl. 18:02 skrev Jamie Fox <Jamie.Fox(a)arm.com>: >> >> >> >> Hi Thomas, >> >> This is not expected. Please can you share the error that you see? >> (Might be best to open an issue on developer.trustedfirmware.org for it) >> >> Kind regards, >> >> Jamie >> >> *From:*TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of >> *Thomas Törnblom via TF-M >> *Sent:* 29 June 2020 16:38 >> *To:* tf-m(a)lists.trustedfirmware.org >> *Subject:* [TF-M] f58bd227, Build: Disable RAM FS by default, breaks >> Musca_A builds >> >> Looks like f58bd227 breaks Musca_A builds, or at least it will not >> boot without additional configuration options. >> >> Is this expected? >> >> 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>

4 years, 3 months

1
0
0 0

f58bd227, Build: Disable RAM FS by default, breaks Musca_A builds

by Thomas Törnblom

Looks like f58bd227 breaks Musca_A builds, or at least it will not boot without additional configuration options. Is this expected? 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>

4 years, 3 months

1
0
0 0

Re: [TF-M] Build issues with GNUARM with 7946bdd3

by Kumar Gala

I think I found the issue in cmake/Compiler/GNUARM.cmake not handling “.exe” correctly. Try: diff --git a/cmake/Compiler/GNUARM.cmake b/cmake/Compiler/GNUARM.cmake index fc9db7a0..8fbd97bb 100644 --- a/cmake/Compiler/GNUARM.cmake +++ b/cmake/Compiler/GNUARM.cmake @@ -18,6 +18,7 @@ set(CMAKE_EXECUTABLE_SUFFIX ".axf") if(NOT DEFINED GNUARM_PREFIX) get_filename_component(__c_bin ${CMAKE_C_COMPILER} NAME) string(REPLACE "-gcc" "" GNUARM_PREFIX ${__c_bin}) + string(REPLACE ".exe" "" GNUARM_PREFIX ${GNUARM_PREFIX}) endif() Will work up a proper change if that tests out ok. - k > On Jun 26, 2020, at 7:40 AM, Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Thanks Anton, > > I worked around it with: > > git rebase 7946bdd3 --onto 7946bdd3^ > > Cheers, > Thomas > > Den 2020-06-26 kl. 14:30, skrev Anton Komlev via TF-M: >> Thanks, Thomas. >> >> Yes, it was noted right after RC1 applied. The problem affects the build (not code) on Windows platform only. >> While waiting for the fix we do continue tests using Linux build. >> A fix will be applied or the patch reverted before TF-M release or with RC2, if happen. >> >> Cheers, >> Anton >> >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M >> Sent: 26 June 2020 09:23 >> To: DeMars, Alan via TF-M <tf-m(a)lists.trustedfirmware.org> >> Subject: [TF-M] Build issues with GNUARM with 7946bdd3 >> >> The merge of "Build: Add support for specifying GNUARM_PREFIX" appears to break GNUARM builds. >> >> [100%] Linking C static library mbedcrypto.a >> /usr/bin/sh: CMAKE_GNUARM_AR-NOTFOUND: command not found >> make[5]: *** [library/mbedcrypto.a] Fel 127 >> make[4]: *** [library/CMakeFiles/mbedcrypto.dir/all] Fel 2 >> make[3]: *** [all] Fel 2 >> make[2]: *** [secure_fw/partitions/crypto/mbedcrypto_lib-prefix/src/mbedcrypto_lib-stamp/mbedcrypto_lib-build] Fel 2 >> make[1]: *** [secure_fw/partitions/crypto/CMakeFiles/mbedcrypto_lib.dir/all] Fel 2 >> make: *** [all] Fel 2 >> >> Excluding this commit is a workaround. >> >> This is on Win 10. >> >> 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

4 years, 3 months

1
0
0 0

Re: [TF-M] Alignment issues on stack with ITS

by Jamie Fox

Hi Thomas, It is only the size of the struct that needs to be aligned to the flash program unit, so that the write size is aligned when the struct is programmed to flash. So indeed the attribute puts too strong a constraint on the compiler as it also forces it to allocate these structs at aligned addresses on the stack. The only vaguely clean, portable way I can think of aligning up the size of the struct alone is something like: struct its_file_meta_t_padded { struct its_file_meta_t file_meta; uint8_t pad[ITS_FLASH_MAX_ALIGNMENT - (sizeof(struct its_file_meta_t) % ITS_FLASH_MAX_ALIGNMENT)]; }; But that has the disadvantage of adding ITS_FLASH_MAX_ALIGNMENT to the size of the struct in the case that it is already aligned (no zero-sized arrays), as well as the extra step of accessing the nested struct each time. Would be happy to hear any alternative solutions though. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 26 June 2020 10:07 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Alignment issues on stack with ITS ITS defines a few structs with specific alignment requirements, like: struct __attribute__((__aligned__(ITS_FLASH_MAX_ALIGNMENT))) its_file_meta_t { uint32_t lblock; /*!< Logical datablock where file is * stored */ size_t data_idx; /*!< Offset in the logical data block */ size_t cur_size; /*!< Size in storage system for this # * fragment */ size_t max_size; /*!< Maximum size of this file */ uint32_t flags; /*!< Flags set when the file was created */ uint8_t id[ITS_FILE_ID_SIZE]; /*!< ID of this file */ }; This causes issues with the IAR compiler when these structs are declared as autos: static psa_status_t its_mblock_copy_remaining_block_meta( struct its_flash_fs_ctx_t *fs_ctx, uint32_t lblock) { struct its_block_meta_t block_meta; psa_status_t err; uint32_t meta_block; size_t pos; uint32_t scratch_block; size_t size; ... The IAR compiler gives these errors if the alignment is 0x10 (the stack is 8 byte aligned): struct its_block_meta_t block_meta; ^ "C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m\secure_fw\partitions\internal_trusted_storage\flash_fs\its_flash_fs_mblock.c",415 Error[Ta121]: Auto variable "block_meta" cannot have a stricter alignment than the stack I assume this alignment is only required for the flash, so the alignment attributes should be set when declaring variables in the flash, not on the type. Comments? 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>

4 years, 3 months

1
0
0 0

Re: [TF-M] Build issues with GNUARM with 7946bdd3

by Thomas Törnblom

Thanks Anton, I worked around it with: git rebase 7946bdd3 --onto 7946bdd3^ Cheers, Thomas Den 2020-06-26 kl. 14:30, skrev Anton Komlev via TF-M: > > Thanks, Thomas. > > Yes, it was noted right after RC1 applied. The problem affects the > build (not code) on Windows platform only. > > While waiting for the fix we do continue tests using Linux build. > > A fix will be applied or the patch reverted before TF-M release or > with RC2, if happen. > > Cheers, > > Anton > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of > *Thomas Törnblom via TF-M > *Sent:* 26 June 2020 09:23 > *To:* DeMars, Alan via TF-M <tf-m(a)lists.trustedfirmware.org> > *Subject:* [TF-M] Build issues with GNUARM with 7946bdd3 > > The merge of "Build: Add support for specifying GNUARM_PREFIX" appears > to break GNUARM builds. > > [100%] Linking C static library mbedcrypto.a > /usr/bin/sh: CMAKE_GNUARM_AR-NOTFOUND: command not found > make[5]: *** [library/mbedcrypto.a] Fel 127 > make[4]: *** [library/CMakeFiles/mbedcrypto.dir/all] Fel 2 > make[3]: *** [all] Fel 2 > make[2]: *** > [secure_fw/partitions/crypto/mbedcrypto_lib-prefix/src/mbedcrypto_lib-stamp/mbedcrypto_lib-build] > Fel 2 > make[1]: *** > [secure_fw/partitions/crypto/CMakeFiles/mbedcrypto_lib.dir/all] Fel 2 > make: *** [all] Fel 2 > > Excluding this commit is a workaround. > > This is on Win 10. > > 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>

4 years, 3 months

1
0
0 0

Re: [TF-M] Build issues with GNUARM with 7946bdd3

by Anton Komlev

Thanks, Thomas. Yes, it was noted right after RC1 applied. The problem affects the build (not code) on Windows platform only. While waiting for the fix we do continue tests using Linux build. A fix will be applied or the patch reverted before TF-M release or with RC2, if happen. Cheers, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 26 June 2020 09:23 To: DeMars, Alan via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Build issues with GNUARM with 7946bdd3 The merge of "Build: Add support for specifying GNUARM_PREFIX" appears to break GNUARM builds. [100%] Linking C static library mbedcrypto.a /usr/bin/sh: CMAKE_GNUARM_AR-NOTFOUND: command not found make[5]: *** [library/mbedcrypto.a] Fel 127 make[4]: *** [library/CMakeFiles/mbedcrypto.dir/all] Fel 2 make[3]: *** [all] Fel 2 make[2]: *** [secure_fw/partitions/crypto/mbedcrypto_lib-prefix/src/mbedcrypto_lib-stamp/mbedcrypto_lib-build] Fel 2 make[1]: *** [secure_fw/partitions/crypto/CMakeFiles/mbedcrypto_lib.dir/all] Fel 2 make: *** [all] Fel 2 Excluding this commit is a workaround. This is on Win 10. 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>

4 years, 3 months

1
0
0 0

Re: [TF-M] Build issues with GNUARM with 7946bdd3

by Kumar Gala

> On Jun 26, 2020, at 3:23 AM, Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > The merge of "Build: Add support for specifying GNUARM_PREFIX" appears to break GNUARM builds. > > [100%] Linking C static library mbedcrypto.a > /usr/bin/sh: CMAKE_GNUARM_AR-NOTFOUND: command not found > make[5]: *** [library/mbedcrypto.a] Fel 127 > make[4]: *** [library/CMakeFiles/mbedcrypto.dir/all] Fel 2 > make[3]: *** [all] Fel 2 > make[2]: *** [secure_fw/partitions/crypto/mbedcrypto_lib-prefix/src/mbedcrypto_lib-stamp/mbedcrypto_lib-build] Fel 2 > make[1]: *** [secure_fw/partitions/crypto/CMakeFiles/mbedcrypto_lib.dir/all] Fel 2 > make: *** [all] Fel 2 > > Excluding this commit is a workaround. > > This is on Win 10. > > Cheers, > Thomas Is this issue seen on any other host OS? Linux, Mac OS X? Which specific toolchain are you using? - k

4 years, 3 months

2
1
0 0

Alignment issues on stack with ITS

by Thomas Törnblom

ITS defines a few structs with specific alignment requirements, like: struct __attribute__((__aligned__(ITS_FLASH_MAX_ALIGNMENT))) its_file_meta_t { uint32_t lblock; /*!< Logical datablock where file is * stored */ size_t data_idx; /*!< Offset in the logical data block */ size_t cur_size; /*!< Size in storage system for this # * fragment */ size_t max_size; /*!< Maximum size of this file */ uint32_t flags; /*!< Flags set when the file was created */ uint8_t id[ITS_FILE_ID_SIZE]; /*!< ID of this file */ }; This causes issues with the IAR compiler when these structs are declared as autos: static psa_status_t its_mblock_copy_remaining_block_meta( struct its_flash_fs_ctx_t *fs_ctx, uint32_t lblock) { struct its_block_meta_t block_meta; psa_status_t err; uint32_t meta_block; size_t pos; uint32_t scratch_block; size_t size; ... The IAR compiler gives these errors if the alignment is 0x10 (the stack is 8 byte aligned): struct its_block_meta_t block_meta; ^ "C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m\secure_fw\partitions\internal_trusted_storage\flash_fs\its_flash_fs_mblock.c",415 Error[Ta121]: Auto variable "block_meta" cannot have a stricter alignment than the stack I assume this alignment is only required for the flash, so the alignment attributes should be set when declaring variables in the flash, not on the type. Comments? 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>

4 years, 3 months

1
0
0 0

Build issues with GNUARM with 7946bdd3

by Thomas Törnblom

The merge of "Build: Add support for specifying GNUARM_PREFIX" appears to break GNUARM builds. [100%] Linking C static library mbedcrypto.a /usr/bin/sh: CMAKE_GNUARM_AR-NOTFOUND: command not found make[5]: *** [library/mbedcrypto.a] Fel 127 make[4]: *** [library/CMakeFiles/mbedcrypto.dir/all] Fel 2 make[3]: *** [all] Fel 2 make[2]: *** [secure_fw/partitions/crypto/mbedcrypto_lib-prefix/src/mbedcrypto_lib-stamp/mbedcrypto_lib-build] Fel 2 make[1]: *** [secure_fw/partitions/crypto/CMakeFiles/mbedcrypto_lib.dir/all] Fel 2 make: *** [all] Fel 2 Excluding this commit is a workaround. This is on Win 10. 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>

4 years, 3 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M