source: rtems/doc/supplements/powerpc/intr.t @ 03c8223

4.104.114.84.95
Last change on this file since 03c8223 was 03c8223, checked in by Joel Sherrill <joel.sherrill@…>, on Jul 31, 1997 at 6:45:32 PM

Added more info.

  • Property mode set to 100644
File size: 8.0 KB
Line 
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 Exceptions::
17* Interrupt Processing Vectoring of Interrupt Handler::
18* Interrupt Processing Interrupt Levels::
19* Interrupt Processing Disabling of Interrupts by RTEMS::
20* Interrupt Processing Interrupt Stack::
21@end menu
22@end ifinfo
23
24@ifinfo
25@node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing, Interrupt Processing
26@end ifinfo
27@section Introduction
28
29Different types of processors respond to the
30occurrence of an interrupt in its own unique fashion. In
31addition, each processor type provides a control mechanism to
32allow for the proper handling of an interrupt.  The processor
33dependent response to the interrupt modifies the current
34execution state and results in a change in the execution stream.
35Most processors require that an interrupt handler utilize some
36special control mechanisms to return to the normal processing
37stream.  Although RTEMS hides many of the processor dependent
38details of interrupt processing, it is important to understand
39how the RTEMS interrupt manager is mapped onto the processor's
40unique architecture. Discussed in this chapter are the PPC's
41interrupt response and control mechanisms as they pertain to
42RTEMS.
43
44RTEMS and associated documentation uses the terms
45interrupt and vector.  In the PPC architecture, these terms
46correspond to exception and exception handler, respectively.  The terms will
47be used interchangeably in this manual.
48
49@ifinfo
50@node Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Introduction, Interrupt Processing
51@end ifinfo
52@section Synchronous Versus Asynchronous Exceptions
53
54In the PPC architecture exceptions can be either precise or
55imprecise and either synchronous or asynchronous.  Asynchronous
56exceptions occur when an external event interrupts the processor.
57Synchronous exceptions are caused by the actions of an
58instruction. During an exception SRR0 is used to calculate where
59instruction processing should resume.  All instructions prior to
60the resume instruction will have completed execution.  SRR1 is used to
61store the machine status.
62
63There are two asynchronous nonmaskable, highest-priority exceptions
64system reset and machine check.  There are two asynchrononous maskable
65low-priority exceptions external interrupt and decrementer.  Nonmaskable
66execptions are never delayed, therefore if two nonmaskable, asynchronous
67exceptions occur in immediate succession, the state information saved by
68the first exception may be overwritten when the subsequent exception occurs.
69
70The PowerPC arcitecure defines one imprecise exception, the imprecise
71floating point enabled exception.  All other synchronous exceptions are
72precise.  The synchronization occuring during asynchronous precise
73exceptions conforms to the requirements for context synchronization.
74
75@ifinfo
76@node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Interrupt Levels, Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing
77@end ifinfo
78@section Vectoring of Interrupt Handler
79
80Upon determining that an exception can be taken the PPC  automatically
81performs the following actions:
82
83@itemize @bullet
84@item an instruction address is loaded into SRR0
85
86@item bits 33-36 and 42-47 of SRR1 are loaded with information
87specific to the exception.
88
89@item bits 0-32, 37-41, and 48-63 of SRR1 are loaded with corresponding
90bits from the MSR.
91
92@item the MSR is set based upon the exception type.
93
94@item instruction fetch and execution resumes, using the new MSR value, at a location specific to the execption type.
95
96@end itemize
97
98
99If the interrupt handler was installed as an RTEMS
100interrupt handler, then upon receipt of the interrupt, the
101processor passes control to the RTEMS interrupt handler which
102performs the following actions:
103
104@itemize @bullet
105@item saves the state of the interrupted task on it's stack,
106
107@item insures that a register window is available for
108subsequent exceptions,
109
110@item if this is the outermost (i.e. non-nested) interrupt,
111then the RTEMS interrupt handler switches from the current stack
112to the interrupt stack,
113
114@item enables exceptions,
115
116@item invokes the vectors to a user interrupt service routine (ISR).
117@end itemize
118
119Asynchronous interrupts are ignored while exceptions are
120disabled.  Synchronous interrupts which occur while  are
121disabled result in the CPU being forced into an error mode.
122
123A nested interrupt is processed similarly with the
124exception that the current stack need not be switched to the
125interrupt stack.
126
127@ifinfo
128@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing
129@end ifinfo
130@section Interrupt Levels
131
132TBD levels (0-TBD) of interrupt priorities are
133supported by the PowerPC architecture with level TBD (TBD)
134being the highest priority.  Level zero (0) indicates that
135interrupts are fully enabled.  Interrupt requests for interrupts
136with priorities less than or equal to the current interrupt mask
137level are ignored.
138
139TBD
140All other RTEMS interrupt levels are undefined and their behavior is
141unpredictable.
142
143@ifinfo
144@node Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack, Interrupt Processing Interrupt Levels, Interrupt Processing
145@end ifinfo
146@section Disabling of Interrupts by RTEMS
147
148During the execution of directive calls, critical
149sections of code may be executed.  When these sections are
150encountered, RTEMS disables interrupts to level TBD (TBD)
151before the execution of this section and restores them to the
152previous level upon completion of the section.  RTEMS has been
153optimized to insure that interrupts are disabled for less than
154RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a
155RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz PowerPC 603e with zero
156wait states.  These numbers will vary based the number of wait
157states and processor speed present on the target board.
158[NOTE:  The maximum period with interrupts disabled is hand calculated.  This
159calculation was last performed for Release
160RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
161
162[NOTE: It is thought that the length of time at which
163the processor interrupt level is elevated to fifteen by RTEMS is
164not anywhere near as long as the length of time ALL exceptions are
165disabled as part of the "flush all register windows" operation.]
166
167Non-maskable interrupts (NMI) cannot be disabled, and
168ISRs which execute at this level MUST NEVER issue RTEMS system
169calls.  If a directive is invoked, unpredictable results may
170occur due to the inability of RTEMS to protect its critical
171sections.  However, ISRs that make no system calls may safely
172execute as non-maskable interrupts.
173
174@ifinfo
175@node Interrupt Processing Interrupt Stack, Default Fatal Error Processing, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing
176@end ifinfo
177@section Interrupt Stack
178
179The PowerPC architecture does not provide for a
180dedicated interrupt stack.  Thus by default, exception handlers would
181execute on the stack of the RTEMS task which they interrupted.
182This artificially inflates the stack requirements for each task
183since EVERY task stack would have to include enough space to
184account for the worst case interrupt stack requirements in
185addition to it's own worst case usage.  RTEMS addresses this
186problem on the PowerPC by providing a dedicated interrupt stack
187managed by software.
188
189During system initialization, RTEMS allocates the
190interrupt stack from the Workspace Area.  The amount of memory
191allocated for the interrupt stack is determined by the
192interrupt_stack_size field in the CPU Configuration Table.  As
193part of processing a non-nested interrupt, RTEMS will switch to
194the interrupt stack before invoking the installed handler.
195
196
197
Note: See TracBrowser for help on using the repository browser.