Discussion: How to handle HALs, SDKs and libraries

[Karel Gardas]

Hello,

are we really that close to RTEMS 6 release that none of this is 
acceptable to do now?

Asking since I'd also like to update stm32h7 HAL. I may do that manually 
or I may do that submodule way which may perhaps save some of the manual 
work involved as some of the patches may not be needed anymore. It 
depends on resolution to following questions:

- stm32h7 hal contains Sebastian's modification/additions of Doxygen 
tags. Do we need to preserve that in the submodule? I guess not, but I'm 
not sure and this question of Doxygen markups was not solved in this 
thread yet AFAIK.

- all ARMs HALs probably also depends on particular version of CMSIS 
files, so I guess we should use separate submodules of CMSIS per HAL. At 
least STM recommends that: 
https://htmlpreview.github.io/?https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Release_Notes.html 
-- this would certainly be improvement in comparison with current state 
of the art besides update of CMSIS alone we would also support 
manufacture tested CMSIS version for their HAL...

- where to put submodules? What is preferred location? For stm32h7 case!
   (i) hals/arm/stm32h7
  or
   (ii) deps/arm/stm32h7
  or
   (iii) contrib/arm/stm32h7
  or
   (iv) anything else preferred?


I may do stm32h7 hal + its CMSIS dependency now (or next week), but only 
if the chance of inclusion into RTEMS 6 is reasonably high. Otherwise I 
would need to go more safer route of manual in-tree HAL update assuming 
this is still acceptable for RTEMS 6 release.

Testing of stm32h7 changes is on my shoulders, hardware is here and 
customer is using the platform in field. Offering this as an opportunity 
to test the submodule vehicle ASAP on some part of RTEMS...

Thanks,
Karel

On 5/23/23 09:26, Christian MAUDERER wrote:
> Hello,
> 
> I recently updated the HAL in the i.MXRT BSP. I used the same approach 
> that we use for a lot of similar cases: Import the sources into RTEMS 
> and adapt them slightly so that they work for us. So basically a 
> Clone-and-Own approach.
> 
> During the discussion of the patches, some concerns were raised, whether 
> we should find a better solution to handle HALs, SDKs and similar cases. 
> We should start discussing a solution that can be used after the 6 
> release so that maybe someone can start to work on a prototype.
> 
> Some example cases are:
> 
> - the mcux_sdk in the imxrt BSP
> - the hal in the stm32h7 BSP
> - general ARM CMSIS files
> - zlib
> - libfdt
> 
> One solution could be to build these libraries external and only link 
> RTEMS with them. There are disadvantages to this aproach:
> 
> - Also in my experience, the API of the HALs / SDKs / libraries seems to 
> be quite stable, it's possible that there are combinations where some 
> unexpected change breaks a driver or makes it impossible to link the 
> applications.
> 
> - BSPs rely on basic drivers from these libraries (like console or clock 
> driver). If we link against the libraries, the testsuite wouldn't build 
> any more without preinstalled libraries.
> 
> Another solution could be to include libraties like that as submodules 
> and build them using the RTEMS build system. We could clone the repos 
> onto the RTEMS git server, and add necessary patches. Advantage would be 
> that it is more similar to the process that we currently have. Another 
> advantage is that we have a known-working version of the files. Upstream 
> updates could be either merged or we could rebase our patches to a new 
> version.
> 
>  From my point of view, the second option would be the better one 
> especially because we have a tested, fixed version of the library 
> instead telling the user to just use some random version that might or 
> might not work.
> 
> Regardless which aproach we use: We have to think about how to handle 
> that on releases. In the link aproach (first case), we have to somehow 
> archive source tar balls and some kind of build recipe. In the submodule 
> aproach, we could checkout all submodules and pack the files into the 
> RTEMS release tar ball. So I would expect that the second aproach has 
> less impact here too.
> 
> Comments? Improvements? Better suggestions?
> 
> Best regards
> 
> Christian