cancel
Showing results for 
Search instead for 
Did you mean: 

Load SFB from external flash, decrypt and store Internal flash eventually launch from internal flash.

Grogu
Associate III

Device - STM32H7B3I-DK

Base Project : 2_Images_ExtFlash

Objective:

Load SFB from external flash, decrypt and store in Internal flash eventually launch SFB from internal flash.

Setup:

1) Firmware binary for our project may be greater than 1 MB, SFB would be stored into external flash of STM32H7B3I-DK which is received over WIFI.

2) Option is we can directly run from external flash however it will be slow.

Can someone guide what would be good approach to follow considering above constrains.

Started with reducing the size of fimrware image and placing it in internal flash. Download area still would be external memory.

mapping_fwing.ld

__ICFEDIT_SLOT_Active_1_header__ = 0x08010000;

__ICFEDIT_SLOT_Active_1_start__ = 0x08020000;

__ICFEDIT_SLOT_Active_1_end__  = 0x081DFFFF;

1 ACCEPTED SOLUTION

Accepted Solutions
Jocelyn RICARD
ST Employee

Hello @Community member​ ,

With STM32H7B3, you have different possibilities

First you have a simple example:

SBSFU\V2.6.0\Projects\B-L475E-IOT01A\Applications\2_Images_ExtFlash\

This example shows you how to manage 2 firmware images with 2 download slots.

But principle is the same with 1 firmware image (I mean 1 application).

In your case, you put active slot in internal flash and download slot in external flash.

The limitation of such setup is that you will need to use SFU_NO_SWAP setting to avoid having decrypted data in external flash.

Second solution is to use the OTFDEC (On The Fly Decoding) capability of the STM32H7B3

This solution give more flexibility as you can keep encrypted firmware in external flash and even execute it on the fly.

So, if for instance internal flash is not big enough for your application, you can have :

One active slot in internal flash with the main application

One active slot in external flash with the remaining part of your application (bitmaps for instance)

One download slot in external flash for the main application

One download slot in external flash for the remaining part of the application.

In that case you will use the SECBOOT_ECCDSA_WITH_AES128_CTR_SHA256 crypto scheme that is adapted to OTFDEC.

I hope this makes sense !

Best regards

Jocelyn

View solution in original post

3 REPLIES 3
Jocelyn RICARD
ST Employee

Hello @Community member​ ,

With STM32H7B3, you have different possibilities

First you have a simple example:

SBSFU\V2.6.0\Projects\B-L475E-IOT01A\Applications\2_Images_ExtFlash\

This example shows you how to manage 2 firmware images with 2 download slots.

But principle is the same with 1 firmware image (I mean 1 application).

In your case, you put active slot in internal flash and download slot in external flash.

The limitation of such setup is that you will need to use SFU_NO_SWAP setting to avoid having decrypted data in external flash.

Second solution is to use the OTFDEC (On The Fly Decoding) capability of the STM32H7B3

This solution give more flexibility as you can keep encrypted firmware in external flash and even execute it on the fly.

So, if for instance internal flash is not big enough for your application, you can have :

One active slot in internal flash with the main application

One active slot in external flash with the remaining part of your application (bitmaps for instance)

One download slot in external flash for the main application

One download slot in external flash for the remaining part of the application.

In that case you will use the SECBOOT_ECCDSA_WITH_AES128_CTR_SHA256 crypto scheme that is adapted to OTFDEC.

I hope this makes sense !

Best regards

Jocelyn

Thanks for the pointer @Jocelyn RICARD​ 

I see APP crash because the APP image is not decrypted but present in encrypted form at __ICFEDIT_SLOT_Active_1_start__

configure the active slot 1 in internal flash and download area in external slot.

#define SFU_NO_SWAP   
 
__ICFEDIT_SLOT_Active_1_header__ = 0x08010000;
__ICFEDIT_SLOT_Active_1_start__  = 0x08020000;
__ICFEDIT_SLOT_Active_1_end__    = 0x081DFFFF;
 
/* Dwl slot #1  */
__ICFEDIT_SLOT_Dwl_1_start__     = 0x90400000;
__ICFEDIT_SLOT_Dwl_1_end__       = 0x905BFFFF;

Encryption set to

#define SECBOOT_CRYPTO_SCHEME SECBOOT_ECCDSA_WITH_AES128_CTR_SHA256 /*!< Selected Crypto Scheme */

I see the firmware from __ICFEDIT_SLOT_Dwl_1_start__ is not decrypted its just copied over to __ICFEDIT_SLOT_Active_1_start__

0693W00000HpjEwQAJ.pngAfter call SE_Decrypt_Append both fw_encrypted_chunk and fw_decrypted_chunk_size are same value.

#elif ( (SECBOOT_CRYPTO_SCHEME == SECBOOT_ECCDSA_WITHOUT_ENCRYPT_SHA256) || ((SECBOOT_CRYPTO_SCHEME == SECBOOT_ECCDSA_WITH_AES128_CTR_SHA256)) )
  /* Nothing to do as we won't decrypt anything */
  /* Prevent unused argument(s) compilation warning */
  UNUSED(SE_FwType);
  e_ret_status = SE_SUCCESS;
#else
#error "The current example does not support the selected crypto scheme."
#endif /* SECBOOT_CRYPTO_SCHEME */
 
  /* Return status*/
  return e_ret_status;
}

Which leads to application crash when we transfer control from BL to APP

Grogu
Associate III

I guess got it working with SECBOOT_ECCDSA_WITH_AES128_CBC_SHA256 @Jocelyn RICARD​ please correct if my understanding and fix are correct

1) We should not use #define SECBOOT_CRYPTO_SCHEME SECBOOT_ECCDSA_WITH_AES128_CTR_SHA256 since its not implemented in se_crypto_bootloader.c for STM32H7B3I-DK as OTFDEC is used by default.

2) With SECBOOT_ECCDSA_WITH_AES128_CBC_SHA256 the APP header address and slot address should point to same internal flash location same as per example of STM32H7B3I-DK 2_Images ?

#define SECBOOT_CRYPTO_SCHEME SECBOOT_ECCDSA_WITH_AES128_CBC_SHA256 /*!< Selected Crypto Scheme */
 
---
 
/*For  SECBOOT_ECCDSA_WITH_AES128_CBC_SHA256 header and start should point to same location */
/*__ICFEDIT_SLOT_Active_1_header__ = 0x08010000;*/
__ICFEDIT_SLOT_Active_1_start__  = 0x08020000;
__ICFEDIT_SLOT_Active_1_end__    = 0x081DFFFF;
__ICFEDIT_SLOT_Active_1_header__ = __ICFEDIT_SLOT_Active_1_start__;