GSoC 2014 | Porting RTEMS for OpenRISC

[Alan Cudmore]

There is a Microblaze port out there, but it has not been released.
But, I agree that the availability of the toolchain should be a factor.

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?

Alan



On Wed, Mar 5, 2014 at 8:29 AM, Gedare Bloom <gedare at rtems.org> wrote:

> On Tue, Mar 4, 2014 at 8:58 PM, Hesham Moustafa
> <heshamelmatary at gmail.com> wrote:
> >
> >
> >
> > On Tue, Mar 4, 2014 at 8:47 PM, Gedare Bloom <gedare at rtems.org> wrote:
> >>
> >> On Tue, Mar 4, 2014 at 1:22 PM, Hesham Moustafa
> >>
> >> <heshamelmatary at gmail.com> wrote:
> >> >
> >> >
> >> >
> >> > On Mon, Mar 3, 2014 at 6:54 PM, Gedare Bloom <gedare at rtems.org>
> wrote:
> >> >>
> >> >> Hesham,
> >> >>
> >> >> On Mon, Mar 3, 2014 at 11:06 AM, Hesham Moustafa
> >> >> <heshamelmatary at gmail.com> wrote:
> >> >> >>
> >> >> >> Long term a port needs to be to a viable architecture from a "is
> it
> >> >> >> alive"
> >> >> >> view  this includes the cpu, tools, a way for us to test, etc
> >> >> >
> >> >> > Sure, that's what I hope to work on.
> >> >> In order to have a chance that your proposal will be accepted, you
> >> >> will need to demonstrate that the openrisc tools work for recent gcc
> /
> >> >> newlib with an adequate simulator. Based on wikipedia, you should be
> >> >> able to cross-compile Linux for the OpenRISC to run on Qemu, or you
> >> >> may like to just try to get a bare-metal application to run in the
> >> >> simulator.
> >> >>
> >> > I have built their latest toolchain, gcc  4.9.0 and binutils 2.24.51.
> >> > with newlib. A helloworld program is working fine with or1k-elf-run,
> >> > or1k-elf-gdb (which connects to their or1ksim simulator) and qemu.
> >> >
> >> > The questions is, should this project include porting their toolchains
> >> > to
> >> > RTEMS toolchains (with their copyrights) ? or that may cause some
> >> > licence/copyrights problems ?
> >> In order for RTEMS Project to accept the BSP for inclusion, the GCC
> >> toolchain must be available and prepared for upstream submission. If
> >> there is already OpenRISC (or1k) support accepted by GCC for linux, it
> >> should be straightforward to make it work for RTEMS. You will need to
> >> propose it as part of your GSOC, and you will need to make the proper
> >> steps including submitting FSF paperwork for contributing to GCC.
> >
> > They have their latest toolchain at github [1]. Also there is a linux
> port
> > that can work
> > on both or1ksim and real HW FPGA [2]. Not sure how the project would
> > interface/interact with the existing or1k toolchain at github, gcc, and
> > RTEMS. I would
> > appreciate more clarification about this issue.
> >
> > [1] https://github.com/openrisc/or1k-src
> > [2] http://openrisc.net/toolchain-build.html
> If the or1k toolchain is not already upstream to GCC, you will need to
> provide a solution for a workable toolchain for users, probably by
> integrating the toolchain build into the RTEMS Source Builder. You
> should also push patches to GCC if possible. You should do an analysis
> of how much difference there is between the or1k toolchain and the
> vanilla GCC/binutils/newlib, and figure out if there is any reason
> other than laziness that the or1k maintainers have not pushed their
> toolchain into the upstream gcc / sourceware repositories.
>
> I'm hesitant to accept any port that lacks a dedicated RTEMS
> maintainer or tools maintained upstream in gcc.
>
> At least for microblaze we know there exists some toolchain support
> already. I'm not sure if there is enough left to do with the
> microblaze port to warrant a GSOC or not. You would have to inquire
> with the developers who have done work on it already.
>
> -Gedare
>
> >>
> >> -Gedare
> >
> >
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140305/5a8240fb/attachment.html>