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