On Sun, Dec 27, 2015 at 2:13 AM, sgtas company <sg...@mail.com> wrote:
> Hi,
>
> Two humble apologies in advance:
> 1) sorry for spamming y'all that didn't hit the 'delete' button or spam
> filter already and have wasted valuable seconds reading this
> 2) sorry if this is completely the wrong place for this email --- please
> let me know where I should have gone instead
>
This is the right place.
>
> However, given the following (and other similar blurbs I found on the
> Wiki):
> Potential Ports
>
> 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.
>
> - Atmel AVR
> - Xtensa
> - Motorola MCore
> - Texas Instruments C6x
> - ARC
> - ...
>
> FWIW The list is out of date. The AVR has been ported and is in the
process of
being removed. It was a challenge to fit RTEMS on anything but the largest
AVR
CPU models. Plus GCC seems to always be broken for AVR.
> 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).
>
>
This is the right place for us.
> 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:)
>
> 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).
> 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.
>
> 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.
> 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...
>
>
This much already running should give you a good head start. :)
The basic porting process is:
+ add mcore*-*-rtems* to binutils and gcc
- RTEMS uses its own targets since we have multithread safe libc,
libstdc++,
Thread Local Storage, and other support that the basic CPU-elf targets
do not.
- add this recipe to the RTEMS Source Builder so we all can build the
tools easily.
+ Focus on hello world on the mcore simulator in gdb. Having a BSP
for that allows us to do automated testing. We don't all have hardware.
- Using newlib, you should be able to get the linker script, crt0.S, and
polled IO for a console. This goes for gdb simulator BSP and your own.
- This will require most of the port except interrupts to work.
+ Once hello world is running on simulator, you can add the automated
testing support to rtems-tools.
- At this point, you can run most tests on a simulator and see how things
are going.
+ You can add Thread Local Storage at this point or later.
+ If the simulator in gdb doesn't support any interrupts, then move to real
hardware and focus on the "ticker" application.
There is a porting guide which has a lot of advice. The emphasis on the
simulator is important because it eases testing of both RTEMS and the
tools. It also gives us all a common reference platform to discuss bugs
and issues you encounter.
Ask questions, dive in, and welcome on-board.
> So, there! Comments anyone...?
>
> Thanks,
> Michiel (sgtas at mail dot com).
>
>
> _______________________________________________
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
