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#priorities 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.com<mailto: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<mailto:tf-m@lists.trustedfirmware.org>>
Sent: 07 November 2023 15:44
To: tf-m@lists.trustedfirmware.org<mailto: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