I’m working on improving the STM32F4 BSP and the current discussed approach to integrate HAL is to move STM32CubeHAL management out of rtems.git and into the RSB.
The idea would be to treat STM32Cube HAL as an external dependency managed by the RSB, rather than vendoring snapshots directly in the RTEMS source tree.
I’d like to better understand how such a HAL package should be structured in the RSB. I’ve a few questions:
Whats the recommended way to track HAL versions
Are there existing RSB recipes that would be a good reference for this
I’d appreciate any guidance, examples or documentation on how to structure such a recipe.
Thanks for looking at this project. It is an interesting project as it is a new area we have not done before and so we will all be learning.
The reasons packaging this way is:
Less contributed code in RTEMS and that helps long term maintenance.
Users can bug fix, upgrade or not upgrade the HAL layer at their discretion. A user can update a HAL for an older release of RTEMS.
RTEMS releases do not set the required HAL version. A user can use a newer HAL version with an older RTEMS release.
The key to getting this approach to work is to understand the calls the HAL needs to work. There will be a range of calls to RTEMS it needs to make. How these interfaces are constructed is the interesting part and important to making this project a success.
The key parts:
The HAL code can only depend on the headers and interfaces provided the tools. This is GCC and newlib.
RTEMS can depend on all interfaces in the HAL.
RTEMS contains HAL glue code to bind services the HAL provides to RTEMS, for example interrupts.
There is an assumption the HAL code understands the hardware and how to access it without any input from RTEMS.
If the HAL code is shared by BSPs in a fmaily that have different ABIs it may need to support a form of multilib.
Multilib is a build process that takes a set of sources and builds it with different compiler machine flags creating a .a library for each set of flags. You need libraries that match the BSP API flags.
A separate HAL library sits between the tools and RTEMS. It is built and installed into the RTEMS prefix before RTEMS is built. A BSP that depends on a separate HAL package needs to check the HAL headers are available during it’s configure stage of a build of RTEMS.
@santosh.py A first step therefore would be to take the current HAL that is inside of rtems.git, and try to get it to compile into a library that you can link with the RTEMS build. Do this manually before you even attempt to use RSB for it.
I tested compiling STM32F4 HAL outside RTEMS and was able to build a static library from the HAL sources.The HAL depends only on CMSIS headers and the toolchain, not RTEMS.This suggests it should be possible to build HAL via the RSB and link it with the BSP.
Okay so I did all my experiments with the H7 BSP since there is no HAL for the F4 in rtems.git yet.
The glue code between the HAL and RTEMS can be written with the H7 as reference:
We need the hal configuration file enabling modules and setting hse value among other things
A header and source file with stm32h7_clk_enable() and stm32h7_get_module_index() for the peripheral base address map and so on. This needs to embed UART_HandleTypeDef and add rtems_termios_device_context
We would need MspInit callbacks which ST’s HAL expects.
BSP start hooks for board specific startup
We would also need the HAL_GetTick() bridge with rtems just like in the bspstart.c of the h7 bsp.
Then we’d need individual glue code files for UART console, SPI, DMA and other peripherals.
What is not trivial is handling rtems patches in the HAL. I discovered that the HAL in contrib is not vanilla and has ifdef__rtems__ and ifndef__rtems__ in a lot of the .c files and even the cmsis header.
They do the job of removing the global functions provided by the RTEMS BSP (HAL_InitTick,HAL_IncTick etc), they also remove the __weak MspInit stubs.
We will need to handle these patches differently in order to detach the HAL.
For my experiment, I left the rtems patches in but didnt define __rtems___. It appears that its possible to get the function definitions in the bsp to override them at linktime as the HAL versions are all __weak(ST HAL actually uses it extensively for callback funcs). This is fine for the crude test I did but I think long term we would have to make it work with the vanilla ST HAL.
Crucially we need to handle the global function patches such as the tick bypass.
The CMSIS header has #include <bspopts.h> in it for the purpose of handling chip variants. We’ll need to pass that as an argument like -DSTM32H747xx.
To build the HAL library itself we’ll need to know the ABI flags and make sure there arent any missing cmsis core headers or bspopt.h references.
After building the hal library and putting it with the headers in a directory where the bsp can find it we’ll need to remove the hal sources from obj.yml and the likes. We’ll need to pass the hal install path as a linker flag.
Am I going on the right track? Will this be sufficient for my proposal or will I need to explore further?
The RSB has a way to handle patches. You could either use the patches to inject __rtems__ guards, direct changes, or add the -D__rtems__ in the compiler flags. At any rate, this looks like a suitable basis for the proposal.