Hi Tomasz,
If I understand you correctly, then your scenario is fully implemented on NSPE side while TF-M is essentially responsible for SPE side only, allowing any functionality of NS application as long as it stays in the memory range allocated for NSPE. Does it help?
I cut the image from the original mail to stay within the size limit (80K).
Best regards, Anton
From: Tomasz Jastrzębski via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Thursday, January 25, 2024 9:25 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Subject: [TF-M] Can primary and secondary images size change in opposite directions?
Hi All,
I'm considering a scenario where users will be able to manually update device firmware from USB pen drive. For this reason, my Main App does not need a secondary copy kept in case update failed. If update fails, user can simply make another attempt a using different media or a different image. However, what needs to be protected against failed update is the Local Loader (LL) - updatable app reading files from pen drive, which updates the Main App. As new versions get developed and functionality is added (e.g. NTFS support), Local Loader (LL) may grow in size. The same time I would like to be able to use all the remaining flash space for the Main App. All the above dictates the flash layout depictured below. Local Loader update may result in the Main App update, but that is OK.
Can primary and secondary LL images size change in opposite directions? Does TF-M support the described scenario? Image size flexibility is my goal. Kind regards, Tomasz Jastrzębski
https://drive.google.com/file/d/17jrIfz0vE6OGJDWvXRn6TqNSh3mAX7e-/view?usp=s...
[cid:image002.png@01DA5399.4D502290]
