port mcuboot demo app to custom board

[horatiosdad]

Have successfully worked through

STM32Cube_FW_U5_V1.8.0/Projects/B-U585I-IOT02A/Applications/SBSFU/readme.html

I need to port this (..boot, ..loader, ..appli) to a custom board running STM32U585VIT6.

Within the readme it states "This example has been tested with STMicroelectronics B-U585I-IOT02A board and can be easily tailored to any other supported device and development board."

Is there an example / idiots guide to work through doing the above?

Thanks

 

[Jocelyn RICARD]

 Hello @horatiosdad ,

no specific documentation is available as far as I know.

Now, the die you are using is exactly the same, only the package is different 100 pins instead of 169.

The porting will only consist in

1) Adapting the UART trace: Select the UART + GPIO that are available on your board. Look for *com*.c or .h files

2) If using the external loader you can force jump using user button detection at boot time. This button is setup in boot_hal.h

That's it

Best regards

Jocelyn

[horatiosdad]

Thanks Jocelyn

Yes the porting of that app in situ to a custom hardware is straight forward.

What I should have asked is

1) What are the steps required to debug (step though etc.) the SBSFU_Appli?

2) What is the recommended process for importing a non secure / non TZ project / application that has already been developed to work with SBSFU.

Regards

 

[Jocelyn RICARD]

Hello @horatiosdad ,

For debugging, first thing to do is to disable the protections : RDP should remain open (level 0), write protection of the secure boot disabled, tamper disabled. That should be enough.

Then you can create a debug configuration with 5 items:

1- the SBSFU_Boot elf file with download option or not

2- The secure app elf file for symbols only

3- the non secure app elf file for symbols only

4 - the secure app init signed binary file at address of secure app execution slot (found in SBSFU_UPDATE.sh)

5 - the non secure app init signed binary file at address of non secure app execution slot 

You can adapt depending on your needs. Not always necessary to flash everything each time.

 

For your second question, I'm don't catch the point. You say it was already developed to work with SBSFU, so could you please elaborate ?

Thank you

Best regards

Jocelyn

[horatiosdad]

Hi Jocelyn

Re my second point my wording was not clear. I meant we have developed a project and now want it to work with SBSFU.......

We have a standalone project developed via CubeMX / CubeIDE etc. so it has all the default .ld files, system_stm..., startup_stm...etc. This includes ThreadX, NexXDuu moddleware and others.

How do I go about porting this into the reference package framework so as it has SBSFU functionality.

Thanks

Jamie