[GSoC] How RTEMS, GCC and newlib interact ?

[Joel Sherrill]

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 <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/
>>
>> 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 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/1c3ec7da/attachment-0001.html>