Discussion: How to handle HALs, SDKs and libraries

[Christian MAUDERER]

On 2023-05-23 16:11, Kinsey Moore wrote:
> On Tue, May 23, 2023 at 2:26 AM Christian MAUDERER 
> <christian.mauderer at embedded-brains.de 
> <mailto:christian.mauderer at embedded-brains.de>> 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?
> 
> 
> I would definitely prefer the submodule approach over the linking 
> approach to avoid the test issues since some of these HALs bring core 
> functionality. The Xilinx driver framework (embeddedsw repo on Github) 
> would be well-suited to the submodule approach since it is already 
> broken out into the shared driver space because it can apply to at least 
> 3 architectures (ARM, AArch64, MicroBlaze).
> 
> One issue with either approach is the need to modify the HAL source to 
> suit RTEMS. As far as I'm aware, there is no tooling in place in git for 
> applying patches to submodules and in the external build scenario we'd 
> end up maintaining a branch of the origin repo with patches applied. 
> Upstreaming the changes would be ideal, but I wouldn't expect them to 
> accept RTEMS-specific patches. The Xilinx NAND driver already requires a 
> minor modification because that driver doesn't expose an option and 
> instead has a defined macro that determines how many chip selects are 
> usable to address different parts of the NAND chip. Technically, this 
> particular change could be worked around with some include path trickery 
> to leave the original sources unmodified, but many other changes would 
> not be suited by that type of workaround and it makes the source less 
> maintainable. We would need to come up with our own tooling for 
> submodule patch application and silencing of warnings about dirty 
> submodule trees due to applied patches.
> 
> Kinsey

I would suggest that we maintain a branch on the git.rtems.org if 
adaptions are necessary and patches can't be upstreamed. We can either 
merge upstream changes or rebase that branch onto the latest upstream if 
we update. I think that is more intuitive and robust compared to a tool 
that applies RTEMS specific patches after cloning the submodule.

Best regards

Christian
-- 
--------------------------------------------
embedded brains GmbH & Co. KG
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email:  christian.mauderer at embedded-brains.de
phone:  +49-89-18 94 741 - 18
mobile: +49-176-152 206 08

Registergericht: Amtsgericht München
Registernummer: HRA 117265
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/