Hi Anton,

I think now I finally understand what I what to achieve with TF-M and it may not be achievable.

I was hoping for the TF-M to be able to be able to manage both SPE and NSPE partition containing my LocalLoader using two slots of variable size placed in non-continuous memory.

The PRIMARY LocalLoader slot has fixed start while the SECONDARY LocalLoader slot has fixed end, but byte order in secondary blocks can be reversed so bootloader always knows where to start - that is, at the end of flash memory where the header starts going backwards.

My MainApp remains managed by LocalLoader using Secure FW services, not by TF-M/MCUboot directly.

I am afraid that the above scenario is currently not achievable with TF-M because:
- LocalLoader secondary slot must have a fixed start location
- The memory area that Primary/Secondary slots occupy has to be continuous
- Secondary slot reverse byte order is not supported - although probably fairly easy to implement.

Is my understanding correct?

Kind regards,

Tomasz

From: Anton Komlev <Anton.Komlev@arm.com>
Sent: Tuesday, January 30, 2024 5:32 PM
To: Tomasz Jastrzębski <tdjastrzebski@wp.pl>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: RE: [TF-M] Can primary and secondary images size change in opposite directions?

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.org>
Sent: Thursday, January 25, 2024 9:25 AM
To: 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