porting RTEMS to OpenSparc

Wed Aug 12 18:52:11 UTC 2009

Thanks Joel,
your input is really useful.
The OpenSparc community has a SPARC simulator,  http://cooltools.sunsource.net/shade/index.html (works only for Solaris unfortunatelly ), but there might be others, I will look closer.

Why OpenSparc is attractive to me is that we do have close relations with a group that can augment the FPGA implementation of OpenSparc with the architectural enhancements we study. I am not sure whether OpenSparc is more valuable than Leon ( which is also FPGA synthesisable), but because of the detailed simulator availability it is certainly a more attractive option for me.

Having just one core and (maybe) ignoring the hardware threads features at first would be best for me as well. I am quite unfamiliar with the SPARC architecture in general, you can imagine I know little about the particularities of the UltraSparc T1/OpenSparc cores. This is what grad school is for, learning :). I will try to look at the compiler/libc/binutils side and booting process for the OpenSparc first and take it from there.

Eugen

--- On Tue, 8/11/09, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:

From: Joel Sherrill <joel.sherrill at oarcorp.com>
Subject: Re: porting RTEMS to OpenSparc
To: "Leontie Eugen" <e_leontie at yahoo.com>
Cc: "rtems-users at rtems.org" <rtems-users at rtems.org>
Date: Tuesday, August 11, 2009, 10:50 PM

Leontie Eugen wrote:
> Question in short : How difficult is it to port RTEMS to a really simple bsp based on the OpenSparc T1 processor ?
> 
If you ignore the idea of distributing RTEMS threads onto the multiple cores at first
and restrict yourself to a simple view of it as a single core CPU, you will have to
deal with whatever SPARC architectural differences there are between the V7 CPU
models currently supported and the V9 T1.   This may result in having to touch
the interrupt processing and context switch code.  I really don't know offhand.

A basic BSP with enough to run simple multithreaded code on and run
the RTEMS tests needs the following:

+ start - assembly code to initialize stack
+ hw initialization - board specific
+ clock tick - periodic interrupt to update time
+ console for debug output

Without knowing much, the V7 versus V9 differences will likely more challenging
than the BSP itself.

One minor issue is that the current gcc tools only build v7 and v8 "multilib"
variants.  v9 variants will have to be added.  This from the gcc manual hints
at some of the differences.

    With `-mcpu=v9', GCC generates code for the V9 variant of the SPARC
    architecture.  This adds 64-bit integer and floating-point move
    instructions, 3 additional floating-point condition code registers
    and conditional move instructions.  With `-mcpu=ultrasparc', the
    compiler additionally optimizes it for the Sun UltraSPARC I/II/IIi
    chips.  With `-mcpu=ultrasparc3', the compiler additionally
    optimizes it for the Sun UltraSPARC III/III+/IIIi/IIIi+/IV/IV+
    chips.  With `-mcpu=niagara', the compiler additionally optimizes
    it for Sun UltraSPARC T1 chips.  With `-mcpu=niagara2', the
    compiler additionally optimizes it for Sun UltraSPARC T2 chips.

So the context has to support 64 bit registers and there are more
FP registers to deal with.  The mips port already is an example of
sharing source between 32 and 64 bit variants so probably has guidance
for us.

> Question in details : My name is Eugen Leontie, I am a doctoral student at George Washington University. I want to use RTEMS as a target OS for a security enhanced processor architecture ( a MMU like structure that we are trying to develop - I will not go into details - I know RTEMS does not yet have virtual memory/security support, this is one of the reasons we chose it ). At this point I need to evaluate if it is feaseable to use RTEMS and I need some help from you. In order to get accurate cycle accurate performance measurements I need to get RTEMS to run one of Simics (http://www.virtutech.com/) target systems that supports Microarchitectural Simulations ( cycle accurate pipeline and caches simulations ). I found that there is a Leon2 port of Rtems that works with Simics http://www.cs.sfu.ca/~fedorova/Tech/simics-guides-3.0.26/simics-target-guide-leon2-simple.pdf
 <http://www.cs.sfu.ca/%7Efedorova/Tech/simics-guides-3.0.26/simics-target-guide-leon2-simple.pdf> , unfortunatelly the Leon target is pretty limited and can not support the features we need. The target we have in mind uses a SPARC processor, UltraSparc T1, http://www.cs.sfu.ca/~fedorova/Tech/simics-guides-3.0.26/simics-target-guide-niagara.pdf <http://www.cs.sfu.ca/%7Efedorova/Tech/simics-guides-3.0.26/simics-target-guide-niagara.pdf> that models very basically a Sun Fire T2000 server, it only has a console and RTC as modelled devices. It currently only works with an existing solaris image provided by the OpenSparc project. My question is how difficult ( in terms of time ) would it be to port RTEMS to the UltraSparc T1 based BSP ( a begginer versus a pro - as I need to estimate if I can use an undergraduate to this task or to contract a RTEMS speciallist just for this). And how valuable is to the RTEMS project such a port - I hope I can trade in this
 contribution to the RTEMS community and getting some forum/chat support getting this done . I am more than happy to provide additional details. Thank you in advance for your help. Eugen
> 

One long term issue we would face as a project is testing.  Is
there a free simulator that the BSP will be able to be tested on?

We are always happy to help by providing advice when someone wants to
port RTEMS to something new.  I don't know how much general interest there
is in a T1 port but it is interesting. :)

-- Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available             (256) 722-9985