We've been using STiROT + OEMuROT for STM32H7S on our system, with our own application.
The secure bootloader handles most of its functionality very well, and the security aspects in particular. The scripts provided by ST were very helpful, as was the documentation on the ST wiki. We are grateful to ST for providing these.
However, it proved extremely challenging to get the secure bootloader working with our application, mainly because the secure bootloader makes a number of important assumptions about the user application which are not documented.
These unstated assumptions initially prevented our application from running, and it took a considerable amount of time and effort to solve all the problems associated with them.
Assumptions
The main assumptions are:
OEMuROT assumes that the application will use the same clock setup as itself (especially PLL1 and PLL2): as documented in a separate post, we needed to change the clock settings in our application compared to OEMuROT, and this proved to be very difficult to fix as our code executes from external flash which relies on the PLLs.
It doesn't help that the setup code is called directly from the reset vector in a hand-written function (SetSysClock() in system_stm32h7rsxx.c), rather then being initialised by CubeMX, which would make this easier to customise. In a future update, would you consider making greater use of CubeMX, so that users could customise OEMuROT more easily?
OEMuROT assumes that if your application runs in place (i.e. from flash), then you don't need external RAM: as also documented in a separate post, there's no option to enable external RAM in this situation. The workaround was relatively simple, but it would be nice to have that option in addition to the 3 already presented.
STiROT loader + OEMuROT makes no provision for an early call to HAL_PWREx_ConfigSupply(): this function sets up the power supply type, and must be called very close to the start of the bootloader (specifically, in the loader). It writes to register PWR_CSR2, and must be the first function to write to that register, as the power supply bits cannot be written to again without a power-on reset.
This is critical, as using the wrong setting can affect later operations, and cannot be fixed anywhere else in the code.
Other issues
There's no script for simply programming the chip: there are a number of very useful scripts provided (especially provisioning.bat, plus the DA scripts) - but there is no script for just programming the processor, without all the OBK and XML generation.
For normal development (once the system is stable), and for manufacturing, the OBK and XML files don't need to be generated every time. So, I created a script from provisioning.bat, removing all those parts.
Can I suggest adding such a script in a future update?
Critical bugs: as already documented in posts here and here, we found two bugs which prevented the system from working. Fortunately, they were relatively simple to fix. (ST have responded to my posts, and are looking into the issues.)
RAM ECC: as far as I can tell, RAM ECC needs to be turned off in two places: in boot_hal_cfg.h (comment out #define OEMIROT_USER_SRAM_ECC) and also in STiROT_Config.xml (change the SRAM ECC setting to zero). If this isn't already documented clearly somewhere, please could you ensure that this is added?
Summary
To be clear: ST's secure bootloader is a great product, and we are grateful that they have gone to some considerable effort to create and document it.
However, some unstated assumptions and consequential hard-to-debug issues took up a huge amount of our time.
We are grateful to ST for their responses to our posts, and we hope that future updates to OEMuROT are able to address these issues.
