How to modify MCUBoot example to fit the project?

[wesleywong]

Hi ST team,

I am using STM32U5G9 in my project. It would need simple firmware update feature and the image would be received by UART from a zigbee module.

I have read UM2851 and AN5447 application notes and check the SBSFU example in STM32CubeU5 package (v1.8.0) in github.

I believe this is what my project needs:

1. MCUBOOT (Secure area)

2. NS Application (non-secure primary slot)

3. Nonsecure image secondary slot (for firmware update)

4. Authentication and integrity check

5. SWAP mode with scratch region

I want to maximize the flash usage, so it doesn't need:

1. Secure application

2. Secure data

3. Non-secure data

4. Loader

5. Encryption

The bootloader would verify the signature in primary slot and execute the NS application. NS application would write the new image into Nonsecure image secondary slot when firmware update is needed.

I would like to ask:

1. How to modify the SBSFU example to meet above requirement? How should I modify below config file?

- mcuboot_config.h

- flash_layout.h

- region_defs.h

2. Does the SBSFU example include direct-xip mode in its MCUBOOT? I would like to skip the installation time if possible.

3. In SBSFU example, the public key for image authentication is in keys.c. Does it support ECDSA-P256 public key in .pem or .cer format? How to adapt different format of public key in SBSFU example?

[Jocelyn RICARD · Accepted solution]

Hello @wesleywong ,

There is no simple way to remove the secure application. It can be reduced to strict minimum size.

Also, secure application will receive secure fault. If you jump directly from secure boot to non secure application, you will not have any way to manage such fault because secure boot becomes invisible.

SBSFU does not support direct XIP mode.

The keys.c is generated using keygen.sh taking pem files as input. It creates a backup of your current keys before generating new ones.

Best regards

Jocelyn

[wesleywong]

Hi @Jocelyn RICARD ,

Thank you for the reply.

As removing secure application is difficult and I don't really care about secure application, could I just use the secure application in SBSFU example? The only modification would be removing line 124 and 125 (LED1, LED2) in main.c in SBSFU_Appli_Secure.

I would use one image method (MCUBOOT_APP_IMAGE_NUMBER = 1) to maximize flash usage.

I would like to ask:

1. I believe changing the size of secure application slot would be possible and I could set number of both secure and non-secure data slot to 0. But how about NV COUNTER, PS area and ITS area? Should I keep them as 16Kbytes according to UM2851 application note?

2. As I am using one image method, which post build script would merge secure application and non-secure application into one binary and then signing? Or I need to do the merging and signing manually?

3. Is there any reason direct-xip mode is not in SBSFU? I would like to refer the latest MCUboot application and add this feature into SBSFU.

Thank you.

[Jocelyn RICARD]

Hello @wesleywong ,

In your first post you wrote " NS application would write the new image into Nonsecure image secondary slot when firmware update is needed."

This is a 2 slots configuration.

If you want to use only one slot you must use the standalone loader to be able to download the application.

Please use SBSFU example provided in the STM32CubeU5.

In this example you don't have any PS or ITS area. You shouldn't remove NVCNT area, it will not work. NVCNT is used to store firmware version and check you don't rollback to older version.

If you make proper changes in the flash_layout.h, the postbuild scripts will adapt.

SBSFU is provided as example. You are free to make your own adaptation to fit your need.

Best regards

Jocelyn

[wesleywong]

Hi @Jocelyn RICARD ,

Thank you for your reply. One more question. As you mentioned that I shouldn't remove NVCNT area (protected TLV area) because it is for anti-rollback feature.

But my application might need to rollback to previous version. How to disable this feature?

Are below actions enough to disable this feature?

1. Undefined "MCUBOOT_HW_ROLLBACK_PROT" in mcuboot_config.h

2. In application postbuild.sh, delete "-s auto"

Thank you.

[Jocelyn RICARD]

Hello @wesleywong ,

Removing this feature is up to you. I'm sorry I cannot help

Best regards

Jocelyn