[GSoC] How RTEMS, GCC and newlib interact ?

[Joel Sherrill]

On Mar 8, 2014 1:35 PM, Hesham Moustafa <heshamelmatary at gmail.com> wrote:
>
> On Sat, Mar 8, 2014 at 5:10 PM, Joel Sherrill <Joel.Sherrill at oarcorp.com> wrote:
> >
> > On Mar 7, 2014 4:37 PM, Hesham Moustafa <heshamelmatary at 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 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/20140308/3cfc18d0/attachment-0001.html>