OEMiROT - ROT_Provisioning folder location

[giubacchio]

Hello,

I’m working with a project with STM32h563 micro which includes the use of the OEMiROT bootloader. I tried different solution to set up the project, and, in order to use CubeMX, I think this is the “normal” way. 

However, there are some things that look awkward to me.

1. If you want to use the OEMiROT bootloader included in the firmware package mentioned in the tutorial, it seems to be mandatory to strictly respect the folder tree given used inside the package. This means that your application project has to reside in STM32Cube_FW_H5_V1.6.0/Projects/NUCLEO-H563ZI/Applications/ROT/ even if you are not using a NUCLEO board.
2. When, in CubeMX, you set the Boot Path and Debug Authentication options, you can modify the OEM_iROT reference location but not the Config Files Location, which is mandatory to be inside the ROT_Provisioning folder automatically created inside the newly created application (e.g. STM32Cube_FW_H5_V1.6.0/Projects/NUCLEO-H563ZI/Applications/ROT/ROT_Provisioning). However, if it is not present a similar ROT_Provisioning folder inside the parent directory STM32Cube_FW_H5_V1.6.0/Projects/NUCLEO-H563ZI/ROT_Provisioning. This means that two similar ROT_Provisioning folders have to exist inside the project, making the organization quite messy.

Probably I am misunderstanding something, but I found the process really complicated and it is very easy to broke some ring of the chain. I’m using CubeMX 6.17.

Thank you,
Giulio

[giubacchio]

Sorry but I have lost a part of the second bullet point. 

2. … However, if it is not present a similar ROT_Provisioning folder inside the parent directory STM32Cube_FW_H5_V1.6.0/Projects/NUCLEO-H563ZI/ROT_Provisioning it seems not possible to link the OEMiROT bootloader to the current project. This would mean that two similar ROT_Provisioning folders have to exist inside the project to make it works.

Thank you,

Giulio

[JesperEC]

Hi,

I have not tested the Boot Path and Debug Authentication with STM32CubeMX. But with regards to point 1.

Sorry for this being somewhat rant-y - others may have different opinions on this.

 

You can patch Projects/NUCLEO-H563ZI/ROT_Provisioning/env.sh and Projects/NUCLEO-H563ZI/Applications/ROT/OEMiROT_Boot/STM32CubeIDE/postbuild.sh to put your application code outside of ST’s code tree.

I have done this, but to be honest - in my next project I will use a different approach.

All these scripts (env.sh, postbuild.sh, the scripts in Projects/NUCLEO-H563ZI/ROT_Provisioning) and the applicfg-system that tries parse C headers to hunt for flash area size and address definitions (be very wary of trying to put more complicated expressions in flash_layout.h - things will fail silently - at least in 1.5.0!) are only there to make the provided demo system with OEMiROT and the demo split secure/non-secure app easy to run. Especially, you can toy around with the flash layout and still do a one click build-and-deploy to the Nucleo board and get the LED blinking.

Kudos to ST for providing a low barrier of entry setup for learning about TrustZone and OEMiROT on STM32H5. I have heard that other vendors are doing much worse here.

 

But once you understand how the system works, you don’t actually need all this complicated machinery. With OEMiROT, the flash layout is fixed. You cannot change it as part of an update post-launch since you need to rebuild the bootloader and the OEMiROT is not updateable in a running system. You’ll need to do Debug Auhentication (presuming you remembered to provision the DA keys and did not move PRODUCT STATE to LOCKED) and regress all the way back to OPEN and flash new OEMiROT, app, keys, …

Once you have settled on what your flash layout needs to be, you can just take the the updated linker scripts, xml files (that drives the wrapper around MCUBoot’s imgtool.py) and provisioning scripts and put wherever you want and then remove all calls to postbuild.sh from your build. Sure - if you do later need to change the flash layout there will be more files to update manually. But personally, I don’t think the gain of not having to do that is worth the effort of keeping the postbuild-system running. Especially when it needs to run for multiple developers and in the CI and suddenly the hard coded paths in env.sh doesn’t scale anymore and you spend more time debugging build failures with paths like “$project_dir/../../../../ROT_Provisioning/OEMiROT/ob_flash_programming.sh” than working on the features of your product.

And you will very likely want to replace the provisioning-scripts with your own things to provision firmware to your product when it is manufactured.

 

In summary: use the existing tree-structure for prototyping and learning and then roll your own.

 

That being said, ST could make the whole system simpler by defining the flash layout constraints in one place - say in a Python script - and then let that script generate C/shell/XML includes that the projects and the scripts in ROT_Provisioning would just include. And then as a second step run the compilers and image generators. The includes could then be put in a temporary directory (or .gitignored). All this in-tree patching is brittle and tends to leave diff clutter around even when no values where actually changed. But that won’t happen within the scope of STM32H5 at least.

[giubacchio]

Hi Jesper, thank you for your answer. I mostly agree with your thoughts but there is still something I am missing on the way you suggest to proceed.

I am already doing something similar: I have my own copies of all the scripts that I don’t want will be modified by CubeMX as you suggested. However, I am keeping the standard folder structure to preserve the link between the application and the OEMiROT.

Do you suggest to initialize the project using CubeMX from the standard tree STM32Cube_FW_H5_V1.6.0, linking it to the OEMiROT using the desired flash layout, and then move it (and the OEMiROT) to your desired folder tree? Am I correct?
If so, successive access to the ioc through CubeMX will lose the link to the OEMiROT. I was seeing this as a bad thing, with potentially “harmful” results on the link between OEMiROT and the application, and many files to be updated every time the layout is changed. But maybe I have been too cautious and misinterpreted the CubeMX OEMiROT chain.

Thank you!
Giulio