Imagelibrary/rtems
1
0
Fork 1
mirror of https://gitlab.rtems.org/rtems/rtos/rtems.git synced 2025-12-05 15:15:44 +00:00
Code Issues Packages Projects Releases Wiki Activity

Added more info.

Browse Source
This commit is contained in:
Joel Sherrill
1997-07-31 18:45:32 +00:00
parent c3fec1c035
commit 03c8223b96
6 changed files with 276 additions and 272 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
doc/supplements/powerpc/bsp.t
View File

@@ -25,7 +25,7 @@
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.
This chapter presents a discussion of PowerPC 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.
@@ -36,21 +36,22 @@ Applications User's Guide.
@section System Reset
An RTEMS based application is initiated or
re-initiated when the SPARC processor is reset. When the SPARC
re-initiated when the PowerPC processor is reset. When the PowerPC
is reset, the processor performs the following actions:
@itemize @bullet
@item the enable trap (ET) of the psr is set to 0 to disable
traps,
@item TBD
@item the supervisor bit (S) of the psr is set to 1 to enter
supervisor mode, and
@item TBD
@item the PC is set 0 and the nPC is set to 4.
@item TBD
@end itemize
The processor then begins to execute the code at
location 0. It is important to note that all fields in the psr
The processor then begins to execute the code at location 0x00100.
By using the SRR1 bit corresponding to MSR[RI] the softwere may
distinguish between power-on reset and other types of system resets.
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
@@ -79,7 +80,7 @@ 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 @value{RTEMS-LANGUAGE}
Board Support Packages chapter of the @value{LANGUAGE}
Applications User's Manual for the reset code
which is executed before the call to
rtems_initialize executive, the SPARC version has the following

21
doc/supplements/powerpc/bsp.texi
View File

@@ -25,7 +25,7 @@
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.
This chapter presents a discussion of PowerPC 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.
@@ -36,21 +36,22 @@ Applications User's Guide.
@section System Reset
An RTEMS based application is initiated or
re-initiated when the SPARC processor is reset. When the SPARC
re-initiated when the PowerPC processor is reset. When the PowerPC
is reset, the processor performs the following actions:
@itemize @bullet
@item the enable trap (ET) of the psr is set to 0 to disable
traps,
@item TBD
@item the supervisor bit (S) of the psr is set to 1 to enter
supervisor mode, and
@item TBD
@item the PC is set 0 and the nPC is set to 4.
@item TBD
@end itemize
The processor then begins to execute the code at
location 0. It is important to note that all fields in the psr
The processor then begins to execute the code at location 0x00100.
By using the SRR1 bit corresponding to MSR[RI] the softwere may
distinguish between power-on reset and other types of system resets.
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
@@ -79,7 +80,7 @@ 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 @value{RTEMS-LANGUAGE}
Board Support Packages chapter of the @value{LANGUAGE}
Applications User's Manual for the reset code
which is executed before the call to
rtems_initialize executive, the SPARC version has the following

106
doc/supplements/powerpc/cpumodel.t
View File

@@ -56,10 +56,11 @@ across the entire family.
* CPU Model Dependent Features Has Double Precision Floating Point::
* CPU Model Dependent Features Critical Interrupts::
* CPU Model Dependent Features MSR Values::
* CPU Model Dependent Features FPU Status Control Register Values::
* CPU Model Dependent Features Use Multiword Load/Store Instructions::
* CPU Model Dependent Features Instruction Cache Size::
* CPU Model Dependent Features Data Cache Size::
* CPU Model Dependent Features Debug Model::
* CPU Model Dependent Features Low Power Model::
@end menu
@end ifinfo
@@ -99,94 +100,131 @@ model, this macro is set to the string "PowerPC 603e".
@end ifinfo
@subsection Floating Point Unit
The macro PPC_HAS_FPU is set to 1 to indicate that
this CPU model has a hardware floating point unit and 0
otherwise.
The macro PPC_HAS_FPU is set to 1 to indicate that this CPU model
has a hardware floating point unit and 0 otherwise.
@ifinfo
@node CPU Model Dependent Features Alignment, CPU Model Dependent Features Cache Alignment, CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Alignment
The macro PPC_ALIGNMENT is set to
The macro PPC_ALIGNMENT is set to the PowerPC model's worst case alignment
requirement for data types on a byte boundary. This value is used
to derive the alignment restrictions for memory allocated from
regions and partitions.
@ifinfo
@node CPU Model Dependent Features Cache Alignment, CPU Model Dependent Features Maximum Interrupts, CPU Model Dependent Features Alignment, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Cache Alignment
The macro PPC_CACHE_ALIGNMENT is set to
The macro PPC_CACHE_ALIGNMENT is set to the line size of the cache. It is
used to align the entry point of critical routines so that as much code
as possible can be retrieved with the initial read into cache. This
is done for the interrupt handler as well as the context switch routines.
Similarly, the macro PPC_CACHE_ALIGN_POWER is set to the
In addition, the "shortcut" data structure used by the PowerPC implementation
to ease access to data elements frequently accessed by RTEMS routines
implemented in assembly language is aligned using this value.
@ifinfo
@node CPU Model Dependent Features Maximum Interrupts, CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features Cache Alignment, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Maximum Interrupts
The macro PPC_INTERRUPT_MAX is set to
The macro PPC_INTERRUPT_MAX is set to the number of exception sources
supported by this PowerPC model.
@ifinfo
@node CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features Maximum Interrupts, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Has Double Precision Floating Point
The macro PPC_HAS_DOUBLE is set to
The macro PPC_HAS_DOUBLE is set to 1 to indicate that the PowerPC model
has support for double precision floating point numbers. This is
important because the floating point registers need only be four bytes
wide (not eight) if double precision is not supported.
@ifinfo
@node CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features MSR Values, CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Critical Interrupts
The macro PPC_HAS_RFCI is set to
The macro PPC_HAS_RFCI is set to 1 to indicate that the PowerPC model
has the Critical Interrupt capability as defined by the IBM 403 models.
@ifinfo
@node CPU Model Dependent Features MSR Values, CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags
@node CPU Model Dependent Features MSR Values, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection MSR Values
The macro PPC_MSR_DISABLE_MASK is set to
The macro PPC_MSR_INITIAL is set to
The macro PPC_MSR_0 is set to
The macro PPC_MSR_1 is set to
The macro PPC_MSR_2 is set to
The macro PPC_MSR_3 is set to
@ifinfo
@node CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features MSR Values, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection FPU Status Control Register Values
The macro PPC_INIT_FPSCR is set to
@ifinfo
@node CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features CPU Model Feature Flags
@node CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features MSR Values, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Use Multiword Load/Store Instructions
The macro PPC_USE_MULTIPLE is set to
The macro PPC_USE_MULTIPLE is set to 1 to indicate that multiword load and
store instructions should be used to perform context switch operations.
The relative efficiency of multiword load and store instructions versus
an equivalent set of single word load and store instructions varies based
upon the PowerPC model.
@ifinfo
@node CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Instruction Cache Size
The macro PPC_I_CACHE is set to
The macro PPC_I_CACHE is set to the size in bytes of the instruction cache.
@ifinfo
@node CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features CPU Model Implementation Notes, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features CPU Model Feature Flags
@node CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features Debug Model, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Data Cache Size
The macro PPC_D_CACHE is set to
The macro PPC_D_CACHE is set to the size in bytes of the data cache.
@ifinfo
@node CPU Model Dependent Features CPU Model Implementation Notes, Calling Conventions, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features
@node CPU Model Dependent Features Debug Model, CPU Model Dependent Features Low Power Model, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Debug Model
The macro PPC_DEBUG_MODEL
@table @b
@item @code{PPC_DEBUG_MODEL_STANDARD}
indicates XXX
@item @code{PPC_DEBUG_MODEL_SINGLE_STEP_ONLY}
indicates XXX
@item @code{PPC_DEBUG_MODEL_IBM4xx}
indicates XXX
@end table
@ifinfo
@node CPU Model Dependent Features Low Power Model, CPU Model Dependent Features CPU Model Implementation Notes, CPU Model Dependent Features Debug Model, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Low Power Model
The macro PPC_LOW_POWER_MODE
@table @b
@item @code{PPC_LOW_POWER_MODE_NONE}
indicates XXX
@item @code{PPC_LOW_POWER_MODE_STANDARD}
indicates XXX
@end table
@ifinfo
@node CPU Model Dependent Features CPU Model Implementation Notes, Calling Conventions, CPU Model Dependent Features Low Power Model, CPU Model Dependent Features
@end ifinfo
@section CPU Model Implementation Notes

106
doc/supplements/powerpc/cpumodel.texi
View File

@@ -56,10 +56,11 @@ across the entire family.
* CPU Model Dependent Features Has Double Precision Floating Point::
* CPU Model Dependent Features Critical Interrupts::
* CPU Model Dependent Features MSR Values::
* CPU Model Dependent Features FPU Status Control Register Values::
* CPU Model Dependent Features Use Multiword Load/Store Instructions::
* CPU Model Dependent Features Instruction Cache Size::
* CPU Model Dependent Features Data Cache Size::
* CPU Model Dependent Features Debug Model::
* CPU Model Dependent Features Low Power Model::
@end menu
@end ifinfo
@@ -99,94 +100,131 @@ model, this macro is set to the string "PowerPC 603e".
@end ifinfo
@subsection Floating Point Unit
The macro PPC_HAS_FPU is set to 1 to indicate that
this CPU model has a hardware floating point unit and 0
otherwise.
The macro PPC_HAS_FPU is set to 1 to indicate that this CPU model
has a hardware floating point unit and 0 otherwise.
@ifinfo
@node CPU Model Dependent Features Alignment, CPU Model Dependent Features Cache Alignment, CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Alignment
The macro PPC_ALIGNMENT is set to
The macro PPC_ALIGNMENT is set to the PowerPC model's worst case alignment
requirement for data types on a byte boundary. This value is used
to derive the alignment restrictions for memory allocated from
regions and partitions.
@ifinfo
@node CPU Model Dependent Features Cache Alignment, CPU Model Dependent Features Maximum Interrupts, CPU Model Dependent Features Alignment, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Cache Alignment
The macro PPC_CACHE_ALIGNMENT is set to
The macro PPC_CACHE_ALIGNMENT is set to the line size of the cache. It is
used to align the entry point of critical routines so that as much code
as possible can be retrieved with the initial read into cache. This
is done for the interrupt handler as well as the context switch routines.
Similarly, the macro PPC_CACHE_ALIGN_POWER is set to the
In addition, the "shortcut" data structure used by the PowerPC implementation
to ease access to data elements frequently accessed by RTEMS routines
implemented in assembly language is aligned using this value.
@ifinfo
@node CPU Model Dependent Features Maximum Interrupts, CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features Cache Alignment, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Maximum Interrupts
The macro PPC_INTERRUPT_MAX is set to
The macro PPC_INTERRUPT_MAX is set to the number of exception sources
supported by this PowerPC model.
@ifinfo
@node CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features Maximum Interrupts, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Has Double Precision Floating Point
The macro PPC_HAS_DOUBLE is set to
The macro PPC_HAS_DOUBLE is set to 1 to indicate that the PowerPC model
has support for double precision floating point numbers. This is
important because the floating point registers need only be four bytes
wide (not eight) if double precision is not supported.
@ifinfo
@node CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features MSR Values, CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Critical Interrupts
The macro PPC_HAS_RFCI is set to
The macro PPC_HAS_RFCI is set to 1 to indicate that the PowerPC model
has the Critical Interrupt capability as defined by the IBM 403 models.
@ifinfo
@node CPU Model Dependent Features MSR Values, CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags
@node CPU Model Dependent Features MSR Values, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection MSR Values
The macro PPC_MSR_DISABLE_MASK is set to
The macro PPC_MSR_INITIAL is set to
The macro PPC_MSR_0 is set to
The macro PPC_MSR_1 is set to
The macro PPC_MSR_2 is set to
The macro PPC_MSR_3 is set to
@ifinfo
@node CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features MSR Values, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection FPU Status Control Register Values
The macro PPC_INIT_FPSCR is set to
@ifinfo
@node CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features CPU Model Feature Flags
@node CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features MSR Values, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Use Multiword Load/Store Instructions
The macro PPC_USE_MULTIPLE is set to
The macro PPC_USE_MULTIPLE is set to 1 to indicate that multiword load and
store instructions should be used to perform context switch operations.
The relative efficiency of multiword load and store instructions versus
an equivalent set of single word load and store instructions varies based
upon the PowerPC model.
@ifinfo
@node CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Instruction Cache Size
The macro PPC_I_CACHE is set to
The macro PPC_I_CACHE is set to the size in bytes of the instruction cache.
@ifinfo
@node CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features CPU Model Implementation Notes, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features CPU Model Feature Flags
@node CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features Debug Model, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Data Cache Size
The macro PPC_D_CACHE is set to
The macro PPC_D_CACHE is set to the size in bytes of the data cache.
@ifinfo
@node CPU Model Dependent Features CPU Model Implementation Notes, Calling Conventions, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features
@node CPU Model Dependent Features Debug Model, CPU Model Dependent Features Low Power Model, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Debug Model
The macro PPC_DEBUG_MODEL
@table @b
@item @code{PPC_DEBUG_MODEL_STANDARD}
indicates XXX
@item @code{PPC_DEBUG_MODEL_SINGLE_STEP_ONLY}
indicates XXX
@item @code{PPC_DEBUG_MODEL_IBM4xx}
indicates XXX
@end table
@ifinfo
@node CPU Model Dependent Features Low Power Model, CPU Model Dependent Features CPU Model Implementation Notes, CPU Model Dependent Features Debug Model, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Low Power Model
The macro PPC_LOW_POWER_MODE
@table @b
@item @code{PPC_LOW_POWER_MODE_NONE}
indicates XXX
@item @code{PPC_LOW_POWER_MODE_STANDARD}
indicates XXX
@end table
@ifinfo
@node CPU Model Dependent Features CPU Model Implementation Notes, Calling Conventions, CPU Model Dependent Features Low Power Model, CPU Model Dependent Features
@end ifinfo
@section CPU Model Implementation Notes

147
doc/supplements/powerpc/intr.t
View File

@@ -13,9 +13,8 @@
@ifinfo
@menu
* Interrupt Processing Introduction::
* Interrupt Processing Synchronous Versus Asynchronous Traps::
* Interrupt Processing Synchronous Versus Asynchronous Exceptions::
* Interrupt Processing Vectoring of Interrupt Handler::
* Interrupt Processing Traps and Register Windows::
* Interrupt Processing Interrupt Levels::
* Interrupt Processing Disabling of Interrupts by RTEMS::
* Interrupt Processing Interrupt Stack::
@@ -23,7 +22,7 @@
@end ifinfo
@ifinfo
@node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing, Interrupt Processing
@node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing, Interrupt Processing
@end ifinfo
@section Introduction
@@ -38,80 +37,64 @@ 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
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 SPARC architecture, these terms
correspond to traps and trap type, respectively. The terms will
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 Traps, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Introduction, Interrupt Processing
@node Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Introduction, Interrupt Processing
@end ifinfo
@section Synchronous Versus Asynchronous Traps
@section Synchronous Versus Asynchronous Exceptions
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.
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.
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.
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 Traps and Register Windows, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing
@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 receipt of an interrupt the SPARC automatically
Upon determining that an exception can be taken the PPC automatically
performs the following actions:
@itemize @bullet
@item disables traps (sets the ET bit of the psr to 0),
@item an instruction address is loaded into SRR0
@item the S bit of the psr is copied into the Previous
Supervisor Mode (PS) bit of the psr,
@item bits 33-36 and 42-47 of SRR1 are loaded with information
specific to the exception.
@item the cwp is decremented by one (modulo the number of
register windows) to activate a trap window,
@item bits 0-32, 37-41, and 48-63 of SRR1 are loaded with corresponding
bits from the MSR.
@item the PC and nPC are loaded into local register 1 and 2
(l0 and l1),
@item the MSR is set based upon the exception type.
@item the trap type (tt) field of the Trap Base Register (TBR)
is set to the appropriate value, and
@item instruction fetch and execution resumes, using the new MSR value, at a location specific to the execption type.
@item 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.
@end itemize
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
@@ -122,19 +105,19 @@ performs the following actions:
@item saves the state of the interrupted task on it's stack,
@item insures that a register window is available for
subsequent traps,
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 traps,
@item enables exceptions,
@item invokes the vectors to a user interrupt service routine (ISR).
@end itemize
Asynchronous interrupts are ignored while traps are
disabled. Synchronous traps which occur while traps are
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
@@ -142,41 +125,19 @@ exception that the current stack need not be switched to the
interrupt stack.
@ifinfo
@node Interrupt Processing Traps and Register Windows, Interrupt Processing Interrupt Levels, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing
@end ifinfo
@section 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.
@ifinfo
@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Traps and Register Windows, Interrupt Processing
@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
Sixteen levels (0-15) of interrupt priorities are
supported by the SPARC architecture with level fifteen (15)
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.
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
TBD
All other RTEMS interrupt levels are undefined and their behavior is
unpredictable.
@ifinfo
@@ -186,21 +147,21 @@ unpredictable.
During the execution of directive calls, critical
sections of code may be executed. When these sections are
encountered, RTEMS disables interrupts to level seven (15)
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.
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 traps are
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
@@ -215,14 +176,14 @@ execute as non-maskable interrupts.
@end ifinfo
@section Interrupt Stack
The SPARC architecture does not provide for a
dedicated interrupt stack. Thus by default, trap handlers would
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 SPARC by providing a dedicated interrupt stack
problem on the PowerPC by providing a dedicated interrupt stack
managed by software.
During system initialization, RTEMS allocates the
@@ -232,3 +193,5 @@ 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.

147
doc/supplements/powerpc/intr_NOTIMES.t
View File

@@ -13,9 +13,8 @@
@ifinfo
@menu
* Interrupt Processing Introduction::
* Interrupt Processing Synchronous Versus Asynchronous Traps::
* Interrupt Processing Synchronous Versus Asynchronous Exceptions::
* Interrupt Processing Vectoring of Interrupt Handler::
* Interrupt Processing Traps and Register Windows::
* Interrupt Processing Interrupt Levels::
* Interrupt Processing Disabling of Interrupts by RTEMS::
* Interrupt Processing Interrupt Stack::
@@ -23,7 +22,7 @@
@end ifinfo
@ifinfo
@node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing, Interrupt Processing
@node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing, Interrupt Processing
@end ifinfo
@section Introduction
@@ -38,80 +37,64 @@ 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
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 SPARC architecture, these terms
correspond to traps and trap type, respectively. The terms will
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 Traps, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Introduction, Interrupt Processing
@node Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Introduction, Interrupt Processing
@end ifinfo
@section Synchronous Versus Asynchronous Traps
@section Synchronous Versus Asynchronous Exceptions
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.
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.
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.
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 Traps and Register Windows, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing
@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 receipt of an interrupt the SPARC automatically
Upon determining that an exception can be taken the PPC automatically
performs the following actions:
@itemize @bullet
@item disables traps (sets the ET bit of the psr to 0),
@item an instruction address is loaded into SRR0
@item the S bit of the psr is copied into the Previous
Supervisor Mode (PS) bit of the psr,
@item bits 33-36 and 42-47 of SRR1 are loaded with information
specific to the exception.
@item the cwp is decremented by one (modulo the number of
register windows) to activate a trap window,
@item bits 0-32, 37-41, and 48-63 of SRR1 are loaded with corresponding
bits from the MSR.
@item the PC and nPC are loaded into local register 1 and 2
(l0 and l1),
@item the MSR is set based upon the exception type.
@item the trap type (tt) field of the Trap Base Register (TBR)
is set to the appropriate value, and
@item instruction fetch and execution resumes, using the new MSR value, at a location specific to the execption type.
@item 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.
@end itemize
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
@@ -122,19 +105,19 @@ performs the following actions:
@item saves the state of the interrupted task on it's stack,
@item insures that a register window is available for
subsequent traps,
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 traps,
@item enables exceptions,
@item invokes the vectors to a user interrupt service routine (ISR).
@end itemize
Asynchronous interrupts are ignored while traps are
disabled. Synchronous traps which occur while traps are
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
@@ -142,41 +125,19 @@ exception that the current stack need not be switched to the
interrupt stack.
@ifinfo
@node Interrupt Processing Traps and Register Windows, Interrupt Processing Interrupt Levels, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing
@end ifinfo
@section 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.
@ifinfo
@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Traps and Register Windows, Interrupt Processing
@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
Sixteen levels (0-15) of interrupt priorities are
supported by the SPARC architecture with level fifteen (15)
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.
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
TBD
All other RTEMS interrupt levels are undefined and their behavior is
unpredictable.
@ifinfo
@@ -186,21 +147,21 @@ unpredictable.
During the execution of directive calls, critical
sections of code may be executed. When these sections are
encountered, RTEMS disables interrupts to level seven (15)
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.
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 traps are
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
@@ -215,14 +176,14 @@ execute as non-maskable interrupts.
@end ifinfo
@section Interrupt Stack
The SPARC architecture does not provide for a
dedicated interrupt stack. Thus by default, trap handlers would
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 SPARC by providing a dedicated interrupt stack
problem on the PowerPC by providing a dedicated interrupt stack
managed by software.
During system initialization, RTEMS allocates the
@@ -232,3 +193,5 @@ 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.