
<html><head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

<meta name="Generator" content="Microsoft Exchange Server">

<!-- converted from text -->

<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style></head>

<body>

<body><p dir="ltr">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.</p><div class="quote">On Mar 8, 2014 1:35 PM, Hesham Moustafa <heshamelmatary@gmail.com> wrote:<br type="attribution"></div></body>

<font size="2"><div class="PlainText">On Sat, Mar 8, 2014 at 5:10 PM, Joel Sherrill <Joel.Sherrill@oarcorp.com> wrote:<br>

><br>

> On Mar 7, 2014 4:37 PM, Hesham Moustafa <heshamelmatary@gmail.com> wrote:<br>

>><br>

>> I have some questions about how RTEMS, GCC, newlib interact with each<br>

>> other,<br>

>> and which parts of them should I care and know about when porting RTEMS<br>

>> to OpenRISC.<br>

>><br>

>> For example, the newlib port for OpenRISC includes some functions that<br>

>> deal with<br>

>> interrupts, exceptions, writing to SPRs, Caches, MMU, etc [1]. How this<br>

>> should<br>

>> be used within RTEMS ?<br>

><br>

> Most Newlib ports do not include things like this. They only add stuff like<br>

> setjmp and maybe str* and mem* to libc/machine. Plus some .h file tweaks to<br>

> know the architecture.<br>

><br>

> What directory are these in? If in libgloss, we would have to figure out how<br>

> to reuse them. Libgloss is not used by RTEMS.<br>

><br>

These are on newlib/libc/machine/or1k/<br>

>><br>

>> What is the main distinction between code in score/cpu and rtems/libcpu<br>

>> and<br>

>> which functions to place in either one?<br>

>> For previous projects I worked on, there were some duplicate code between<br>

>> both.<br>

><br>

> Score/cpu is only allowed to know what can be determined by GCC multilibs.<br>

> No peripherals or cpu model specific information.<br>

><br>

> Libcpu had broader scope initially but I would probably stick to supporting<br>

> cache methods there now and do all the code under libbsp.<br>

> Libbsp/openrisc/shared for common pieces. Since there is reusable IP, the<br>

> question is whether it is openrisc specific or available to other<br>

> architectures. Then it should be in something like<br>

> libbsp/shared/opencores/...<br>

><br>

> The bsp itself represents a single instance of a system on chip and board<br>

> configuration. It may support a related family and easily could in this<br>

> case.<br>

><br>

>> Also there are some functions within OpenRISC newlib port that implement<br>

>> board<br>

>> specific functions. How these functions should interact with RTEMS libbsp<br>

>> ?<br>

>> wrappers maybe ?<br>

><br>

> Most likely just example code.<br>

><br>

>> How could I identify which function needs to be implemented in RTEMS (and<br>

>> where), and which to use from newlib/gcc ?<br>

><br>

> Technically the openrisc Newlib patch should have all we need. They need to<br>

> get it submitted to Newlib for review.<br>

><br>

> If they have driver-ish code, it should be in libgloss and since we do not<br>

> use that code, it is technically just examples for building a bsp. But if<br>

> they have .h files for chip and peripherals, we want to find a reasonable<br>

> way to reuse it.<br>

><br>

Yes there are .c files at ibgloss/or1k which implement read, write, uart,<br>

board specifics and other processes functions (fork, getpid, etc)<br>

<br>

>> Which parts of GCC/binuitls toolchain I need to know about (other than the<br>

>> backend and OpenRISC port) and modify to fit with RTEMS ?<br>

><br>

> Most of the time, all we end up with is gcc/config/CPU/rtems.h and some<br>

> configure script additions. Look at what was done for other ports. Nothing<br>

> radical. First try to build their or1k elf tools and we move from there.<br>

><br>

I have already built all their toolchain and ran HelloWorld program on<br>

gdb/or1ksim.<br>

> I would also dig back in the rtems repo and see if what used to exist as a<br>

> port is useful. If the architecture is the same, the port will be easier.<br>

><br>

>> [1] <a href="http://opencores.org/or1k/Newlib">http://opencores.org/or1k/Newlib</a><br>

>><br>

>> Thanks,<br>

>> Hesham<br>

>> _______________________________________________<br>

>> rtems-devel mailing list<br>

>> rtems-devel@rtems.org<br>

>> <a href="http://www.rtems.org/mailman/listinfo/rtems-devel">http://www.rtems.org/mailman/listinfo/rtems-devel</a><br>

</div></font>

</body>

</html>