Hi,

What is missing for RAM_LOAD mode:
If I remember well, on problem is the missing “slot” information from MCUBoot. So, the FWU partition only knows which image is running, but it doesn’t know which slot is the active, the primary or the secondary. Another problem is, the FWU partition or MCUboot can only handle the primary slot as active slot.

Dávid

From: Julien Beraud via TF-M <tf-m@lists.trustedfirmware.org>
Sent: 04 March 2025 09:29
To: tf-m@lists.trustedfirmware.org
Subject: [TF-M] Firmware Upgrade in RAM_LOAD mode

Hello Everyone,

We are currently working on TF-M for the firmware of our Cortex-M55 based core, part of a bigger platform

including a cortex-A based application processor, a bit like the corstone1000.

We use the RAM_LOAD boot mode of TF-M/MCUBoot and we want to implement an upgrade strategy based on

2 banks, and a switch to decide which bank to boot from. I have a few questions regarding some design choices.

I hope someone can answer them. Please correct me if some of my assumptions are wrong.

• For the generic Firmware Upgrade partition, are there plans to support the RAM_LOAD mode ? Do you have
  suggestions about what is missing or how it should be done ?

• Currently, MCUBoot in RAM_LOAD mode only supports booting the slot with the highest version.
  Do you think it is realistic to try and integrate another boot mode in MCUBoot that matches our needs ?
  I'm asking this because I noticed that the corstone1000 platform has been developed working around
  this limitation by changing the flash_map at platform initialization in order to abstract the problem from
  MCUBoot completely.

Thank you and all the best,

Julien