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
--
--------------------------------------------
embedded brains GmbH & Co. KG
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@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/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
