SPARC V9 support

[Joel Sherrill]

Alexandre Constantino wrote:

>Hi,
>
>I tried to run the hello_world executive on a SPARC V9 (Ultra 5) machine
>using SILO but the result wasn't very encouraging.
>
>Using the ERC32 and ERC32nfp OpenBoot error messaged me with "Fast
>Instruction Access MMU Miss"
>With the Leon1 BSP I received an "Illegal Instruction" error message.
>
>Digging into RTEMS mail archives I found one single message (with no
>replies) about the V9:
>http://www.rtems.com/ml/rtems-users/2002/november/msg00216.html
>
>And indeed the V9 has undergone a lot of changes, like the PSR
>(Processor State Register) being deleted... And RTEMS can't work without
>this one :)
>http://docs.sun.com/app/docs/doc/806-3774
>
>OTOH Wikipedia states that "The architecture has provided continuous
>application binary compatibility from the first SPARC V7 implementation
>in 1987 into the Sun UltraSPARC Architecture implementations."
>http://en.wikipedia.org/wiki/UltraSparc
>And on RTEMS webpage it is mentioned that RTEMS supports "SPARC V7 and
>above CPUs"
>http://www.rtems.com/targets.html
>
>
>
>Could anyone clarify me on this?
>  
>
Sounds like we trusted Sun on what they said. :)

I don't know of anyone who has ever successfully run RTEMS on any SPARC 
other than
an ERC32 or LEON.    Those were/are the most popular embedded SPARC 
CPUs. According
to the documentation, it should have worked on more advanced CPU models. 

Looking at the changes section and making an educated guess, I would say 
that score/cpu/sparc
is going to need some v7/v8/v9 ifdef's for the PSR and that the 
windowing trap handler is
going to need to be different.  The size of the registers in the context 
data structure will have to
be conditional for 32/64 bits.

It should have no impact outside cpukit/score/cpu/sparc, libcpu/sparc, 
and you will have to have a
new BSP for the Ultra.  But given their documentation on differences, it 
should be fairly mechanical
to review the SPARC specific code in RTEMS and identify the areas.  
Looks like a handful of point
modifications ignoring the BSP issue.

>Thank you for your time.
>
>
>Alexandre Constantino
>  
>