updates

17 files changed, 540 insertions, 655 deletions

diff --git a/doc/supplements/powerpc/bsp.t b/doc/supplements/powerpc/bsp.t
index 99fdd3fb94..015f7347e0 100644
--- a/doc/supplements/powerpc/bsp.t
+++ b/doc/supplements/powerpc/bsp.t
@@ -36,26 +36,17 @@ Applications User's Guide.
 @section System Reset
 
 An RTEMS based application is initiated or
-re-initiated when the PowerPC processor is reset.  When the PowerPC
-is reset, the processor performs the following actions:
-
-@itemize @bullet
-@item TBD
-
-@item TBD
-
-@item TBD
-@end itemize
-
-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
-reflect the last trap which occurred before the reset.
+re-initiated when the PowerPC processor is reset.  The PowerPC 
+architecture defines a Reset Exception, but leaves the
+details of the CPU state as implementation specific.  Please
+refer to the User's Manual for the CPU model in question.
+
+In general, at power-up the PowerPC begin execution at address
+0xFFF00100 in supervisor mode with all exceptions disabled.  For
+soft resets, the CPU will vector to either 0xFFF00100 or 0x00000100
+depending upon the setting of the Exception Prefix bit in the MSR.
+If during a soft reset, a Machine Check Exception occurs, then the
+CPU may execute a hard reset.
 
 @ifinfo
 @node Board Support Packages Processor Initialization, Processor Dependent Information Table, Board Support Packages System Reset, Board Support Packages
@@ -63,36 +54,33 @@ reflect the last trap which occurred before the reset.
 @section Processor Initialization
 
 It is the responsibility of the application's
-initialization code to initialize the TBR and install trap
-handlers for at least the register window overflow and register
-window underflow conditions.  Traps should be enabled before
-invoking any subroutines to allow for register window
-management.  However, interrupts should be disabled by setting
-the Processor Interrupt Level (pil) field of the psr to 15.
-RTEMS installs it's own Trap Table as part of initialization
-which is initialized with the contents of the Trap Table in
-place when the rtems_initialize_executive directive was invoked.
-Upon completion of executive initialization, interrupts are
-enabled.
+initialization code to initialize the CPU and board
+to a quiescent state before invoking the @code{rtems_initialize_executive}
+directive.  It is recommended that the BSP utilize the @code{predriver_hook}
+to install default handlers for all exceptions.  These default handlers
+may be overwritten as various device drivers and subsystems install
+their own exception handlers.  Upon completion of RTEMS executive
+initialization, all interrupts are enabled.
 
 If this PowerPC implementation supports on-chip caching
 and this is to be utilized, then it should be enabled during the
-reset application initialization code.
+reset application initialization code.  On-chip caching has been
+observed to prevent some emulators from working properly, so it
+may be necessary to run with caching disabled to use these emulators.
 
 In addition to the requirements described in the
-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 PowrePC version has the following
-specific requirements:
+@b{Board Support Packages} chapter of the @b{@value{LANGUAGE}
+Applications User's Manual} for the reset code
+which is executed before the call to @code{rtems_initialize_executive},
+the PowrePC version has the following specific requirements:
 
 @itemize @bullet
-@item Must leave the PR bit of the machine state register set so that
-the PowerPC remains in the supervisor state.
+@item Must leave the PR bit of the Machine State Register (MSR) set 
+to 0 so the PowerPC remains in the supervisor state.
 
-@item Must set stack pointer (sp) such that a minimum stack
+@item Must set stack pointer (sp or r1) such that a minimum stack
 size of MINIMUM_STACK_SIZE bytes is provided for the
-rtems_initialize executive directive.
+@code{rtems_initialize_executive} directive.
 
 @item Must disable all external interrupts (i.e. clear the EI (EE)
 bit of the machine state register).
@@ -100,8 +88,8 @@ bit of the machine state register).
 @item Must enable traps so window overflow and underflow
 conditions can be properly handled.
 
-@item Must initialize the PowerPC's initial trap table with at
-least trap handlers for register window overflow and register
-window underflow.
+@item Must initialize the PowerPC's initial Exception Table with default
+handlers.
+
 @end itemize
 
diff --git a/doc/supplements/powerpc/bsp.texi b/doc/supplements/powerpc/bsp.texi
index 99fdd3fb94..015f7347e0 100644
--- a/doc/supplements/powerpc/bsp.texi
+++ b/doc/supplements/powerpc/bsp.texi
@@ -36,26 +36,17 @@ Applications User's Guide.
 @section System Reset
 
 An RTEMS based application is initiated or
-re-initiated when the PowerPC processor is reset.  When the PowerPC
-is reset, the processor performs the following actions:
-
-@itemize @bullet
-@item TBD
-
-@item TBD
-
-@item TBD
-@end itemize
-
-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
-reflect the last trap which occurred before the reset.
+re-initiated when the PowerPC processor is reset.  The PowerPC 
+architecture defines a Reset Exception, but leaves the
+details of the CPU state as implementation specific.  Please
+refer to the User's Manual for the CPU model in question.
+
+In general, at power-up the PowerPC begin execution at address
+0xFFF00100 in supervisor mode with all exceptions disabled.  For
+soft resets, the CPU will vector to either 0xFFF00100 or 0x00000100
+depending upon the setting of the Exception Prefix bit in the MSR.
+If during a soft reset, a Machine Check Exception occurs, then the
+CPU may execute a hard reset.
 
 @ifinfo
 @node Board Support Packages Processor Initialization, Processor Dependent Information Table, Board Support Packages System Reset, Board Support Packages
@@ -63,36 +54,33 @@ reflect the last trap which occurred before the reset.
 @section Processor Initialization
 
 It is the responsibility of the application's
-initialization code to initialize the TBR and install trap
-handlers for at least the register window overflow and register
-window underflow conditions.  Traps should be enabled before
-invoking any subroutines to allow for register window
-management.  However, interrupts should be disabled by setting
-the Processor Interrupt Level (pil) field of the psr to 15.
-RTEMS installs it's own Trap Table as part of initialization
-which is initialized with the contents of the Trap Table in
-place when the rtems_initialize_executive directive was invoked.
-Upon completion of executive initialization, interrupts are
-enabled.
+initialization code to initialize the CPU and board
+to a quiescent state before invoking the @code{rtems_initialize_executive}
+directive.  It is recommended that the BSP utilize the @code{predriver_hook}
+to install default handlers for all exceptions.  These default handlers
+may be overwritten as various device drivers and subsystems install
+their own exception handlers.  Upon completion of RTEMS executive
+initialization, all interrupts are enabled.
 
 If this PowerPC implementation supports on-chip caching
 and this is to be utilized, then it should be enabled during the
-reset application initialization code.
+reset application initialization code.  On-chip caching has been
+observed to prevent some emulators from working properly, so it
+may be necessary to run with caching disabled to use these emulators.
 
 In addition to the requirements described in the
-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 PowrePC version has the following
-specific requirements:
+@b{Board Support Packages} chapter of the @b{@value{LANGUAGE}
+Applications User's Manual} for the reset code
+which is executed before the call to @code{rtems_initialize_executive},
+the PowrePC version has the following specific requirements:
 
 @itemize @bullet
-@item Must leave the PR bit of the machine state register set so that
-the PowerPC remains in the supervisor state.
+@item Must leave the PR bit of the Machine State Register (MSR) set 
+to 0 so the PowerPC remains in the supervisor state.
 
-@item Must set stack pointer (sp) such that a minimum stack
+@item Must set stack pointer (sp or r1) such that a minimum stack
 size of MINIMUM_STACK_SIZE bytes is provided for the
-rtems_initialize executive directive.
+@code{rtems_initialize_executive} directive.
 
 @item Must disable all external interrupts (i.e. clear the EI (EE)
 bit of the machine state register).
@@ -100,8 +88,8 @@ bit of the machine state register).
 @item Must enable traps so window overflow and underflow
 conditions can be properly handled.
 
-@item Must initialize the PowerPC's initial trap table with at
-least trap handlers for register window overflow and register
-window underflow.
+@item Must initialize the PowerPC's initial Exception Table with default
+handlers.
+
 @end itemize
 
diff --git a/doc/supplements/powerpc/callconv.t b/doc/supplements/powerpc/callconv.t
index 73bcba8c83..1bf2c8fc79 100644
--- a/doc/supplements/powerpc/callconv.t
+++ b/doc/supplements/powerpc/callconv.t
@@ -7,14 +7,13 @@
 @c
 
 @ifinfo
-@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features CPU Model Implementation Notes, Top
+@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features Low Power Model, Top
 @end ifinfo
 @chapter Calling Conventions
 @ifinfo
 @menu
 * Calling Conventions Introduction::
 * Calling Conventions Programming Model::
-* Calling Conventions Register Windows::
 * Calling Conventions Call and Return Mechanism::
 * Calling Conventions Calling Mechanism::
 * Calling Conventions Register Usage::
@@ -53,14 +52,14 @@ calling convention.  Documentation for EABI is available by sending
 a message with a subject line of "EABI" to eabi@@goth.sis.mot.com.
 
 @ifinfo
-@node Calling Conventions Programming Model, Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions
+@node Calling Conventions Programming Model, Calling Conventions Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions
 @end ifinfo
 @section Programming Model
 @ifinfo
 @menu
-* Non-Floating Point Registers::
-* Floating Point Registers::
-* Special Registers::
+* Calling Conventions Non-Floating Point Registers::
+* Calling Conventions Floating Point Registers::
+* Calling Conventions Special Registers::
 @end menu
 @end ifinfo
 
@@ -68,7 +67,7 @@ This section discusses the programming model for the
 PowerPC architecture.
 
 @ifinfo
-@node Non-Floating Point Registers, Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model
+@node Calling Conventions Non-Floating Point Registers, Calling Conventions Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model
 @end ifinfo
 @subsection Non-Floating Point Registers
 
@@ -85,18 +84,19 @@ The following table describes the role of each of these registers:
 @ifset use-ascii
 @example
 @group
-     +---------------+----------------+----------------------+
-     | Register Name | Alternate Name |      Description     |
-     +---------------+----------------+----------------------+
-     |     g0        |      na        |    reads return 0    |
-     |               |                |  writes are ignored  |
-     +---------------+----------------+----------------------+
-     |     o6        |      sp        |     stack pointer    |
-     +---------------+----------------+----------------------+
-     |     i6        |      fp        |     frame pointer    |
-     +---------------+----------------+----------------------+
-     |     i7        |      na        |    return address    |
-     +---------------+----------------+----------------------+
+     +---------------+----------------+------------------------------+
+     | Register Name | Alternate Name |         Description          |
+     +---------------+----------------+------------------------------+
+     |      r1       |      sp        |         stack pointer        |
+     +---------------+----------------+------------------------------+
+     |               |                |  global pointer to the Small |
+     |      r2       |      na        |     Constant Area (SDA2)     |
+     +---------------+----------------+------------------------------+
+     |    r3 - r12   |      na        | parameter and result passing |
+     +---------------+----------------+------------------------------+
+     |               |                |  global pointer to the Small |
+     |      r13      |      na        |         Data Area (SDA)      |
+     +---------------+----------------+------------------------------+
 @end group
 @end example
 @end ifset
@@ -110,15 +110,16 @@ The following table describes the role of each of these registers:
 \vrule#&
 \hbox to 1.75in{\enskip\hfil#\hfil}&
 \vrule#&
-\hbox to 1.75in{\enskip\hfil#\hfil}&
+\hbox to 2.50in{\enskip\hfil#\hfil}&
 \vrule#\cr
 \noalign{\hrule}
 &\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule}
-&g0&&NA&&reads return 0; &\cr
-&&&&&writes are ignored&\cr\noalign{\hrule}
-&o6&&sp&&stack pointer&\cr\noalign{\hrule}
-&i6&&fp&&frame pointer&\cr\noalign{\hrule}
-&i7&&NA&&return address&\cr\noalign{\hrule}
+&r1&&sp&&stack pointer&\cr\noalign{\hrule}
+&r2&&NA&&global pointer to the Small&\cr
+&&&&&Constant Area (SDA2)&\cr\noalign{\hrule}
+&r3 - r12&&NA&&parameter and result passing&\cr\noalign{\hrule}
+&r13&&NA&&global pointer to the Small&\cr
+&&&&&Data Area (SDA2)&\cr\noalign{\hrule}
 }}\hfil}
 @end tex
 @end ifset
@@ -130,18 +131,18 @@ The following table describes the role of each of these registers:
 <TR><TD ALIGN=center><STRONG>Register Name</STRONG></TD>
     <TD ALIGN=center><STRONG>Alternate Name</STRONG></TD>
     <TD ALIGN=center><STRONG>Description</STRONG></TD></TR>
-<TR><TD ALIGN=center>g0</TD>
-    <TD ALIGN=center>NA</TD>
-    <TD ALIGN=center>reads return 0 ; writes are ignored</TD></TR>
-<TR><TD ALIGN=center>o6</TD>
+<TR><TD ALIGN=center>r1</TD>
     <TD ALIGN=center>sp</TD>
     <TD ALIGN=center>stack pointer</TD></TR>
-<TR><TD ALIGN=center>i6</TD>
-    <TD ALIGN=center>fp</TD>
-    <TD ALIGN=center>frame pointer</TD></TR>
-<TR><TD ALIGN=center>i7</TD>
+<TR><TD ALIGN=center>r2</TD>
+    <TD ALIGN=center>na</TD>
+    <TD ALIGN=center>global pointer to the Small Constant Area (SDA2)</TD></TR>
+<TR><TD ALIGN=center>r3 - r12</TD>
     <TD ALIGN=center>NA</TD>
-    <TD ALIGN=center>return address</TD></TR>
+    <TD ALIGN=center>parameter and result passing</TD></TR>
+<TR><TD ALIGN=center>r13</TD>
+    <TD ALIGN=center>NA</TD>
+    <TD ALIGN=center>global pointer to the Small Data Area (SDA)</TD></TR>
   </TABLE>
 </CENTER>
 @end html
@@ -149,13 +150,13 @@ The following table describes the role of each of these registers:
 
 
 @ifinfo
-@node Floating Point Registers, Special Registers, Non-Floating Point Registers, Calling Conventions Programming Model
+@node Calling Conventions Floating Point Registers, Calling Conventions Special Registers, Calling Conventions Non-Floating Point Registers, Calling Conventions Programming Model
 @end ifinfo
 @subsection Floating Point Registers
 
-The PowerPC architecture includes thirty-two,
-sixty-four bit registers.  All PowwerPC floating point instructions 
-interprete these registers as 32 double precision floating point registers,
+The PowerPC architecture includes thirty-two, sixty-four bit
+floating point registers.  All PowerPC floating point instructions 
+interpret these registers as 32 double precision floating point registers,
 regardless of whether the processor has 64-bit or 32-bit implementation.
 
 The floating point status and control register (fpscr) records exceptions
@@ -163,159 +164,66 @@ and the type of result generated by floating-point operations.
 Additionally, it controls the rounding mode of operations and allows the
 reporting of floating exceptions to be enabled or disabled.
 
-XXXXXX
-A queue of the floating point instructions which have
-started execution but not yet completed is maintained.  This
-queue is needed to support the multiple cycle nature of floating
-point operations and to aid floating point exception trap
-handlers.  Once a floating point exception has been encountered,
-the queue is frozen until it is emptied by the trap handler.
-The floating point queue is loaded by launching instructions.
-It is emptied normally when the floating point completes all
-outstanding instructions and by floating point exception
-handlers with the store double floating point queue (stdfq)
-instruction.
-XXX
-
 @ifinfo
-@node Special Registers, Calling Conventions Register Windows, Floating Point Registers, Calling Conventions Programming Model
+@node Calling Conventions Special Registers, Calling Conventions Call and Return Mechanism, Calling Conventions Floating Point Registers, Calling Conventions Programming Model
 @end ifinfo
 @subsection Special Registers
 
-The PowerPC architecture includes XXX special registers
-which are critical to the programming model: the Machine State
-Register (msr) and XXX the Window Invalid Mask (wim) XXX.  The msr
-contains the processor mode, power management mode, endian mode, exception
-information, privlige level, floating point available and floating point 
-excepiton mode, address translation information and the exception prefix.
-
-XXX
-condition codes, processor interrupt level, trap
-enable bit, supervisor mode and previous supervisor mode bits,
-version information, floating point unit and coprocessor enable
-bits, and the current window pointer (cwp).  The cwp field of
-the psr and wim register are used to manage the register windows
-in the SPARC architecture.  The register windows are discussed
-in more detail below.
-XXX
+The PowerPC architecture includes a number of special registers
+which are critical to the programming model:
 
-@ifinfo
-@node Calling Conventions Register Windows, Calling Conventions Call and Return Mechanism, Special Registers, Calling Conventions
-@end ifinfo
-@section Register Windows
-
-The SPARC architecture includes the concept of
-register windows.  An overly simplistic way to think of these
-windows is to imagine them as being an infinite supply of
-"fresh" register sets available for each subroutine to use.  In
-reality, they are much more complicated.
-
-The save instruction is used to obtain a new register
-window.  This instruction decrements the current window pointer,
-thus providing a new set of registers for use.  This register
-set includes eight fresh local registers for use exclusively by
-this subroutine.  When done with a register set, the restore
-instruction increments the current window pointer and the
-previous register set is once again available.
-
-The two primary issues complicating the use of
-register windows are that (1) the set of register windows is
-finite, and (2) some registers are shared between adjacent
-registers windows.
-
-Because the set of register windows is finite, it is
-possible to execute enough save instructions without
-corresponding restore's to consume all of the register windows.
-This is easily accomplished in a high level language because
-each subroutine typically performs a save instruction upon
-entry.  Thus having a subroutine call depth greater than the
-number of register windows will result in a window overflow
-condition.  The window overflow condition generates a trap which
-must be handled in software.  The window overflow trap handler
-is responsible for saving the contents of the oldest register
-window on the program stack.
-
-Similarly, the subroutines will eventually complete
-and begin to perform restore's.  If the restore results in the
-need for a register window which has previously been written to
-memory as part of an overflow, then a window underflow condition
-results.  Just like the window overflow, the window underflow
-condition must be handled in software by a trap handler.  The
-window underflow trap handler is responsible for reloading the
-contents of the register window requested by the restore
-instruction from the program stack.
-
-The Window Invalid Mask (wim) and the Current Window
-Pointer (cwp) field in the psr are used in conjunction to manage
-the finite set of register windows and detect the window
-overflow and underflow conditions.  The cwp contains the index
-of the register window currently in use.  The save instruction
-decrements the cwp modulo the number of register windows.
-Similarly, the restore instruction increments the cwp modulo the
-number of register windows.  Each bit in the  wim represents
-represents whether a register window contains valid information.
-The value of 0 indicates the register window is valid and 1
-indicates it is invalid.  When a save instruction causes the cwp
-to point to a register window which is marked as invalid, a
-window overflow condition results.  Conversely, the restore
-instruction may result in a window underflow condition.
-
-Other than the assumption that a register window is
-always available for trap (i.e. interrupt) handlers, the SPARC
-architecture places no limits on the number of register windows
-simultaneously marked as invalid (i.e. number of bits set in the
-wim).  However, RTEMS assumes that only one register window is
-marked invalid at a time (i.e. only one bit set in the wim).
-This makes the maximum possible number of register windows
-available to the user while still meeting the requirement that
-window overflow and underflow conditions can be detected.
-
-The window overflow and window underflow trap
-handlers are a critical part of the run-time environment for a
-SPARC application.  The SPARC architectural specification allows
-for the number of register windows to be any power of two less
-than or equal to 32.  The most common choice for SPARC
-implementations appears to be 8 register windows.  This results
-in the cwp ranging in value from 0 to 7 on most implementations.
-
-
-The second complicating factor is the sharing of
-registers between adjacent register windows.  While each
-register window has its own set of local registers, the input
-and output registers are shared between adjacent windows.  The
-output registers for register window N are the same as the input
-registers for register window ((N - 1) modulo RW) where RW is
-the number of register windows.  An alternative way to think of
-this is to remember how parameters are passed to a subroutine on
-the SPARC.  The caller loads values into what are its output
-registers.  Then after the callee executes a save instruction,
-those parameters are available in its input registers.  This is
-a very efficient way to pass parameters as no data is actually
-moved by the save or restore instructions.
+@table @b
+
+@item Machine State Register
+
+The MSR contains the processor mode, power management mode, endian mode,
+exception information, privilege level, floating point available and
+floating point excepiton mode, address translation information and
+the exception prefix.
+
+@item Link Register
+
+The LR contains the return address after a function call.  This register
+must be saved before a subsequent subroutine call can be made.  The
+use of this register is discussed further in the @b{Call and Return
+Mechanism} section below.
+
+@item Count Register
+
+The CTR contains the iteration variable for some loops.  It may also be used
+for indirect function calls and jumps.
+
+@end table
 
 @ifinfo
-@node Calling Conventions Call and Return Mechanism, Calling Conventions Calling Mechanism, Calling Conventions Register Windows, Calling Conventions
+@node Calling Conventions Call and Return Mechanism, Calling Conventions Calling Mechanism, Calling Conventions Special Registers, Calling Conventions
 @end ifinfo
 @section Call and Return Mechanism
 
-The SPARC architecture supports a simple yet
-effective call and return mechanism.  A subroutine is invoked
-via the call (call) instruction.  This instruction places the
-return address in the caller's output register 7 (o7).  After
-the callee executes a save instruction, this value is available
-in input register 7 (i7) until the corresponding restore
-instruction is executed.
-
-The callee returns to the caller via a jmp to the
-return address.  There is a delay slot following this
-instruction which is commonly used to execute a restore
-instruction -- if a register window was allocated by this
-subroutine.
-
-It is important to note that the SPARC subroutine
+The PowerPC architecture supports a simple yet effective call
+and return mechanism.  A subroutine is invoked
+via the "branch and link" (@code{bl}) and
+"brank and link absolute" (@code{bla})
+instructions.  This instructions place the return address
+in the Link Register (LR).  The callee returns to the caller by 
+executing a "branch unconditional to the link register" (@code{blr})
+instruction.  Thus the callee returns to the caller via a jump
+to the return address which is stored in the LR.
+
+The previous contents of the LR are not automatically saved 
+by either the @code{bl} or @code{bla}.  It is the responsibility
+of the callee to save the contents of the LR before invoking
+another subroutine.  If the callee invokes another subroutine,
+it must restore the LR before executing the @code{blr} instruction
+to return to the caller.
+
+It is important to note that the PowerPC subroutine
 call and return mechanism does not automatically save and
-restore any registers.  This is accomplished via the save and
-restore instructions which manage the set of registers windows.
+restore any registers.
+
+The LR may be accessed as special purpose register 8 (@code{SPR8}) using the
+"move from special register" (@code{mfspr}) and
+"move to special register" (@code{mtspr}) instructions.
 
 @ifinfo
 @node Calling Conventions Calling Mechanism, Calling Conventions Register Usage, Calling Conventions Call and Return Mechanism, Calling Conventions
@@ -323,7 +231,8 @@ restore instructions which manage the set of registers windows.
 @section Calling Mechanism
 
 All RTEMS directives are invoked using the regular
-SPARC calling convention via the call instruction.
+PowerPC EABI calling convention via the @code{bl} or
+@code{bla} instructions.
 
 @ifinfo
 @node Calling Conventions Register Usage, Calling Conventions Parameter Passing, Calling Conventions Calling Mechanism, Calling Conventions
@@ -331,11 +240,11 @@ SPARC calling convention via the call instruction.
 @section Register Usage
 
 As discussed above, the call instruction does not
-automatically save any registers.  The save and restore
-instructions are used to allocate and deallocate register
-windows.  When a register window is allocated, the new set of
-local registers are available for the exclusive use of the
-subroutine which allocated this register set.
+automatically save any registers.  It is the responsibility
+of the callee to save and restore any registers which must be preserved
+across subroutine calls.  The callee is responsible for saving 
+callee-preserved registers to the program stack and restoring them
+before returning to the caller.
 
 @ifinfo
 @node Calling Conventions Parameter Passing, Calling Conventions User-Provided Routines, Calling Conventions Register Usage, Calling Conventions
@@ -343,19 +252,19 @@ subroutine which allocated this register set.
 @section Parameter Passing
 
 RTEMS assumes that arguments are placed in the
-caller's output registers with the first argument in output
-register 0 (o0), the second argument in output register 1 (o1),
-and so forth.  Until the callee executes a save instruction, the
-parameters are still visible in the output registers.  After the
-callee executes a save instruction, the parameters are visible
-in the corresponding input registers.  The following pseudo-code
+general purpose registers with the first argument in 
+register 3 (@code{r3}), the second argument in general purpose
+register 4 (@code{r4}), and so forth until the seventh
+argument is in general purpose register 10 (@code{r10}).  
+If there are more than seven arguments, then subsequent arguments
+are placed on the program stack.  The following pseudo-code
 illustrates the typical sequence used to call a RTEMS directive
 with three (3) arguments:
 
 @example
-load third argument into o2
-load second argument into o1
-load first argument into o0
+load third argument into r5
+load second argument into r4
+load first argument into r3
 invoke directive
 @end example
 
@@ -366,7 +275,6 @@ invoke directive
 
 All user-provided routines invoked by RTEMS, such as
 user extensions, device drivers, and MPCI routines, must also
-adhere to these calling conventions.
-
+adhere to these same calling conventions.
 
 
diff --git a/doc/supplements/powerpc/callconv.texi b/doc/supplements/powerpc/callconv.texi
index 73bcba8c83..1bf2c8fc79 100644
--- a/doc/supplements/powerpc/callconv.texi
+++ b/doc/supplements/powerpc/callconv.texi
@@ -7,14 +7,13 @@
 @c
 
 @ifinfo
-@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features CPU Model Implementation Notes, Top
+@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features Low Power Model, Top
 @end ifinfo
 @chapter Calling Conventions
 @ifinfo
 @menu
 * Calling Conventions Introduction::
 * Calling Conventions Programming Model::
-* Calling Conventions Register Windows::
 * Calling Conventions Call and Return Mechanism::
 * Calling Conventions Calling Mechanism::
 * Calling Conventions Register Usage::
@@ -53,14 +52,14 @@ calling convention.  Documentation for EABI is available by sending
 a message with a subject line of "EABI" to eabi@@goth.sis.mot.com.
 
 @ifinfo
-@node Calling Conventions Programming Model, Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions
+@node Calling Conventions Programming Model, Calling Conventions Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions
 @end ifinfo
 @section Programming Model
 @ifinfo
 @menu
-* Non-Floating Point Registers::
-* Floating Point Registers::
-* Special Registers::
+* Calling Conventions Non-Floating Point Registers::
+* Calling Conventions Floating Point Registers::
+* Calling Conventions Special Registers::
 @end menu
 @end ifinfo
 
@@ -68,7 +67,7 @@ This section discusses the programming model for the
 PowerPC architecture.
 
 @ifinfo
-@node Non-Floating Point Registers, Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model
+@node Calling Conventions Non-Floating Point Registers, Calling Conventions Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model
 @end ifinfo
 @subsection Non-Floating Point Registers
 
@@ -85,18 +84,19 @@ The following table describes the role of each of these registers:
 @ifset use-ascii
 @example
 @group
-     +---------------+----------------+----------------------+
-     | Register Name | Alternate Name |      Description     |
-     +---------------+----------------+----------------------+
-     |     g0        |      na        |    reads return 0    |
-     |               |                |  writes are ignored  |
-     +---------------+----------------+----------------------+
-     |     o6        |      sp        |     stack pointer    |
-     +---------------+----------------+----------------------+
-     |     i6        |      fp        |     frame pointer    |
-     +---------------+----------------+----------------------+
-     |     i7        |      na        |    return address    |
-     +---------------+----------------+----------------------+
+     +---------------+----------------+------------------------------+
+     | Register Name | Alternate Name |         Description          |
+     +---------------+----------------+------------------------------+
+     |      r1       |      sp        |         stack pointer        |
+     +---------------+----------------+------------------------------+
+     |               |                |  global pointer to the Small |
+     |      r2       |      na        |     Constant Area (SDA2)     |
+     +---------------+----------------+------------------------------+
+     |    r3 - r12   |      na        | parameter and result passing |
+     +---------------+----------------+------------------------------+
+     |               |                |  global pointer to the Small |
+     |      r13      |      na        |         Data Area (SDA)      |
+     +---------------+----------------+------------------------------+
 @end group
 @end example
 @end ifset
@@ -110,15 +110,16 @@ The following table describes the role of each of these registers:
 \vrule#&
 \hbox to 1.75in{\enskip\hfil#\hfil}&
 \vrule#&
-\hbox to 1.75in{\enskip\hfil#\hfil}&
+\hbox to 2.50in{\enskip\hfil#\hfil}&
 \vrule#\cr
 \noalign{\hrule}
 &\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule}
-&g0&&NA&&reads return 0; &\cr
-&&&&&writes are ignored&\cr\noalign{\hrule}
-&o6&&sp&&stack pointer&\cr\noalign{\hrule}
-&i6&&fp&&frame pointer&\cr\noalign{\hrule}
-&i7&&NA&&return address&\cr\noalign{\hrule}
+&r1&&sp&&stack pointer&\cr\noalign{\hrule}
+&r2&&NA&&global pointer to the Small&\cr
+&&&&&Constant Area (SDA2)&\cr\noalign{\hrule}
+&r3 - r12&&NA&&parameter and result passing&\cr\noalign{\hrule}
+&r13&&NA&&global pointer to the Small&\cr
+&&&&&Data Area (SDA2)&\cr\noalign{\hrule}
 }}\hfil}
 @end tex
 @end ifset
@@ -130,18 +131,18 @@ The following table describes the role of each of these registers:
 <TR><TD ALIGN=center><STRONG>Register Name</STRONG></TD>
     <TD ALIGN=center><STRONG>Alternate Name</STRONG></TD>
     <TD ALIGN=center><STRONG>Description</STRONG></TD></TR>
-<TR><TD ALIGN=center>g0</TD>
-    <TD ALIGN=center>NA</TD>
-    <TD ALIGN=center>reads return 0 ; writes are ignored</TD></TR>
-<TR><TD ALIGN=center>o6</TD>
+<TR><TD ALIGN=center>r1</TD>
     <TD ALIGN=center>sp</TD>
     <TD ALIGN=center>stack pointer</TD></TR>
-<TR><TD ALIGN=center>i6</TD>
-    <TD ALIGN=center>fp</TD>
-    <TD ALIGN=center>frame pointer</TD></TR>
-<TR><TD ALIGN=center>i7</TD>
+<TR><TD ALIGN=center>r2</TD>
+    <TD ALIGN=center>na</TD>
+    <TD ALIGN=center>global pointer to the Small Constant Area (SDA2)</TD></TR>
+<TR><TD ALIGN=center>r3 - r12</TD>
     <TD ALIGN=center>NA</TD>
-    <TD ALIGN=center>return address</TD></TR>
+    <TD ALIGN=center>parameter and result passing</TD></TR>
+<TR><TD ALIGN=center>r13</TD>
+    <TD ALIGN=center>NA</TD>
+    <TD ALIGN=center>global pointer to the Small Data Area (SDA)</TD></TR>
   </TABLE>
 </CENTER>
 @end html
@@ -149,13 +150,13 @@ The following table describes the role of each of these registers:
 
 
 @ifinfo
-@node Floating Point Registers, Special Registers, Non-Floating Point Registers, Calling Conventions Programming Model
+@node Calling Conventions Floating Point Registers, Calling Conventions Special Registers, Calling Conventions Non-Floating Point Registers, Calling Conventions Programming Model
 @end ifinfo
 @subsection Floating Point Registers
 
-The PowerPC architecture includes thirty-two,
-sixty-four bit registers.  All PowwerPC floating point instructions 
-interprete these registers as 32 double precision floating point registers,
+The PowerPC architecture includes thirty-two, sixty-four bit
+floating point registers.  All PowerPC floating point instructions 
+interpret these registers as 32 double precision floating point registers,
 regardless of whether the processor has 64-bit or 32-bit implementation.
 
 The floating point status and control register (fpscr) records exceptions
@@ -163,159 +164,66 @@ and the type of result generated by floating-point operations.
 Additionally, it controls the rounding mode of operations and allows the
 reporting of floating exceptions to be enabled or disabled.
 
-XXXXXX
-A queue of the floating point instructions which have
-started execution but not yet completed is maintained.  This
-queue is needed to support the multiple cycle nature of floating
-point operations and to aid floating point exception trap
-handlers.  Once a floating point exception has been encountered,
-the queue is frozen until it is emptied by the trap handler.
-The floating point queue is loaded by launching instructions.
-It is emptied normally when the floating point completes all
-outstanding instructions and by floating point exception
-handlers with the store double floating point queue (stdfq)
-instruction.
-XXX
-
 @ifinfo
-@node Special Registers, Calling Conventions Register Windows, Floating Point Registers, Calling Conventions Programming Model
+@node Calling Conventions Special Registers, Calling Conventions Call and Return Mechanism, Calling Conventions Floating Point Registers, Calling Conventions Programming Model
 @end ifinfo
 @subsection Special Registers
 
-The PowerPC architecture includes XXX special registers
-which are critical to the programming model: the Machine State
-Register (msr) and XXX the Window Invalid Mask (wim) XXX.  The msr
-contains the processor mode, power management mode, endian mode, exception
-information, privlige level, floating point available and floating point 
-excepiton mode, address translation information and the exception prefix.
-
-XXX
-condition codes, processor interrupt level, trap
-enable bit, supervisor mode and previous supervisor mode bits,
-version information, floating point unit and coprocessor enable
-bits, and the current window pointer (cwp).  The cwp field of
-the psr and wim register are used to manage the register windows
-in the SPARC architecture.  The register windows are discussed
-in more detail below.
-XXX
+The PowerPC architecture includes a number of special registers
+which are critical to the programming model:
 
-@ifinfo
-@node Calling Conventions Register Windows, Calling Conventions Call and Return Mechanism, Special Registers, Calling Conventions
-@end ifinfo
-@section Register Windows
-
-The SPARC architecture includes the concept of
-register windows.  An overly simplistic way to think of these
-windows is to imagine them as being an infinite supply of
-"fresh" register sets available for each subroutine to use.  In
-reality, they are much more complicated.
-
-The save instruction is used to obtain a new register
-window.  This instruction decrements the current window pointer,
-thus providing a new set of registers for use.  This register
-set includes eight fresh local registers for use exclusively by
-this subroutine.  When done with a register set, the restore
-instruction increments the current window pointer and the
-previous register set is once again available.
-
-The two primary issues complicating the use of
-register windows are that (1) the set of register windows is
-finite, and (2) some registers are shared between adjacent
-registers windows.
-
-Because the set of register windows is finite, it is
-possible to execute enough save instructions without
-corresponding restore's to consume all of the register windows.
-This is easily accomplished in a high level language because
-each subroutine typically performs a save instruction upon
-entry.  Thus having a subroutine call depth greater than the
-number of register windows will result in a window overflow
-condition.  The window overflow condition generates a trap which
-must be handled in software.  The window overflow trap handler
-is responsible for saving the contents of the oldest register
-window on the program stack.
-
-Similarly, the subroutines will eventually complete
-and begin to perform restore's.  If the restore results in the
-need for a register window which has previously been written to
-memory as part of an overflow, then a window underflow condition
-results.  Just like the window overflow, the window underflow
-condition must be handled in software by a trap handler.  The
-window underflow trap handler is responsible for reloading the
-contents of the register window requested by the restore
-instruction from the program stack.
-
-The Window Invalid Mask (wim) and the Current Window
-Pointer (cwp) field in the psr are used in conjunction to manage
-the finite set of register windows and detect the window
-overflow and underflow conditions.  The cwp contains the index
-of the register window currently in use.  The save instruction
-decrements the cwp modulo the number of register windows.
-Similarly, the restore instruction increments the cwp modulo the
-number of register windows.  Each bit in the  wim represents
-represents whether a register window contains valid information.
-The value of 0 indicates the register window is valid and 1
-indicates it is invalid.  When a save instruction causes the cwp
-to point to a register window which is marked as invalid, a
-window overflow condition results.  Conversely, the restore
-instruction may result in a window underflow condition.
-
-Other than the assumption that a register window is
-always available for trap (i.e. interrupt) handlers, the SPARC
-architecture places no limits on the number of register windows
-simultaneously marked as invalid (i.e. number of bits set in the
-wim).  However, RTEMS assumes that only one register window is
-marked invalid at a time (i.e. only one bit set in the wim).
-This makes the maximum possible number of register windows
-available to the user while still meeting the requirement that
-window overflow and underflow conditions can be detected.
-
-The window overflow and window underflow trap
-handlers are a critical part of the run-time environment for a
-SPARC application.  The SPARC architectural specification allows
-for the number of register windows to be any power of two less
-than or equal to 32.  The most common choice for SPARC
-implementations appears to be 8 register windows.  This results
-in the cwp ranging in value from 0 to 7 on most implementations.
-
-
-The second complicating factor is the sharing of
-registers between adjacent register windows.  While each
-register window has its own set of local registers, the input
-and output registers are shared between adjacent windows.  The
-output registers for register window N are the same as the input
-registers for register window ((N - 1) modulo RW) where RW is
-the number of register windows.  An alternative way to think of
-this is to remember how parameters are passed to a subroutine on
-the SPARC.  The caller loads values into what are its output
-registers.  Then after the callee executes a save instruction,
-those parameters are available in its input registers.  This is
-a very efficient way to pass parameters as no data is actually
-moved by the save or restore instructions.
+@table @b
+
+@item Machine State Register
+
+The MSR contains the processor mode, power management mode, endian mode,
+exception information, privilege level, floating point available and
+floating point excepiton mode, address translation information and
+the exception prefix.
+
+@item Link Register
+
+The LR contains the return address after a function call.  This register
+must be saved before a subsequent subroutine call can be made.  The
+use of this register is discussed further in the @b{Call and Return
+Mechanism} section below.
+
+@item Count Register
+
+The CTR contains the iteration variable for some loops.  It may also be used
+for indirect function calls and jumps.
+
+@end table
 
 @ifinfo
-@node Calling Conventions Call and Return Mechanism, Calling Conventions Calling Mechanism, Calling Conventions Register Windows, Calling Conventions
+@node Calling Conventions Call and Return Mechanism, Calling Conventions Calling Mechanism, Calling Conventions Special Registers, Calling Conventions
 @end ifinfo
 @section Call and Return Mechanism
 
-The SPARC architecture supports a simple yet
-effective call and return mechanism.  A subroutine is invoked
-via the call (call) instruction.  This instruction places the
-return address in the caller's output register 7 (o7).  After
-the callee executes a save instruction, this value is available
-in input register 7 (i7) until the corresponding restore
-instruction is executed.
-
-The callee returns to the caller via a jmp to the
-return address.  There is a delay slot following this
-instruction which is commonly used to execute a restore
-instruction -- if a register window was allocated by this
-subroutine.
-
-It is important to note that the SPARC subroutine
+The PowerPC architecture supports a simple yet effective call
+and return mechanism.  A subroutine is invoked
+via the "branch and link" (@code{bl}) and
+"brank and link absolute" (@code{bla})
+instructions.  This instructions place the return address
+in the Link Register (LR).  The callee returns to the caller by 
+executing a "branch unconditional to the link register" (@code{blr})
+instruction.  Thus the callee returns to the caller via a jump
+to the return address which is stored in the LR.
+
+The previous contents of the LR are not automatically saved 
+by either the @code{bl} or @code{bla}.  It is the responsibility
+of the callee to save the contents of the LR before invoking
+another subroutine.  If the callee invokes another subroutine,
+it must restore the LR before executing the @code{blr} instruction
+to return to the caller.
+
+It is important to note that the PowerPC subroutine
 call and return mechanism does not automatically save and
-restore any registers.  This is accomplished via the save and
-restore instructions which manage the set of registers windows.
+restore any registers.
+
+The LR may be accessed as special purpose register 8 (@code{SPR8}) using the
+"move from special register" (@code{mfspr}) and
+"move to special register" (@code{mtspr}) instructions.
 
 @ifinfo
 @node Calling Conventions Calling Mechanism, Calling Conventions Register Usage, Calling Conventions Call and Return Mechanism, Calling Conventions
@@ -323,7 +231,8 @@ restore instructions which manage the set of registers windows.
 @section Calling Mechanism
 
 All RTEMS directives are invoked using the regular
-SPARC calling convention via the call instruction.
+PowerPC EABI calling convention via the @code{bl} or
+@code{bla} instructions.
 
 @ifinfo
 @node Calling Conventions Register Usage, Calling Conventions Parameter Passing, Calling Conventions Calling Mechanism, Calling Conventions
@@ -331,11 +240,11 @@ SPARC calling convention via the call instruction.
 @section Register Usage
 
 As discussed above, the call instruction does not
-automatically save any registers.  The save and restore
-instructions are used to allocate and deallocate register
-windows.  When a register window is allocated, the new set of
-local registers are available for the exclusive use of the
-subroutine which allocated this register set.
+automatically save any registers.  It is the responsibility
+of the callee to save and restore any registers which must be preserved
+across subroutine calls.  The callee is responsible for saving 
+callee-preserved registers to the program stack and restoring them
+before returning to the caller.
 
 @ifinfo
 @node Calling Conventions Parameter Passing, Calling Conventions User-Provided Routines, Calling Conventions Register Usage, Calling Conventions
@@ -343,19 +252,19 @@ subroutine which allocated this register set.
 @section Parameter Passing
 
 RTEMS assumes that arguments are placed in the
-caller's output registers with the first argument in output
-register 0 (o0), the second argument in output register 1 (o1),
-and so forth.  Until the callee executes a save instruction, the
-parameters are still visible in the output registers.  After the
-callee executes a save instruction, the parameters are visible
-in the corresponding input registers.  The following pseudo-code
+general purpose registers with the first argument in 
+register 3 (@code{r3}), the second argument in general purpose
+register 4 (@code{r4}), and so forth until the seventh
+argument is in general purpose register 10 (@code{r10}).  
+If there are more than seven arguments, then subsequent arguments
+are placed on the program stack.  The following pseudo-code
 illustrates the typical sequence used to call a RTEMS directive
 with three (3) arguments:
 
 @example
-load third argument into o2
-load second argument into o1
-load first argument into o0
+load third argument into r5
+load second argument into r4
+load first argument into r3
 invoke directive
 @end example
 
@@ -366,7 +275,6 @@ invoke directive
 
 All user-provided routines invoked by RTEMS, such as
 user extensions, device drivers, and MPCI routines, must also
-adhere to these calling conventions.
-
+adhere to these same calling conventions.
 
 
diff --git a/doc/supplements/powerpc/cpumodel.t b/doc/supplements/powerpc/cpumodel.t
index fd7280d981..a56cc1fd76 100644
--- a/doc/supplements/powerpc/cpumodel.t
+++ b/doc/supplements/powerpc/cpumodel.t
@@ -14,7 +14,6 @@
 @menu
 * CPU Model Dependent Features Introduction::
 * CPU Model Dependent Features CPU Model Feature Flags::
-* CPU Model Dependent Features CPU Model Implementation Notes::
 @end menu
 @end ifinfo
 
@@ -55,7 +54,6 @@ across the entire family.
 * CPU Model Dependent Features Maximum Interrupts::
 * 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 Use Multiword Load/Store Instructions::
 * CPU Model Dependent Features Instruction Cache Size::
 * CPU Model Dependent Features Data Cache Size::
@@ -146,7 +144,7 @@ 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
+@node CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
 @subsection Critical Interrupts
 
@@ -154,14 +152,7 @@ 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 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_INITIAL 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 MSR 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 Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
 @subsection Use Multiword Load/Store Instructions
 
@@ -190,42 +181,43 @@ The macro PPC_D_CACHE is set to the size in bytes of the data cache.
 @end ifinfo
 @subsection Debug Model
 
-The macro PPC_DEBUG_MODEL
+The macro PPC_DEBUG_MODEL is set to indicate the debug support features 
+present in this CPU model.  The following debug support feature sets
+are currently supported:
 
 @table @b
 
 @item @code{PPC_DEBUG_MODEL_STANDARD}
-indicates XXX
+indicates that the single-step trace enable (SE) and branch trace
+enable (BE) bits in the MSR are supported by this CPU model.
 
 @item @code{PPC_DEBUG_MODEL_SINGLE_STEP_ONLY}
-indicates XXX
+indicates that only the single-step trace enable (SE) bit in the MSR
+is supported by this CPU model. 
 
 @item @code{PPC_DEBUG_MODEL_IBM4xx}
-indicates XXX
+indicates that the debug exception enable (DE) bit in the MSR is supported
+by this CPU model.  At this time, this particular debug feature set 
+has only been seen in the IBM 4xx series.
 
 @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
+@node CPU Model Dependent Features Low Power Model, Calling Conventions, 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
+The macro PPC_LOW_POWER_MODE is set to indicate the low power model
+supported by this CPU model.  The following low power modes are currently
+supported.
 
 @table @b
 
 @item @code{PPC_LOW_POWER_MODE_NONE}
-indicates XXX
+indicates that this CPU model has no low power mode support.
 
 @item @code{PPC_LOW_POWER_MODE_STANDARD}
-indicates XXX
+indicates that this CPU model follows the low power model defined for
+the PPC603e.
 
 @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 
-
-TBD
diff --git a/doc/supplements/powerpc/cpumodel.texi b/doc/supplements/powerpc/cpumodel.texi
index fd7280d981..a56cc1fd76 100644
--- a/doc/supplements/powerpc/cpumodel.texi
+++ b/doc/supplements/powerpc/cpumodel.texi
@@ -14,7 +14,6 @@
 @menu
 * CPU Model Dependent Features Introduction::
 * CPU Model Dependent Features CPU Model Feature Flags::
-* CPU Model Dependent Features CPU Model Implementation Notes::
 @end menu
 @end ifinfo
 
@@ -55,7 +54,6 @@ across the entire family.
 * CPU Model Dependent Features Maximum Interrupts::
 * 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 Use Multiword Load/Store Instructions::
 * CPU Model Dependent Features Instruction Cache Size::
 * CPU Model Dependent Features Data Cache Size::
@@ -146,7 +144,7 @@ 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
+@node CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
 @subsection Critical Interrupts
 
@@ -154,14 +152,7 @@ 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 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_INITIAL 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 MSR 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 Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
 @subsection Use Multiword Load/Store Instructions
 
@@ -190,42 +181,43 @@ The macro PPC_D_CACHE is set to the size in bytes of the data cache.
 @end ifinfo
 @subsection Debug Model
 
-The macro PPC_DEBUG_MODEL
+The macro PPC_DEBUG_MODEL is set to indicate the debug support features 
+present in this CPU model.  The following debug support feature sets
+are currently supported:
 
 @table @b
 
 @item @code{PPC_DEBUG_MODEL_STANDARD}
-indicates XXX
+indicates that the single-step trace enable (SE) and branch trace
+enable (BE) bits in the MSR are supported by this CPU model.
 
 @item @code{PPC_DEBUG_MODEL_SINGLE_STEP_ONLY}
-indicates XXX
+indicates that only the single-step trace enable (SE) bit in the MSR
+is supported by this CPU model. 
 
 @item @code{PPC_DEBUG_MODEL_IBM4xx}
-indicates XXX
+indicates that the debug exception enable (DE) bit in the MSR is supported
+by this CPU model.  At this time, this particular debug feature set 
+has only been seen in the IBM 4xx series.
 
 @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
+@node CPU Model Dependent Features Low Power Model, Calling Conventions, 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
+The macro PPC_LOW_POWER_MODE is set to indicate the low power model
+supported by this CPU model.  The following low power modes are currently
+supported.
 
 @table @b
 
 @item @code{PPC_LOW_POWER_MODE_NONE}
-indicates XXX
+indicates that this CPU model has no low power mode support.
 
 @item @code{PPC_LOW_POWER_MODE_STANDARD}
-indicates XXX
+indicates that this CPU model follows the low power model defined for
+the PPC603e.
 
 @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 
-
-TBD
diff --git a/doc/supplements/powerpc/cputable.t b/doc/supplements/powerpc/cputable.t
index 013a76b7dd..5e4ebd9c83 100644
--- a/doc/supplements/powerpc/cputable.t
+++ b/doc/supplements/powerpc/cputable.t
@@ -50,18 +50,19 @@ typedef struct @{
   void       (*stack_free_hook)( void* );
   /* end of fields required on all CPUs */
 
-  unsigned32   clicks_per_usec; /* Timer clicks per microsecond */
+  unsigned32   clicks_per_usec;       /* Timer clicks per microsecond */
   void       (*spurious_handler)(unsigned32 vector, CPU_Interrupt_frame *);
   boolean      exceptions_in_RAM;     /* TRUE if in RAM */
-  unsigned32   serial_per_sec;  /* Serial clocks per second */
+
+#if defined(ppc403)
+  unsigned32   serial_per_sec;        /* Serial clocks per second */
   boolean      serial_external_clock;
   boolean      serial_xon_xoff;
   boolean      serial_cts_rts;
   unsigned32   serial_rate;
-  unsigned32   timer_average_overhead; /* Average overhead of timer in ticks */
-  unsigned32   timer_least_valid; /* Least valid number from timer */
-  void (*spurious_handler)(unsigned32 vector, CPU_Interrupt_frame *);
-
+  unsigned32   timer_average_overhead; /* in ticks */
+  unsigned32   timer_least_valid;      /* Least valid number from timer */
+#endif
 @};
 @end example
 
@@ -132,31 +133,33 @@ they are located in RAM dynamic vector installation occurs, otherwise
 it does not.
 
 @item serial_per_sec
-is the number of clock ticks per second for the PPC403 serial timer.
+is a PPC403 specific field which specifies the number of clock
+ticks per second for the PPC403 serial timer.
 
 @item serial_rate
-is the baud rate for the PPC403 serial timer.
+is a PPC403 specific field which specifies the baud rate for the
+PPC403 serial port.
 
 @item serial_external_clock
-is a flag used by the BSP to indicate whether or not to mask in a 0x2 into
+is a PPC403 specific field which indicates whether or not to mask in a 0x2 into
 the Input/Output Configuration Register (IOCR) during initialization of the
-PPC403 console.  XXX This bit is defined as "reserved" 6-12?
+PPC403 console.  (NOTE: This bit is defined as "reserved" 6-12?)
 
 @item serial_xon_xoff
-is a flag used by the BSP to indicate whether or not  XON/XOFF flow control 
-is supported for the PPC403 serial timer.
+is a PPC403 specific field which indicates whether or not
+XON/XOFF flow control is supported for the PPC403 serial port.
 
 @item serial_cts_rts
-is a flag used by the BSP to indicate whether or not to set the lsb of the 
-Input/Output Configuration Register (IOCR) during initialization of the
-PPC403 console.  XXX This bit is defined as "reserved" 6-12?
-
+is a PPC403 specific field which indicates whether or not to set the 
+least significant bit of the Input/Output Configuration Register
+(IOCR) during initialization of the PPC403 console.  (NOTE: This
+bit is defined as "reserved" 6-12?)
 
 @item timer_average_overhead
-is the average number of overhead ticks that occur on the PPC403 timer.
+is a PPC403 specific field which specifies the average number of overhead ticks that occur on the PPC403 timer.
 
 @item timer_least_valid
-is the maximum valid PPC403 timer value.
+is a PPC403 specific field which specifies the maximum valid PPC403 timer value.
 
 @end table
 
diff --git a/doc/supplements/powerpc/cputable.texi b/doc/supplements/powerpc/cputable.texi
index 013a76b7dd..5e4ebd9c83 100644
--- a/doc/supplements/powerpc/cputable.texi
+++ b/doc/supplements/powerpc/cputable.texi
@@ -50,18 +50,19 @@ typedef struct @{
   void       (*stack_free_hook)( void* );
   /* end of fields required on all CPUs */
 
-  unsigned32   clicks_per_usec; /* Timer clicks per microsecond */
+  unsigned32   clicks_per_usec;       /* Timer clicks per microsecond */
   void       (*spurious_handler)(unsigned32 vector, CPU_Interrupt_frame *);
   boolean      exceptions_in_RAM;     /* TRUE if in RAM */
-  unsigned32   serial_per_sec;  /* Serial clocks per second */
+
+#if defined(ppc403)
+  unsigned32   serial_per_sec;        /* Serial clocks per second */
   boolean      serial_external_clock;
   boolean      serial_xon_xoff;
   boolean      serial_cts_rts;
   unsigned32   serial_rate;
-  unsigned32   timer_average_overhead; /* Average overhead of timer in ticks */
-  unsigned32   timer_least_valid; /* Least valid number from timer */
-  void (*spurious_handler)(unsigned32 vector, CPU_Interrupt_frame *);
-
+  unsigned32   timer_average_overhead; /* in ticks */
+  unsigned32   timer_least_valid;      /* Least valid number from timer */
+#endif
 @};
 @end example
 
@@ -132,31 +133,33 @@ they are located in RAM dynamic vector installation occurs, otherwise
 it does not.
 
 @item serial_per_sec
-is the number of clock ticks per second for the PPC403 serial timer.
+is a PPC403 specific field which specifies the number of clock
+ticks per second for the PPC403 serial timer.
 
 @item serial_rate
-is the baud rate for the PPC403 serial timer.
+is a PPC403 specific field which specifies the baud rate for the
+PPC403 serial port.
 
 @item serial_external_clock
-is a flag used by the BSP to indicate whether or not to mask in a 0x2 into
+is a PPC403 specific field which indicates whether or not to mask in a 0x2 into
 the Input/Output Configuration Register (IOCR) during initialization of the
-PPC403 console.  XXX This bit is defined as "reserved" 6-12?
+PPC403 console.  (NOTE: This bit is defined as "reserved" 6-12?)
 
 @item serial_xon_xoff
-is a flag used by the BSP to indicate whether or not  XON/XOFF flow control 
-is supported for the PPC403 serial timer.
+is a PPC403 specific field which indicates whether or not
+XON/XOFF flow control is supported for the PPC403 serial port.
 
 @item serial_cts_rts
-is a flag used by the BSP to indicate whether or not to set the lsb of the 
-Input/Output Configuration Register (IOCR) during initialization of the
-PPC403 console.  XXX This bit is defined as "reserved" 6-12?
-
+is a PPC403 specific field which indicates whether or not to set the 
+least significant bit of the Input/Output Configuration Register
+(IOCR) during initialization of the PPC403 console.  (NOTE: This
+bit is defined as "reserved" 6-12?)
 
 @item timer_average_overhead
-is the average number of overhead ticks that occur on the PPC403 timer.
+is a PPC403 specific field which specifies the average number of overhead ticks that occur on the PPC403 timer.
 
 @item timer_least_valid
-is the maximum valid PPC403 timer value.
+is a PPC403 specific field which specifies the maximum valid PPC403 timer value.
 
 @end table
 
diff --git a/doc/supplements/powerpc/fatalerr.t b/doc/supplements/powerpc/fatalerr.t
index 6717f406cc..ab7281368c 100644
--- a/doc/supplements/powerpc/fatalerr.t
+++ b/doc/supplements/powerpc/fatalerr.t
@@ -38,9 +38,25 @@ handler.
 @section Default Fatal Error Handler Operations
 
 The default fatal error handler which is invoked by
-the fatal_error_occurred directive when there is no user handler
+the @code{rtems_fatal_error_occurred} directive when there is no user handler
 configured or the user handler returns control to RTEMS.  The
-default fatal error handler disables all processor exceptions,
-places the error code in r5, and goes into an infinite
-loop to simulate a halt processor instruction.
+default fatal error handler performs the following actions:
+
+@itemize @bullet
+
+@item places the error code in r3, and
+
+@item executes a trap instruction which results in a Program Exception.
+
+@end itemize
+
+If the Program Exception returns, then the following actions are performed:
+
+@itemize @bullet
+
+@item disables all processor exceptions by loading a 0 into the MSR, and
+
+@item goes into an infinite loop to simulate a halt processor instruction.
+
+@end itemize
 
diff --git a/doc/supplements/powerpc/fatalerr.texi b/doc/supplements/powerpc/fatalerr.texi
index 6717f406cc..ab7281368c 100644
--- a/doc/supplements/powerpc/fatalerr.texi
+++ b/doc/supplements/powerpc/fatalerr.texi
@@ -38,9 +38,25 @@ handler.
 @section Default Fatal Error Handler Operations
 
 The default fatal error handler which is invoked by
-the fatal_error_occurred directive when there is no user handler
+the @code{rtems_fatal_error_occurred} directive when there is no user handler
 configured or the user handler returns control to RTEMS.  The
-default fatal error handler disables all processor exceptions,
-places the error code in r5, and goes into an infinite
-loop to simulate a halt processor instruction.
+default fatal error handler performs the following actions:
+
+@itemize @bullet
+
+@item places the error code in r3, and
+
+@item executes a trap instruction which results in a Program Exception.
+
+@end itemize
+
+If the Program Exception returns, then the following actions are performed:
+
+@itemize @bullet
+
+@item disables all processor exceptions by loading a 0 into the MSR, and
+
+@item goes into an infinite loop to simulate a halt processor instruction.
+
+@end itemize
 
diff --git a/doc/supplements/powerpc/intr.t b/doc/supplements/powerpc/intr.t
index 08b22f8031..67213010aa 100644
--- a/doc/supplements/powerpc/intr.t
+++ b/doc/supplements/powerpc/intr.t
@@ -37,12 +37,12 @@ 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
+unique architecture. Discussed in this chapter are the PowerPC'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
+interrupt and vector.  In the PowerPC architecture, these terms
 correspond to exception and exception handler, respectively.  The terms will
 be used interchangeably in this manual.
 
@@ -51,7 +51,7 @@ be used interchangeably in this manual.
 @end ifinfo
 @section Synchronous Versus Asynchronous Exceptions
 
-In the PPC architecture exceptions can be either precise or 
+In the PowerPC 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 
@@ -77,7 +77,7 @@ exceptions conforms to the requirements for context synchronization.
 @end ifinfo
 @section Vectoring of Interrupt Handler
 
-Upon determining that an exception can be taken the PPC  automatically
+Upon determining that an exception can be taken the PowerPC automatically
 performs the following actions:
 
 @itemize @bullet
@@ -95,7 +95,6 @@ bits from the MSR.
 
 @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
@@ -104,8 +103,9 @@ 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 saves all registers which are not normally preserved
+by the calling sequence so the user's interrupt service
+routine can be written in a high-level language.
 
 @item if this is the outermost (i.e. non-nested) interrupt,
 then the RTEMS interrupt handler switches from the current stack
@@ -117,7 +117,7 @@ to the interrupt stack,
 @end itemize
 
 Asynchronous interrupts are ignored while exceptions are
-disabled.  Synchronous interrupts which occur while  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
@@ -129,16 +129,39 @@ interrupt stack.
 @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.
+The PowerPC architecture supports only a single external
+asynchronous interrupt source.  This interrupt source
+may be enabled and disabled via the External Interrupt Enable (EE)
+bit in the Machine State Register (MSR).  Thus only two level (enabled
+and disabled) of external device interrupt priorities are 
+directly supported by the PowerPC architecture.  
+
+Some PowerPC implementations include a Critical Interrupt capability
+which is often used to receive interrupts from high priority external
+devices.
+
+The RTEMS interrupt level mapping scheme for the PowerPC is not 
+a numeric level as on most RTEMS ports.  It is a bit mapping in
+which the least three significiant bits of the interrupt level
+are mapped directly to the enabling of specific interrupt 
+sources as follows:
+
+@table @b
+
+@item Critical Interrupt
+Setting bit 0 (the least significant bit) of the interrupt level
+enables the Critical Interrupt source, if it is available on this
+CPU model.
+
+@item Machine Check
+Setting bit 1 of the interrupt level enables Machine Check execptions.
+
+@item External Interrupt
+Setting bit 2 of the interrupt level enables External Interrupt execptions.
+
+@end table
 
-TBD
-All other RTEMS interrupt levels are undefined and their behavior is
-unpredictable.
+All other bits in the RTEMS task interrupt level are ignored.
 
 @ifinfo
 @node Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack, Interrupt Processing Interrupt Levels, Interrupt Processing
@@ -147,9 +170,9 @@ unpredictable.
 
 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
+encountered, RTEMS disables Critical Interrupts, External Interrupts
+and Machine Checks 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
@@ -159,17 +182,12 @@ states and processor speed present on the target board.
 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.
+If a PowerPC implementation provides non-maskable interrupts (NMI)
+which cannot be disabled, ISRs which process these interrupts
+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
diff --git a/doc/supplements/powerpc/intr_NOTIMES.t b/doc/supplements/powerpc/intr_NOTIMES.t
index 08b22f8031..67213010aa 100644
--- a/doc/supplements/powerpc/intr_NOTIMES.t
+++ b/doc/supplements/powerpc/intr_NOTIMES.t
@@ -37,12 +37,12 @@ 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
+unique architecture. Discussed in this chapter are the PowerPC'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
+interrupt and vector.  In the PowerPC architecture, these terms
 correspond to exception and exception handler, respectively.  The terms will
 be used interchangeably in this manual.
 
@@ -51,7 +51,7 @@ be used interchangeably in this manual.
 @end ifinfo
 @section Synchronous Versus Asynchronous Exceptions
 
-In the PPC architecture exceptions can be either precise or 
+In the PowerPC 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 
@@ -77,7 +77,7 @@ exceptions conforms to the requirements for context synchronization.
 @end ifinfo
 @section Vectoring of Interrupt Handler
 
-Upon determining that an exception can be taken the PPC  automatically
+Upon determining that an exception can be taken the PowerPC automatically
 performs the following actions:
 
 @itemize @bullet
@@ -95,7 +95,6 @@ bits from the MSR.
 
 @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
@@ -104,8 +103,9 @@ 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 saves all registers which are not normally preserved
+by the calling sequence so the user's interrupt service
+routine can be written in a high-level language.
 
 @item if this is the outermost (i.e. non-nested) interrupt,
 then the RTEMS interrupt handler switches from the current stack
@@ -117,7 +117,7 @@ to the interrupt stack,
 @end itemize
 
 Asynchronous interrupts are ignored while exceptions are
-disabled.  Synchronous interrupts which occur while  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
@@ -129,16 +129,39 @@ interrupt stack.
 @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.
+The PowerPC architecture supports only a single external
+asynchronous interrupt source.  This interrupt source
+may be enabled and disabled via the External Interrupt Enable (EE)
+bit in the Machine State Register (MSR).  Thus only two level (enabled
+and disabled) of external device interrupt priorities are 
+directly supported by the PowerPC architecture.  
+
+Some PowerPC implementations include a Critical Interrupt capability
+which is often used to receive interrupts from high priority external
+devices.
+
+The RTEMS interrupt level mapping scheme for the PowerPC is not 
+a numeric level as on most RTEMS ports.  It is a bit mapping in
+which the least three significiant bits of the interrupt level
+are mapped directly to the enabling of specific interrupt 
+sources as follows:
+
+@table @b
+
+@item Critical Interrupt
+Setting bit 0 (the least significant bit) of the interrupt level
+enables the Critical Interrupt source, if it is available on this
+CPU model.
+
+@item Machine Check
+Setting bit 1 of the interrupt level enables Machine Check execptions.
+
+@item External Interrupt
+Setting bit 2 of the interrupt level enables External Interrupt execptions.
+
+@end table
 
-TBD
-All other RTEMS interrupt levels are undefined and their behavior is
-unpredictable.
+All other bits in the RTEMS task interrupt level are ignored.
 
 @ifinfo
 @node Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack, Interrupt Processing Interrupt Levels, Interrupt Processing
@@ -147,9 +170,9 @@ unpredictable.
 
 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
+encountered, RTEMS disables Critical Interrupts, External Interrupts
+and Machine Checks 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
@@ -159,17 +182,12 @@ states and processor speed present on the target board.
 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.
+If a PowerPC implementation provides non-maskable interrupts (NMI)
+which cannot be disabled, ISRs which process these interrupts
+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
diff --git a/doc/supplements/powerpc/memmodel.t b/doc/supplements/powerpc/memmodel.t
index 90199dc5bc..1e248d478e 100644
--- a/doc/supplements/powerpc/memmodel.t
+++ b/doc/supplements/powerpc/memmodel.t
@@ -41,7 +41,7 @@ RTEMS supports the PowerPC using a flat memory model with
 paging disabled.  In this mode, the PowerPC automatically
 converts every address from a logical to a physical address
 each time it is used.  The PowerPC uses information provided
-in the XXX to convert these addresses.
+in the Block Address Translation (BAT) to convert these addresses.
 
 Implementations of the PowerPC architecture may be thirty-two or sixty-four bit.
 The PowerPC architecture supports a flat thirty-two or sixty-four bit address
@@ -119,7 +119,7 @@ of data accesses:
 Doubleword load and store operations are only available in 
 PowerPC CPU models which are sixty-four bit implementations.
 
-RTEMS does not directly support any PowerPC  Memory Management
+RTEMS does not directly support any PowerPC Memory Management
 Units, therefore, virtual memory or segmentation systems
 involving the PowerPC  are not supported.
 
diff --git a/doc/supplements/powerpc/memmodel.texi b/doc/supplements/powerpc/memmodel.texi
index 90199dc5bc..1e248d478e 100644
--- a/doc/supplements/powerpc/memmodel.texi
+++ b/doc/supplements/powerpc/memmodel.texi
@@ -41,7 +41,7 @@ RTEMS supports the PowerPC using a flat memory model with
 paging disabled.  In this mode, the PowerPC automatically
 converts every address from a logical to a physical address
 each time it is used.  The PowerPC uses information provided
-in the XXX to convert these addresses.
+in the Block Address Translation (BAT) to convert these addresses.
 
 Implementations of the PowerPC architecture may be thirty-two or sixty-four bit.
 The PowerPC architecture supports a flat thirty-two or sixty-four bit address
@@ -119,7 +119,7 @@ of data accesses:
 Doubleword load and store operations are only available in 
 PowerPC CPU models which are sixty-four bit implementations.
 
-RTEMS does not directly support any PowerPC  Memory Management
+RTEMS does not directly support any PowerPC Memory Management
 Units, therefore, virtual memory or segmentation systems
 involving the PowerPC  are not supported.
 
diff --git a/doc/supplements/powerpc/preface.texi b/doc/supplements/powerpc/preface.texi
index e55a98816a..e898c3d8dd 100644
--- a/doc/supplements/powerpc/preface.texi
+++ b/doc/supplements/powerpc/preface.texi
@@ -33,13 +33,48 @@ corresponds to that processor.
 @subheading PowerPC Architecture Documents
 
 For information on the PowerPC architecture, refer to
-the following documents available from Motorola
-(http://www.moto.com):
+the following documents available from Motorola and IBM:
 
 @itemize @bullet
-@item some PowerPC document shere
+
+@item @cite{PowerPC Microprocessor Family: The Programming Environment}
+(Motorola Document MPRPPCFPE-01).
+
+@item @cite{IBM PPC403GB Embedded Controller User's Manual}.
+
+@item @cite{PoweRisControl MPC500 Family RCPU RISC Central Processing
+Unit Reference Manual} (Motorola Document RCPUURM/AD).
+
+@item @cite{PowerPC 601 RISC Microprocessor User's Manual}
+(Motorola Document MPR601UM/AD).
+
+@item @cite{PowerPC 603 RISC Microprocessor User's Manual}
+(Motorola Document MPR603UM/AD).
+
+@item @cite{PowerPC 603e RISC Microprocessor User's Manual}
+(Motorola Document MPR603EUM/AD).
+
+@item @cite{PowerPC 604 RISC Microprocessor User's Manual}
+(Motorola Document MPR604UM/AD).
+
+@item @cite{PowerPC MPC821 Portable Systems Microprocessor User's Manual}
+(Motorola Document MPC821UM/AD).
+
+@item @cite{PowerQUICC MPC860 User's Manual} (Motorola Document MPC860UM/AD).
+
+
 @end itemize
 
+Motorola maintains an on-line electronic library for the PowerPC
+at the following URL:
+
+@itemize @code{ }
+@item @cite{http://www.mot.com/powerpc/library/library.html}
+@end itemize
+
+This site has a a wealth of information and examples.  Many of the
+manuals are available from that site in electronic format.
+
 @subheading PowerPC Processor Simulator Information
 
 PSIM is a program which emulates the Instruction Set Architecture
diff --git a/doc/supplements/sparc/bsp.t b/doc/supplements/sparc/bsp.t
index 727941b777..6930065cab 100644
--- a/doc/supplements/sparc/bsp.t
+++ b/doc/supplements/sparc/bsp.t
@@ -70,7 +70,7 @@ management.  However, interrupts should be disabled by setting
 the Processor Interrupt Level (pil) field of the psr to 15.
 RTEMS installs it's own Trap Table as part of initialization
 which is initialized with the contents of the Trap Table in
-place when the rtems_initialize_executive directive was invoked.
+place when the @code{rtems_initialize_executive} directive was invoked.
 Upon completion of executive initialization, interrupts are
 enabled.
 
@@ -82,7 +82,7 @@ In addition to the requirements described in the
 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
+@code{rtems_initialize_executive}, the SPARC version has the following
 specific requirements:
 
 @itemize @bullet
@@ -91,7 +91,7 @@ the SPARC remains in the supervisor state.
 
 @item Must set stack pointer (sp) such that a minimum stack
 size of MINIMUM_STACK_SIZE bytes is provided for the
-rtems_initialize executive directive.
+@code{rtems_initialize_executive} directive.
 
 @item Must disable all external interrupts (i.e. set the pil
 to 15).
diff --git a/doc/supplements/sparc/bsp.texi b/doc/supplements/sparc/bsp.texi
index 727941b777..6930065cab 100644
--- a/doc/supplements/sparc/bsp.texi
+++ b/doc/supplements/sparc/bsp.texi
@@ -70,7 +70,7 @@ management.  However, interrupts should be disabled by setting
 the Processor Interrupt Level (pil) field of the psr to 15.
 RTEMS installs it's own Trap Table as part of initialization
 which is initialized with the contents of the Trap Table in
-place when the rtems_initialize_executive directive was invoked.
+place when the @code{rtems_initialize_executive} directive was invoked.
 Upon completion of executive initialization, interrupts are
 enabled.
 
@@ -82,7 +82,7 @@ In addition to the requirements described in the
 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
+@code{rtems_initialize_executive}, the SPARC version has the following
 specific requirements:
 
 @itemize @bullet
@@ -91,7 +91,7 @@ the SPARC remains in the supervisor state.
 
 @item Must set stack pointer (sp) such that a minimum stack
 size of MINIMUM_STACK_SIZE bytes is provided for the
-rtems_initialize executive directive.
+@code{rtems_initialize_executive} directive.
 
 @item Must disable all external interrupts (i.e. set the pil
 to 15).