porting RTEMS to OpenSparc
e_leontie at yahoo.com
Mon Oct 5 18:21:29 UTC 2009
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,
--- 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
> 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
> , 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
> 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
More information about the users