[563f7e0] | 1 | @c |
---|
| 2 | @c COPYRIGHT (c) 1988-1997. |
---|
| 3 | @c On-Line Applications Research Corporation (OAR). |
---|
| 4 | @c All rights reserved. |
---|
| 5 | @c |
---|
| 6 | @c $Id$ |
---|
| 7 | @c |
---|
| 8 | |
---|
| 9 | @ifinfo |
---|
| 10 | @node Interrupt Processing, Interrupt Processing Introduction, Memory Model Flat Memory Model, Top |
---|
| 11 | @end ifinfo |
---|
| 12 | @chapter Interrupt Processing |
---|
| 13 | @ifinfo |
---|
| 14 | @menu |
---|
| 15 | * Interrupt Processing Introduction:: |
---|
| 16 | * Interrupt Processing Synchronous Versus Asynchronous Traps:: |
---|
| 17 | * Interrupt Processing Vectoring of Interrupt Handler:: |
---|
| 18 | * Interrupt Processing Traps and Register Windows:: |
---|
| 19 | * Interrupt Processing Interrupt Levels:: |
---|
| 20 | * Interrupt Processing Disabling of Interrupts by RTEMS:: |
---|
| 21 | * Interrupt Processing Interrupt Stack:: |
---|
| 22 | @end menu |
---|
| 23 | @end ifinfo |
---|
| 24 | |
---|
| 25 | @ifinfo |
---|
| 26 | @node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing, Interrupt Processing |
---|
| 27 | @end ifinfo |
---|
| 28 | @section Introduction |
---|
| 29 | |
---|
| 30 | Different types of processors respond to the |
---|
| 31 | occurrence of an interrupt in its own unique fashion. In |
---|
| 32 | addition, each processor type provides a control mechanism to |
---|
| 33 | allow for the proper handling of an interrupt. The processor |
---|
| 34 | dependent response to the interrupt modifies the current |
---|
| 35 | execution state and results in a change in the execution stream. |
---|
| 36 | Most processors require that an interrupt handler utilize some |
---|
| 37 | special control mechanisms to return to the normal processing |
---|
| 38 | stream. Although RTEMS hides many of the processor dependent |
---|
| 39 | details of interrupt processing, it is important to understand |
---|
| 40 | how the RTEMS interrupt manager is mapped onto the processor's |
---|
| 41 | unique architecture. Discussed in this chapter are the SPARC's |
---|
| 42 | interrupt response and control mechanisms as they pertain to |
---|
| 43 | RTEMS. |
---|
| 44 | |
---|
| 45 | RTEMS and associated documentation uses the terms |
---|
| 46 | interrupt and vector. In the SPARC architecture, these terms |
---|
| 47 | correspond to traps and trap type, respectively. The terms will |
---|
| 48 | be used interchangeably in this manual. |
---|
| 49 | |
---|
| 50 | @ifinfo |
---|
| 51 | @node Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Introduction, Interrupt Processing |
---|
| 52 | @end ifinfo |
---|
| 53 | @section Synchronous Versus Asynchronous Traps |
---|
| 54 | |
---|
| 55 | The SPARC architecture includes two classes of traps: |
---|
| 56 | synchronous and asynchronous. Asynchronous traps occur when an |
---|
| 57 | external event interrupts the processor. These traps are not |
---|
| 58 | associated with any instruction executed by the processor and |
---|
| 59 | logically occur between instructions. The instruction currently |
---|
| 60 | in the execute stage of the processor is allowed to complete |
---|
| 61 | although subsequent instructions are annulled. The return |
---|
| 62 | address reported by the processor for asynchronous traps is the |
---|
| 63 | pair of instructions following the current instruction. |
---|
| 64 | |
---|
| 65 | Synchronous traps are caused by the actions of an |
---|
| 66 | instruction. The trap stimulus in this case either occurs |
---|
| 67 | internally to the processor or is from an external signal that |
---|
| 68 | was provoked by the instruction. These traps are taken |
---|
| 69 | immediately and the instruction that caused the trap is aborted |
---|
| 70 | before any state changes occur in the processor itself. The |
---|
| 71 | return address reported by the processor for synchronous traps |
---|
| 72 | is the instruction which caused the trap and the following |
---|
| 73 | instruction. |
---|
| 74 | |
---|
| 75 | @ifinfo |
---|
| 76 | @node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Traps and Register Windows, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing |
---|
| 77 | @end ifinfo |
---|
| 78 | @section Vectoring of Interrupt Handler |
---|
| 79 | |
---|
| 80 | Upon receipt of an interrupt the SPARC automatically |
---|
| 81 | performs the following actions: |
---|
| 82 | |
---|
| 83 | @itemize @bullet |
---|
| 84 | @item disables traps (sets the ET bit of the psr to 0), |
---|
| 85 | |
---|
| 86 | @item the S bit of the psr is copied into the Previous |
---|
| 87 | Supervisor Mode (PS) bit of the psr, |
---|
| 88 | |
---|
| 89 | @item the cwp is decremented by one (modulo the number of |
---|
| 90 | register windows) to activate a trap window, |
---|
| 91 | |
---|
| 92 | @item the PC and nPC are loaded into local register 1 and 2 |
---|
| 93 | (l0 and l1), |
---|
| 94 | |
---|
| 95 | @item the trap type (tt) field of the Trap Base Register (TBR) |
---|
| 96 | is set to the appropriate value, and |
---|
| 97 | |
---|
| 98 | @item if the trap is not a reset, then the PC is written with |
---|
| 99 | the contents of the TBR and the nPC is written with TBR + 4. If |
---|
| 100 | the trap is a reset, then the PC is set to zero and the nPC is |
---|
| 101 | set to 4. |
---|
| 102 | @end itemize |
---|
| 103 | |
---|
| 104 | Trap processing on the SPARC has two features which |
---|
| 105 | are noticeably different than interrupt processing on other |
---|
| 106 | architectures. First, the value of psr register in effect |
---|
| 107 | immediately before the trap occurred is not explicitly saved. |
---|
| 108 | Instead only reversible alterations are made to it. Second, the |
---|
| 109 | Processor Interrupt Level (pil) is not set to correspond to that |
---|
| 110 | of the interrupt being processed. When a trap occurs, ALL |
---|
| 111 | subsequent traps are disabled. In order to safely invoke a |
---|
| 112 | subroutine during trap handling, traps must be enabled to allow |
---|
| 113 | for the possibility of register window overflow and underflow |
---|
| 114 | traps. |
---|
| 115 | |
---|
| 116 | If the interrupt handler was installed as an RTEMS |
---|
| 117 | interrupt handler, then upon receipt of the interrupt, the |
---|
| 118 | processor passes control to the RTEMS interrupt handler which |
---|
| 119 | performs the following actions: |
---|
| 120 | |
---|
| 121 | @itemize @bullet |
---|
| 122 | @item saves the state of the interrupted task on it's stack, |
---|
| 123 | |
---|
| 124 | @item insures that a register window is available for |
---|
| 125 | subsequent traps, |
---|
| 126 | |
---|
| 127 | @item if this is the outermost (i.e. non-nested) interrupt, |
---|
| 128 | then the RTEMS interrupt handler switches from the current stack |
---|
| 129 | to the interrupt stack, |
---|
| 130 | |
---|
| 131 | @item enables traps, |
---|
| 132 | |
---|
| 133 | @item invokes the vectors to a user interrupt service routine (ISR). |
---|
| 134 | @end itemize |
---|
| 135 | |
---|
| 136 | Asynchronous interrupts are ignored while traps are |
---|
| 137 | disabled. Synchronous traps which occur while traps are |
---|
| 138 | disabled result in the CPU being forced into an error mode. |
---|
| 139 | |
---|
| 140 | A nested interrupt is processed similarly with the |
---|
| 141 | exception that the current stack need not be switched to the |
---|
| 142 | interrupt stack. |
---|
| 143 | |
---|
| 144 | @ifinfo |
---|
| 145 | @node Interrupt Processing Traps and Register Windows, Interrupt Processing Interrupt Levels, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing |
---|
| 146 | @end ifinfo |
---|
| 147 | @section Traps and Register Windows |
---|
| 148 | |
---|
| 149 | One of the register windows must be reserved at all |
---|
| 150 | times for trap processing. This is critical to the proper |
---|
| 151 | operation of the trap mechanism in the SPARC architecture. It |
---|
| 152 | is the responsibility of the trap handler to insure that there |
---|
| 153 | is a register window available for a subsequent trap before |
---|
| 154 | re-enabling traps. It is likely that any high level language |
---|
| 155 | routines invoked by the trap handler (such as a user-provided |
---|
| 156 | RTEMS interrupt handler) will allocate a new register window. |
---|
| 157 | The save operation could result in a window overflow trap. This |
---|
| 158 | trap cannot be correctly processed unless (1) traps are enabled |
---|
| 159 | and (2) a register window is reserved for traps. Thus, the |
---|
| 160 | RTEMS interrupt handler insures that a register window is |
---|
| 161 | available for subsequent traps before enabling traps and |
---|
| 162 | invoking the user's interrupt handler. |
---|
| 163 | |
---|
| 164 | @ifinfo |
---|
| 165 | @node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Traps and Register Windows, Interrupt Processing |
---|
| 166 | @end ifinfo |
---|
| 167 | @section Interrupt Levels |
---|
| 168 | |
---|
| 169 | Sixteen levels (0-15) of interrupt priorities are |
---|
| 170 | supported by the SPARC architecture with level fifteen (15) |
---|
| 171 | being the highest priority. Level zero (0) indicates that |
---|
| 172 | interrupts are fully enabled. Interrupt requests for interrupts |
---|
| 173 | with priorities less than or equal to the current interrupt mask |
---|
| 174 | level are ignored. |
---|
| 175 | |
---|
| 176 | Although RTEMS supports 256 interrupt levels, the |
---|
| 177 | SPARC only supports sixteen. RTEMS interrupt levels 0 through |
---|
| 178 | 15 directly correspond to SPARC processor interrupt levels. All |
---|
| 179 | other RTEMS interrupt levels are undefined and their behavior is |
---|
| 180 | unpredictable. |
---|
| 181 | |
---|
| 182 | @ifinfo |
---|
| 183 | @node Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack, Interrupt Processing Interrupt Levels, Interrupt Processing |
---|
| 184 | @end ifinfo |
---|
| 185 | @section Disabling of Interrupts by RTEMS |
---|
| 186 | |
---|
| 187 | During the execution of directive calls, critical |
---|
| 188 | sections of code may be executed. When these sections are |
---|
| 189 | encountered, RTEMS disables interrupts to level seven (15) |
---|
| 190 | before the execution of this section and restores them to the |
---|
| 191 | previous level upon completion of the section. RTEMS has been |
---|
| 192 | optimized to insure that interrupts are disabled for less than |
---|
| 193 | RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ |
---|
| 194 | Mhz PowerPC 603e with zero wait states. |
---|
| 195 | These numbers will vary based the number of wait states and |
---|
| 196 | processor speed present on the target board. |
---|
| 197 | [NOTE: The maximum period with interrupts disabled is hand calculated. This |
---|
| 198 | calculation was last performed for Release |
---|
| 199 | RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] |
---|
| 200 | |
---|
| 201 | [NOTE: It is thought that the length of time at which |
---|
| 202 | the processor interrupt level is elevated to fifteen by RTEMS is |
---|
| 203 | not anywhere near as long as the length of time ALL traps are |
---|
| 204 | disabled as part of the "flush all register windows" operation.] |
---|
| 205 | |
---|
| 206 | Non-maskable interrupts (NMI) cannot be disabled, and |
---|
| 207 | ISRs which execute at this level MUST NEVER issue RTEMS system |
---|
| 208 | calls. If a directive is invoked, unpredictable results may |
---|
| 209 | occur due to the inability of RTEMS to protect its critical |
---|
| 210 | sections. However, ISRs that make no system calls may safely |
---|
| 211 | execute as non-maskable interrupts. |
---|
| 212 | |
---|
| 213 | @ifinfo |
---|
| 214 | @node Interrupt Processing Interrupt Stack, Default Fatal Error Processing, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing |
---|
| 215 | @end ifinfo |
---|
| 216 | @section Interrupt Stack |
---|
| 217 | |
---|
| 218 | The SPARC architecture does not provide for a |
---|
| 219 | dedicated interrupt stack. Thus by default, trap handlers would |
---|
| 220 | execute on the stack of the RTEMS task which they interrupted. |
---|
| 221 | This artificially inflates the stack requirements for each task |
---|
| 222 | since EVERY task stack would have to include enough space to |
---|
| 223 | account for the worst case interrupt stack requirements in |
---|
| 224 | addition to it's own worst case usage. RTEMS addresses this |
---|
| 225 | problem on the SPARC by providing a dedicated interrupt stack |
---|
| 226 | managed by software. |
---|
| 227 | |
---|
| 228 | During system initialization, RTEMS allocates the |
---|
| 229 | interrupt stack from the Workspace Area. The amount of memory |
---|
| 230 | allocated for the interrupt stack is determined by the |
---|
| 231 | interrupt_stack_size field in the CPU Configuration Table. As |
---|
| 232 | part of processing a non-nested interrupt, RTEMS will switch to |
---|
| 233 | the interrupt stack before invoking the installed handler. |
---|
| 234 | |
---|