porting RTEMS to OpenSparc

[Leontie Eugen]

Hi Dr. Sherrill, 

Just a few further questions. 
I could not find much info on the rtems specific changes to gcc. I saw there are rtems patches to gcc but I did not get a chance yet to look more carefully at what they are. 

it would help me a lot if you can summarize shortly what changes do you think will be needed for obtaining a sparc64-rtems4.10 compiler and toolchain. 

Me and a fellow student spent some time understanding the UltraSparc v9 and the sun4v architecture, it is time to move back to understanding RTEMS now. We got some porting guidance from a well documented HelenOS port to sun4v, we hope to rely on that to get started.

Thank you in advance,
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
> 
> 
>