From d3d9908fec8f5d146ffeff5607e9091c3ddd5bfd Mon Sep 17 00:00:00 2001 From: Joel Sherrill Date: Tue, 15 Jun 2010 22:48:08 +0000 Subject: 2010-06-15 Gedare Bloom PR 1565/cpukit * cpu_supplement/Makefile.am, cpu_supplement/cpu_supplement.texi: Merge SPARC64 port. * cpu_supplement/sparc64.t: New file. --- doc/ChangeLog | 7 + doc/cpu_supplement/Makefile.am | 7 +- doc/cpu_supplement/cpu_supplement.texi | 2 + doc/cpu_supplement/sparc64.t | 817 +++++++++++++++++++++++++++++++++ 4 files changed, 832 insertions(+), 1 deletion(-) create mode 100644 doc/cpu_supplement/sparc64.t (limited to 'doc') diff --git a/doc/ChangeLog b/doc/ChangeLog index 9ebc9a5fd9..6bbf395060 100644 --- a/doc/ChangeLog +++ b/doc/ChangeLog @@ -1,3 +1,10 @@ +2010-06-15 Gedare Bloom + + PR 1565/cpukit + * cpu_supplement/Makefile.am, cpu_supplement/cpu_supplement.texi: Merge + SPARC64 port. + * cpu_supplement/sparc64.t: New file. + 2010-06-11 Ralf Corsépius * Makefile.am: Don't install html_imagesdir unconditionally. diff --git a/doc/cpu_supplement/Makefile.am b/doc/cpu_supplement/Makefile.am index 6178223c56..f6f2f45d8c 100644 --- a/doc/cpu_supplement/Makefile.am +++ b/doc/cpu_supplement/Makefile.am @@ -14,7 +14,7 @@ include $(top_srcdir)/main.am REPLACE2 = $(PERL) $(top_srcdir)/tools/word-replace2 GENERATED_FILES = general.texi arm.texi avr.texi bfin.texi i386.texi lm32.texi \ - m68k.texi mips.texi powerpc.texi sh.texi sparc.texi tic4x.texi + m68k.texi mips.texi powerpc.texi sh.texi sparc.texi sparc64.texi tic4x.texi COMMON_FILES += $(top_srcdir)/common/cpright.texi @@ -82,6 +82,11 @@ sparc.texi: sparc.t -u "Top" \ -n "" < $< > $@ +sparc64.texi: sparc64.t + $(BMENU2) -p "" \ + -u "Top" \ + -n "" < $< > $@ + tic4x.texi: tic4x.t $(BMENU2) -p "" \ -u "Top" \ diff --git a/doc/cpu_supplement/cpu_supplement.texi b/doc/cpu_supplement/cpu_supplement.texi index bdc630d61b..c0627bd739 100644 --- a/doc/cpu_supplement/cpu_supplement.texi +++ b/doc/cpu_supplement/cpu_supplement.texi @@ -70,6 +70,7 @@ @include powerpc.texi @include sh.texi @include sparc.texi +@include sparc64.texi @include tic4x.texi @ifinfo @node Top, Preface, (dir), (dir) @@ -90,6 +91,7 @@ This is the online version of the RTEMS CPU Architecture Supplement. * PowerPC Specific Information:: * SuperH Specific Information:: * SPARC Specific Information:: +* SPARC-64 Specific Information:: * Texas Instruments C3x/C4x Specific Information:: * Command and Variable Index:: * Concept Index:: diff --git a/doc/cpu_supplement/sparc64.t b/doc/cpu_supplement/sparc64.t new file mode 100644 index 0000000000..a6bee41884 --- /dev/null +++ b/doc/cpu_supplement/sparc64.t @@ -0,0 +1,817 @@ +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@ifinfo +@end ifinfo +@chapter SPARC-64 Specific Information + +This document discusses the SPARC Version 9 (aka SPARC-64, SPARC64 or SPARC V9) +architecture dependencies in this port of RTEMS. + +The SPARC V9 architecture leaves a lot of undefined implemenation dependencies +which are defined by the processor models. Consult the specific CPU model +section in this document for additional documents covering the implementation +dependent architectural features. + +@subheading sun4u Specific Information +sun4u is the subset of the SPARC V9 implementations comprising the UltraSPARC I +through UltraSPARC IV processors. + +The following documents were used in developing the SPARC-64 sun4u port: +@itemize @bullet +@item UltraSPARC User’s Manual +(http://www.sun.com/microelectronics/manuals/ultrasparc/802-7220-02.pdf) +@item UltraSPARC IIIi Processor (datasheets.chipdb.org/Sun/UltraSparc-IIIi.pdf) +@end itemize + +@subheading sun4v Specific Information +sun4v is the subset of the SPARC V9 implementations comprising the +UltraSPARC T1 or T2 processors. + +The following documents were used in developing the SPARC-64 sun4v port: +@itemize @bullet +@item UltraSPARC Architecture 2005 Specification + (http://opensparc-t1.sunsource.net/specs/UA2005-current-draft-P-EXT.pdf) +@item UltraSPARC T1 supplement to UltraSPARC Architecture 2005 Specification +(http://opensparc-t1.sunsource.net/specs/UST1-UASuppl-current-draft-P-EXT.pdf) +@end itemize + +The defining feature that separates the sun4v architecture from its +predecessor is the existence of a super-privileged hypervisor that +is responsible for providing virtualized execution environments. The impact +of the hypervisor on the real-time guarantees available with sun4v has not +yet been determined. + +@c +@c +@c + +@section CPU Model Dependent Features + +@subsection CPU Model Feature Flags +This section presents the set of features which vary across +SPARC-64 implementations and +are of importance to RTEMS. The set of CPU model feature macros +are defined in the file +cpukit/score/cpu/sparc64/sparc64.h based upon the particular +CPU model defined on the compilation command line. + +@subsubsection CPU Model Name + +The macro CPU MODEL NAME is a string which designates +the name of this CPU model. +For example, for the UltraSPARC T1 SPARC V9 model, +this macro is set to the string "sun4v". + +@subsubsection Floating Point Unit + +The macro SPARC_HAS_FPU is set to 1 to indicate that +this CPU model has a hardware floating point unit and 0 +otherwise. + +@subsubsection Number of Register Windows + +The macro SPARC_NUMBER_OF_REGISTER_WINDOWS is set to +indicate the number of register window sets implemented by this +CPU model. The SPARC architecture allows for a maximum of +thirty-two register window sets although most implementations +only include eight. + +@subsection CPU Model Implementation Notes + +This section describes the implemenation dependencies of the +CPU Models sun4u and sun4v of the SPARC V9 architecture. + +@subsubsection sun4u Notes + +XXX + +@subsection sun4v Notes + +XXX + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Calling Conventions + +Each high-level language compiler generates +subroutine entry and exit code based upon a set of rules known +as the compiler's calling convention. These rules address the +following issues: + +@itemize @bullet +@item register preservation and usage + +@item parameter passing + +@item call and return mechanism +@end itemize + +A compiler's calling convention is of importance when +interfacing to subroutines written in another language either +assembly or high-level. Even when the high-level language and +target processor are the same, different compilers may use +different calling conventions. As a result, calling conventions +are both processor and compiler dependent. + +The following document also provides some conventions on the +global register usage in SPARC V9: +http://developers.sun.com/solaris/articles/sparcv9abi.html + +@subsection Programming Model + +This section discusses the programming model for the +SPARC architecture. + +@subsubsection Non-Floating Point Registers + +The SPARC architecture defines thirty-two +non-floating point registers directly visible to the programmer. +These are divided into four sets: + +@itemize @bullet +@item input registers + +@item local registers + +@item output registers + +@item global registers +@end itemize + +Each register is referred to by either two or three +names in the SPARC reference manuals. First, the registers are +referred to as r0 through r31 or with the alternate notation +r[0] through r[31]. Second, each register is a member of one of +the four sets listed above. Finally, some registers have an +architecturally defined role in the programming model which +provides an alternate name. The following table describes the +mapping between the 32 registers and the register sets: + +@ifset use-ascii +@example +@group + +-----------------+----------------+------------------+ + | Register Number | Register Names | Description | + +-----------------+----------------+------------------+ + | 0 - 7 | g0 - g7 | Global Registers | + +-----------------+----------------+------------------+ + | 8 - 15 | o0 - o7 | Output Registers | + +-----------------+----------------+------------------+ + | 16 - 23 | l0 - l7 | Local Registers | + +-----------------+----------------+------------------+ + | 24 - 31 | i0 - i7 | Input Registers | + +-----------------+----------------+------------------+ +@end group +@end example +@end ifset + +@ifset use-tex +@sp 1 +@tex +\centerline{\vbox{\offinterlineskip\halign{ +\vrule\strut#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#\cr +\noalign{\hrule} +&\bf Register Number &&\bf Register Names&&\bf Description&\cr\noalign{\hrule} +&0 - 7&&g0 - g7&&Global Registers&\cr\noalign{\hrule} +&8 - 15&&o0 - o7&&Output Registers&\cr\noalign{\hrule} +&16 - 23&&l0 - l7&&Local Registers&\cr\noalign{\hrule} +&24 - 31&&i0 - i7&&Input Registers&\cr\noalign{\hrule} +}}\hfil} +@end tex +@end ifset + +@ifset use-html +@html +
+ + + + + + + + + + + + + + + + +
Register NumberRegister NamesDescription
0 - 7g0 - g7Global Registers
8 - 15o0 - o7Output Registers
16 - 23l0 - l7Local Registers
24 - 31i0 - i7Input Registers
+
+@end html +@end ifset + +As mentioned above, some of the registers serve +defined roles in the programming model. The following table +describes the role of each of these registers: + +@ifset use-ascii +@example +@group + +---------------+----------------+----------------------+ + | Register Name | Alternate Name | Description | + +---------------+----------------+----------------------+ + | g0 | na | reads return 0 | + | | | writes are ignored | + +---------------+----------------+----------------------+ + | o6 | sp | stack pointer | + +---------------+----------------+----------------------+ + | i6 | fp | frame pointer | + +---------------+----------------+----------------------+ + | i7 | na | return address | + +---------------+----------------+----------------------+ +@end group +@end example +@end ifset + +@ifset use-tex +@sp 1 +@tex +\centerline{\vbox{\offinterlineskip\halign{ +\vrule\strut#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#\cr +\noalign{\hrule} +&\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule} +&g0&&NA&&reads return 0; &\cr +&&&&&writes are ignored&\cr\noalign{\hrule} +&o6&&sp&&stack pointer&\cr\noalign{\hrule} +&i6&&fp&&frame pointer&\cr\noalign{\hrule} +&i7&&NA&&return address&\cr\noalign{\hrule} +}}\hfil} +@end tex +@end ifset + +@ifset use-html +@html +
+ + + + + + + + + + + + + + + + +
Register NameAlternate NameDescription
g0NAreads return 0 ; writes are ignored
o6spstack pointer
i6fpframe pointer
i7NAreturn address
+
+@end html +@end ifset + + +@subsubsection Floating Point Registers + +The SPARC V9 architecture includes sixty-four, +thirty-two bit registers. These registers may be viewed as +follows: + +@itemize @bullet +@item 32 32-bit single precision floating point or integer registers +(f0, f1, ... f31) + +@item 32 64-bit double precision floating point registers (f0, f2, +f4, ... f62) + +@item 16 128-bit extended precision floating point registers (f0, f4, +f8, ... f60) +@end itemize + +The floating point state register (fsr) specifies +the behavior of the floating point unit for rounding, contains +its condition codes, version specification, and trap information. + +@subsubsection Special Registers + +The SPARC architecture includes a number of special registers: +@table @b + +@item @code{Ancillary State Registers (ASRs)} +The ancillary state registers (ASRs) are optional state registers that +may be privileged or nonprivileged. ASRs 16-31 are implementation- +dependent. The SPARC V9 ASRs include: y, ccr, asi, tick, pc, fprs. +The sun4u ASRs include: pcr, pic, dcr, gsr, softint set, softint clr, +softint, and tick cmpr. The sun4v ASRs include: pcr, pic, gsr, soft- +int set, softint clr, softint, tick cmpr, stick, and stick cmpr. + +@item @code{Processor State Register (pstate)} +The privileged pstate register contains control fields for the proces- +sor’s current state. Its flag fields include the interrupt enable, privi- +leged mode, and enable FPU. + +@item @code{Processor Interrupt Level (pil)} +The PIL specifies the interrupt level above which interrupts will be +accepted. + +@item @code{Trap Registers} +The trap handling mechanism of the SPARC V9 includes a number of +registers, including: trap program counter (tpc), trap next pc (tnpc), +trap state (tstate), trap type (tt), trap base address (tba), and trap +level (tl). + +@item @code{Alternate Globals} +The AG bit of the pstate register provides access to an alternate set +of global registers. On sun4v, the AG bit is replaced by the global +level (gl) register, providing access to at least two and at most eight +alternate sets of globals. + +@item @code{Register Window registers} +A number of registers assist in register window management. +These include the current window pointer (cwp), savable windows +(cansave), restorable windows (canrestore), clean windows (clean- +win), other windows (otherwin), and window state (wstate). + +@end table + +@subsection Register Windows + +The SPARC architecture includes the concept of +register windows. An overly simplistic way to think of these +windows is to imagine them as being an infinite supply of +"fresh" register sets available for each subroutine to use. In +reality, they are much more complicated. + +The save instruction is used to obtain a new register window. +This instruction increments the current window pointer, thus +providing a new set of registers for use. This register set +includes eight fresh local registers for use exclusively by +this subroutine. When done with a register set, the restore +instruction decrements the current window pointer and the +previous register set is once again available. + +The two primary issues complicating the use of register windows +are that (1) the set of register windows is finite, and (2) some +registers are shared between adjacent registers windows. + +Because the set of register windows is finite, it is +possible to execute enough save instructions without +corresponding restore's to consume all of the register windows. +This is easily accomplished in a high level language because +each subroutine typically performs a save instruction upon +entry. Thus having a subroutine call depth greater than the +number of register windows will result in a window overflow +condition. The window overflow condition generates a trap which +must be handled in software. The window overflow trap handler +is responsible for saving the contents of the oldest register +window on the program stack. + +Similarly, the subroutines will eventually complete +and begin to perform restore's. If the restore results in the +need for a register window which has previously been written to +memory as part of an overflow, then a window underflow condition +results. Just like the window overflow, the window underflow +condition must be handled in software by a trap handler. The +window underflow trap handler is responsible for reloading the +contents of the register window requested by the restore +instruction from the program stack. + +The cansave, canrestore, otherwin, and cwp are used in conjunction +to manage the finite set of register windows and detect the window +overflow and underflow conditions. The first three of these +registers must satisfy the invariant cansave + canrestore + otherwin = +nwindow - 2, where nwindow is the number of register windows. +The cwp contains the index of the register window currently in use. +RTEMS does not use the cleanwin and otherwin registers. + +The save instruction increments the cwp modulo the number of +register windows, and if cansave is 0 then it also generates a +window overflow. Similarly, the restore instruction decrements the +cwp modulo the number of register windows, and if canrestore is 0 then it +also generates a window underflow. + +Unlike with the SPARC model, the SPARC-64 port does not assume that +a register window is available for a trap. The window overflow +and underflow conditions are not detected without hardware generating +the trap. (These conditions can be detected by reading the register window +registers and doing some simple arithmetic.) + +The window overflow and window underflow trap +handlers are a critical part of the run-time environment for a +SPARC application. The SPARC architectural specification allows +for the number of register windows to be any power of two less +than or equal to 32. The most common choice for SPARC +implementations appears to be 8 register windows. This results +in the cwp ranging in value from 0 to 7 on most implementations. + +The second complicating factor is the sharing of +registers between adjacent register windows. While each +register window has its own set of local registers, the input +and output registers are shared between adjacent windows. The +output registers for register window N are the same as the input +registers for register window ((N + 1) modulo RW) where RW is +the number of register windows. An alternative way to think of +this is to remember how parameters are passed to a subroutine on +the SPARC. The caller loads values into what are its output +registers. Then after the callee executes a save instruction, +those parameters are available in its input registers. This is +a very efficient way to pass parameters as no data is actually +moved by the save or restore instructions. + +@subsection Call and Return Mechanism + +The SPARC architecture supports a simple yet +effective call and return mechanism. A subroutine is invoked +via the call (call) instruction. This instruction places the +return address in the caller's output register 7 (o7). After +the callee executes a save instruction, this value is available +in input register 7 (i7) until the corresponding restore +instruction is executed. + +The callee returns to the caller via a jmp to the +return address. There is a delay slot following this +instruction which is commonly used to execute a restore +instruction -- if a register window was allocated by this +subroutine. + +It is important to note that the SPARC subroutine +call and return mechanism does not automatically save and +restore any registers. This is accomplished via the save and +restore instructions which manage the set of registers windows. +This allows for the compiler to generate leaf-optimized functions +that utilize the caller’s output registers without using save and restore. + +@subsection Calling Mechanism + +All RTEMS directives are invoked using the regular +SPARC calling convention via the call instruction. + +@subsection Register Usage + +As discussed above, the call instruction does not +automatically save any registers. The save and restore +instructions are used to allocate and deallocate register +windows. When a register window is allocated, the new set of +local registers are available for the exclusive use of the +subroutine which allocated this register set. + +@subsection Parameter Passing + +RTEMS assumes that arguments are placed in the +caller's output registers with the first argument in output +register 0 (o0), the second argument in output register 1 (o1), +and so forth. Until the callee executes a save instruction, the +parameters are still visible in the output registers. After the +callee executes a save instruction, the parameters are visible +in the corresponding input registers. The following pseudo-code +illustrates the typical sequence used to call a RTEMS directive +with three (3) arguments: + +@example +load third argument into o2 +load second argument into o1 +load first argument into o0 +invoke directive +@end example + +@subsection User-Provided Routines + +All user-provided routines invoked by RTEMS, such as +user extensions, device drivers, and MPCI routines, must also +adhere to these calling conventions. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Memory Model + + +A processor may support any combination of memory +models ranging from pure physical addressing to complex demand +paged virtual memory systems. RTEMS supports a flat memory +model which ranges contiguously over the processor's allowable +address space. RTEMS does not support segmentation or virtual +memory of any kind. The appropriate memory model for RTEMS +provided by the targeted processor and related characteristics +of that model are described in this chapter. + +@subsection Flat Memory Model + +The SPARC-64 architecture supports a flat 64-bit address space with +addresses ranging from 0x0000000000000000 to 0xFFFFFFFFFFFFFFFF. +Each address is represented by a 64-bit value (and an 8-bit address +space identifider or ASI) and is byte addressable. The address +may be used to reference a single byte, half-word (2-bytes), +word (4 bytes), doubleword (8 bytes), or quad-word (16 bytes). +Memory accesses within this address space are performed +in big endian fashion by the SPARC. Memory accesses which are not +properly aligned generate a "memory address not aligned" trap +(type number 0x34). The following table lists the alignment +requirements for a variety of data accesses: + +@ifset use-ascii +@example +@group + +--------------+-----------------------+ + | Data Type | Alignment Requirement | + +--------------+-----------------------+ + | byte | 1 | + | half-word | 2 | + | word | 4 | + | doubleword | 8 | + | quadword | 16 | + +--------------+-----------------------+ +@end group +@end example +@end ifset + +@ifset use-tex +@sp 1 +@tex +\centerline{\vbox{\offinterlineskip\halign{ +\vrule\strut#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#\cr +\noalign{\hrule} +&\bf Data Type &&\bf Alignment Requirement&\cr\noalign{\hrule} +&byte&&1&\cr\noalign{\hrule} +&half-word&&2&\cr\noalign{\hrule} +&word&&4&\cr\noalign{\hrule} +&doubleword&&8&\cr\noalign{\hrule} +&quadword&&16&\cr\noalign{\hrule} +}}\hfil} +@end tex +@end ifset + +@ifset use-html +@html +
+ + + + + + + + + + + + + +
Data TypeAlignment Requirement
byte1
half-word2
word4
doubleword8
quadword16
+
+@end html +@end ifset + +RTEMS currently does not support any SPARC Memory Management +Units, therefore, virtual memory or segmentation systems +involving the SPARC are not supported. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Interrupt Processing + +RTEMS and associated documentation uses the terms +interrupt and vector. In the SPARC architecture, these terms +correspond to traps and trap type, respectively. The terms will +be used interchangeably in this manual. Note that in the SPARC manuals, +interrupts are a subset of the traps that are delivered to software +interrupt handlers. + +@subsection Synchronous Versus Asynchronous Traps + +The SPARC architecture includes two classes of traps: +synchronous (precise) and asynchronous (deferred). +Asynchronous traps occur when an +external event interrupts the processor. These traps are not +associated with any instruction executed by the processor and +logically occur between instructions. The instruction currently +in the execute stage of the processor is allowed to complete +although subsequent instructions are annulled. The return +address reported by the processor for asynchronous traps is the +pair of instructions following the current instruction. + +Synchronous traps are caused by the actions of an +instruction. The trap stimulus in this case either occurs +internally to the processor or is from an external signal that +was provoked by the instruction. These traps are taken +immediately and the instruction that caused the trap is aborted +before any state changes occur in the processor itself. The +return address reported by the processor for synchronous traps +is the instruction which caused the trap and the following +instruction. + +@subsection Vectoring of Interrupt Handler + +Upon receipt of an interrupt the SPARC automatically +performs the following actions: + +@itemize @bullet +@item The trap level is set. This provides access to a fresh set of +privileged trap-state registers used to save the current state, +in effect, pushing a frame on the trap stack. +TL <- TL + 1 +@item Existing state is preserved +@itemize @bullet + @item TSTATE[TL].CCR <- CCR + @item TSTATE[TL].ASI <- ASI + @item TSTATE[TL].PSTATE <- PSTATE + @item TSTATE[TL].CWP <- CWP + @item TPC[TL] <- PC + @item TNPC[TL] <- nPC +@end itemize +@item The trap type is preserved. TT[TL] <- the trap type +@item The PSTATE register is updated to a predefined state +@itemize @bullet + @item PSTATE.MM is unchanged + @item PSTATE.RED <- 0 + @item PSTATE.PEF <- 1 if FPU is present, 0 otherwise + @item PSTATE.AM <- 0 (address masking is turned off) + @item PSTATE.PRIV <- 1 (the processor enters privileged mode) + @item PSTATE.IE <- 0 (interrupts are disabled) + @item PSTATE.AG <- 1 (global regs are replaced with alternate globals) + @item PSTATE.CLE <- PSTATE.TLE (set endian mode for traps) +@end itemize +@item For a register-window trap only, CWP is set to point to the register +window that must be accessed by the trap-handler software, that is: +@itemize @bullet + @item If TT[TL] = 0x24 (a clean window trap), then CWP <- CWP + 1. + @item If (0x80 <= TT[TL] <= 0xBF) (window spill trap), then CWP <- CWP + +CANSAVE + 2. + @item If (0xC0 <= TT[TL] <= 0xFF) (window fill trap), then CWP <- CWP1. + @item For non-register-window traps, CWP is not changed. +@end itemize +@item Control is transferred into the trap table: +@itemize @bullet + @item PC <- TBA<63:15> (TL>0) TT[TL] 0 0000 + @item nPC <- TBA<63:15> (TL>0) TT[TL] 0 0100 + @item where (TL>0) is 0 if TL = 0, and 1 if TL > 0. +@end itemize + +@end itemize + +In order to safely invoke a subroutine during trap handling, traps must be +enabled to allow for the possibility of register window overflow and +underflow traps. + +If the interrupt handler was installed as an RTEMS +interrupt handler, then upon receipt of the interrupt, the +processor passes control to the RTEMS interrupt handler which +performs the following actions: + +@itemize @bullet +@item saves the state of the interrupted task on it's stack, + +@item switches the processor to trap level 0, + +@item if this is the outermost (i.e. non-nested) interrupt, +then the RTEMS interrupt handler switches from the current stack +to the interrupt stack, + +@item enables traps, + +@item invokes the vectors to a user interrupt service routine (ISR). +@end itemize + +Asynchronous interrupts are ignored while traps are +disabled. Synchronous traps which occur while traps are +disabled may result in the CPU being forced into an error mode. + +A nested interrupt is processed similarly with the +exception that the current stack need not be switched to the +interrupt stack. + +@subsection Traps and Register Windows + +XXX + +@subsection Interrupt Levels + +Sixteen levels (0-15) of interrupt priorities are +supported by the SPARC architecture with level fifteen (15) +being the highest priority. Level zero (0) indicates that +interrupts are fully enabled. Interrupt requests for interrupts +with priorities less than or equal to the current interrupt mask +level are ignored. + +Although RTEMS supports 256 interrupt levels, the +SPARC only supports sixteen. RTEMS interrupt levels 0 through +15 directly correspond to SPARC processor interrupt levels. All +other RTEMS interrupt levels are undefined and their behavior is +unpredictable. + +@subsection Disabling of Interrupts by RTEMS + +XXX + +@subsection Interrupt Stack + +The SPARC architecture does not provide for a +dedicated interrupt stack. Thus by default, trap handlers would +execute on the stack of the RTEMS task which they interrupted. +This artificially inflates the stack requirements for each task +since EVERY task stack would have to include enough space to +account for the worst case interrupt stack requirements in +addition to it's own worst case usage. RTEMS addresses this +problem on the SPARC by providing a dedicated interrupt stack +managed by software. + +During system initialization, RTEMS allocates the +interrupt stack from the Workspace Area. The amount of memory +allocated for the interrupt stack is determined by the +interrupt_stack_size field in the CPU Configuration Table. As +part of processing a non-nested interrupt, RTEMS will switch to +the interrupt stack before invoking the installed handler. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Default Fatal Error Processing + + +Upon detection of a fatal error by either the +application or RTEMS the fatal error manager is invoked. The +fatal error manager will invoke the user-supplied fatal error +handlers. If no user-supplied handlers are configured, the +RTEMS provided default fatal error handler is invoked. If the +user-supplied fatal error handlers return to the executive the +default fatal error handler is then invoked. This chapter +describes the precise operations of the default fatal error +handler. + +@subsection Default Fatal Error Handler Operations + +The default fatal error handler which is invoked by +the fatal_error_occurred directive when there is no user handler +configured or the user handler returns control to RTEMS. The +default fatal error handler disables processor interrupts to +level 15, places the error code in g1, and goes into an infinite +loop to simulate a halt processor instruction. + + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Board Support Packages + +An RTEMS Board Support Package (BSP) must be designed +to support a particular processor and target board combination. +This chapter presents a discussion of SPARC specific BSP issues. +For more information on developing a BSP, refer to the chapter +titled Board Support Packages in the RTEMS +Applications User's Guide. + +@subsection HelenOS and Open Firmware +The provided BSPs make use of some bootstrap and low-level hardware code +of the HelenOS operating system. These files can be found in the shared/helenos +directory of the sparc64 bsp directory. Consult the sources for more +detailed information. + +The shared BSP code also uses the Open Firmware interface to re-use firmware +code, primarily for console support and default trap handlers. + -- cgit v1.2.3