<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 3/5/2014 9:12 AM, Alan Cudmore
wrote:<br>
</div>
<blockquote
cite="mid:CAJrjN72Ni1prAnuZk1LAs-LPnORRgME2DqjOP7O58t3KyGEo-w@mail.gmail.com"
type="cite">
<div dir="ltr">There is a Microblaze port out there, but it has
not been released.</div>
</blockquote>
<br>
And I would love to see it freed. Bounty to pay for his work is
basically all<br>
it takes. <br>
<br>
***Hint to RTEMS users who would like to see Microblaze port.. email
me***<br>
<blockquote
cite="mid:CAJrjN72Ni1prAnuZk1LAs-LPnORRgME2DqjOP7O58t3KyGEo-w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>But, I agree that the availability of the toolchain should
be a factor. </div>
<div><br>
</div>
</div>
</blockquote>
We need to be confident the FSF main source has or soon will have
the port.<br>
<blockquote
cite="mid:CAJrjN72Ni1prAnuZk1LAs-LPnORRgME2DqjOP7O58t3KyGEo-w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Tough call: If we do the microblaze port, it may be
duplicating work that may eventually become available to the
RTEMS project. If we do the OpenRISC port, will it have the
toolchain support and will it have users to keep it from
rotting?</div>
<div><br>
</div>
</div>
</blockquote>
The OpenRISC folks just started talking copyright assignments to
binutils.<br>
So the intent is good but it isn't there yet.<br>
<br>
Remember, a full tool chain includes:<br>
<br>
+ binutils<br>
+ gcc<br>
+ newlib<br>
+ gdb<br>
+ decent simulator<br>
+ rtems source build configuration files<br>
+ rtems test and sim-scripts support for testing<br>
<br>
A porting effort includes work on those to add CPU-*-rtems* to each
<br>
before you can fill in the port itself:<br>
<br>
+ score/cpu<br>
+ libnetworking in cksum<br>
+ at least one BSP<br>
- community needs one which runs on simulator<br>
<br>
All of the above are needed to support the port long term.<br>
<br>
I still would like to know how what is called OpenRISC now compares
to<br>
what they called OpenRISC 1K and 2K years ago. And if there is any
work<br>
in the old port which can be reused.<br>
<br>
Also do you have anyone from the OpenCores project who would be
willing<br>
to co-mentor? I do not think I know anyone there.<br>
<br>
--joel<br>
<blockquote
cite="mid:CAJrjN72Ni1prAnuZk1LAs-LPnORRgME2DqjOP7O58t3KyGEo-w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Alan</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Mar 5, 2014 at 8:29 AM, Gedare
Bloom <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue,
Mar 4, 2014 at 8:58 PM, Hesham Moustafa<br>
<div>
<div class="h5"><<a moz-do-not-send="true"
href="mailto:heshamelmatary@gmail.com">heshamelmatary@gmail.com</a>>
wrote:<br>
><br>
><br>
><br>
> On Tue, Mar 4, 2014 at 8:47 PM, Gedare Bloom <<a
moz-do-not-send="true" href="mailto:gedare@rtems.org">gedare@rtems.org</a>>
wrote:<br>
>><br>
>> On Tue, Mar 4, 2014 at 1:22 PM, Hesham Moustafa<br>
>><br>
>> <<a moz-do-not-send="true"
href="mailto:heshamelmatary@gmail.com">heshamelmatary@gmail.com</a>>
wrote:<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Mon, Mar 3, 2014 at 6:54 PM, Gedare
Bloom <<a moz-do-not-send="true"
href="mailto:gedare@rtems.org">gedare@rtems.org</a>>
wrote:<br>
>> >><br>
>> >> Hesham,<br>
>> >><br>
>> >> On Mon, Mar 3, 2014 at 11:06 AM,
Hesham Moustafa<br>
>> >> <<a moz-do-not-send="true"
href="mailto:heshamelmatary@gmail.com">heshamelmatary@gmail.com</a>>
wrote:<br>
>> >> >><br>
>> >> >> Long term a port needs to be
to a viable architecture from a "is it<br>
>> >> >> alive"<br>
>> >> >> view this includes the cpu,
tools, a way for us to test, etc<br>
>> >> ><br>
>> >> > Sure, that's what I hope to work
on.<br>
>> >> In order to have a chance that your
proposal will be accepted, you<br>
>> >> will need to demonstrate that the
openrisc tools work for recent gcc /<br>
>> >> newlib with an adequate simulator.
Based on wikipedia, you should be<br>
>> >> able to cross-compile Linux for the
OpenRISC to run on Qemu, or you<br>
>> >> may like to just try to get a
bare-metal application to run in the<br>
>> >> simulator.<br>
>> >><br>
>> > I have built their latest toolchain, gcc
4.9.0 and binutils 2.24.51.<br>
>> > with newlib. A helloworld program is
working fine with or1k-elf-run,<br>
>> > or1k-elf-gdb (which connects to their
or1ksim simulator) and qemu.<br>
>> ><br>
>> > The questions is, should this project
include porting their toolchains<br>
>> > to<br>
>> > RTEMS toolchains (with their copyrights) ?
or that may cause some<br>
>> > licence/copyrights problems ?<br>
>> In order for RTEMS Project to accept the BSP
for inclusion, the GCC<br>
>> toolchain must be available and prepared for
upstream submission. If<br>
>> there is already OpenRISC (or1k) support
accepted by GCC for linux, it<br>
>> should be straightforward to make it work for
RTEMS. You will need to<br>
>> propose it as part of your GSOC, and you will
need to make the proper<br>
>> steps including submitting FSF paperwork for
contributing to GCC.<br>
><br>
> They have their latest toolchain at github [1].
Also there is a linux port<br>
> that can work<br>
> on both or1ksim and real HW FPGA [2]. Not sure how
the project would<br>
> interface/interact with the existing or1k toolchain
at github, gcc, and<br>
> RTEMS. I would<br>
> appreciate more clarification about this issue.<br>
><br>
> [1] <a moz-do-not-send="true"
href="https://github.com/openrisc/or1k-src"
target="_blank">https://github.com/openrisc/or1k-src</a><br>
> [2] <a moz-do-not-send="true"
href="http://openrisc.net/toolchain-build.html"
target="_blank">http://openrisc.net/toolchain-build.html</a><br>
</div>
</div>
If the or1k toolchain is not already upstream to GCC, you
will need to<br>
provide a solution for a workable toolchain for users,
probably by<br>
integrating the toolchain build into the RTEMS Source
Builder. You<br>
should also push patches to GCC if possible. You should do
an analysis<br>
of how much difference there is between the or1k toolchain
and the<br>
vanilla GCC/binutils/newlib, and figure out if there is any
reason<br>
other than laziness that the or1k maintainers have not
pushed their<br>
toolchain into the upstream gcc / sourceware repositories.<br>
<br>
I'm hesitant to accept any port that lacks a dedicated RTEMS<br>
maintainer or tools maintained upstream in gcc.<br>
<br>
At least for microblaze we know there exists some toolchain
support<br>
already. I'm not sure if there is enough left to do with the<br>
microblaze port to warrant a GSOC or not. You would have to
inquire<br>
with the developers who have done work on it already.<br>
<br>
-Gedare<br>
<br>
>><br>
>> -Gedare<br>
<div class="HOEnZb">
<div class="h5">><br>
><br>
_______________________________________________<br>
rtems-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:rtems-devel@rtems.org">rtems-devel@rtems.org</a><br>
<a moz-do-not-send="true"
href="http://www.rtems.org/mailman/listinfo/rtems-devel"
target="_blank">http://www.rtems.org/mailman/listinfo/rtems-devel</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Joel Sherrill, Ph.D. Director of Research & Development
<a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a> On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985</pre>
</body>
</html>