There is a certain number of images and each has 2 slots. The only images that are bootable by TF-M are bl2 and app (NS + S).

The platform is very similar to the corstone1000 and the use case too, only the components are updatable separately.
The "switch" is actually just an active_index to select slot 0 or 1 for each of the images.

So the idea is to get the inactive slot (by reading some metadata in the flash/SD or TLV passed by the BL1), write the new image there, switch the slot

in the metadata (0->1, 1->0) in flash/SD, and then reboot.
We expect the bootloader to try to load the slot indicated in the metadata (and follow the rest of the PSA upgrade process).
We use a non volatile counter to lock versions considered too old but we don't necessarily want to always load the slot with the newest version, we just
want to boot the slot indicated in the metadata. It is what the corstone1000 implements by changing flash_map according to what's read in the
metadata in flash.

We can discuss this on discord if you prefer.

All the best,
Julien

From: David Vincze <David.Vincze@arm.com>
Sent: Wednesday, March 5, 2025 10:57 AM
To: Julien Beraud <julien.beraud@scalinx.com>; David Hazi <David.Hazi@arm.com>; tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Subject: Re: [EXTERNAL] RE: Firmware Upgrade in RAM_LOAD mode

⚠️ CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Regarding the RAM_LOAD upgrade strategy of MCUBoot: the basic idea around which all the upgrade strategies are organized in MCUboot is that it

tries to find the newest version of a given image that is valid, meets all the criteria we expect, and its requirements are also met. I believe there was

no use case in the past that required anything else and for this reason there are no other mechanisms for image selection that I’m aware of.

I would suggest posing this question to the wider MCUboot community on its Discord channel:

(Maybe others who have encountered this same problem already have a solution suggestion.)

May I ask what is the “switch” in your case that decides which image slot to boot from? Do you have

I believe Corstone-1000 choose this solution because it had the lowest impact, but I’ll get back to you if I have more information about their decision.

In the meantime, if you would have a suggested solution for the FWU partition and RAM_LOAD that covers your use case I would be happy to discuss it.

From: Julien Beraud via TF-M <tf-m@lists.trustedfirmware.org>
Date: Tuesday, 2025. March 4. at 15:52
To: David Hazi <David.Hazi@arm.com>, tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Re: [EXTERNAL] RE: Firmware Upgrade in RAM_LOAD mode

Thanks for the feedback and information,

Any idea why the developments on corstone1000 didn't choose to address those issues by adding the relevant functionalities to the FWU partition and MCUBoot ?

Julien

From: David Hazi <David.Hazi@arm.com>
Sent: Tuesday, March 4, 2025 1:49 PM
To: Julien Beraud <julien.beraud@scalinx.com>; tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Subject: [EXTERNAL] RE: Firmware Upgrade in RAM_LOAD mode

You don't often get email from david.hazi@arm.com. Learn why this is important

⚠️ CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

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