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