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 | |
---|