Rtems-core Binaries

Joel Sherrill joel.sherrill at OARcorp.com
Fri Feb 6 14:14:41 UTC 2009

Ralf Corsepius wrote:
> Resending, this list is once again swallowing mails.
> Joel Sherrill wrote:
>> Matt Rippa wrote:
>>> Hi all -
>>> I'm not sure who started managing binaries for the RTEMS
>>> toolchains, but it's really fantastic. I think praise goes to
>>> Ralf Corsepius?
>>> For Gemini, we're adopting a model to manage RPM spec-files and
>>> a yum repo for all of our observing critical code. I was
>>> wondering if anyone is working on binary releases for rtems-core
>>> and perhaps others such as rtems-addon-packages, and Cexp.
>>> Before I start this effort for our requirements, I was hoping to
>>> hear your thoughts. Maybe it's already in a near term plan?
>> Ralf has done some packaging work on this and I really
>> really would like to see us be able to do this for
>> released RTEMS versions.
> Yes and no.
> Yes, I have done some packaging work aiming at this, but this
> unfortunately dropped off the desk for several reasons.
> No, this is unlikely to happen for released RTEMS version, because these
> versions have not been prepared to utilize this.
I was thinking of making this a 4.10 goal not an additional
requirement on 4.9.  This would be a "new feature" in 4.10
even though bits and pieces have been around but not
finished for a while.
>> Unfortunately, there are some BSP specific clean up
>> issues remaining so every BSP will build against an
>> installed CPU Kit.
> Correct. This is one detail, I am referring to above.
>>  If Ralf can post a work plan for
>> resolving this, I would like to see this in 4.10.
> A work plan would be quite simple:
> 1. Start building cpukit rpms from rtems-tarballs.
> I would expect us to be already quite close to be able to do so, however
> the "devil's in the details" - This step definitely isn't intellectually
> challenging, but labor intense and resource consuming ;)
Indeed.  That was why I wanted to highlight this
as an activity now with a goal of 4.10 so we would have
time to work on the details.
> Once this step has been performed, I would expect it to be fairly easy
> to back-port to released RTEMS versions.
Assuming it doesn't take 100s of BSP specific changes that
 need to be tested on real hardware.  As you say the devil
is in the details.  If it is only a few changes, then it should be
OK.  If it is a lot, then it just will be too much.
> The limiting factor wrt. implementing this at the moment is my personal
> time constraints. For the moment, it will have to remain a "spare-time
> side-task" while working on other topics.
I think I was building this way for the tool testing initially
but went back to the old way because I had enough problems
with testing the tools and didn't need to add RTEMS build

Can you outline the proper build procedure again?
I will try to leave a build running over the weekend
and post a report Monday or Tuesday.

Given a known procedure and a list of issues to address,
we can work through them.
> 2. Split out cpukit from the RTEMS source tree and convert it into a
> stand-alone package.
> The basic idea would be to ship a separate cpukit-tarball and a tarball
> containing the bsps and the testsuites.
> However, the details are unclear to me.
Me too.  But I do know that until BSPs can be built against
the installed CPU Kit image, the packaging doesn't matter.

I had expected us to do something like gcc where there is
a master full tarball and subset tarballs which (I think) can be
mechanically produced from the full one.  But I really don't know

> Ralf

Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

More information about the users mailing list