From 72a62ad88f82fe1ffee50024db4dd0f3fa5806f7 Mon Sep 17 00:00:00 2001 From: Chris Johns Date: Thu, 3 Nov 2016 16:58:08 +1100 Subject: Rename all manuals with an _ to have a -. It helps released naming of files. --- cpu_supplement/sparc.rst | 788 ----------------------------------------------- 1 file changed, 788 deletions(-) delete mode 100644 cpu_supplement/sparc.rst (limited to 'cpu_supplement/sparc.rst') diff --git a/cpu_supplement/sparc.rst b/cpu_supplement/sparc.rst deleted file mode 100644 index f993cd8..0000000 --- a/cpu_supplement/sparc.rst +++ /dev/null @@ -1,788 +0,0 @@ -.. comment SPDX-License-Identifier: CC-BY-SA-4.0 - -.. COMMENT: COPYRIGHT (c) 1988-2002. -.. COMMENT: On-Line Applications Research Corporation (OAR). -.. COMMENT: All rights reserved. - -SPARC Specific Information -########################## - -The Real Time Executive for Multiprocessor Systems (RTEMS) is designed to be -portable across multiple processor architectures. However, the nature of -real-time systems makes it essential that the application designer understand -certain processor dependent implementation details. These processor -dependencies include calling convention, board support package issues, -interrupt processing, exact RTEMS memory requirements, performance data, header -files, and the assembly language interface to the executive. - -This document discusses the SPARC architecture dependencies in this port of -RTEMS. This architectural port is for SPARC Version 7 and -8. Implementations for SPARC V9 are in the sparc64 target. - -It is highly recommended that the SPARC RTEMS application developer obtain and -become familiar with the documentation for the processor being used as well as -the specification for the revision of the SPARC architecture which corresponds -to that processor. - -**SPARC Architecture Documents** - -For information on the SPARC architecture, refer to the following documents -available from SPARC International, Inc. (http://www.sparc.com): - -- SPARC Standard Version 7. - -- SPARC Standard Version 8. - -**ERC32 Specific Information** - -The European Space Agency's ERC32 is a three chip computing core implementing a -SPARC V7 processor and associated support circuitry for embedded space -applications. The integer and floating-point units (90C601E & 90C602E) are -based on the Cypress 7C601 and 7C602, with additional error-detection and -recovery functions. The memory controller (MEC) implements system support -functions such as address decoding, memory interface, DMA interface, UARTs, -timers, interrupt control, write-protection, memory reconfiguration and -error-detection. The core is designed to work at 25MHz, but using space -qualified memories limits the system frequency to around 15 MHz, resulting in a -performance of 10 MIPS and 2 MFLOPS. - -Information on the ERC32 and a number of development support tools, such as the -SPARC Instruction Simulator (SIS), are freely available on the Internet. The -following documents and SIS are available via anonymous ftp or pointing your -web browser at ftp://ftp.estec.esa.nl/pub/ws/wsd/erc32. - -- ERC32 System Design Document - -- MEC Device Specification - -Additionally, the SPARC RISC User's Guide from Matra MHS documents the -functionality of the integer and floating point units including the instruction -set information. To obtain this document as well as ERC32 components and VHDL -models contact: - - Matra MHS SA - 3 Avenue du Centre, BP 309, - 78054 St-Quentin-en-Yvelines, - Cedex, France - VOICE: +31-1-30607087 - FAX: +31-1-30640693 - -Amar Guennon (amar.guennon@matramhs.fr) is familiar with the ERC32. - -CPU Model Dependent Features -============================ - -Microprocessors are generally classified into families with a variety of CPU -models or implementations within that family. Within a processor family, there -is a high level of binary compatibility. This family may be based on either an -architectural specification or on maintaining compatibility with a popular -processor. Recent microprocessor families such as the SPARC or PowerPC are -based on an architectural specification which is independent or any particular -CPU model or implementation. Older families such as the M68xxx and the iX86 -evolved as the manufacturer strived to produce higher performance processor -models which maintained binary compatibility with older models. - -RTEMS takes advantage of the similarity of the various models within a CPU -family. Although the models do vary in significant ways, the high level of -compatibility makes it possible to share the bulk of the CPU dependent -executive code across the entire family. - -CPU Model Feature Flags ------------------------ - -Each processor family supported by RTEMS has a list of features which vary -between CPU models within a family. For example, the most common model -dependent feature regardless of CPU family is the presence or absence of a -floating point unit or coprocessor. When defining the list of features present -on a particular CPU model, one simply notes that floating point hardware is or -is not present and defines a single constant appropriately. Conditional -compilation is utilized to include the appropriate source code for this CPU -model's feature set. It is important to note that this means that RTEMS is -thus compiled using the appropriate feature set and compilation flags optimal -for this CPU model used. The alternative would be to generate a binary which -would execute on all family members using only the features which were always -present. - -This section presents the set of features which vary across SPARC -implementations and are of importance to RTEMS. The set of CPU model feature -macros are defined in the file cpukit/score/cpu/sparc/sparc.h based upon the -particular CPU model defined on the compilation command line. - -CPU Model Name -~~~~~~~~~~~~~~ - -The macro CPU_MODEL_NAME is a string which designates the name of this CPU -model. For example, for the European Space Agency's ERC32 SPARC model, this -macro is set to the string "erc32". - -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. - -Bitscan Instruction -~~~~~~~~~~~~~~~~~~~ - -The macro SPARC_HAS_BITSCAN is set to 1 to indicate that this CPU model has the -bitscan instruction. For example, this instruction is supported by the Fujitsu -SPARClite family. - -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 a for a maximum of thirty-two register window sets although most -implementations only include eight. - -Low Power Mode -~~~~~~~~~~~~~~ - -The macro SPARC_HAS_LOW_POWER_MODE is set to one to indicate that this CPU -model has a low power mode. If low power is enabled, then there must be CPU -model specific implementation of the IDLE task in cpukit/score/cpu/sparc/cpu.c. -The low power mode IDLE task should be of the form: - -.. code-block:: c - - while ( TRUE ) { - enter low power mode - } - -The code required to enter low power mode is CPU model specific. - -CPU Model Implementation Notes ------------------------------- - -The ERC32 is a custom SPARC V7 implementation based on the Cypress 601/602 -chipset. This CPU has a number of on-board peripherals and was developed by -the European Space Agency to target space applications. RTEMS currently -provides support for the following peripherals: - -- UART Channels A and B - -- General Purpose Timer - -- Real Time Clock - -- Watchdog Timer (so it can be disabled) - -- Control Register (so powerdown mode can be enabled) - -- Memory Control Register - -- Interrupt Control - -The General Purpose Timer and Real Time Clock Timer provided with the ERC32 -share the Timer Control Register. Because the Timer Control Register is write -only, we must mirror it in software and insure that writes to one timer do not -alter the current settings and status of the other timer. Routines are -provided in erc32.h which promote the view that the two timers are completely -independent. By exclusively using these routines to access the Timer Control -Register, the application can view the system as having a General Purpose Timer -Control Register and a Real Time Clock Timer Control Register rather than the -single shared value. - -The RTEMS Idle thread take advantage of the low power mode provided by the -ERC32. Low power mode is entered during idle loops and is enabled at -initialization time. - -Calling Conventions -=================== - -Each high-level language compiler generates subroutine entry and exit code -based upon a set of rules known as the application binary interface (ABI) -calling convention. These rules address the following issues: - -- register preservation and usage - -- parameter passing - -- call and return mechanism - -An ABI calling convention is of importance when interfacing to subroutines -written in another language either assembly or high-level. It determines also -the set of registers to be saved or restored during a context switch and -interrupt processing. - -The ABI relevant for RTEMS on SPARC is defined by SYSTEM V APPLICATION BINARY -INTERFACE, SPARC Processor Supplement, Third Edition. - -Programming Model ------------------ - -This section discusses the programming model for the SPARC architecture. - -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: - -- input registers - -- local registers - -- output registers - -- global registers - -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: - -================ ================ =================== -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 -================ ================ =================== - -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: - -============== ================ ================================== -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 -============== ================ ================================== - -The registers g2 through g4 are reserved for applications. GCC uses them as -volatile registers by default. So they are treated like volatile registers in -RTEMS as well. - -The register g6 is reserved for the operating system and contains the address -of the per-CPU control block of the current processor. This register is -initialized during system start and then remains unchanged. It is not -saved/restored by the context switch or interrupt processing code. - -The register g7 is reserved for the operating system and contains the thread -pointer used for thread-local storage (TLS) as mandated by the SPARC ABI. - -Floating Point Registers -~~~~~~~~~~~~~~~~~~~~~~~~ - -The SPARC V7 architecture includes thirty-two, thirty-two bit registers. These -registers may be viewed as follows: - -- 32 single precision floating point or integer registers (f0, f1, ... f31) - -- 16 double precision floating point registers (f0, f2, f4, ... f30) - -- 8 extended precision floating point registers (f0, f4, f8, ... f28) - -The floating point status register (FSR) specifies the behavior of the floating -point unit for rounding, contains its condition codes, version specification, -and trap information. - -According to the ABI all floating point registers and the floating point status -register (FSR) are volatile. Thus the floating point context of a thread is -the empty set. The rounding direction is a system global state and must not be -modified by threads. - -A queue of the floating point instructions which have started execution but not -yet completed is maintained. This queue is needed to support the multiple -cycle nature of floating point operations and to aid floating point exception -trap handlers. Once a floating point exception has been encountered, the queue -is frozen until it is emptied by the trap handler. The floating point queue is -loaded by launching instructions. It is emptied normally when the floating -point completes all outstanding instructions and by floating point exception -handlers with the store double floating point queue (stdfq) instruction. - -Special Registers -~~~~~~~~~~~~~~~~~ - -The SPARC architecture includes two special registers which are critical to the -programming model: the Processor State Register (psr) and the Window Invalid -Mask (wim). The psr contains the condition codes, processor interrupt level, -trap enable bit, supervisor mode and previous supervisor mode bits, version -information, floating point unit and coprocessor enable bits, and the current -window pointer (cwp). The cwp field of the psr and wim register are used to -manage the register windows in the SPARC architecture. The register windows -are discussed in more detail below. - -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 -decrements 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 increments 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 Window Invalid Mask (wim) and the Current Window Pointer (cwp) field in the -psr are used in conjunction to manage the finite set of register windows and -detect the window overflow and underflow conditions. The cwp contains the -index of the register window currently in use. The save instruction decrements -the cwp modulo the number of register windows. Similarly, the restore -instruction increments the cwp modulo the number of register windows. Each bit -in the wim represents represents whether a register window contains valid -information. The value of 0 indicates the register window is valid and 1 -indicates it is invalid. When a save instruction causes the cwp to point to a -register window which is marked as invalid, a window overflow condition -results. Conversely, the restore instruction may result in a window underflow -condition. - -Other than the assumption that a register window is always available for trap -(i.e. interrupt) handlers, the SPARC architecture places no limits on the -number of register windows simultaneously marked as invalid (i.e. number of -bits set in the wim). However, RTEMS assumes that only one register window is -marked invalid at a time (i.e. only one bit set in the wim). This makes the -maximum possible number of register windows available to the user while still -meeting the requirement that window overflow and underflow conditions can be -detected. - -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. - -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. - -In case a floating-point unit is supported, then floating-point return values -appear in the floating-point registers. Single-precision values occupy %f0; -double-precision values occupy %f0 and %f1. Otherwise, these are scratch -registers. Due to this the hardware and software floating-point ABIs are -incompatible. - -Calling Mechanism ------------------ - -All RTEMS directives are invoked using the regular SPARC calling convention via -the call instruction. - -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. - -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: - -.. code-block:: c - - load third argument into o2 - load second argument into o1 - load first argument into o0 - invoke directive - -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. - -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. - -Flat Memory Model ------------------ - -The SPARC architecture supports a flat 32-bit address space with addresses -ranging from 0x00000000 to 0xFFFFFFFF (4 gigabytes). Each address is -represented by a 32-bit value and is byte addressable. The address may be used -to reference a single byte, half-word (2-bytes), word (4 bytes), or doubleword -(8 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 7). The following -table lists the alignment requirements for a variety of data accesses: - -============== ====================== -Data Type Alignment Requirement -============== ====================== -byte 1 -half-word 2 -word 4 -doubleword 8 -============== ====================== - -Doubleword load and store operations must use a pair of registers as their -source or destination. This pair of registers must be an adjacent pair of -registers with the first of the pair being even numbered. For example, a valid -destination for a doubleword load might be input registers 0 and 1 (i0 and i1). -The pair i1 and i2 would be invalid. \[NOTE: Some assemblers for the SPARC do -not generate an error if an odd numbered register is specified as the beginning -register of the pair. In this case, the assembler assumes that what the -programmer meant was to use the even-odd pair which ends at the specified -register. This may or may not have been a correct assumption.] - -RTEMS does not support any SPARC Memory Management Units, therefore, virtual -memory or segmentation systems involving the SPARC are not supported. - -Interrupt Processing -==================== - -Different types of processors respond to the occurrence of an interrupt in its -own unique fashion. In addition, each processor type provides a control -mechanism to allow for the proper handling of an interrupt. The processor -dependent response to the interrupt modifies the current execution state and -results in a change in the execution stream. Most processors require that an -interrupt handler utilize some special control mechanisms to return to the -normal processing stream. Although RTEMS hides many of the processor dependent -details of interrupt processing, it is important to understand how the RTEMS -interrupt manager is mapped onto the processor's unique architecture. Discussed -in this chapter are the SPARC's interrupt response and control mechanisms as -they pertain to RTEMS. - -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. - -Synchronous Versus Asynchronous Traps -------------------------------------- - -The SPARC architecture includes two classes of traps: synchronous and -asynchronous. 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. - -Vectoring of Interrupt Handler ------------------------------- - -Upon receipt of an interrupt the SPARC automatically performs the following -actions: - -- disables traps (sets the ET bit of the psr to 0), - -- the S bit of the psr is copied into the Previous Supervisor Mode (PS) bit of - the psr, - -- the cwp is decremented by one (modulo the number of register windows) to - activate a trap window, - -- the PC and nPC are loaded into local register 1 and 2 (l0 and l1), - -- the trap type (tt) field of the Trap Base Register (TBR) is set to the - appropriate value, and - -- if the trap is not a reset, then the PC is written with the contents of the - TBR and the nPC is written with TBR + 4. If the trap is a reset, then the PC - is set to zero and the nPC is set to 4. - -Trap processing on the SPARC has two features which are noticeably different -than interrupt processing on other architectures. First, the value of psr -register in effect immediately before the trap occurred is not explicitly -saved. Instead only reversible alterations are made to it. Second, the -Processor Interrupt Level (pil) is not set to correspond to that of the -interrupt being processed. When a trap occurs, ALL subsequent traps are -disabled. 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: - -- saves the state of the interrupted task on it's stack, - -- insures that a register window is available for subsequent traps, - -- if this is the outermost (i.e. non-nested) interrupt, then the RTEMS - interrupt handler switches from the current stack to the interrupt stack, - -- enables traps, - -- invokes the vectors to a user interrupt service routine (ISR). - -Asynchronous interrupts are ignored while traps are disabled. Synchronous -traps which occur while traps are disabled 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. - -Traps and Register Windows --------------------------- - -One of the register windows must be reserved at all times for trap processing. -This is critical to the proper operation of the trap mechanism in the SPARC -architecture. It is the responsibility of the trap handler to insure that -there is a register window available for a subsequent trap before re-enabling -traps. It is likely that any high level language routines invoked by the trap -handler (such as a user-provided RTEMS interrupt handler) will allocate a new -register window. The save operation could result in a window overflow trap. -This trap cannot be correctly processed unless (1) traps are enabled and (2) a -register window is reserved for traps. Thus, the RTEMS interrupt handler -insures that a register window is available for subsequent traps before -enabling traps and invoking the user's interrupt handler. - -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. Level fifteen (15) is a non-maskable interrupt (NMI), which -makes it unsuitable for standard usage since it can affect the real-time -behaviour by interrupting critical sections and spinlocks. Disabling traps -stops also the NMI interrupt from happening. It can however be used for -power-down or other critical events. - -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. - -Many LEON SPARC v7/v8 systems features an extended interrupt controller which -adds an extra step of interrupt decoding to allow handling of interrupt -16-31. When such an extended interrupt is generated the CPU traps into a -specific interrupt trap level 1-14 and software reads out from the interrupt -controller which extended interrupt source actually caused the interrupt. - -Disabling of Interrupts by RTEMS --------------------------------- - -During the execution of directive calls, critical sections of code may be -executed. When these sections are encountered, RTEMS disables interrupts to -level fifteen (15) before the execution of the section and restores them to the -previous level upon completion of the section. RTEMS has been optimized to -ensure that interrupts are disabled for less than RTEMS_MAXIMUM_DISABLE_PERIOD -microseconds on a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz ERC32 with zero wait -states. These numbers will vary based the number of wait states and processor -speed present on the target board. [NOTE: The maximum period with interrupts -disabled is hand calculated. This calculation was last performed for Release -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] - -[NOTE: It is thought that the length of time at which the processor interrupt -level is elevated to fifteen by RTEMS is not anywhere near as long as the -length of time ALL traps are disabled as part of the "flush all register -windows" operation.] - -Non-maskable interrupts (NMI) cannot be disabled, and ISRs which execute at -this level MUST NEVER issue RTEMS system calls. If a directive is invoked, -unpredictable results may occur due to the inability of RTEMS to protect its -critical sections. However, ISRs that make no system calls may safely execute -as non-maskable interrupts. - -Interrupts are disabled or enabled by performing a system call to the Operating -System reserved software traps 9 (SPARC_SWTRAP_IRQDIS) or 10 -(SPARC_SWTRAP_IRQDIS). The trap is generated by the software trap (Ticc) -instruction or indirectly by calling sparc_disable_interrupts() or -sparc_enable_interrupts() functions. Disabling interrupts return the previous -interrupt level (on trap entry) in register G1 and sets PSR.PIL to 15 to -disable all maskable interrupts. The interrupt level can be restored by -trapping into the enable interrupt handler with G1 containing the new interrupt -level. - -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. - -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. - -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. - -If the BSP has been configured with ``BSP_POWER_DOWN_AT_FATAL_HALT`` set to -true, the default handler will disable interrupts and enter power down mode. If -power down mode is not available, it goes into an infinite loop to simulate a -halt processor instruction. - -If ``BSP_POWER_DOWN_AT_FATAL_HALT`` is set to false, the default handler will -place the value ``1`` in register ``g1``, the error source in register ``g2``, -and the error code in register``g3``. It will then generate a system error -which will hand over control to the debugger, simulator, etc. - -Symmetric Multiprocessing -========================= - -SMP is supported. Available platforms are the Cobham Gaisler GR712RC and -GR740. - -Thread-Local Storage -==================== - -Thread-local storage is supported. - -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. - -System Reset ------------- - -An RTEMS based application is initiated or re-initiated when the SPARC -processor is reset. When the SPARC is reset, the processor performs the -following actions: - -- the enable trap (ET) of the psr is set to 0 to disable traps, - -- the supervisor bit (S) of the psr is set to 1 to enter supervisor mode, and - -- the PC is set 0 and the nPC is set to 4. - -The processor then begins to execute the code at location 0. It is important -to note that all fields in the psr are not explicitly set by the above steps -and all other registers retain their value from the previous execution mode. -This is true even of the Trap Base Register (TBR) whose contents reflect the -last trap which occurred before the reset. - -Processor Initialization ------------------------- - -It is the responsibility of the application's initialization code to initialize -the TBR and install trap handlers for at least the register window overflow and -register window underflow conditions. Traps should be enabled before invoking -any subroutines to allow for register window management. However, interrupts -should be disabled by setting the Processor Interrupt Level (pil) field of the -psr to 15. RTEMS installs it's own Trap Table as part of initialization which -is initialized with the contents of the Trap Table in place when the -``rtems_initialize_executive`` directive was invoked. Upon completion of -executive initialization, interrupts are enabled. - -If this SPARC implementation supports on-chip caching and this is to be -utilized, then it should be enabled during the reset application initialization -code. - -In addition to the requirements described in the Board Support Packages chapter -of the C Applications Users Manual for the reset code which is executed before -the call to``rtems_initialize_executive``, the SPARC version has the following -specific requirements: - -- Must leave the S bit of the status register set so that the SPARC remains in - the supervisor state. - -- Must set stack pointer (sp) such that a minimum stack size of - MINIMUM_STACK_SIZE bytes is provided for the``rtems_initialize_executive`` - directive. - -- Must disable all external interrupts (i.e. set the pil to 15). - -- Must enable traps so window overflow and underflow conditions can be properly - handled. - -- Must initialize the SPARC's initial trap table with at least trap handlers - for register window overflow and register window underflow. -- cgit v1.2.3