<p dir="ltr"><br>
On Mar 8, 2014 1:35 PM, Hesham Moustafa <heshamelmatary@gmail.com> wrote:<br>
><br>
> On Sat, Mar 8, 2014 at 5:10 PM, Joel Sherrill <Joel.Sherrill@oarcorp.com> wrote:<br>
> ><br>
> > On Mar 7, 2014 4:37 PM, Hesham Moustafa <heshamelmatary@gmail.com> wrote:<br>
> >><br>
> >> I have some questions about how RTEMS, GCC, newlib interact with each<br>
> >> other,<br>
> >> and which parts of them should I care and know about when porting RTEMS<br>
> >> to OpenRISC.<br>
> >><br>
> >> For example, the newlib port for OpenRISC includes some functions that<br>
> >> deal with<br>
> >> interrupts, exceptions, writing to SPRs, Caches, MMU, etc [1]. How this<br>
> >> should<br>
> >> be used within RTEMS ?<br>
> ><br>
> > Most Newlib ports do not include things like this. They only add stuff like<br>
> > setjmp and maybe str* and mem* to libc/machine. Plus some .h file tweaks to<br>
> > know the architecture.<br>
> ><br>
> > What directory are these in? If in libgloss, we would have to figure out how<br>
> > to reuse them. Libgloss is not used by RTEMS.<br>
> ><br>
> These are on newlib/libc/machine/or1k/</p>
<p dir="ltr">This is unusual but if the Newlib maintainers accept the patch with these .h files in this directory, then they are fair to use in or1k specific files.</p>
<p dir="ltr">> >><br>
> >> What is the main distinction between code in score/cpu and rtems/libcpu<br>
> >> and<br>
> >> which functions to place in either one?<br>
> >> For previous projects I worked on, there were some duplicate code between<br>
> >> both.<br>
> ><br>
> > Score/cpu is only allowed to know what can be determined by GCC multilibs.<br>
> > No peripherals or cpu model specific information.<br>
> ><br>
> > Libcpu had broader scope initially but I would probably stick to supporting<br>
> > cache methods there now and do all the code under libbsp.<br>
> > Libbsp/openrisc/shared for common pieces. Since there is reusable IP, the<br>
> > question is whether it is openrisc specific or available to other<br>
> > architectures. Then it should be in something like<br>
> > libbsp/shared/opencores/...<br>
> ><br>
> > The bsp itself represents a single instance of a system on chip and board<br>
> > configuration. It may support a related family and easily could in this<br>
> > case.<br>
> ><br>
> >> Also there are some functions within OpenRISC newlib port that implement<br>
> >> board<br>
> >> specific functions. How these functions should interact with RTEMS libbsp<br>
> >> ?<br>
> >> wrappers maybe ?<br>
> ><br>
> > Most likely just example code.<br>
> ><br>
> >> How could I identify which function needs to be implemented in RTEMS (and<br>
> >> where), and which to use from newlib/gcc ?<br>
> ><br>
> > Technically the openrisc Newlib patch should have all we need. They need to<br>
> > get it submitted to Newlib for review.<br>
> ><br>
> > If they have driver-ish code, it should be in libgloss and since we do not<br>
> > use that code, it is technically just examples for building a bsp. But if<br>
> > they have .h files for chip and peripherals, we want to find a reasonable<br>
> > way to reuse it.<br>
> ><br>
> Yes there are .c files at ibgloss/or1k which implement read, write, uart,<br>
> board specifics and other processes functions (fork, getpid, etc)<br>
><br>
> >> Which parts of GCC/binuitls toolchain I need to know about (other than the<br>
> >> backend and OpenRISC port) and modify to fit with RTEMS ?<br>
> ><br>
> > Most of the time, all we end up with is gcc/config/CPU/rtems.h and some<br>
> > configure script additions. Look at what was done for other ports. Nothing<br>
> > radical. First try to build their or1k elf tools and we move from there.<br>
> ><br>
> I have already built all their toolchain and ran HelloWorld program on<br>
> gdb/or1ksim.</p>
<p dir="ltr">The libgloss code used to print will correspond to the console driver guts.</p>
<p dir="ltr">Does the simulator include interrupt support? For at least a clock tick? If not, this is a good thing to have a bsp to test with but not enough to do a complete port.<br>
> > I would also dig back in the rtems repo and see if what used to exist as a<br>
> > port is useful. If the architecture is the same, the port will be easier.<br>
> ><br>
> >> [1] http://opencores.org/or1k/Newlib<br>
> >><br>
> >> Thanks,<br>
> >> Hesham<br>
> >> _______________________________________________<br>
> >> rtems-devel mailing list<br>
> >> rtems-devel@rtems.org<br>
> >> http://www.rtems.org/mailman/listinfo/rtems-devel<br>
</p>