Hello Chris,
On 2023-05-24 03:44, Chris Johns wrote:
Hi Christian,
Thanks for raising this topic. It is a tough one.
On 24/5/2023 12:11 am, 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.
Xilinx with the more complex devices like the Versal have been moving things
about. The Versal SMC call set is fluid and the PM (platform manager) seems to
functionally align to Xilinx tools releases plus Petalinux versions. For example
there are stable defined API calls in Versal Linux (XRT/zocl) that depends on PM
code that is commented in the code as "to be removed".
When I first used the Zynq I used Xilinx's drivers like OAR is currently with
the Microblaze. I could not release the results because of the license at the
time. I quickly found the drivers lacked functionality for general use and broke
under high loads and boundary conditions. The fixes are part of a project and
cannot be released because the license at the time made it impossible. What I
leant from the exercise is to not depend on their drivers.
That sounds like a quite bad case. So it's a good example for that
discussion. Thanks for bringing it up.
I feel what we considered stable will depend on the origin of the code and that
will be case by case.
Agreed.
- 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.
Yes the mutual dependence if built externally and before RTEMS is not easy to
solve. The idea of the HAL code being supplied as .h and a .a does let a user
update the drivers without needing an RTEMS version update.
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.
See below for the problems this creates.
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.
This is important. We need to define what a release is and it is a requirement
we provide all code as tarball files. This implies the release process knows how
to create the tarfiles.
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).
I suggest you avoid making that repo a submodule of anything. The code in that
repo is "over the wall" and there is no continuity. I have it as a submodule in
my XRT repo and a Xilinx push of the next release of tools broke the code. What
I had depended on was removed and moved somewhere else. The Xilinx updates are
based on the release cycle of their tools and they do not respond to issues or
PRs. They are free to make what ever changes they like and they do that
internally and what appears externally is based on changes across their internal
repos. To make things harder there is no consistent point they update these
public repos so the code they removed did not reappear for a long time.
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.
Direct dependence on external repos we do not control is a long term maintenance
problem. Repos move and change [1] and this makes maintaining past releases a
challenge. Who is responsible for the long term release branch maintenance?
Without a working submnodule a release cannot be made and that is not great.
Expecting the release manager to clean up is not going to work given the task is
unfunded.
Let's make the dependencies indirect: We clone repos to git.rtems.org
and to our mirrors. Then we can either use a submodule URL starting with
git://git.rtems.org or even with a relative URL if we want to make
better use of the mirrors.
If necessary, that approach allows adding an RTEMS-branch that adds
patches. It's more similar to the clone and own we do now. But having a
clone of the original repo makes it a lot simpler to merge upstream
changes. Having an RTEMS-branch makes it easier to see what has been
changed for RTEMS.
We don't have to integrate automatic updates or similar. We only
maintain and keep a tested version. If a BSP maintainer or user wants to
upgrade, he pulls the changes from the upstream repo and merges them
into the branch that includes our patches.
That should even work for your extreme case of the Xilinx repo. We have
a tested version on our server. If someone wants to update, he has to
update, find out what Xilinx did break during their updates and adapt to
that. Then we can push that new version to our clone of the Xilinx repo.
Submodules in rtems.git is a change in policy. We allow submodules in add-on
packages like libbsd but it has never been something we have allowed with
rtems.git.
I agree that it would be a change in policy. But that's the whole point
of the discussion: The current method makes it hard to maintain library
code. Do we find a better solution that either fits in current policies
or do we find sensible adaptions to the policies that are OK for everyone?
I don't see submodules as the only valid solution. But it's one that
looks promising to me, and therefore I brought it up. It is similar to
the approach that has worked well in libbsd. What I currently suggest
only tries to avoid the step of copying code between the upstream repo
and the local one like we do in libbsd.
Do you have a good alternative idea that would need less changes in policy?
Best regards
Christian
Chris
[1] All recently moved ... https://github.com/freedesktop
--
--------------------------------------------
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
