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.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.org Sent: 07 November 2023 15:44 To: 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