[GSoC] How RTEMS, GCC and newlib interact ?

[Joel Sherrill]

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.

>
> 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.

> 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 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/6dadc530/attachment-0001.html>