<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 27, 2015 at 2:13 AM, sgtas company <span dir="ltr"><<a href="mailto:sgtas@mail.com" target="_blank">sgtas@mail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:Verdana;font-size:12.0px"><div>Hi,</div>

<div> </div>

<div>Two humble apologies in advance:</div>

<div>1) sorry for spamming y'all that didn't hit the 'delete' button or spam filter already and have wasted valuable seconds reading this</div>

<div>2) sorry if this is completely the wrong place for this email --- please let me know where I should have gone instead</div></div></div></blockquote><div><br></div><div style="">This is the right place. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:Verdana;font-size:12.0px">

<div> </div>

<div>However, given the following (and other similar blurbs I found on the Wiki):</div>

<div>
<h1>Potential Ports</h1>

<p>We are always interested in adding ports to other CPU families supported by the GNU tools. If you are interested in working on a port or are ready to submit one, contact us.</p>

<ul>
        <li>Atmel AVR</li>
        <li>Xtensa</li>
        <li>Motorola MCore</li>
        <li>Texas Instruments C6x</li>
        <li>ARC</li>
        <li>...</li>
</ul>

<div></div></div></div></div></blockquote><div style="">FWIW The list is out of date. The AVR has been ported and is in the process of</div><div style="">being removed. It was a challenge to fit RTEMS on anything but the largest AVR</div><div style="">CPU models. Plus GCC seems to always be broken for AVR.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:Verdana;font-size:12.0px"><div><div>This is to let "us" from "contact us" know that I am interested in porting rtmems to Motorola MCore, or to be more specific, to my s8g001 processor (and s8g1eb platform/board), which is 99.999% compatible with MCore (i.e. minus some MCore bugs).</div>

<div> </div></div></div></div></blockquote><div style="">This is the right place for us.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:Verdana;font-size:12.0px"><div>

<div>I'm going to go ahead with this starting next month, with or without help, and any comments/suggestions at this point would be welcome (especially the "don't bother, it's already been done" kind:)</div>

<div> </div>

<div>I'm primarily a hardware/processor/ASIC/SoC designer, but I do know my way around software (C/C++/assembly/etc), although my OS/porting experience is limited (for now).</div>

<div>I've worked on/with MCore processors for many many years, and I'm intimately familiar with the hardware and ISA, having system-designed with, and (re-)developed/implemented several MCore variants (SM210/M210S/M310S/C306/C310/C312/CS320/etc and my own compatible s8g001/011/012/021 cores) in various 0.35u to 45nm processes and FPGA.</div>

<div> </div>

<div>At this point, I've got my MCore compatible processor(s) coded, synthesized and running on my FPGA board. I've cross-compiled GCC/binutils with Newlib, to the point where I'm able to compile simple C-code programs and have those execute on my processor/board.</div>

<div>I've got a big/long technology roadmap that includes faster cores, multi-core platforms and DSP-extensions, however, my immediate/next step is to have 'something' OS-ish ported to my core/board such that it can boot up to a linux-ish command-line prompt. I'm assuming that rtmems will suit, and that it (porting) can be done for a system that includes just one CPU, some RAM, ROM, and one or two serial ports for I/O (text display and keyboard?). I'm happy to add other hardware as needed (eg MMU, graphics, etc). The ultimatre goal is to have all the bells and whistles (full blown desktop/server linux, openCL, etc) on an MCore based many-core platform, but one has to start somewehere. I'm guessing just porting/booting rtmems will be difficult enough to keep me entertained for a while...</div>

<div> </div></div></div></div></blockquote><div style="">This much already running should give you a good head start. :)</div><div style=""><br></div><div style="">The basic porting process is:</div><div style=""><br></div><div style="">+ add mcore*-*-rtems* to binutils and gcc</div><div style="">  - RTEMS uses its own targets since we have multithread safe libc, libstdc++,</div><div style="">    Thread Local Storage, and other support that the basic CPU-elf targets do not.</div><div style="">  - add this recipe to the RTEMS Source Builder so we all can build the tools easily.</div><div style="">+ Focus on hello world on the mcore simulator in gdb. Having a BSP</div><div style="">   for that allows us to do automated testing. We don't all have hardware.</div><div style="">   - Using newlib, you should be able to get the linker script, crt0.S, and</div><div style="">     polled IO for a console.  This goes for gdb simulator BSP and your own.</div><div style="">   - This will require most of the port except interrupts to work.</div><div style="">+ Once hello world is running on simulator, you can add the automated</div><div style="">   testing support to rtems-tools.</div><div style="">   - At this point, you can run most tests on a simulator and see how things</div><div style="">     are going.</div><div style="">+ You can add Thread Local Storage at this point or later.</div><div style="">+ If the simulator in gdb doesn't support any interrupts, then move to real</div><div style="">   hardware and focus on the "ticker" application.</div><div style=""><br></div><div style="">There is a porting guide which has a lot of advice. The emphasis on the</div><div style="">simulator is important because it eases testing of both RTEMS and the</div><div style="">tools. It also gives us all a common reference platform to discuss bugs</div><div style="">and issues you encounter.</div><div style=""><br></div><div style="">Ask questions, dive in, and welcome on-board.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:Verdana;font-size:12.0px"><div>

<div>
<div>So, there! Comments anyone...?</div>

<div> </div>

<div>Thanks,</div>

<div>Michiel (sgtas at mail dot com).</div>

<div> </div>
</div>
</div></div></div>
<br>_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br></blockquote></div><br></div></div>