<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 23, 2023 at 2:26 AM Christian MAUDERER <<a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
I recently updated the HAL in the i.MXRT BSP. I used the same approach <br>
that we use for a lot of similar cases: Import the sources into RTEMS <br>
and adapt them slightly so that they work for us. So basically a <br>
Clone-and-Own approach.<br>
<br>
During the discussion of the patches, some concerns were raised, whether <br>
we should find a better solution to handle HALs, SDKs and similar cases. <br>
We should start discussing a solution that can be used after the 6 <br>
release so that maybe someone can start to work on a prototype.<br>
<br>
Some example cases are:<br>
<br>
- the mcux_sdk in the imxrt BSP<br>
- the hal in the stm32h7 BSP<br>
- general ARM CMSIS files<br>
- zlib<br>
- libfdt<br>
<br>
One solution could be to build these libraries external and only link <br>
RTEMS with them. There are disadvantages to this aproach:<br>
<br>
- Also in my experience, the API of the HALs / SDKs / libraries seems to <br>
be quite stable, it's possible that there are combinations where some <br>
unexpected change breaks a driver or makes it impossible to link the <br>
applications.<br>
<br>
- BSPs rely on basic drivers from these libraries (like console or clock <br>
driver). If we link against the libraries, the testsuite wouldn't build <br>
any more without preinstalled libraries.<br>
<br>
Another solution could be to include libraties like that as submodules <br>
and build them using the RTEMS build system. We could clone the repos <br>
onto the RTEMS git server, and add necessary patches. Advantage would be <br>
that it is more similar to the process that we currently have. Another <br>
advantage is that we have a known-working version of the files. Upstream <br>
updates could be either merged or we could rebase our patches to a new <br>
version.<br>
<br>
 From my point of view, the second option would be the better one <br>
especially because we have a tested, fixed version of the library <br>
instead telling the user to just use some random version that might or <br>
might not work.<br>
<br>
Regardless which aproach we use: We have to think about how to handle <br>
that on releases. In the link aproach (first case), we have to somehow <br>
archive source tar balls and some kind of build recipe. In the submodule <br>
aproach, we could checkout all submodules and pack the files into the <br>
RTEMS release tar ball. So I would expect that the second aproach has <br>
less impact here too.<br>
<br>
Comments? Improvements? Better suggestions?<br></blockquote><div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>Kinsey</div> </div></div></div>