Hi Sherry,
Thanks for the info. Wondering if there is some documentation or powerpoint explaining how the MCUBoot is changed to accommodate the FWU API.
Details that would help:
1. How the MCUboot works without the FWU API - natively 2. How the MCUBoot needs to be modified to leverage from FWU API 3. What components are retained in MCUBoot ex: image format, signing, metadata, tools
I am of the belief that MCUboot will be a very thin shim layer over the FWU API to provide the compatibility interface to legacy software and most of the work that was done earlier in MCUboot is pushed down into the FWU partition.
The other way to look at it is: If somebody wants to replace MCUboot with a simple BL to integrate it tightly into TFM, what would that look like?
thanks Suresh Marisetty Infineon Semiconductor Corporation
From: Sherry Zhang Sherry.Zhang2@arm.com Sent: Thursday, May 13, 2021 7:51 PM To: Marisetty Suresh (CYSC CSS ICW SW SSE) Suresh.Marisetty@infineon.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: RE: Firmware update API - MCUboot update
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safehttps://goto.infineon.com/SocialEngineering.
Hi Suresh,
The MCUboot update functionality is about validating the existing images on the device which is different from that of the firmware update service which follows mostly with the PSA Firmware Update API spechttps://developer.arm.com/documentation/ihi0093/latest/.
We designed a shim layer between the firmware update partition and bootloader. A specific bootloader can be ported into the firmware update partition via that shim layer. Please refer to the firmware update service documenthttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/technical_references/tfm_fwu_service.rst#n75. In the MCUboot based shim layer implementation, it calls some user/public APIs provided by MCUboot to achieve its functionality. For example, the Firmware Update API spec describes that psa_fwu_install() API should validate the image or defer the validation to a system reboot. In the MCUboot shim layer implementation, it calls the boot_write_magic() API to mark the image as a candidate image for MCUboot and defers the image validation to a system reboot. Please refer to this linkhttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/partitions/firmware_update/bootloader/mcuboot/tfm_mcuboot_fwu.c#n298.
Can you please provide more specific suggestion or questions?
Regards, Sherry Zhang
From: Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com> Sent: Thursday, May 13, 2021 11:40 PM To: Sherry Zhang <Sherry.Zhang2@arm.commailto:Sherry.Zhang2@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: RE: Firmware update API - MCUboot update
Hi Sherry,
Please take a closer look at the MCUboot and TFM might want to have a clear position/distinction between these two and how to transition from MCUboot update to this mechanism or it could be that they complement each other.
thanks Suresh Marisetty Infineon Semiconductor Corporation
From: Sherry Zhang <Sherry.Zhang2@arm.commailto:Sherry.Zhang2@arm.com> Sent: Wednesday, May 12, 2021 8:55 PM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: RE: Firmware update API - MCUboot update
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safehttps://goto.infineon.com/SocialEngineering.
Hi Suresh,
The firmware update service APIs are for updating the firmware. The functionalities of these APIs includes loading the image into its target device(flash), verifying the image and installing it and so on. The user can call the these APIs to achieve update images. For example, in the integration of TF-M and the FreeRTOS OTAhttps://github.com/Linaro/amazon-freertos/blob/tfm-fwu/libraries/abstractions/ota_pal_psa/README.md#what-is-this-project, the OTA agent calls the firmware update service APIs to achieve an image update remotely.
I guess that the "MCUboot update services" you mentioned refers to the functionality of MCUboot which acts as a bootloader. As a bootloader, it can verify the image which already exists on the device and chose the right image to start up. But it cannot, for example, load the image into device or control the image update process.
The firmware update partition calls some user APIs provided by MCUboot to cooperate with it. You can refer to https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techni....
Regards, Sherry Zhang
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M Sent: Thursday, May 13, 2021 11:09 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Subject: [TF-M] Firmware update API - MCUboot update
Hi,
I would like to see if there is any guidance/documentation on how to coordinate between the firmware update services API with that of MCUboot.
Does the use of this API make the MCUboot update services redundant?
thanks Suresh Marisetty Infineon Semiconductor Corporation Lead Member of Technical Staff CYSC CSS ICW SW SSE Mobile: +5103863997 Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com