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/
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. > >> > >> 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. The libgloss code used to print will correspond to the console driver guts. 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. > > 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
