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