SBSFU with two active and two download slots

[sute]

Hi,

I have an application using STM32H7B3, SBSFU and TouchGFX. We are running out of flash space so we want to place TouchGFX images to external flash. I understand that to achieve this, we need two SBSFU active and download slots. The first active slot and download slot are for application code, and they need to be placed in the internal flash with read protection. Images don't need read protection, so the second active slot and download slot can be used for them in the external flash.

I am wondering can this be achieved with SBSFU and are there any examples? There is the 2_Images_ExtFlash example for B-L475E-IOT01A, but it has both download slots placed in the external flash which we cannot do since the active firmware slot would be swapped there and it has no read protection. Although, I am a bit confused since the example has no SWAP area so how does it even work?

Thanks!

[Fred]

I will double-check, but as far as I remember:

• the SBSFU code is not really "aware" that the external flahs is encrypted: it only activates the OTFDEC and all operations are handled "smoothly" by the OTFDEC.
• OTFDEC should not hinder the performances

I will x-cehk and come back to you later this week.

[Fred]

Regarding your question about internal FLASH and encryption: I need to check what the code expects.

But, from a design perspective, as soon as we are in internal FLASH, it is acceptable to work with a clear image.

We impose the encryption for the external flash because we are out of the SoC.

As soon as we are in the SoC, we consider that RDP-L2 and other protections are "sufficient".

[sute]

Yes, thank you for checking this! My worry is that when the old unencrypted active image in the internal flash is swapped to download slot, it remains uncencrypted in the download slot.

[Fred]

At first sight, it seems that the swap algorithm does not deal with encrypt/decrypt.

This is "expected" because in our examples the slots always belong to the same FLASH area (either both slots in internal FLASH or both slots in external FLASH).

      /* Copy the block from active slot to dwl slot or swap (using "number_of_chunk" chunks) */
      for (chunk = (number_of_chunk - 1); chunk >= 0 ; chunk--)
      {
        /* ignore return value,  no double ecc error is expected, area already read before */
        (void)SFU_LL_FLASH_Read(buffer, CHUNK_0_ADDR_HEADER(ActiveSlot, index_active_slot, chunk), sizeof(buffer));
        write_len = sizeof(buffer);
        if (index_dwl_slot_write == -1)
        {
          /* Destination block is the swap */
          e_ret_status = SFU_LL_FLASH_Write(&flash_if_status, CHUNK_SWAP_ADDR(chunk), buffer, write_len);
          STATUS_FWIMG(e_ret_status == SFU_ERROR, SFU_IMG_FLASH_WRITE_FAILED);
          if (e_ret_status != SFU_SUCCESS)
          {
            return SFU_ERROR;
          }
        }
...

Also, the OTFDEC seems to be configured in this mode:

#define OTFDEC_REG_MODE_INSTRUCTION_OR_DATA_ACCESSES           OTFDEC_REG_CONFIGR_MODE_1  /*!< All read accesses are decrypted 

So, it does not reencrypt "on the fly".

This does not seem to be available anyway:

https://www.st.com/resource/en/application_note/an5281-how-to-use-otfdec-for-encryptiondecryption-in-trusted-environment-on-stm32h7bxxx-and-stm32h73xx-microcontrollers-stmicroelectronics.pdf

Hence, I would say that by setting the active slot in INTERNAL FLASH and the download slot in EXTERNAL FLASH, then you might end up backup-ing an unencrypted version of the firmware in the EXTERNAL FLASH.

So, I do not recommend this if your firmware needs confidentiality.

But, I guess your initial idea was to have:

• application active and download slots in internal flash
• GFX data in external FLASH ?

This may work.

[sute]

Yes that was the initial idea and I guess we will go with that. Using one active slot in internal and one download slot in external would have saved some more flash space and would have been a bit simpler but the initial idea works too. Thanks anyway!

[Fred]

Another possibility to consider if you really want to optimize the FLASH usage: do you really need the backup feature?

If this is not needed, then let's skip the backup and then you are on the safe side I guess.

You download the encrypted image in EXTERNAL flash.

You decrypt and install it in the active slot in INTERNAL flash.

We do not have any example demonstrating it, but probably you can give a try with SFU_NO_SWAP as a starting point?

As stated by Jocelyn, it would just replace the content of the active slot by the (decrypted) content of the download slot.

In this case, you do not need OTFDEC at all.

So, as you can see, you have several options depending on your exact needs and priorities.

[sute]

Yes, backup is needed. Thanks anyway, we now have plenty of information to go forward!