Hi Julien,

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: https://discord.com/channels/1106321706588577904/1106322802308550716 (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.

Best regards, Dávid Vincze

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 importanthttps://aka.ms/LearnAboutSenderIdentification

⚠️ 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

Hi Julien,

If “playing” with the image version in the image’s header (as defined by MCUboothttps://github.com/mcu-tools/mcuboot/blob/main/boot/bootutil/include/bootutil/image.h#L160) is not an option I believe this part of the boot logic must be supplemented with a different image selection method. If we are talking about RAM_LOAD the check that should be replaced is the find_slot_with_highest_version()https://github.com/mcu-tools/mcuboot/blob/main/boot/bootutil/src/loader.c#L2854. A few quick thoughts:

* There is the ‘ih_flags’ item in the header where you could use a new flag to indicate the active image but the header is part of the image signature therefore changing it at runtime would practically “corrupt” the image, * Using the unprotected part of the TLV area to indicate the active image with a custom TLV type would be a more obvious solution (if this memory is even available by the runtime FW), but one must think about whether it has any security implications, * A shared memory area could be used between the bootloader and the runtime FW as you already suggested. There is already a mechanism availablehttps://github.com/mcu-tools/mcuboot/blob/main/boot/bootutil/include/bootutil/boot_record.h#L65 to share application specific data (TLV formatted) with runtime. This can be used for example to share which slot is being booted (active slot).

I believe this should be continued on Discord…

Regards, Dávid

From: Julien Beraud julien.beraud@scalinx.com Date: Wednesday, 2025. March 5. at 14:34 To: David Vincze David.Vincze@arm.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 Hello David,

Thanks for your answers.

What we want to implement is an upgrade with different images, and different slots for each of the images. 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

You don't often get email from david.vincze@arm.com. Learn why this is importanthttps://aka.ms/LearnAboutSenderIdentification

⚠️ 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 Julien,

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:

https://discord.com/channels/1106321706588577904/1106322802308550716

(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.

Best regards, Dávid Vincze

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 importanthttps://aka.ms/LearnAboutSenderIdentification

⚠️ 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