July 2025 - 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

2 weeks, 3 days

15
114
0 0

New Clang/LLVM Toolchain Support Announcement

by Anton Komlev

Hello, I am thrilled to announce the support of new Clan/LLVM toolchain, freely available here: https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm. This extends a suite of powerful tools designed to enhance your development experience and boost productivity. Key Features: * Offers Clang frontend * Available for Linux, Windows and macOS * Builds TF-M binaries for all Arm targets * Secure side built without libc and picolib libraries, while both are available to Bootloader and Non-Secure side Important notes: * Floating point support is not verified * MVE is not supported yet * This has been verified with version v18.1.3 of the toolchain. We're excited for you to try out the new toolchain support and look forward to your feedback. The use of the toolchain_CLANG.cmake is the same as all other toolchains. I plan to present the new toolchain and compare it with the existing tools in one of the upcoming TF-M forums. Meanwhile I encourage the platform owners to include the new toolchain support using arm platforms as a reference. The relevant changes are in this chain: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/34351 There is ongoing discussion on the best name for the toolchain to avoid possible confusion. Should it be Clang as now, LLVM, or even LLVMClang? Please share your opinion. Thanks, and best regards, Anton.

5 months, 1 week

2
2
0 0

Technical Forum call - Sep 12 (East time zone).

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, Sep 12 at 7:00-8:00 UTC (East 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

7 months, 2 weeks

2
21
0 0

by Takekazu Tabata (Fujitsu)

Dear TF-M Team, I'm Takekazu Tabata, a director and architect from the Fujitsu processor team. We are currently developing FUJITSU-MONAKA, which supports the CCA feature. We have three questions regarding the TF-M documents and TF-M implementations. We would greatly appreciate it if you could provide answers. Question 1) In the TF-M document “RSE provisioning”, The CM provisioning Key is used to encrypt DM Provisioning Bundle. https://trustedfirmware-m.readthedocs.io/en/latest/platform/arm/rse/rse_pro… After the cold reset, the RSE will automatically transition to Device Manufacturer provisioning state “DM” as the LCM hardware state-machine reads the values of the cm_config_1 and cm_config_2 fields as non-zero. This state is designed to provision the DM provisioning key, the DM code-encryption key and the DM config. The procedure follows the same steps as the CM provisioning flow, with the exception that the bundle will now be encrypted and signed using the CM provisioning key and must be placed at the base of VM1. However, the purpose of the data provided in the DM is not described in this document. These data are not used in the source code of TF-M v2.2.0. DM provisioning is probably assumed to be done during device manufacturing, but could you explain the purpose in more detail? Also, What are the DM provisioning key, the DM code-encryption key and the DM config used for? Question 2) In the TF-M document “RSE integration guide”, attestation key(CPAK) is derived by GUK. https://trustedfirmware-m.readthedocs.io/en/latest/platform/arm/rse/rse_int…<https://trustedfirmware-m.readthedocs.io/en/latest/platform/arm/rse/rse_int…> The GUK is a key unique to a group of chips that have identical security properties, used to derive the attestation key. However, CPAK is derived from HUK in the source code of TF-M. GUK in the specification is a typo. https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git…<https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git…> /* This derives from HUK, there is a typo in the spec, not from GUK. * FixMe: this should be configurable per platform */ return setup_key_from_derivation(KMU_HW_SLOT_HUK, NULL, iak_seed_label, sizeof(iak_seed_label), NULL, 0, RSE_KMU_SLOT_CPAK_SEED, /* FixMe: The slot needs rename to IAK_SEED */ &aes_key0_export_config, NULL, false, boot_state_config); Which is right, GUK or HUK? If it‘s HUK (not Virtual HUK), is it no problem that multiple CPAKs are generated in Multi-socket systems? Question 3) In the CM/DM lifecycle state, is it no problem to create an original provisioning bundle to run chip or device verification programs in PE? Thank you for your time and assistance. Best regards, TABATA

11 months, 1 week

2
6
0 0

Re: RSE booting with HardFault issue when TRAM enabled

by 김륜현

Hi Raef, I share the issue while applying shared patchset. Because a variable 'dma_channel_amount' is used after the DMA wipe DTCM,   it causes that dma_channel_amount have wrong data when waiting for DMA channel finish.     /* Configure all DMA channels to wipe the DTCM with the random value in parallel. */     for (int idx = 0; idx < dma_channel_amount; idx++) {         /* DMA channel configuration to wipe DTCM*/     }     /* Wait for all the DMA channels to finish */     for (int idx = 0; idx < dma_channel_amount; idx++) { // Error occurs at here         while ((*((volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x000)) & 0x1) != 0) {}     } So i have chosen a way that use defined value using #define like below.     /* Enable the TRAM */     *(volatile uint32_t *)(TRAM_BASE_S + 0x004) = 0x00000001;     /* Generate the TRAM erase random value */     tram_erase_value = *((volatile uint32_t *)(CC3XX_BASE_S + 0x124));     /* Configure all DMA channels to wipe the DTCM with the random value in parallel. */     for (int idx = 0; idx < DMA350_DMA0_CHANNEL_COUNT; idx++) {         /* LINKADDR must be cleared because the command linking is used in DMA H/W boot. */         *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x078) = 0x00000000;                   *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x038) = tram_erase_value;         *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x02c) = 0x000F0044;         *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x018) =             DTCM_CPU0_BASE_S + (DTCM_SIZE / DMA350_DMA0_CHANNEL_COUNT * idx);         *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x030) = 0x00010000;         *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x020) =             (DTCM_SIZE / sizeof(uint64_t) / DMA350_DMA0_CHANNEL_COUNT) << 16;         *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x024) = 0x00000000;         *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x00c) = 0x01200603;         *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x008) = 0x00000000;         *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x000) = 0x00000001;     }     /* Wait for all the DMA channels to finish */     for (int idx = 0; idx < DMA350_DMA0_CHANNEL_COUNT; idx++) {         while ((*((volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x000)) & 0x1) != 0) {}     } Please refer to it. Best Regards RH Kim ----- 원본 메시지 ----- 보낸 사람: Raef Coles <Raef.Coles(a)arm.com> 받는 사람: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.xn--org>,-7104au55ev23e <winxp4333(a)adtek.co.kr> 날짜: 2025-07-28 22:06:49 제목: Re: [TF-M] Re: RSE booting with HardFault issue when TRAM enabled Ah thanks for the testing - I had indeed reused a variable after the TRAM init but before the zero. The following patchset should fix it, and remove the unneeded DMA ICS commands https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/41222/2 https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/41224/1 Thanks, Raef ________________________________________ From: 김륜현 via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 28 July 2025 12:57 To: Raef Coles; tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Re: RSE booting with HardFault issue when TRAM enabled OK, Thank you for sharing the plan. About applying patch you gave,(https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838) Using variables immediately after TRAM enable can cause bus errors due to the same reason we discussing. /* Enable the TRAM */ *(volatile uint32_t *)(TRAM_BASE_S + 0x004) = 0x00000001; In actual, the access to variables in DTCM occur bus error after TRAM enabled. So i modified that it temporarily clear to 0 without using variable. /* Enable the TRAM */ *(volatile uint32_t *)(TRAM_BASE_S + 0x004) = 0x00000001; /* Erase the DTCM */ *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x038) = 0; // FILLVAL *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x02c) = 0x000F0044; // DESTRANSCFG *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x018) = DTCM_CPU0_BASE_S; // DESADDR *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x030) = 0x00010000; // XADDRINC *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x020) = (DTCM_SIZE / sizeof(uint64_t)) << 16; // XSIZE *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x00c) = 0x1200603; // CONFIG *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x008) = 0x00000000; // Disable All Interrupt *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x000) = 0x00000001; // RUN_CMD while ((*((volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x000)) & 0x1) != 0) {} But, it needs to find a fundamental solution. Please check it and i will share the solution if we find good idea. Best Regards RH Kim ----- 원본 메시지 ----- 보낸 사람: Raef Coles <Raef.Coles(a)arm.com> 받는 사람: 김륜현 <winxp4333@adtek.co.kr>,tf-m@lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> 날짜: 2025-07-28 19:28:00 제목: Re: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Yeah you're right, the patch does add some duplication. In future we plan to remove the commands to generate the TRAM key, set the TRAM key, initialize the TRAM and erase the TRAM from the DMA ICS. This way it will always be handled in SW. The issue we have is that the TRAM setup requires retrieving random values from the TRNG, and whether that is possible in the DMA ICS depends on which HW TRNG is being used. With a single register read interface (which is what the ICS assumes) it works okay, but with (for example) the cryptocell TRNG it's not possible to read using the ICS since it requires a poll on a status register and it's not possible to encode that into a DMA command. To avoid having some TRNGs using the ICS and some using SW, we figured it was more sensible to perform the TRAM setup in SW in all cases. I believe that the new SW flow _should_ work if the DMA flow has already been run, but if there are any issues (likely with the KMU keyslot) then the simplest solution is to just remove the DMA commands. Raef ________________________________________ From: 김륜현 <winxp4333(a)adtek.co.kr> Sent: 28 July 2025 02:00 To: Raef Coles; tf-m(a)lists.trustedfirmware.org Subject: Re: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Hi Raef Thanks for your answer. I'm trying to apply your patch our base code, but some of issue occur. I will share the result when the patch is applied properly. Before that, i have a question. As i know, DMA descriptor(Program6) enables TRAM on DMA H/W boot. (platform/ext/target/arm/rse/common/bl1/scripts) I think that it seems to do duplicate operation as S/W about enabling TRAM. Regarding this, is there still no fixed method for enabling TRAM? Best Regards RH Kim ----- 원본 메시지 ----- 보낸 사람: Raef Coles <Raef.Coles(a)arm.com> 받는 사람: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.xn--org>,-7104au55ev23e <winxp4333(a)adtek.co.kr> 날짜: 2025-07-24 21:00:22 제목: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Hey RH Apologies, this has been a known issue for a while (or rather, a series of known issues that we keep fixing). We've just merged a patch upstream which: * Replaces the function calls with fixed register writes to avoid issues with uninitialized global data * Performs DTCM initialization in all cases, avoiding relying on the DMA ICS or having to check the SP mode You can find it here https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838 Unfortunately we've only been able to test it on the FVP at the moment, which has limited ECC support. If you'd be able to test the patch and let me know if it fixes your issue, that would be appreciated. Raef ________________________________________ From: 김륜현 via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 24 July 2025 05:38 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] RSE booting with HardFault issue when TRAM enabled Dear TF-M developers Hello, i'm developing and porting TF-M our platforms based on RDV3R1. To enable TRAM, i modified a cmake config file like below(platform/ext/target/arm/rse/common/config.cmake) - set(RSE_ENABLE_TRAM OFF CACHE BOOL "Whether TRAM encryption is enabled") + set(RSE_ENABLE_TRAM ON CACHE BOOL "Whether TRAM encryption is enabled") First of all, RSE core boots with Virgin CM In this mode, Secure Provisioning is not enabled so that the DTCM don't be initialized even if TRAM is enabled. setup_tram_encryption()(a)startup_rse_bl1_1.c tram_enable_encryption(&tram_dev_s); if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } Because DTCM doesn't be initialized, the next codes which use global variable in BL1_1 data section on DTCM cause hardfault. So, i applied the workaround by modifying condition like below. tram_enable_encryption(&tram_dev_s); - if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { + if ((lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } But the global variable in uninitialized DTCM are also used in bl1_trng_generate_random(). So, i tried to initialize DTCM as 0 without calling bl1_trng_generate_random(). But after that, setting SP_ENABLED for CM Provisioning causes warm reset, TRAM is disabled but DTCM doesn't be initialized. It causes same problem. I know that enabling TRAM is performed DMA descriptor without RSE_ENABLE_TRAM option, it may also cause the problem because of the phenomenon that TRAM is disabled but DTCM doesn't be initialized when warm reset. Should i modify let it use local variable? or is there anything to fix this problem? Best Regards RH Kim

11 months, 3 weeks

1
0
0 0

Re: RSE booting with HardFault issue when TRAM enabled

by 김륜현

OK, Thank you for sharing the plan. About applying patch you gave,(https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838)… Using variables immediately after TRAM enable can cause bus errors due to the same reason we discussing. /* Enable the TRAM */ *(volatile uint32_t *)(TRAM_BASE_S + 0x004) = 0x00000001; In actual, the access to variables in DTCM occur bus error after TRAM enabled. So i modified that it temporarily clear to 0 without using variable.     /* Enable the TRAM */     *(volatile uint32_t *)(TRAM_BASE_S + 0x004) = 0x00000001;     /* Erase the DTCM */     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 +  0x038) = 0; // FILLVAL     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 +  0x02c) = 0x000F0044; // DESTRANSCFG     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 +  0x018) =  DTCM_CPU0_BASE_S; // DESADDR     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x030) = 0x00010000; // XADDRINC     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x020) = (DTCM_SIZE / sizeof(uint64_t)) << 16; // XSIZE     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x00c) = 0x1200603; // CONFIG     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x008) = 0x00000000; // Disable All Interrupt     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x000) = 0x00000001; // RUN_CMD          while ((*((volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x000)) & 0x1) != 0) {} But, it needs to find a fundamental solution. Please check it and i will share the solution if we find good idea. Best Regards RH Kim ----- 원본 메시지 ----- 보낸 사람: Raef Coles <Raef.Coles(a)arm.com> 받는 사람: 김륜현 <winxp4333@adtek.co.kr>,tf-m@lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> 날짜: 2025-07-28 19:28:00 제목: Re: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Yeah you're right, the patch does add some duplication. In future we plan to remove the commands to generate the TRAM key, set the TRAM key, initialize the TRAM and erase the TRAM from the DMA ICS. This way it will always be handled in SW. The issue we have is that the TRAM setup requires retrieving random values from the TRNG, and whether that is possible in the DMA ICS depends on which HW TRNG is being used. With a single register read interface (which is what the ICS assumes) it works okay, but with (for example) the cryptocell TRNG it's not possible to read using the ICS since it requires a poll on a status register and it's not possible to encode that into a DMA command. To avoid having some TRNGs using the ICS and some using SW, we figured it was more sensible to perform the TRAM setup in SW in all cases. I believe that the new SW flow _should_ work if the DMA flow has already been run, but if there are any issues (likely with the KMU keyslot) then the simplest solution is to just remove the DMA commands. Raef ________________________________________ From: 김륜현 <winxp4333(a)adtek.co.kr> Sent: 28 July 2025 02:00 To: Raef Coles; tf-m(a)lists.trustedfirmware.org Subject: Re: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Hi Raef Thanks for your answer. I'm trying to apply your patch our base code, but some of issue occur. I will share the result when the patch is applied properly. Before that, i have a question. As i know, DMA descriptor(Program6) enables TRAM on DMA H/W boot. (platform/ext/target/arm/rse/common/bl1/scripts) I think that it seems to do duplicate operation as S/W about enabling TRAM. Regarding this, is there still no fixed method for enabling TRAM? Best Regards RH Kim ----- 원본 메시지 ----- 보낸 사람: Raef Coles <Raef.Coles(a)arm.com> 받는 사람: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.xn--org>,-7104au55ev23e <winxp4333(a)adtek.co.kr> 날짜: 2025-07-24 21:00:22 제목: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Hey RH Apologies, this has been a known issue for a while (or rather, a series of known issues that we keep fixing). We've just merged a patch upstream which: * Replaces the function calls with fixed register writes to avoid issues with uninitialized global data * Performs DTCM initialization in all cases, avoiding relying on the DMA ICS or having to check the SP mode You can find it here https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838 Unfortunately we've only been able to test it on the FVP at the moment, which has limited ECC support. If you'd be able to test the patch and let me know if it fixes your issue, that would be appreciated. Raef ________________________________________ From: 김륜현 via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 24 July 2025 05:38 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] RSE booting with HardFault issue when TRAM enabled Dear TF-M developers Hello, i'm developing and porting TF-M our platforms based on RDV3R1. To enable TRAM, i modified a cmake config file like below(platform/ext/target/arm/rse/common/config.cmake) - set(RSE_ENABLE_TRAM OFF CACHE BOOL "Whether TRAM encryption is enabled") + set(RSE_ENABLE_TRAM ON CACHE BOOL "Whether TRAM encryption is enabled") First of all, RSE core boots with Virgin CM In this mode, Secure Provisioning is not enabled so that the DTCM don't be initialized even if TRAM is enabled. setup_tram_encryption()(a)startup_rse_bl1_1.c tram_enable_encryption(&tram_dev_s); if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } Because DTCM doesn't be initialized, the next codes which use global variable in BL1_1 data section on DTCM cause hardfault. So, i applied the workaround by modifying condition like below. tram_enable_encryption(&tram_dev_s); - if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { + if ((lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } But the global variable in uninitialized DTCM are also used in bl1_trng_generate_random(). So, i tried to initialize DTCM as 0 without calling bl1_trng_generate_random(). But after that, setting SP_ENABLED for CM Provisioning causes warm reset, TRAM is disabled but DTCM doesn't be initialized. It causes same problem. I know that enabling TRAM is performed DMA descriptor without RSE_ENABLE_TRAM option, it may also cause the problem because of the phenomenon that TRAM is disabled but DTCM doesn't be initialized when warm reset. Should i modify let it use local variable? or is there anything to fix this problem? Best Regards RH Kim

11 months, 3 weeks

2
1
0 0

Re: RSE booting with HardFault issue when TRAM enabled

by Raef Coles

Yeah you're right, the patch does add some duplication. In future we plan to remove the commands to generate the TRAM key, set the TRAM key, initialize the TRAM and erase the TRAM from the DMA ICS. This way it will always be handled in SW. The issue we have is that the TRAM setup requires retrieving random values from the TRNG, and whether that is possible in the DMA ICS depends on which HW TRNG is being used. With a single register read interface (which is what the ICS assumes) it works okay, but with (for example) the cryptocell TRNG it's not possible to read using the ICS since it requires a poll on a status register and it's not possible to encode that into a DMA command. To avoid having some TRNGs using the ICS and some using SW, we figured it was more sensible to perform the TRAM setup in SW in all cases. I believe that the new SW flow _should_ work if the DMA flow has already been run, but if there are any issues (likely with the KMU keyslot) then the simplest solution is to just remove the DMA commands. Raef ________________________________________ From: 김륜현 <winxp4333(a)adtek.co.kr> Sent: 28 July 2025 02:00 To: Raef Coles; tf-m(a)lists.trustedfirmware.org Subject: Re: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Hi Raef Thanks for your answer. I'm trying to apply your patch our base code, but some of issue occur. I will share the result when the patch is applied properly. Before that, i have a question. As i know, DMA descriptor(Program6) enables TRAM on DMA H/W boot. (platform/ext/target/arm/rse/common/bl1/scripts) I think that it seems to do duplicate operation as S/W about enabling TRAM. Regarding this, is there still no fixed method for enabling TRAM? Best Regards RH Kim ----- 원본 메시지 ----- 보낸 사람: Raef Coles <Raef.Coles(a)arm.com> 받는 사람: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>,김륜현 <winxp4333(a)adtek.co.kr> 날짜: 2025-07-24 21:00:22 제목: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Hey RH Apologies, this has been a known issue for a while (or rather, a series of known issues that we keep fixing). We've just merged a patch upstream which: * Replaces the function calls with fixed register writes to avoid issues with uninitialized global data * Performs DTCM initialization in all cases, avoiding relying on the DMA ICS or having to check the SP mode You can find it here https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838 Unfortunately we've only been able to test it on the FVP at the moment, which has limited ECC support. If you'd be able to test the patch and let me know if it fixes your issue, that would be appreciated. Raef ________________________________________ From: 김륜현 via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 24 July 2025 05:38 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] RSE booting with HardFault issue when TRAM enabled Dear TF-M developers Hello, i'm developing and porting TF-M our platforms based on RDV3R1. To enable TRAM, i modified a cmake config file like below(platform/ext/target/arm/rse/common/config.cmake) - set(RSE_ENABLE_TRAM OFF CACHE BOOL "Whether TRAM encryption is enabled") + set(RSE_ENABLE_TRAM ON CACHE BOOL "Whether TRAM encryption is enabled") First of all, RSE core boots with Virgin CM In this mode, Secure Provisioning is not enabled so that the DTCM don't be initialized even if TRAM is enabled. setup_tram_encryption()(a)startup_rse_bl1_1.c tram_enable_encryption(&tram_dev_s); if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } Because DTCM doesn't be initialized, the next codes which use global variable in BL1_1 data section on DTCM cause hardfault. So, i applied the workaround by modifying condition like below. tram_enable_encryption(&tram_dev_s); - if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { + if ((lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } But the global variable in uninitialized DTCM are also used in bl1_trng_generate_random(). So, i tried to initialize DTCM as 0 without calling bl1_trng_generate_random(). But after that, setting SP_ENABLED for CM Provisioning causes warm reset, TRAM is disabled but DTCM doesn't be initialized. It causes same problem. I know that enabling TRAM is performed DMA descriptor without RSE_ENABLE_TRAM option, it may also cause the problem because of the phenomenon that TRAM is disabled but DTCM doesn't be initialized when warm reset. Should i modify let it use local variable? or is there anything to fix this problem? Best Regards RH Kim

11 months, 3 weeks

1
0
0 0

Re: RSE booting with HardFault issue when TRAM enabled

by 김륜현

Hi Raef Thanks for your answer. I'm trying to apply your patch our base code, but some of issue occur.  I will share the result when the patch is applied properly. Before that, i have a question. As i know, DMA descriptor(Program6) enables TRAM on DMA H/W boot. (platform/ext/target/arm/rse/common/bl1/scripts) I think that it seems to do duplicate operation as S/W about enabling TRAM. Regarding this, is there still no fixed method for enabling TRAM? Best Regards RH Kim ----- 원본 메시지 ----- 보낸 사람: Raef Coles <Raef.Coles(a)arm.com> 받는 사람: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.xn--org>,-7104au55ev23e <winxp4333(a)adtek.co.kr> 날짜: 2025-07-24 21:00:22 제목: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Hey RH Apologies, this has been a known issue for a while (or rather, a series of known issues that we keep fixing). We've just merged a patch upstream which: * Replaces the function calls with fixed register writes to avoid issues with uninitialized global data * Performs DTCM initialization in all cases, avoiding relying on the DMA ICS or having to check the SP mode You can find it here https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838 Unfortunately we've only been able to test it on the FVP at the moment, which has limited ECC support. If you'd be able to test the patch and let me know if it fixes your issue, that would be appreciated. Raef ________________________________________ From: 김륜현 via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 24 July 2025 05:38 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] RSE booting with HardFault issue when TRAM enabled Dear TF-M developers Hello, i'm developing and porting TF-M our platforms based on RDV3R1. To enable TRAM, i modified a cmake config file like below(platform/ext/target/arm/rse/common/config.cmake) - set(RSE_ENABLE_TRAM OFF CACHE BOOL "Whether TRAM encryption is enabled") + set(RSE_ENABLE_TRAM ON CACHE BOOL "Whether TRAM encryption is enabled") First of all, RSE core boots with Virgin CM In this mode, Secure Provisioning is not enabled so that the DTCM don't be initialized even if TRAM is enabled. setup_tram_encryption()(a)startup_rse_bl1_1.c tram_enable_encryption(&tram_dev_s); if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } Because DTCM doesn't be initialized, the next codes which use global variable in BL1_1 data section on DTCM cause hardfault. So, i applied the workaround by modifying condition like below. tram_enable_encryption(&tram_dev_s); - if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { + if ((lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } But the global variable in uninitialized DTCM are also used in bl1_trng_generate_random(). So, i tried to initialize DTCM as 0 without calling bl1_trng_generate_random(). But after that, setting SP_ENABLED for CM Provisioning causes warm reset, TRAM is disabled but DTCM doesn't be initialized. It causes same problem. I know that enabling TRAM is performed DMA descriptor without RSE_ENABLE_TRAM option, it may also cause the problem because of the phenomenon that TRAM is disabled but DTCM doesn't be initialized when warm reset. Should i modify let it use local variable? or is there anything to fix this problem? Best Regards RH Kim

11 months, 3 weeks

1
0
0 0

RSE booting with HardFault issue when TRAM enabled

by 김륜현

Dear TF-M developers Hello, i'm developing and porting TF-M our platforms based on RDV3R1. To enable TRAM, i modified a cmake config file like below(platform/ext/target/arm/rse/common/config.cmake) - set(RSE_ENABLE_TRAM                     OFF       CACHE BOOL "Whether TRAM encryption is enabled") + set(RSE_ENABLE_TRAM                     ON       CACHE BOOL "Whether TRAM encryption is enabled") First of all, RSE core boots with Virgin CM  In this mode, Secure Provisioning is not enabled so that the DTCM don't be initialized even if TRAM is enabled.  setup_tram_encryption()(a)startup_rse_bl1_1.c     tram_enable_encryption(&tram_dev_s);     if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) {         bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word));         for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) {             ((uint32_t *)DTCM_BASE_S)[idx] = random_word;         }     } Because DTCM doesn't be initialized, the next codes which use global variable in BL1_1 data section on DTCM cause hardfault. So, i applied the workaround by modifying condition like below.     tram_enable_encryption(&tram_dev_s); -    if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { +   if ((lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) {         bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word));         for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) {             ((uint32_t *)DTCM_BASE_S)[idx] = random_word;         }     } But the global variable in uninitialized DTCM are also used in bl1_trng_generate_random(). So, i tried to initialize DTCM as 0 without calling bl1_trng_generate_random().  But after that, setting SP_ENABLED for CM Provisioning causes warm reset, TRAM is disabled but DTCM doesn't be initialized. It causes same problem. I know that enabling TRAM is performed DMA descriptor without RSE_ENABLE_TRAM option, it may also cause the problem because of the phenomenon that TRAM is disabled but DTCM doesn't be initialized when warm reset. Should i modify let it use local variable?  or is there anything to fix this problem? Best Regards RH Kim

12 months

2
1
0 0

Re: Issue with integrity_checker_compute_value() and cache coherence on RDV3R1 with TF-M

by 박진국

Hi Raef Based on your advice, I made the modifications as below and confirmed that it works properly. Thank you for your help. JK Park enum integrity_checker_error_t integrity_checker_compute_value_bl2(struct integrity_checker_dev_t *dev, enum integrity_checker_mode_t mode, const uint32_t *data, size_t size, uint32_t *value, size_t value_size, size_t *value_len) { //volatile uint32_t __ALIGNED(INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) // temp_val[INTEGRITY_CHECKER_OUTPUT_SIZE_SHA256 / sizeof(uint32_t)] = {0}; //jkpark volatile uint32_t __ALIGNED(32) temp_val[INTEGRITY_CHECKER_OUTPUT_SIZE_SHA256 / sizeof(uint32_t)] = {0}; volatile uint32_t *value_ptr = value; struct _integrity_checker_reg_map_t* p_integrity_checker = (struct _integrity_checker_reg_map_t*)dev->cfg->base; enum integrity_checker_error_t err; uint32_t iccval = 0; err = check_mode_is_supported(dev, mode, true); if (err != INTEGRITY_CHECKER_ERROR_NONE) { return err; } if (value_size < mode_sizes[mode]) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_BUFFER_TOO_SMALL); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_BUFFER_TOO_SMALL; } if (((uintptr_t)data % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_ALIGNMENT); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_ALIGNMENT; } if ((size % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_LENGTH); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_LENGTH; } init_integrity_checker(dev, &iccval); /* Set algorithm */ iccval |= (mode & 0b111) << 1; /* Set to compute mode */ iccval |= 1 << 4; /* Configure input data. Size is in words */ p_integrity_checker->icda = remap_addr(dev, (uintptr_t)data); p_integrity_checker->icdl = size / INTEGRITY_CHECKER_REQUIRED_ALIGNMENT; /* Set output address */ p_integrity_checker->iccva = remap_addr(dev, (uintptr_t)value_ptr); /* Start integrity checker */ iccval |= 1; p_integrity_checker->icc = iccval; /* Poll for any interrupts */ while(!p_integrity_checker->icis) {} /* Check for any unusual error interrupts */ if (p_integrity_checker->icis & (~0b11)) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_OPERATION_FAILED); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_OPERATION_FAILED; } SCB_InvalidateDCache_by_Addr((void *)temp_val, 32); if (value_ptr != value) { for (int idx = 0; idx < mode_sizes[mode] / sizeof(uint32_t); idx++) { value[idx] = value_ptr[idx]; } } if (value_len != NULL) { *value_len = mode_sizes[mode]; } return INTEGRITY_CHECKER_ERROR_NONE; } enum integrity_checker_error_t integrity_checker_check_value_bl2(struct integrity_checker_dev_t *dev, enum integrity_checker_mode_t mode, const uint32_t *data, size_t size, const uint32_t *value, size_t value_size) { //volatile uint32_t __ALIGNED(INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) // temp_val[INTEGRITY_CHECKER_OUTPUT_SIZE_SHA256 / sizeof(uint32_t)] = {0}; //jkpark volatile uint32_t __ALIGNED(32) temp_val[INTEGRITY_CHECKER_OUTPUT_SIZE_SHA256 / sizeof(uint32_t)] = {0}; const volatile uint32_t *value_ptr = value; struct _integrity_checker_reg_map_t* p_integrity_checker = (struct _integrity_checker_reg_map_t*)dev->cfg->base; enum integrity_checker_error_t err; uint32_t iccval = 0; err = check_mode_is_supported(dev, mode, false); if (err != INTEGRITY_CHECKER_ERROR_NONE) { return err; } if (value_size < mode_sizes[mode]) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_CHECK_VALUE_BUFFER_TOO_SMALL); return INTEGRITY_CHECKER_ERROR_CHECK_VALUE_BUFFER_TOO_SMALL; } if (((uintptr_t)data % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_CHECK_VALUE_INVALID_ALIGNMENT); return INTEGRITY_CHECKER_ERROR_CHECK_VALUE_INVALID_ALIGNMENT; } if ((size % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_CHECK_VALUE_INVALID_LENGTH); return INTEGRITY_CHECKER_ERROR_CHECK_VALUE_INVALID_LENGTH; } //if (((uintptr_t)value % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0 // || (value_size % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { for (int idx = 0; idx < value_size / sizeof(uint32_t); idx++) { temp_val[idx] = value[idx]; } value_ptr = temp_val; //} SCB_CleanDCache_by_Addr((void *)temp_val, 32); init_integrity_checker(dev, &iccval); /* Set algorithm */ iccval |= (mode & 0b111) << 1; /* Configure input data. Size is in words */ p_integrity_checker->icda = remap_addr(dev, (uintptr_t)data); p_integrity_checker->icdl = size / INTEGRITY_CHECKER_REQUIRED_ALIGNMENT; /* Set compare address */ p_integrity_checker->iceva = remap_addr(dev, (uintptr_t)value_ptr); /* Start integrity checker */ iccval |= 1; p_integrity_checker->icc = iccval; /* Poll for any interrupts */ while(!p_integrity_checker->icis) {} /* Check for any unusual error interrupts */ if (p_integrity_checker->icis & (~0b11)) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_CHECK_VALUE_OPERATION_FAILED); return INTEGRITY_CHECKER_ERROR_CHECK_VALUE_OPERATION_FAILED; } else if (p_integrity_checker->icis & (0b10)) { /* Check for comparison failure */ NONFATAL_ERR(INTEGRITY_CHECKER_ERROR_CHECK_VALUE_COMPARISON_FAILED); return INTEGRITY_CHECKER_ERROR_CHECK_VALUE_COMPARISON_FAILED; } return INTEGRITY_CHECKER_ERROR_NONE; }

12 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M July 2025