2008-08-22 Joel Sherrill <joel.sherrill@oarcorp.com>

	* bsp_howto/Makefile.am, bsp_howto/init.t, bsp_howto/intro.t,
	bsp_howto/makefiles.t, bsp_howto/support.t: Update initialization
	sequence. Add another figure.
	* bsp_howto/BSPInitFlowchart-49.eps, bsp_howto/BSPInitFlowchart-49.png: New files.

8 files changed, 256 insertions, 140 deletions

diff --git a/doc/ChangeLog b/doc/ChangeLog
index cfe45bdc6b..39f60f9867 100644
--- a/doc/ChangeLog
+++ b/doc/ChangeLog
@@ -1,3 +1,10 @@
+2008-08-22	Joel Sherrill <joel.sherrill@oarcorp.com>
+
+	* bsp_howto/Makefile.am, bsp_howto/init.t, bsp_howto/intro.t,
+	bsp_howto/makefiles.t, bsp_howto/support.t: Update initialization
+	sequence. Add another figure.
+	* bsp_howto/BSPInitFlowchart-49.eps, bsp_howto/BSPInitFlowchart-49.png: New files.
+
 2008-08-21	Joel Sherrill <joel.sherrill@oarcorp.com>
 
 	* index.html.in: Reorder manuals.
diff --git a/doc/bsp_howto/BSPInitFlowchart-49.eps b/doc/bsp_howto/BSPInitFlowchart-49.eps
new file mode 100644
index 0000000000..b856353d05
--- /dev/null
+++ b/doc/bsp_howto/BSPInitFlowchart-49.eps
diff --git a/doc/bsp_howto/BSPInitFlowchart-49.png b/doc/bsp_howto/BSPInitFlowchart-49.png
new file mode 100644
index 0000000000..da51714415
--- /dev/null
+++ b/doc/bsp_howto/BSPInitFlowchart-49.png
diff --git a/doc/bsp_howto/Makefile.am b/doc/bsp_howto/Makefile.am
index d0d0f6784c..07d511957b 100644
--- a/doc/bsp_howto/Makefile.am
+++ b/doc/bsp_howto/Makefile.am
@@ -19,7 +19,7 @@ GENERATED_FILES = intro.texi target.texi makefiles.texi linkcmds.texi \
 
 COMMON_FILES += $(top_srcdir)/common/cpright.texi
 
-PNG_FILES = Developer-User-Timeline.png
+PNG_FILES = Developer-User-Timeline.png BSPInitFlowchart-49.png
 
 if USE_HTML
 html_project_DATA += $(PNG_FILES)
diff --git a/doc/bsp_howto/init.t b/doc/bsp_howto/init.t
index 421c638056..6f9c902d0a 100644
--- a/doc/bsp_howto/init.t
+++ b/doc/bsp_howto/init.t
@@ -1,5 +1,5 @@
 @c
-@c  COPYRIGHT (c) 1988-2002.
+@c  COPYRIGHT (c) 1988-2008.
 @c  On-Line Applications Research Corporation (OAR).
 @c  All rights reserved.
 @c
@@ -18,62 +18,97 @@ commonly found in the BSP related to initialization.  The remainder of
 this chapter covers special issues which require attention such
 as interrupt vector table and chip select initialization.
 
-Most of the examples in this chapter will be based on the gen68340 BSP
-initialization code.  Like most BSPs, the initialization for this 
-BSP is divided into two subdirectories under the BSP source directory.
-The gen68340 BSP source code is in the following directory:
+Most of the examples in this chapter will be based on the SPARC/ERC32 and
+m68k/gen68340 BSP initialization code.  Like most BSPs, the initialization
+for these BSP is divided into two subdirectories under the BSP source
+directory.  The BSP source code for these BSPs is in the following
+directories:
 
 @example
 c/src/lib/libbsp/m68k/gen68340
+c/src/lib/libbsp/sparc/erc32
 @end example
 
-The following source code files are in this subdirectory.
-
-@itemize @bullet
-
-@item @code{start340}: assembly language code which contains early
-initialization routines
+Both BSPs contain startup code written in assembly language and C.
+The gen68340 BSP has its early initialization start code in the
+@code{start340} subdirectory and its C startup code in the @code{startup}
+directory.  In the @code{start340} directory are two source files.
+The file @code{startfor340only.s} is the simpler of these files as it only
+has initialization code for a MC68340 board.  The file @code{start340.s}
+contains initialization for a 68349 based board as well.
 
-@item @code{startup}: C code with higher level routines (RTEMS
-initialization related) 
+Similarly, the ERC32 BSP has startup code written in assembly language
+and C.  However, this BSP shares this code with other SPARC BSPs.
+Thus the @code{Makefile.am} explicitly references the following files
+for this functionality.
 
-@end itemize
+@example
+../../sparc/shared/start.S
+../../sparc/shared/bspclean.c
+@end example
 
-@b{NOTE:} The directory @code{start340} is simply named @code{start} or 
-start followed by a BSP designation.
-
-In the @code{start340} directory are two source files.  The file
-@code{startfor340only.s} is the simpler of these files as it only has 
-initialization code for a MC68340 board.  The file @code{start340.s}
-contains initialization for a 68349 based board as well.
+@b{NOTE:} In most BSPs, the directory named @code{start340} in the
+gen68340 BSP would be simply named @code{start} or start followed by a
+BSP designation.
 
 @section Required Global Variables
 
 Although not strictly part of initialization, there are a few global
-variables assumed to exist by many support components.  These 
-global variables are normally not defined by the BSP since the RTEMS
-Project strives to avoid duplication as much as possible.
-The following is a list of these global variables:
+variables assumed to exist by reusable device drivers.  These global
+variables should only defined by the BSP when using one of these device
+drivers.
 
-@itemize @bullet
-@item @code{Configuration} is the RTEMS Configuration Table generated
-by @code{<rtems/confdefs.h>}.
+The BSP author probably should be aware of the @code{Configuration}
+Table structure generated by @code{<rtems/confdefs.h>} during debug but
+should not explicitly reference it in the source code.  There are helper
+routines provided by RTEMS to access individual fields.
 
-@end itemize
+In older RTEMS versions, the BSP included a number of required global
+variables.  We have made every attempt to eliminate these in the interest
+of simplicity.
 
 @section Board Initialization
 
 This section describes the steps an application goes through from the
 time the first BSP code is executed until the first application task
-executes.  The routines invoked during this will be discussed and
-their location in the RTEMS source tree pointed out.
+executes.  The following figure illustrates the program flow during
+this sequence:
+
+@ifset use-ascii
+IMAGE NOT AVAILABLE IN ASCII VERSION
+@end ifset
+
+@ifset use-tex
+@image{BSPInitFlowchart-49,6in,,Initialization Sequence,.png}
+@c      @image{FILENAME[, WIDTH[, HEIGHT[, ALTTEXT[, EXTENSION]]]]}
+@end ifset
+
+@ifset use-html
+@html
+<center>
+<IMG SRC="BSPInitFlowchart-49.png" WIDTH=800 ALT="Initialization Sequence">
+</center>
+@end html
+@end ifset
+
+The above figure illustrates the flow from assembly language start code
+to the shared @code{bootcard.c} framework then through the C Library,
+RTEMS, device driver initialization phases, and the context switch
+to the first application task.  After this, the application executes
+until it calls @code{exit}, @code{rtems_shutdown_executive}, or some
+other normal termination initiating routine and control is returned
+to @code{bootcard.c} which allows the BSP to perform some clanup in C
+(@code{bsp_cleanup}) and then @code{boot_card} returns to the assembly
+language which initially invoked it.
+
+The routines invoked during this will be discussed and their location
+in the RTEMS source tree pointed out as we discuss each.
 
 @subsection Start Code - Assembly Language Initialization
 
-The assembly language code in the directory @code{start} is
-the first part of the application to execute.  It is 
-responsible for initializing the processor and board enough to execute
-the rest of the BSP.  This includes:
+The assembly language code in the directory @code{start} is the first part
+of the application to execute.  It is responsible for initializing the
+processor and board enough to execute the rest of the BSP.  This includes:
 
 @itemize @bullet
 @item initializing the stack
@@ -82,26 +117,28 @@ the rest of the BSP.  This includes:
 @item copy the initialized data from ROM to RAM
 @end itemize
 
-The general rule of thumb is that the
-start code in assembly should do the minimum necessary to allow C code
-to execute to complete the initialization sequence.  
+The general rule of thumb is that the start code in assembly should
+do the minimum necessary to allow C code to execute to complete the
+initialization sequence.
 
 The initial assembly language start code completes its execution by
 invoking the shared routine @code{boot_card()}.
 
 The label (symbolic name) associated with the starting address of the
-program is typically called @code{start}.  The start object file
-is the first object file linked into the program image so it is insured
-that the start code is at offset 0 in the @code{.text} section.  It is
-the responsibility of the linker script in conjunction with the 
-compiler specifications file to put the start code in the correct location
-in the application image.
+program is typically called @code{start}.  The start object file is the
+first object file linked into the program image so it is ensured that
+the start code is at offset 0 in the @code{.text} section.  It is the
+responsibility of the linker script in conjunction with the compiler
+specifications file to put the start code in the correct location in
+the application image.
 
 @subsection boot_card() - Boot the Card
 
-The @code{boot_card()} is the first C code invoked.  Most of the BSPs
-use the same shared version of @code{boot_card()} which is located in
-the following file:
+The @code{boot_card()} is the first C code invoked.  This file is the
+core component in the RTEMS BSP Initialization Framework and provides
+the proper sequencing of initialization steps for the BSP, RTEMS and
+device drivers. All BSPs use the same shared version of @code{boot_card()}
+which is located in the following file:
 
 @example
 c/src/lib/libbsp/shared/bootcard.c
@@ -111,23 +148,88 @@ The @code{boot_card()} routine performs the following functions:
 
 @itemize @bullet
 
-@item invokes the BSP specific routine @code{bsp_start()},
+@item It disables processor interrupts.
+
+@item It sets the global program name and command line argument variables
+for later use by the application.
+
+@item If the macro is BSP_BOOTCARD_HANDLES_RAM_ALLOCATION is defined, it
+will invoke the BSP specific @code{bsp_get_work_area} function to obtain
+information on the amount and location of BSP RAM that is available to
+be allocated to the C Program Heap and RTEMS Workspace.  If the amount
+of memory available for the RTEMS Workspace is less than that required
+by the application (e.g. @code{rtems_configuration_get_work_space_size()},
+then a message is printed using @code{printk}, @code{bsp_cleanup} is
+invoked, and -1 is return to the assembly language start code.  BSPs which
+use this memory allocation functionality in @code{bootcard.c}
+must invoke the RTEMS specific autoconf macro
+@code{RTEMS_BSP_BOOTCARD_HANDLES_RAM_ALLOCATION} in the BSP's
+@code{configure.ac} file.
+
+@item It invokes the BSP specific routine @code{bsp_start()} which is
+written in C and thus able to perform more advanced initialization.
+Often MMU and bus initialization occurs here.
+
+@item It invokes the RTEMS directive
+@code{rtems_initialize_data_structures()} to initialize the RTEMS
+executive to a state where objects can be created but tasking is not
+enabled.
+
+@item If the macro is BSP_BOOTCARD_HANDLES_RAM_ALLOCATION is defined,
+it will calculate the memory available for the C Program Heap and invoke
+the initialization routine for the C Library with this information.
+
+@item It invokes the BSP specific routine @code{bsp_pretasking_hook}. On
+most BSPs which utilize the framework, this routine does nothing.
+
+@item If @code{RTEMS_DEBUG} is enabled, then the RTEMS debug mask level
+is inialized appropriately.
+
+@item It invokes the RTEMS directive
+@code{rtems_initialize_before_drivers()} to initialize the MPCI Server
+thread in a multiprocessor configuration and execute API specific
+extensions.
+
+@item It invokes the BSP specific routine @code{bsp_predriver_hook}. For
+most BSPs, the implementation of this routine does nothing.  However,
+on some BSPs, required subsystems which utilize the C Library
+(e.g. @code{malloc} in particular) may be initialized at this point.
+
+@item It invokes the RTEMS directive
+@code{rtems_initialize_device_drivers()} to initialize the statically
+configured set of device drivers in the order they were specified in
+the Configuration Table.
+
+@item It invokes the BSP specific routine @code{bsp_postdriver_hook}. For
+most BSPs, the implementation of this routine does nothing.  However, some
+BSPs use this hook and perform some initialization which must be done at
+this point in the initialization sequence.  This is the last opportunity
+for the BSP to insert BSP specific code into the initialization sequence.
+
+@item It invokes the RTEMS directive
+@code{rtems_initialize_start_multitasking()} which starts multitasking and context switches to the first task.  @code{boot_card()} will not return until the application is shutdown.  As part of this sequence the following actions occur:
 
-@item invokes the RTEMS directive @code{rtems_initialize_executive_early()}
-to initialize the executive, C Library, and all device drivers but
-return without initiating multitasking or enabling interrupts,
+@itemize @bullet
 
-@item invokes the shared @code{main()} in the same file as
-@code{boot_card()} which does not return until the
-@code{rtems_shutdown_executive} directive is called, and
+@item RTEMS will context switch to the first application task.  As a
+side-effect of this context switch, processor interrupts will be enabled.
+This is often the source of a fatal error during BSP development because
+the BSP did not clear and/or disable all interrupt sources and a spurious
+interrupt will occur .
+
+@item When in the context of the first task but before its body has been
+entered, any C++ Global Constructors will be invoked.
+
+@end itemize
 
-@item invokes the BSP specific routine @code{bsp_cleanup()} to perform
-any necessary board specific shutdown actions.
+@item Finally after the application shutsdown RTEMS and control is
+return to @code{boot_card()} from RTEMS, it invokes the BSP specific
+routine @code{bsp_cleanup()} to perform any necessary board specific
+shutdown actions.
 
 @end itemize
 
-It is important to note that the executive and much of the
-support environment must be initialized before invoking @code{main()}.
+That's it.  We just went through the entire sequence. 
 
 @subsection bsp_start() - BSP Specific Initialization
 
@@ -180,7 +282,7 @@ support library and, most importantly, invokes the C++ global
 constructors.  
 
 The precise placement of when @code{main()} is invoked in the 
-RTEMS initialization sequence insures that C Library and non-blocking
+RTEMS initialization sequence ensures that C Library and non-blocking
 calls can be made in global C++ constructors.
 
 The shared implementation of this routine is located in the following file:
diff --git a/doc/bsp_howto/intro.t b/doc/bsp_howto/intro.t
index cce6302277..1d4c1bdfa6 100644
--- a/doc/bsp_howto/intro.t
+++ b/doc/bsp_howto/intro.t
@@ -55,3 +55,22 @@ this manual as the result of his experiences.  At that time, this
 document was viewed internally as the most important "missing manual"
 in the RTEMS documentation set.
 
+The gen68340 BSP is a good example of the life of an RTEMS BSP.  It is
+based upon a part not recommended for new designs and none of the core RTEMS
+Project team members have one of these boards.  Thus we are unlikely to
+perform major updates on this BSP.  So as long as it compiles and links all
+tests, it will be available.  
+
+The RTEMS Project team members are always trying to identify common
+code across BSPs and refactoring the code into shared routines.
+As part of this effort, the we will enhance the common BSP Framework.
+Not surprisingly, not every BSP takes advantage of every feature in
+the framework.  The gen68340 does not take advantage of as many features
+as the ERC32 BSP does.  So in many ways, the ERC32 is a better example
+BSP at this point.  But even the ERC32 BSP does not include examples
+of every driver template and framework available to the BSP author.
+So in this guide we will try to point out good examples from other BSPs.
+
+Our goal is for you to be able to reuse as much code as possible and
+write as little board specific code as possible.
+
diff --git a/doc/bsp_howto/makefiles.t b/doc/bsp_howto/makefiles.t
index baeb3bf5b2..b75f07dd06 100644
--- a/doc/bsp_howto/makefiles.t
+++ b/doc/bsp_howto/makefiles.t
@@ -1,5 +1,5 @@
 @c
-@c  COPYRIGHT (c) 1988-2002.
+@c  COPYRIGHT (c) 1988-2008.
 @c  On-Line Applications Research Corporation (OAR).
 @c  All rights reserved.
 @c
@@ -27,11 +27,9 @@ of four phases as shown here:
 @end example
 @end ifset
 
-
 @ifset use-tex
 @image{Developer-User-Timeline,6in,,Developer User Timeline,.png}
 @c      @image{FILENAME[, WIDTH[, HEIGHT[, ALTTEXT[, EXTENSION]]]]}
-
 @end ifset
 
 @ifset use-html
diff --git a/doc/bsp_howto/support.t b/doc/bsp_howto/support.t
index f9548d2b96..c056650f97 100644
--- a/doc/bsp_howto/support.t
+++ b/doc/bsp_howto/support.t
@@ -18,29 +18,19 @@ file from the PowerPC psim BSP:
 
 @example
 @group
-%rename cpp old_cpp
-%rename lib old_lib
 %rename endfile old_endfile
 %rename startfile old_startfile
 %rename link old_link
 
-*cpp:
-%(old_cpp) %@{qrtems: -D__embedded__@} -Asystem(embedded)
-
-*lib:
-%@{!qrtems: %(old_lib)@} %@{qrtems: --start-group \
-%@{!qrtems_debug: -lrtemsall@} %@{qrtems_debug: -lrtemsall_g@} \
--lc -lgcc --end-group  ecrtn%O%s \
-%@{!qnolinkcmds: -T linkcmds%s@}@}
-
 *startfile:
-%@{!qrtems: %(old_startfile)@} %@{qrtems:  ecrti%O%s \
-%@{!qrtems_debug: startsim.o%s@} \
-%@{qrtems_debug: startsim_g.o%s@}@}
+%@{!qrtems: %(old_startfile)@} \
+%@{!nostdlib: %@{qrtems: ecrti%O%s rtems_crti%O%s crtbegin.o%s start.o%s@}@}
 
 *link:
-%@{!qrtems: %(old_link)@} %@{qrtems: -Qy -dp -Bstatic \
--T linkcmds%s -e _start -u __vectors@}
+%@{!qrtems: %(old_link)@} %@{qrtems: -Qy -dp -Bstatic -e _start -u __vectors@}
+
+*endfile:
+%@{!qrtems: %(old_endfile)@} %@{qrtems: crtend.o%s ecrtn.o%s@}
 @end group
 @end example
 
@@ -50,26 +40,19 @@ embedded their original definition.  The subsequent sections
 specify what behavior is expected when the @code{-qrtems} or
 @code{-qrtems_debug} option is specified.  
 
-The @code{*cpp} definition specifies that when @code{-qrtems}
-is specified, predefine the preprocessor symbol @code{__embedded__}.
-
-The @code{*lib} section insures that the RTEMS library, BSP specific
-linker script, gcc support library, and the EABI specific @code{ecrtn}
-file are used.
-
 The @code{*startfile} section specifies that the BSP specific file
-@code{startsim.o} will be used instead of @code{crt0.o}.  In addition,
-the EABI specific file @code{ecrti.o} will be linked in with the
-executable.
+@code{start.o} will be used instead of @code{crt0.o}.  In addition,
+various EABI support files (@code{ecrti.o} etc.) will be linked in with
+the executable.
 
-The @code{*link} section specifies the arguments that will be passed to
-the linker.
+The @code{*link} section adds some arguments to the linker when it is
+invoked by GCC to link an application for this BSP.
 
 The format of this file is specific to the GNU Compiler Suite.  The
 argument used to override and extend the compiler built-in specifications
-is relatively new to the toolset.  The @code{-specs} option is present
-in all @code{egcs} distributions and @code{gcc} distributions starting
-with version 2.8.0.
+is available in all recent GCC versions.  The @code{-specs} option is
+present in all @code{egcs} distributions and @code{gcc} distributions
+starting with version 2.8.0.
 
 @section README Files
 
@@ -126,16 +109,11 @@ as a starting point.
 Many @code{bsp.h} files provide prototypes of variables defined
 in the linker script (@code{linkcmds}).
 
-There are a number of fields in this file that are used only by the 
-RTEMS Test Suites.  The following is a list of these:
+@section tm27.h Include File
 
-@itemize @bullet
-@item @code{MAX_LONG_TEST_DURATION} - the longest length of time a 
-"long running" test should run.
-
-@item @code{MAX_SHORT_TEST_DURATION} - the longest length of time a
-"short running" test should run.
+The @code{tm27} test from the RTEMS Timing Test Suite is designed to measure the length of time required to vector to and return from an interrupt handler. This test requires some help from the BSP to know how to cause and manipulate the interrupt source used for this measurement.  The following is a list of these:
 
+@itemize @bullet
 @item @code{MUST_WAIT_FOR_INTERRUPT} - modifies behavior of @code{tm27}.
 
 @item @code{Install_tm27_vector} - installs the interrupt service 
@@ -153,6 +131,14 @@ can generate a nested interrupt.
 
 @end itemize
 
+All members of the Timing Test Suite are designed to run @b{WITHOUT}
+the Clock Device Driver installed.  This increases the predictability
+of the tests' execution as well as avoids occassionally including the
+overhead of a clock tick interrupt in the time reported.  Because of
+this it is sometimes possible to use the clock tick interrupt source
+as the source of this test interrupt.  On other architectures, it is
+possible to directly force an interrupt to occur.
+
 @section Calling Overhead File
 
 The file @code{include/coverhd.h} contains the overhead associated
@@ -168,40 +154,35 @@ The numbers in this file are obtained by running the "Timer Overhead"
 overhead is subtracted from the directive execution times reported by
 the Timing Suite.
 
+There is a shared implementation of @code{coverhd.h} which sets all of
+the overhead constants to 0.  On faster processors, this is usually the
+best alternative for the BSP as the calling overhead is extremely small.
+This file is located at:
+
+@example
+c/src/lib/libbsp/shared/include/coverhd.h
+@end example
+
 @section sbrk() Implementation
 
-If the BSP wants to dynamically extend the heap used by the
-C Library memory allocation routines (i.e. @code{malloc} family),
-then this routine must be functional.  The following is the 
-prototype for this routine:
+Although nearly all BSPs give all possible memory to the C Program Heap
+at initialization, it is possible for a BSP to configure the initial
+size of the heap small and let it grow on demand.  If the BSP wants
+to dynamically extend the heap used by the C Library memory allocation
+routines (i.e. @code{malloc} family), then the@code{sbrk} routine must
+be functional.  The following is the prototype for this routine:
 
 @example
 void * sbrk(size_t increment)
 @end example
 
 The @code{increment} amount is based upon the @code{sbrk_amount}
-parameter passed to the @code{RTEMS_Malloc_Initialize} during system
-initialization.
-See @ref{Initialization Code RTEMS Pretasking Callback} for more
-information.
-
-There is a default implementation which returns an error to indicate
-that the heap can not be extended.  This implementation can be
-found in @code{c/src/lib/libbsp/shared/sbrk.c}.  Many of the BSPs
-use this shared implementation.  In order to use this implementation,
-the file @code{Makefile.am} in the BSP's @code{startup} directory
-must be modified so that the @code{$VPATH} variable searches
-both the @code{startup} directory and the shared directory.  The following
-illustates the @code{VPATH} setting in the PowerPC psim BSP's 
-@code{startup/Makefile.am}:
+parameter passed to the @code{bsp_libc_init} during system initialization.
+Historically initialization of the C Library was done as part of the
+BSP's Pretasking Hook but now the BSP Boot Card Framework can perform
+this operation.
 
-@example
-VPATH = @@srcdir@@:@@srcdir@@/../../../shared
-@end example
-
-This instructs make to look in all of the directories in the @code{VPATH}
-for the source files.  The directories will be examined in the order
-they are specified.
+If your BSP does not want to support dynamic heap extension, then you do not have to do anything special.  However, if you want to support @code{sbrk}, you must provide an implementation of this method and define @code{CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK} in @code{bsp.h}.  This informs @code{rtems/confdefs.h} to configure the Malloc Family Extensions which support @code{sbrk}.
 
 @section bsp_cleanup() - Cleanup the Hardware
 
@@ -215,20 +196,28 @@ c/src/lib/libbsp/shared/bspclean.c
 
 The @code{bsp_cleanup()} routine can be used to return to a ROM monitor,
 insure that interrupt sources are disabled, etc..  This routine is the
-last place to insure a clean shutdown of the hardware.
+last place to insure a clean shutdown of the hardware.  On some BSPs,
+it prints a message indicating that the application completed execution
+and waits for the user to press a key before resetting the board.
+The PowerPC/gen83xx and PowerPC/gen5200 BSPs do this when they are built
+to support the FreeScale evaluation boards.  This is convenient when
+using the boards in a development environment and may be disabled for
+production use.
 
 @section set_vector() - Install an Interrupt Vector
 
-The @code{set_vector} routine is responsible for installing an interrupt
-vector.  It invokes the support routines necessary to install an
-interrupt handler as either a "raw" or an RTEMS interrupt handler.  Raw
-handlers bypass the RTEMS interrupt structure and are responsible for 
-saving and restoring all their own registers.  Raw handlers are useful
-for handling traps, debug vectors, etc..
+On targets with Simple Vectored Interrupts, the BSP must provide
+an implementation of the @code{set_vector} routine.  This routine is
+responsible for installing an interrupt vector.  It invokes the support
+routines necessary to install an interrupt handler as either a "raw"
+or an RTEMS interrupt handler.  Raw handlers bypass the RTEMS interrupt
+structure and are responsible for saving and restoring all their own
+registers.  Raw handlers are useful for handling traps, debug vectors,
+etc..
 
-The @code{set_vector} routine is a central place to perform 
-interrupt controller manipulation and encapsulate that information.  
-It is usually implemented as follows:
+The @code{set_vector} routine is a central place to perform interrupt
+controller manipulation and encapsulate that information.  It is usually
+implemented as follows:
 
 @example
 @group
@@ -251,7 +240,8 @@ rtems_isr_entry set_vector(                     /* returns old vector */
 @end group
 @end example
 
-
-@b{NOTE:}  @code{set_vector} is provided by the majority of BSPs but
-not all.  In particular, the i386 BSPs use a different scheme.  
+@b{NOTE:}  The i386, PowerPC and ARM ports use a Programmable
+Interrupt Controller model which does not require the BSP to implement
+@code{set_vector}.  BSPs for these architectures must provide a different
+set of support routines.