forked from Imagelibrary/rtems
198 lines
8.0 KiB
Perl
198 lines
8.0 KiB
Perl
@c
|
|
@c COPYRIGHT (c) 1988-1997.
|
|
@c On-Line Applications Research Corporation (OAR).
|
|
@c All rights reserved.
|
|
@c
|
|
@c $Id$
|
|
@c
|
|
|
|
@ifinfo
|
|
@node Interrupt Processing, Interrupt Processing Introduction, Memory Model Flat Memory Model, Top
|
|
@end ifinfo
|
|
@chapter Interrupt Processing
|
|
@ifinfo
|
|
@menu
|
|
* Interrupt Processing Introduction::
|
|
* Interrupt Processing Synchronous Versus Asynchronous Exceptions::
|
|
* Interrupt Processing Vectoring of Interrupt Handler::
|
|
* Interrupt Processing Interrupt Levels::
|
|
* Interrupt Processing Disabling of Interrupts by RTEMS::
|
|
* Interrupt Processing Interrupt Stack::
|
|
@end menu
|
|
@end ifinfo
|
|
|
|
@ifinfo
|
|
@node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing, Interrupt Processing
|
|
@end ifinfo
|
|
@section Introduction
|
|
|
|
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 PPC's
|
|
interrupt response and control mechanisms as they pertain to
|
|
RTEMS.
|
|
|
|
RTEMS and associated documentation uses the terms
|
|
interrupt and vector. In the PPC architecture, these terms
|
|
correspond to exception and exception handler, respectively. The terms will
|
|
be used interchangeably in this manual.
|
|
|
|
@ifinfo
|
|
@node Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Introduction, Interrupt Processing
|
|
@end ifinfo
|
|
@section Synchronous Versus Asynchronous Exceptions
|
|
|
|
In the PPC architecture exceptions can be either precise or
|
|
imprecise and either synchronous or asynchronous. Asynchronous
|
|
exceptions occur when an external event interrupts the processor.
|
|
Synchronous exceptions are caused by the actions of an
|
|
instruction. During an exception SRR0 is used to calculate where
|
|
instruction processing should resume. All instructions prior to
|
|
the resume instruction will have completed execution. SRR1 is used to
|
|
store the machine status.
|
|
|
|
There are two asynchronous nonmaskable, highest-priority exceptions
|
|
system reset and machine check. There are two asynchrononous maskable
|
|
low-priority exceptions external interrupt and decrementer. Nonmaskable
|
|
execptions are never delayed, therefore if two nonmaskable, asynchronous
|
|
exceptions occur in immediate succession, the state information saved by
|
|
the first exception may be overwritten when the subsequent exception occurs.
|
|
|
|
The PowerPC arcitecure defines one imprecise exception, the imprecise
|
|
floating point enabled exception. All other synchronous exceptions are
|
|
precise. The synchronization occuring during asynchronous precise
|
|
exceptions conforms to the requirements for context synchronization.
|
|
|
|
@ifinfo
|
|
@node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Interrupt Levels, Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing
|
|
@end ifinfo
|
|
@section Vectoring of Interrupt Handler
|
|
|
|
Upon determining that an exception can be taken the PPC automatically
|
|
performs the following actions:
|
|
|
|
@itemize @bullet
|
|
@item an instruction address is loaded into SRR0
|
|
|
|
@item bits 33-36 and 42-47 of SRR1 are loaded with information
|
|
specific to the exception.
|
|
|
|
@item bits 0-32, 37-41, and 48-63 of SRR1 are loaded with corresponding
|
|
bits from the MSR.
|
|
|
|
@item the MSR is set based upon the exception type.
|
|
|
|
@item instruction fetch and execution resumes, using the new MSR value, at a location specific to the execption type.
|
|
|
|
@end itemize
|
|
|
|
|
|
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 insures that a register window is available for
|
|
subsequent exceptions,
|
|
|
|
@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 exceptions,
|
|
|
|
@item invokes the vectors to a user interrupt service routine (ISR).
|
|
@end itemize
|
|
|
|
Asynchronous interrupts are ignored while exceptions are
|
|
disabled. Synchronous interrupts which occur while 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.
|
|
|
|
@ifinfo
|
|
@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing
|
|
@end ifinfo
|
|
@section Interrupt Levels
|
|
|
|
TBD levels (0-TBD) of interrupt priorities are
|
|
supported by the PowerPC architecture with level TBD (TBD)
|
|
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.
|
|
|
|
TBD
|
|
All other RTEMS interrupt levels are undefined and their behavior is
|
|
unpredictable.
|
|
|
|
@ifinfo
|
|
@node Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack, Interrupt Processing Interrupt Levels, Interrupt Processing
|
|
@end ifinfo
|
|
@section 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 TBD (TBD)
|
|
before the execution of this section and restores them to the
|
|
previous level upon completion of the section. RTEMS has been
|
|
optimized to insure that interrupts are disabled for less than
|
|
RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a
|
|
RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz PowerPC 603e 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 exceptions 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.
|
|
|
|
@ifinfo
|
|
@node Interrupt Processing Interrupt Stack, Default Fatal Error Processing, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing
|
|
@end ifinfo
|
|
@section Interrupt Stack
|
|
|
|
The PowerPC architecture does not provide for a
|
|
dedicated interrupt stack. Thus by default, exception 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 PowerPC 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.
|
|
|
|
|
|
|