RTEMS | bsps/arm/stm32u5: Add a new BSP (!515)

[Christian Mauderer (@c-mauderer)]

Christian Mauderer commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/515#note_125488


Thanks for the review.

### Regarding running from RAM

The board has an external RAM connected to OctoSPI. There is also an internal RAM in the controller.

The use case for this check is:
* A bootloader (running from Flash) loads an application (for example) from SD card into the external OctoSPI RAM
* The Application executes from there. It must not touch the OctoSPI settings. Otherwise it would loose access to it's own code.

With the check during startup, you can just use a different linker command file for building the different applications (for example build a bootloader using `linkcmds.flash+` and an application using `linkcmds.ospi`). A compile time constant would make it necessary to compile multiple BSPs for the same thing.

Basically any other symbol could be checked too. I selected the `stm32u5_init_octospi` because that was the first function where I noted the problem. But the `bsp_start_hook_0` or the `_start` symbol would work too.

### NULL Section

That's a preparation for a NULL pointer protection similar to the one in ATSAM, fvp, i.MXRT and STM32H7 BSPs. The MPU isn't implemented yet.

### HAL

You maybe noted, that the BSP is waiting for some cleanup and commit for some time now. I had to wait till the gcc patch for the Cortex M33 managed it into the release. The alternative would have been to add a patch to the RSB which would have been more maintenence effort. Therefore the HAL is an older version.

The imported version of the HAL is 1.5.0. The source and version are in the commit message of the HAL files. The current version is 1.6.1. Release notes are here:

https://htmlpreview.github.io/?https://github.com/STMicroelectronics/stm32u5xx_hal_driver/blob/master/Release_Notes.html

The changes are a mix of cosmetic changes and relevant fixes. With the current method to import HALs and maintain them inside the RTEMS sources, we will always be outdated (Gedare started a separate ticket for the HAL import method at #5282). The BSP currently is already tested for some time with the 1.5.0. Therefore I did not update to avoid adding new undiscovered problems. But if you prefer, I can make that update.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/515#note_125488
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20250627/04eb8832/attachment.htm>