On Thu Nov 13 2014 at 5:58:25 PM Joel Sherrill <joel.sherr...@oarcorp.com> wrote:
> > > On November 13, 2014 11:56:32 AM CST, Hesham Moustafa < > heshamelmat...@gmail.com> wrote: > >Hi, > > > > > >I want to let you know that I found their main repos [1] Can I start > >from there? Imitating what has been done with OpenRISC? > > > > Basically. Except you only need their repos for binutils and gdb. We use > GCC and Newlib from upstream. > > Great, I am waiting for these patches. > I have binutils patches > > >[1] https://github.com/adapteva > > > > > >Regards, > > > >Hesham > > > >On Thu Nov 13 2014 at 3:29:14 PM Hesham Moustafa > ><heshamelmat...@gmail.com> wrote: > > > >On Thu Nov 13 2014 at 2:59:33 PM Joel Sherrill > ><joel.sherr...@oarcorp.com> wrote: > > > > > >On 11/13/2014 8:07 AM, Joel Sherrill wrote: > >> > >> On November 13, 2014 6:30:48 AM CST, Hesham Moustafa > ><heshamelmat...@gmail.com> wrote: > >>> Hi all, > >>> > >>> > >>> I want to ask about the status of RTEMS toolchain for Epiphany > >>> architecture. I think Joel mentioned that there are some previous > >>> support for it; and if yes, does the toolchain need some additional > >>> work? > >> To give you a quick answer, I emailed the people who did the port. > >There apparently is a github repo with some of it and some is merged. I > >will dig through the emails and post the proper links. > >> > >> One issue they mentioned was that the gdb port had many core/thread > >support that made it more than a simple port. > >From Jeremy Bennett: > > > >> piphany tool chain development runs on quite a tight budget, and its > >> GDB implementation is quite complex (it has to pretend cores are > >> threads, when they don't completely share an address space). So we > >> haven't had the effort to devote to upstreaming. And we were > >> reluctant to push the simulator upstream without a GDB implementation > >> to go with it. You can of course access the code here: > >> > >> https://github.com/adapteva/epiphany-binutils-gdb > >> > >> Epiphany GDB is still in quite substantial flux, due to the need to > >> support the Eclipse multicore visualizer with asynchronous and > >> non-stop support. > >The upstream gcc and newlib are OK. But since binutils and gdb are > >now in a single repo, it will need to come from the github site until > >it is merged upstream. And obviously patches just need to go upstream > >to whereever the code is. :) > > > >Jeremy also encouraged you to openly discuss things on their forums. > >He thought you would get good insight and advice there. And I don't > >doubt that. > > > >Thank you, I will. > > > >If it is a relatively low volume place, I may track it. But my email > >volume > >is already high and I don't have time to poke around on a bulletin > >board. > > > >> It will not have RTEMS as a target but that shouldn't be hard to > >address once we know where the master binutils, GCC, Newlib, and gdb > >are. > >So do you want me to try to build a toolchain and get you some starting > >patches? > > > >Sure that will definitely help as a starting point. And if you are so > >busy, you can just drop me HOWTO instructions. > > > >> Then you are porting. > >> > >>> Regards, > >>> > >>> Hesham > >> _______________________________________________ > >> devel mailing list > >> devel@rtems.org > >> http://lists.rtems.org/mailman/listinfo/devel > > > >-- > >Joel Sherrill, Ph.D. Director of Research & Development > >joel.sherr...@oarcorp.com On-Line Applications Research > >Ask me about RTEMS: a free RTOS Huntsville AL 35805 > >Support Available (256) 722-9985 > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
