Hi again Raef,
After I managed to workaround that previous issue, I ran the board and the system behaved exactly as I would expect. However, I wanted to debug using STM32CubeIDE and some problems were faced as the following message appears : "File download complete Time elapsed during download operation: 00:00:00.855
Verifying ...
Error: Data mismatch found at address 0x0C014000 (byte = 0xE8 instead of 0x48)
Error: Download verification failed " I want to point out that to be sure that it wasn't any of my configs that were conflicting, I cloned the project from the 1.8.0 version of TF-M and only added the aforementioned alterations on the platform encryption options. The exact same error appeared on this project. I dont know if it helps, but I ran the command readelf -a bl2.elf and on the output, the address indicated is as follows: 1733: 0c014000 0 OBJECT GLOBAL DEFAULT 5 Image$$ER_CODE$$Base
In my project, the exact same variable appears but on a different address, I think it has some kind of meaning. I also tried to set the DEBUG_AUTHENTICATION option to FULL as for default it was CHIP_DEFAULT and the chip default could be other than FULL. I hope you can help me understand where the problem lies. I thank you again for your patience.
Best regards, João Bento
On Wed, Nov 8, 2023 at 9:17 AM Raef Coles Raef.Coles@arm.com wrote:
Ah yes, I remember why this is happening now.
The MCUBoot encryption option doesn't work how you'd intuitively think it'd work (or at least, it doesn't work how _I'd_ intuitively expect it to work). It's designed to encrypt upgrade images, so the primary image the device boots from is unencrypted, and then an encrypted image is delivered to the second slot (via OTA or otherwise), the second slot is decrypted and an upgrade is performed, finishing with the decrypted new image being copied into the primary slot (modulo which upgrade strategy is selected [1]). I hope this helps explain why you could only create encrypted images for the secondary slot
I would, however, expect this procedure to work by default - if there is no image in the primary slot and an encrypted image in the secondary slot the upgrade procedure should run and succeed, and then the boot should proceed. Maybe there's some issue with your moving the secondary slot out of external flash?
With regard to the config, there's some documentation at https://tf-m-user-guide.trustedfirmware.org/configuration/index.html#priorit... about the order in which config options are applied, which might be useful.
Raef
[1] Except if the upgrade strategy is RAM_LOADING, in which case the encryption support works completely differently by having the images encrypted while in QSPI, and they are decrypted when copied into RAM
From: João Bento joao.bentox@gmail.com Sent: 08 November 2023 05:15 To: Raef Coles Cc: tf-m@lists.trustedfirmware.org Subject: Re: [TF-M] Flashing problems on B-U585I-IOT02A
Hi Raef,
Thank you for noticing it, it worked!
I had no idea that those flags were overriden from the original bl2/ext/mcuboot/mcuboot_default_config.cmake file. Apparently that RE_IMAGE_ENCRYPTED option was set automatically after setting
DMCUBOOT_ENC_IMAGES=OFF -DMCUBOOT_ENCRYPT_RSA=OFF.
Also, because these flags were ON, the image required to be written to the secondary slot., but I was not allowing it to write to it when i assigned "RE_IMAGE_ENCRYPTED= 0X00" which resulted in running an encrypted image, as the upgrade would basically be none.
Best regards, João Bento
On Tue, Nov 7, 2023 at 4:14 PM Raef Coles <Raef.Coles@arm.commailto: Raef.Coles@arm.com> wrote: Hey João
I'm not very familiar with that the RE_IMAGE_ENCRYPTED option does in the STM tooling, but I think if you have disabled encryption there you might also need to disable image encryption in the TF-M build system (which is enabled on the B-U585I-IOT02A by default).
The easiest way to do this is to set `-DMCUBOOT_ENC_IMAGES=OFF -DMCUBOOT_ENCRYPT_RSA=OFF` in the cmake command-line, or to edit platform/ext/target/stm/b_u585i_iot02a/config.cmake and perform a clean build
Hopefully this will help, Raef
From: João Bento via TF-M <tf-m@lists.trustedfirmware.orgmailto: tf-m@lists.trustedfirmware.org> Sent: 07 November 2023 15:44 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Subject: [TF-M] Flashing problems on B-U585I-IOT02A
Hello,
I have recently trying to flash the B-U585I-IOT02A board by running the 3 scripts generated in the build folder, as I usually do with the STM32L552 board. However, I encountered some unexpected errors as I noticed that the secure and non-secure images were being written to external flash address spaces. I quickly noticed that this was happening because the "flash_layout.h" file defines the variable "EXTERNAL_FLASH". Additionally, the "image_macros_to_preprocess_bl2.c" set the image as encrypted by default with "RE_IMAGE_ENCRYPTED= 0X01", causing the "TFM_UPDATE.sh" script to write to the secondary slots. I found it quite strange because tf-m presented an off-the-shelf solution for the other board while for this board it assumes the use of an external flash. Nevertheless, I tried to work around these limitations by commenting the EXTERNAL_FLASH variable and assigning the "RE_IMAGE_ENCRYPTED= 0X00" similarly to the stm32l552. This led to the images being written to the primary slots defined in the flash layout, however, in runtime I encountered an error that states "Unable to find bootable image". Therefore, my question is: Do I need to make further adjustments, or is it possible that there's a configuration issue that is not compatible with the board?
Best regards, João Bento