Hi Bohdan,

 

The current implementation is supposed to support FWU_COMPONENT_NUMBER > 2. The point you mentioned here is a bug.

  1. Will such change be accepted upstream? Do you see any problems with this change?

The fix looks good to me.

  1. Are there already platforms that support update of more than 2 components?

There is no arm platform support this currently. But I am not sure of other platforms.

  1. Are there any known problems with supporting update of more than 2 components?

I didn’t see other problems except the bug you pointed. Both the PSA FWU API(v1.0) and the FWU service implementation is supposed to support this case. From the code logical, there is no difference between the case of 2 components and the case of more than 2 components. But as not arm platform support more than 2 images currently in TF-M, this case is not fully tested in the implementation. If you have this kind of use case, I would appreciate if this case can be verified on your platform.

 

Thanks,

 

Regards,

Sherry Zhang

 

 

From: Bohdan.Hunko--- via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Thursday, April 6, 2023 10:07 PM
To: tf-m@lists.trustedfirmware.org
Subject: [TF-M] Support of MCUBOOT_IMAGE_NUMBER > 2

 

Hi all,

 

PSA FWU API update to version 1.0 made it easy to support updates of more than 2 images.

To do so platform may define its own FWU_DEVICE_CONFIG_FILE which will contain definitions for all the components.

So it looks like in current implementation FWU service should easily support FWU_COMPONENT_NUMBER > 2 (for example FWU_COMPONENT_NUMBER = 4)

 

The only place that I see that doesn’t support this is secure_fw/partitions/firmware_update/bootloader/mcuboot/tfm_mcuboot_fwu.c file which have following code:

#if (MCUBOOT_IMAGE_NUMBER == 1)

#define MAX_IMAGE_INFO_LENGTH    (sizeof(struct image_version) + \

                                  SHARED_DATA_ENTRY_HEADER_SIZE)

#else

#define MAX_IMAGE_INFO_LENGTH    2 * (sizeof(struct image_version) + \

                                      SHARED_DATA_ENTRY_HEADER_SIZE)

#endif

 

So if MCUBOOT_IMAGE_NUMBER is 4 then MAX_IMAGE_INFO_LENGTH will only account for 2 images. To fix this I propose to change the code to:

#define MAX_IMAGE_INFO_LENGTH    MCUBOOT_IMAGE_NUMBER * (sizeof(struct image_version) + \

                                                         SHARED_DATA_ENTRY_HEADER_SIZE)

 

This change will allow platform to support update of more than 2 components (assuming that platforms implementation of bootloader supports that)

 

So I have few questions:

  1. Will such change be accepted upstream? Do you see any problems with this change?\
  2. Are there already platforms that support update of more than 2 components?
  3. Are there any known problems with supporting update of more than 2 components?

 

 

Regards,

Bohdan Hunko

 

Cypress Semiconductor Ukraine

Engineer

CSUKR CSS ICW SW FW

Mobile: +38099 50 19 714
Bohdan.Hunko@infineon.com