On 2023-05-23 16:11, Kinsey Moore wrote:
On Tue, May 23, 2023 at 2:26 AM Christian MAUDERER
<christian.maude...@embedded-brains.de
<mailto:christian.maude...@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.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
