June 2024 - TF-M - lists.trustedfirmware.org

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, July 21, 7:00-8:00 UTC (East time zone). Please reply on this email with your proposals for agenda topics. Link to the forum: https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT… Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

6 days, 13 hours

10
80
0 0

FW: Weird behavior of Clang linker

by Bohdan.Hunko＠infineon.com

Hi Just forwarding older private discussion to mailing list to make it publicly available. Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com> From: Antonio De Angelis <Antonio.DeAngelis(a)arm.com> Sent: Thursday, December 14, 2023 15:57 To: Mazurak Roman (CSS ICW SW FW 3) <Roman.Mazurak(a)infineon.com>; Anton Komlev <Anton.Komlev(a)arm.com>; Hunko Bohdan (CSS ICW SW FW 3) <Bohdan.Hunko(a)infineon.com> Subject: Re: Weird behavior of Clang linker Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi Roman, I tried to look in the ELF spec that I could find by googling, but what I can find online doesn't mention the topic of alignment requirements at all other than a brief mention of how the base address and align requirements must be coherent. How the requirement on alignment propagates from sections to execution regions to load regions is still something that I am trying to understand as I can't find an exhaustive description. The info I shared below stem from a personal conversation that I had with the compiler team internally here in Arm, I have now asked for a reference, will revert back to you in case I get one. [cid:0aef50f0-9105-480f-8090-06cfaa06b8d3] Only explicit mention of alignment that I could find is in the armlink manual in section 3.3.3. [cid:ef5c45ef-7d67-433c-9aba-b8fd7cf0d1c0] The suggestion from the compiler team are as I mentioned: 1. just disable the strict checks on alignment (i.e. the linker will be then allowed to add padding as required to meet the constraint imposed by the base address of the load region and the ALIGN attributes, by suppressing the diagnostic or using --legacyalign (on a side note, I believe this is the default behaviour on GCC linker for example) 2. rewrite the scatter file to have all the input sections without alignment requirements in the output section where the vector reside, and then have another output section just after the first output section (i.e. with base address +0) to put all the other input sections with increased alignment. As a side note, the suggestion is to also align base addresses of sections using AlignExpr(+0, 4096) (for example, to align to 0x1000) rather than forcing ALIGN attributes. Note that this shouldn't be too complex to attain point 2 but it is something that at the moment we can't work on, but happily merge it in if you're willing to provide a patch for it. Your suggestion of having multiple output section is as well doable, but probably enough to have two of them. Will get back to you in case I get some more reference about how the alignment requirements in ELF propagate from input section to output sections just to confirm on the spec itself. Hope this helps, please let me know if any questions! Thanks, Antonio ________________________________ From: Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.com> <Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.com>> Sent: Thursday, December 14, 2023 13:37 To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com<mailto:Antonio.DeAngelis@arm.com>>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com> <Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>> Subject: RE: Weird behavior of Clang linker Hi Antonio, We have a use case when output section has following list of input sections: * Vectors with alignment by 0x400. * Partitions sections with alignment by 0x1000. As result output section alignment is 0x1000 and address is incorrect. So, probably it’s necessary to create a separate output section for each input section. Can you share a link to ELF specification with requirements for output section alignment? Best regards, Roman. From: Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Wednesday, December 13, 2023 18:56 To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Hunko Bohdan (CSS ICW SW FW 3) <Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>> Subject: [TF-M] Re: Weird behavior of Clang linker Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi Bohdan, For reference, this is due to armlink being strict on following the ELF specification for which the region alignment is derived as the maximum alignment of the input sections. You can relax this requirement with armlink by either using the --legacyalign option (although it's being deprecated) or suppressing the diagnostic --diag_suppress=6244. In the future, we could try to reorganize the scatter file for the armclang toolchain to avoid using directly ALIGN attributes and align the base address of the execution regions using AlignExpr() instead, but even with this strategy, any alignment requirement which stems from using .aligned directive in assembly or attribute __ ((aligned)) attributes will influence the input sections alignment, hence it will require a deeper restructuring of the scatter file, possibly moving sections with increased alignment in a separate load region just after LR_CODE which must have a base address that forces a natural alignment. Hope this helps. Thanks, Antonio ________________________________ From: Bohdan.Hunko--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Monday, December 11, 2023 13:39 To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Re: Weird behavior of Clang linker Hi Anton, Here is the version I am using: $ armclang --version Product: Arm Development Studio Gold Edition 2020.1 Component: Arm Compiler for Embedded 6.19 Tool: armclang [5e73cb00] Target: unspecified-arm-none-unspecified Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com> From: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Sent: Monday, December 11, 2023 15:34 To: Hunko Bohdan (CSS ICW SW FW 3) <Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: Weird behavior of Clang linker Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi Bohdan, What is Clang version you are using? Thanks, Anton From: Bohdan.Hunko--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Monday, December 11, 2023 12:58 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Weird behavior of Clang linker Hi all, Our platform uses 4KBs alignment in linker files (as this is the requirement of our protection HW). For this reasons I have introduced tfm_s_linker_alignments.h. Everything works fine with GCC but we have a problem with Clang. The problem is that Clang requires LR_CODE to have same alignment as other sections inside of it. Following are the steps to reproduce the issue: 1. Set TFM_LINKER_DEFAULT_ALIGNMENT to 0x1000 in tfm_s_linker_alignments.h 2. Build AN521 with following command line cmake -S . -B build_an521 -DTFM_PLATFORM=arm/mps2/an521 -DTFM_TOOLCHAIN_FILE=./toolchain_ARMCLANG.cmake Expected result: Everything works fine Actual result: Error: L6244E: Load region LR_CODE address (0x10080400) not aligned on a 4096 byte boundary. This error is weird because there is no explicit alignment assigned to LR_CODE region. Would appreciate a help on this as it is a blocking issue for us. Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

1 week

2
2
0 0

Question about random number g

by Zhang, Hao

Hi TF-M and mbedtls community, I am new to TF-M, I have a few questions about CryptoCell and random number generation. Thank you in advance. 1. I figure there seems to have two CryptoCell 312 implementations within TF-M. One under lib/ext/cryptocell-312-runtime and the other under platform/ext/accelerator/cc312/cc312-rom. What are the difference between these two? 2. For lib/ext/cryptocell-312-runtime, it does not define MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG whereas /ext/accelerator/cc312/cc312-rom does. Does that mean cryptocell-312-runtime is initiating RNG cryptodriver by using mbedtls_entropy_add_source whereas cc312-rom is using mbedtls_psa_external_get_random<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…>. If so, may I ask why these two cryptocells take two different approaches? I read from one of the documentation that mbedtls_psa_external_get_random is used when entropy is sufficient. So if entropy is sufficient, is it always preferred to have MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG defined and implements mbedtls_psa_external_get_random? What are the differences between the two approaches. 3. I also found cryptocell-312-runtime defines the entry point function cc3xx_init_random<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…>. But since PSA random number entry point funciton is not complete, the cc3xx_init_random is not being called anywhere, right? [https://opengraph.githubassets.com/17cdebc400b0ed807c620b586b21f3f77ff9c5d3…]<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…> trusted-firmware-m/platform/ext/accelerator/cc312/cc312-rom/psa_driver_api/src/cc3xx_psa_random.c at 8df9cc8baf46252fd188bba1d87333a8daa9a5e8 · zephyrproject-rtos/trusted-firmware-m<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…> Zephyr repository tracking https://git.trustedfirmware.org/trusted-firmware-m.git/ - zephyrproject-rtos/trusted-firmware-m github.com 4. I know random number generation PSA entry point function is in development, may I ask when that would be expected to complete? Thank you very much! Best regards, Hao

9 months, 2 weeks

2
2
0 0

Technical Forum call - July 7

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, July 7, 15:00-16:00 UTC (West time zone). Please reply on this email with your proposals for agenda topics. Link to the forum: https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz… Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

9 months, 2 weeks

10
62
0 0

New to TF-M

by Michael Khoyilar

Hi all I am porting a new SoC to TF-M platform. I know I have missed something in my platform files that I am getting following error message, can someone please guide me. Thanks Built target manifest_tool [ 3%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/uart_stdout.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/nv_counters.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/flash_otp_nv_counters_backend.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/otp_flash.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/provisioning.o [ 8%] Linking C static library libplatform_s.a [ 12%] Built target platform_s [ 13%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/service_api.o [ 13%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/spm/core/psa_interface_sfn.o [ 13%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/__/interface/src/tfm_psa_call.o [ 14%] Linking C static library libtfm_sprt.a [ 17%] Built target tfm_sprt [ 17%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/tfm_boot_data.o [ 17%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/utilities.o [ 18%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/arch/tfm_arch.o [ 18%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/main.o [ 19%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/spm_ipc.o [ 19%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/rom_loader.o [ 20%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/psa_api.o [ 20%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/psa_call_api.o [ 20%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/psa_version_api.o [ 21%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/psa_read_write_skip_api.o [ 21%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/backend_sfn.o [ 23%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/tfm_svcalls.o [ 23%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/tfm_pools.o [ 24%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ns_client_ext/tfm_spm_ns_ctx.o [ 24%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/spm_local_connection.o [ 24%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/arch/tfm_arch_v8m_main.o [ 25%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/platform/ext/common/tfm_hal_nvic.o C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c: In function 'tfm_hal_irq_enable': C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:21:5: warning: implicit declaration of function 'NVIC_EnableIRQ' [-Wimplicit-function-declaration] 21 | NVIC_EnableIRQ((IRQn_Type)irq_num); | ^~~~~~~~~~~~~~ C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:21:21: error: 'IRQn_Type' undeclared (first use in this function) 21 | NVIC_EnableIRQ((IRQn_Type)irq_num); | ^~~~~~~~~ C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:21:21: note: each undeclared identifier is reported only once for each function it appears in C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:21:31: error: expected ')' before 'irq_num' 21 | NVIC_EnableIRQ((IRQn_Type)irq_num); | ~ ^~~~~~~ | ) C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c: In function 'tfm_hal_irq_disable': C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:28:5: warning: implicit declaration of function 'NVIC_DisableIRQ' [-Wimplicit-function-declaration] 28 | NVIC_DisableIRQ((IRQn_Type)irq_num); | ^~~~~~~~~~~~~~~ C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:28:22: error: 'IRQn_Type' undeclared (first use in this function) 28 | NVIC_DisableIRQ((IRQn_Type)irq_num); | ^~~~~~~~~ C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:28:32: error: expected ')' before 'irq_num' 28 | NVIC_DisableIRQ((IRQn_Type)irq_num); | ~ ^~~~~~~ | ) C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c: In function 'tfm_hal_irq_clear_pending': C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:35:5: warning: implicit declaration of function 'NVIC_ClearPendingIRQ' [-Wimplicit-function-declaration] 35 | NVIC_ClearPendingIRQ((IRQn_Type)irq_num); | ^~~~~~~~~~~~~~~~~~~~ C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:35:27: error: 'IRQn_Type' undeclared (first use in this function) 35 | NVIC_ClearPendingIRQ((IRQn_Type)irq_num); | ^~~~~~~~~ C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:35:37: error: expected ')' before 'irq_num' 35 | NVIC_ClearPendingIRQ((IRQn_Type)irq_num);

10 months

2
1
0 0

Re: Firmware Update: Storage Failure While Rejecting a Staged Image

by Cedric Klikpo

Hi Maulik, Thanks for your support. 1. I think I understand why you don’t get the error on the Musca-B1. In fact, we are not using the same flash driver: 1.1. My build uses the `emulated_flash_dvr`, which checks that the byte is erased in flash before attempting a write (this is where I get the error). 1.2. The Musca-B1 platform uses the `qspi_ip6514e_drv`, which does not perform such a check before writing to the flash. From what I understand, the MT25QL Series Flash NOR does not return an error even if you try to write a 1 in a bit that was 0. As such, you do not encounter the error. 2. It is strange that you don’t get the warning when MCUBOOT_CONFIRM_IMAGE=OFF. Best regards, Cédric

10 months, 1 week

1
0
0 0

Re: Firmware Update: Storage Failure While Rejecting a Staged Image

by Maulik Patel

Hello Cedric, I built with both MCUBOOT_CONFIRM_IMAGE=OFF (default config for musca b1) and MCUBOOT_CONFIRM_IMAGE=ON and in both cases, I do not get any error/warning. Running Test Suite PSA firmware update NS interface tests (TFM_NS_FWU_TEST_1xxx)... > Executing 'TFM_NS_FWU_TEST_1001' Description: 'Functionity test.' TEST: TFM_NS_FWU_TEST_1001 - PASSED! > Executing 'TFM_NS_FWU_TEST_1002' ... Best Regards, Maulik ________________________________ From: tf-m-request(a)lists.trustedfirmware.org <tf-m-request(a)lists.trustedfirmware.org> Sent: 13 June 2024 1:00 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: TF-M Digest, Vol 68, Issue 13 Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to tf-m-request(a)lists.trustedfirmware.org You can reach the person managing the list at tf-m-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-M digest..." Today's Topics: 1. Re: Firmware Update: Storage Failure While Rejecting a Staged Image (cedric.klikpo(a)scalinx.com) ---------------------------------------------------------------------- Message: 1 Date: Wed, 12 Jun 2024 14:06:16 -0000 From: cedric.klikpo(a)scalinx.com Subject: [TF-M] Re: Firmware Update: Storage Failure While Rejecting a Staged Image To: tf-m(a)lists.trustedfirmware.org Message-ID: <171820117605.1175.3411332003376446357(a)lists.trustedfirmware.org> Content-Type: text/plain; charset="utf-8" Hi Maulik, Sorry, I forgot to mention that I got the error when the image is built with the option "MCUBOOT_CONFIRM_IMAGE" enabled. When, when this option is not enable, I do not get the error, and the FWU test status is PASSED. However, the test is marked as passed with the following warning, which clearly states that the testcase is skipped: ``` Executing 'TFM_NS_FWU_TEST_1001' Description: 'Functionality test.' The component isn't in READY state: the device is not ready to run FWU tests, skip FWU test: 1. TEST: TFM_NS_FWU_TEST_1001 - PASSED! ``` So, I would like to confirm with you: 1. When you enable the option "MCUBOOT_CONFIRM_IMAGE," does your TFM_NS_FWU_TEST_1001 testcase pass? 2. When you disable the option "MCUBOOT_CONFIRM_IMAGE," do you get the same warning? Best regards, Cédric ------------------------------ Subject: Digest Footer TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org ------------------------------ End of TF-M Digest, Vol 68, Issue 13 ************************************

10 months, 1 week

1
0
0 0

Re: Firmware Update: Storage Failure While Rejecting a Staged Image

by Maulik Patel

Hello Cedric Unfortunately we only have musca b1 support for FWU at the moment. However as you mentioned, I did try TFM version 1.8.0 on commit *35ac80c85 and all tests (secure and non-secure including FWU) passes without any issues. Best Regards, Maulik

10 months, 1 week

2
1
0 0

Re: Firmware Update: Storage Failure While Rejecting a Staged Image

by Maulik Patel

Hello Cedric, I tried the FWU tests on musca b1 platform and all of them passes without any failures. Could you please provide more context on specific version/commit or platform where you encounter PSA_ERROR_STORAGE_FAILURE? Best Regards, Maulik ________________________________ From: tf-m-request(a)lists.trustedfirmware.org <tf-m-request(a)lists.trustedfirmware.org> Sent: 07 June 2024 1:00 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: TF-M Digest, Vol 68, Issue 6 Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to tf-m-request(a)lists.trustedfirmware.org You can reach the person managing the list at tf-m-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-M digest..." Today's Topics: 1. Firmware Update: Storage Failure While Rejecting a Staged Image (cedric.klikpo(a)scalinx.com) ---------------------------------------------------------------------- Message: 1 Date: Thu, 06 Jun 2024 13:00:29 -0000 From: cedric.klikpo(a)scalinx.com Subject: [TF-M] Firmware Update: Storage Failure While Rejecting a Staged Image To: tf-m(a)lists.trustedfirmware.org Message-ID: <171767882935.438215.6657950002748011855(a)lists.trustedfirmware.org> Content-Type: text/plain; charset="utf-8" Hi, I encounter a storage failure when trying to reject a staged image. I get this error by executing `tfm_fwu_test_common_001` in `fwu_tests_common.c`. The error occurs when the `erase_boot_magic` function attempts to erase the magic number in the image trailer by writing erase into it. The reason I am writing this post is to ask: 1. If the `erase_boot_magic` failure is a known bug in the firmware update, is a fix planned or existing? 2. Why doesn't the `erase_boot_magic` function erase the sector where the magic number is located in the image trailer, considering we erasing in a flash? Thanks! Best regards, Cedric ------------------------------ Subject: Digest Footer TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org ------------------------------ End of TF-M Digest, Vol 68, Issue 6 ***********************************

10 months, 1 week

2
1
0 0

API_DISPATCH for tfm_crypto_api.c

by Quach, Brian

Hi, I noticed that trusted-firmware-m\interface\src\tfm_crypto_api.c defines two API_DISPATCH macros for psa_call(). It is used most of the time in the file, but I still see ~10 instances where psa_call() is used. Can it be changed to consistently use the API_DISPATCH macros. Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

10 months, 1 week

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M June 2024