Hi Raef,

Thank you for your support.

Do I correctly understand that what I can do is simply load the new content of the secondary slot making sure it is located at the end of the flash space and update the flash map before slot swapped or moved? I thought that flash map was more or less permanently hardcoded bl2 and cannot be ever modified, but if it is updatable, than this might be a solution.

The same time I start to think that maybe I try to solve the problem which does not really exist. Since I am ok with overwriting and losing the MainAppp during every update maybe I can just place the secondary slot right after the primary, swap/move, test, then make it permanent and reload the MainApp overwriting, hence losing the no longer needed content the secondary slot?

Is it a feasible approach? - see the attached diagram. I still occasionally may need to update the flash map since what I mainly want to accomplish is flexibility. It is just hard to predict now how much flash I will need for my LocalLoader and the MainApp for the years, and subsequent versions, to come.

Thanks, Tomasz

-----Original Message----- From: Raef Coles Raef.Coles@arm.com Sent: Wednesday, January 31, 2024 2:18 PM To: Anton Komlev Anton.Komlev@arm.com; tf-m@lists.trustedfirmware.org; Tomasz Jastrzębski tdjastrzebski@wp.pl Cc: nd nd@arm.com Subject: Re: [TF-M] Can primary and secondary images size change in opposite directions? (2)

Hey Tomasz

I think it should be possible, but would require a couple of lesser-used features of MCUBoot.

The memory area that Primary/Secondary slots occupy has to be continuous

I don't believe this to be the case, the primary/secondary slot detection uses `FLASH_AREA_IMAGE_PRIMARY/SECONDARY` to map an image ID to a flash area, and then this flash area ID is looked up in `flash_map` in `flash_map_bl2` to get the details. There shouldn't me any contiguousness requirement, though I think we often do keep them contiguous in TF-M by default.

This leads to the main trick, which is that `flash_map` can be rewritten and doesn't have to be static (though it is in most TF-M platforms). What you could do to avoid the fixed location requirements is to have `boot_platform_pre_load` read the flash, determine the start location somehow, and then update `flash_map` to have the correct address. Note that if you do this then you will have to check the security and correctness of the start location alteration yourself, as it's not explicitly supported by MCUBoot.

Byte order reversal is indeed not supported. I'd reccomend a magic value in order to determine where the image is - mcuboot already has headers and trailer magic value, it should be acceptable to scan for these.

Raef ________________________________________ From: Tomasz Jastrzębski via TF-M tf-m@lists.trustedfirmware.org Sent: 31 January 2024 10:00 To: Anton Komlev; tf-m@lists.trustedfirmware.org Cc: nd Subject: [TF-M] Can primary and secondary images size change in opposite directions? (2)

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

[cid:image001.png@01DA5434.AE0581C0]

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