DIscussing HAL version override for stm32f4

Programs Google Summer of Code
1

Following the earlier discussion about STM32 HAL integration, I’d like to discuss a mechanism for managing HAL code within RTEMS.

Currently STM32 BSPs vendor a snapshot of the HAL under rtems.git/contrib. Users cannot easily build against a different HAL version that they might prefer without modifying the tree.

I was thinking of a mechanism where:

  1. Keep a known good HAL snapshot in contrib (default behavior)
  2. Introduce a bsp configure option such as:

STM32_HAL=/path/to/external/hal

  1. During configure:
  • Validate that the provided path contains the expected HAL structure.
  • Store the HAL root path in the build environment.
  • Optionally check HAL version for compatibility.
  1. In the BSP build spec:
  • Replace hardcoded HAL paths with a configurable HAL root path variable.
  • Default this variable to the one in rtems.git/contrib.
  • If overridden then compile the external HAL sources instead.

We could use STM32F4 as a prototype BSP to validate this mechanism before considering generalization to other STM32 BSPs.

I would appreciate any suggestions/feedback on this approach. If there are concerns or any alternate ideas I would love to hear them.

2

I don’t think it would be feasible to provide a custom path as a configure option. However, you might be able to provide a custom spec file to override the one that determines the build of the HAL from contrib.

@sebhub Do you have any ideas how this might be approached?

3

Beyond that, grabbing source from outside of the tree introduces challenges for validating and reproducing the build. The solution might need to be built into something like the RSB so that it can capture the sources used. Maybe @kiwichris has some ideas how this might be approached.

4

It’s been discussed to move all HAL code to the RSB (RTEMS Source Builder) and removing it from the RTEMS source tree completely.

They change too rapidly and different versions can have different support with users wanting to update. The best choice is to move to using this method and using a release file that can be easily updated.

This is where we’re going in the future with this if you’re interested you can try doing it this way it’s fairly easy and there are a lot of examples on how to do this.

5

Would we still support building RTEMS manually, or would it be mandatory to use RSB to build RTEMS when using an external HAL like this?

6

I did some experimentation to see if it was doable by adding an option spec file and making some changes to the obj.yml,optincludes.yml, grp.yml and some minor changes to wscript to support substitution. This would work by adding STM32_HAL=/path… to the config.ini file.
It did seem to work and didnt break any functionality outside of this bsp although I figure its fairly rudimentary and probably not acceptable.

7

This is interesting, treating the HAL like a dependency or a toolchain. I agree this seems like a much cleaner solution.

I think the scope of the project is widened by making the f4 bsp like a testbed for how HALs should be treated going forward.

I would like more information or some examples on how we would go about this.

8

For anything using a HAL you’d need the RSB no matter what unless you decided to build it manually and point RTEMS to it I supposed? You’re going to have to supply where the HAL is located anyway so no big deal if you build it yourself though that wouldn’t be supported by us for debugging purposes.

In reality anyone can do whatever they want the only thing the RSB would do is make it easier and “pin” the version to RTEMS so letting it be a free-for-all in picking versions would make it impossible for debugging or testing.

9

You can post in the RSB category here and @kiwichris will be able to help you with creating a recipe. We’ve talked about this being the direction we want to go several times.