Index: doc/bsp_howto/analog.t
===================================================================
--- doc/bsp_howto/analog.t	(revision a54541d8e382ca0d72e4b15101712681841c6666)
+++ doc/bsp_howto/analog.t	(revision 183369d86520e3880eec8ea306890e007cab7387)
@@ -81,5 +81,5 @@
 At system initialization, the analog driver's initialization entry point
 will be invoked.  As part of initialization, the driver will perform
-whatever board initializatin is required and then set all
+whatever board initialization is required and then set all
 outputs to their configured initial state.
 
@@ -159,5 +159,9 @@
 This is one of the IOCTL functions supported by the I/O control
 device driver entry point.  When this IOCTL function is invoked,
-the last value written to the specified output word along with
-a timestamp of when the last write was performed.
+the following information is returned to the caller:
 
+@itemize @bullet 
+@item last value written to the specified DAC 
+@item timestamp of when the last write was performed
+@end itemize
+
Index: doc/bsp_howto/clock.t
===================================================================
--- doc/bsp_howto/clock.t	(revision a54541d8e382ca0d72e4b15101712681841c6666)
+++ doc/bsp_howto/clock.t	(revision 183369d86520e3880eec8ea306890e007cab7387)
@@ -19,4 +19,7 @@
 
 @section Clock Driver Global Variables
+
+This section describes the global variables expected to be provided by
+this driver.
 
 @subsection Major and Minor Number
Index: doc/bsp_howto/console.t
===================================================================
--- doc/bsp_howto/console.t	(revision a54541d8e382ca0d72e4b15101712681841c6666)
+++ doc/bsp_howto/console.t	(revision 183369d86520e3880eec8ea306890e007cab7387)
@@ -32,5 +32,5 @@
 @end itemize
 
-We may think that one need two serial drivers to deal with those two types
+One may think that two serial drivers are needed to handle these two types
 of data, but Termios permits having only one driver. 
 
@@ -91,5 +91,5 @@
 This mode is not the most efficient way to utilize the UART. But 
 polled mode is usually necessary when one wants to print an
-error message in the event of a fatal error such as al fatal error
+error message in the event of a fatal error such as a fatal error
 in the BSP.  This is also the simplest mode to
 program.  Polled mode is generally preferred if the serial port is
@@ -125,5 +125,5 @@
 
 @example
-This figure needs to be inserted in this document.
+Figure not included in this draft
 @end example
 
Index: doc/bsp_howto/discrete.t
===================================================================
--- doc/bsp_howto/discrete.t	(revision a54541d8e382ca0d72e4b15101712681841c6666)
+++ doc/bsp_howto/discrete.t	(revision 183369d86520e3880eec8ea306890e007cab7387)
@@ -179,5 +179,9 @@
 This is one of the IOCTL functions supported by the I/O control
 device driver entry point.  When this IOCTL function is invoked,
-the last value written to the specified output word along with
-a timestamp of when the last write was performed.
+the following information is returned to the caller:
 
+@itemize @bullet
+@item last value written to the specified output word
+@item timestamp of when the last write was performed
+@end itemize
+
Index: doc/bsp_howto/init.t
===================================================================
--- doc/bsp_howto/init.t	(revision a54541d8e382ca0d72e4b15101712681841c6666)
+++ doc/bsp_howto/init.t	(revision 183369d86520e3880eec8ea306890e007cab7387)
@@ -96,4 +96,12 @@
 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.
+
 @subsection boot_card() - Boot the Card
 
@@ -164,10 +172,9 @@
 
 One of the most important functions performed by this routine
-is determining where the RTEMS Executive Work Space is to be
+is determining where the RTEMS Workspace is to be
 located in memory.  All RTEMS objects and task stacks will be
 allocated from this Workspace.  The RTEMS Workspace is distinct
-from the application heap used for @code{malloc()}.
-
-Many BSPs place this area at the end of RAM although this is
+from the application heap used for @code{malloc()}.  Many BSPs
+place the RTEMS Workspace area at the end of RAM although this is
 certainly not a requirement.
 
Index: doc/bsp_howto/linkcmds.t
===================================================================
--- doc/bsp_howto/linkcmds.t	(revision a54541d8e382ca0d72e4b15101712681841c6666)
+++ doc/bsp_howto/linkcmds.t	(revision 183369d86520e3880eec8ea306890e007cab7387)
@@ -20,5 +20,5 @@
 An embedded systems programmer must be much more aware of the
 placement of their executable image in memory than the average
-"normal" programmer.  A program destined to be embedded as well
+applications programmer.  A program destined to be embedded as well
 as the target system have some specific properties that must be
 taken into account. Embedded machines often mean average performances
@@ -44,7 +44,7 @@
 an embedded program is made of sections.  It is the responsibility of
 the application programmer to place these sections in the appropriate
-place in target memory.  To make this clearer, if using COFF on the
-Motorola m68k family of microprocessors, the following sections will
-be present:
+place in target memory.  To make this clearer, if using the COFF 
+object file format on the Motorola m68k family of microprocessors,
+the following sections will be present:
 
 @itemize @bullet
@@ -418,5 +418,5 @@
 Step 3 shows the final executable image as it logically appears in
 the target's non-volatile program memory.  The board initialization
-code will copy the initialized data initial values (which are stored in
+code will copy the ""copy of @code{.data} section" (which are stored in
 ROM) to their reserved location in RAM. 
 
Index: doc/bsp_howto/makefiles.t
===================================================================
--- doc/bsp_howto/makefiles.t	(revision a54541d8e382ca0d72e4b15101712681841c6666)
+++ doc/bsp_howto/makefiles.t	(revision 183369d86520e3880eec8ea306890e007cab7387)
@@ -8,4 +8,29 @@
 
 @chapter Makefiles
+
+This chapter discusses the Makefiles associated with a BSP.  It does not 
+describe the process of configuring, building, and installing RTEMS.  
+This chapter will not provide detailed information about this process.
+Nonetheless, it is important to remember that the general process consists
+of three parts:
+
+@itemize @bullet
+@item configure
+@item build
+@item install
+@end itemize
+
+During the configure phase, a number of files are generated.  These 
+generated files are tailored for the specific host/target combination
+by the configure script.  This set of files includes the Makefiles used
+to actually compile and install RTEMS.
+
+During the build phase, the source files are compiled into object files
+and libraries are built.
+
+During the install phase, the libraries, header files, and other support
+files are copied to the BSP specific installation point.  After installation
+is successfully completed, the files generated by the configure and build
+phases may be removed.
 
 @section Makefiles Used During The BSP Building Process
@@ -89,6 +114,6 @@
 CPU dependent support code or provide its own.
 
-This Makefile makes use of a neat construct in @b{GNU make} to pick 
-up the required components:
+This Makefile makes use of the @code{foreach} construct in @b{GNU make}
+to pick up the required components:
 
 @example
Index: doc/bsp_howto/nvmem.t
===================================================================
--- doc/bsp_howto/nvmem.t	(revision a54541d8e382ca0d72e4b15101712681841c6666)
+++ doc/bsp_howto/nvmem.t	(revision 183369d86520e3880eec8ea306890e007cab7387)
@@ -66,5 +66,5 @@
 non-volatile memory.
 The following is a list of the type of information normally required
-to configure each area of non-volatile memory
+to configure each area of non-volatile memory.
 
 @table @b
@@ -119,5 +119,5 @@
 
 @item Partitions
-is the address of table that contains an entry to describe each
+is the address of the table that contains an entry to describe each
 partition in this area.  Fields within each element of this
 table are defined as follows:
@@ -144,5 +144,5 @@
 whatever initializatin is required on each non-volatile memory area.
 
-The discrete I/O driver may register devices name for memory 
+The discrete I/O driver may register device names for memory 
 partitions of particular interest to the system.  Normally this
 will be restricted to the device "/dev/nv_memory" to indicate
Index: doc/bsp_howto/rtc.t
===================================================================
--- doc/bsp_howto/rtc.t	(revision a54541d8e382ca0d72e4b15101712681841c6666)
+++ doc/bsp_howto/rtc.t	(revision 183369d86520e3880eec8ea306890e007cab7387)
@@ -90,5 +90,6 @@
 for Vendor A's RTC chip would need to return TRUE if the
 board was a first generation one.  The @code{deviceProbe}
-routines are very board dependent.
+routines are very board dependent and must be provided by
+the BSP.
 
 @section setRealTimeToRTEMS
Index: doc/bsp_howto/target.t
===================================================================
--- doc/bsp_howto/target.t	(revision a54541d8e382ca0d72e4b15101712681841c6666)
+++ doc/bsp_howto/target.t	(revision 183369d86520e3880eec8ea306890e007cab7387)
@@ -55,9 +55,9 @@
 
 This class of code provides a reusable library of peripheral device
-drivers which can be tailored easily to a particular board.  This
-reusable library provides software objects which correspond to standard
-controllers.  Just as the hardware engineer choose a standard controller
-when designing a board, the goal of this library is to let the software
-engineer do the same thing.
+drivers which can be tailored easily to a particular board.  The
+libchip library is a collection of reusable software objects that
+correspond to standard controllers.  Just as the hardware engineer
+chooses a standard controller when designing a board, the goal of
+this library is to let the software engineer do the same thing.
 
 The source code for the reusable peripheral driver library may be found
@@ -91,8 +91,9 @@
 If the BSP does not exist and the board's CPU model is supported, then
 examine the reusable chip library and existing BSPs for a close match.  
-This will help reduce the development effort required.  It is often
-possible to copy existing components in the reusable chip library or
-device drivers from BSPs from different CPU families as the starting
-point for a new device driver. 
+Other BSPs and libchip provide starting points for the development 
+of a new BSP.  It is often possible to copy existing components in
+the reusable chip library or device drivers from BSPs from different
+CPU families as the starting point for a new device driver. 
+This will help reduce the development effort required.  
 
 If the board's CPU family is supported but the particular CPU model on
Index: doc/bsp_howto/timer.t
===================================================================
--- doc/bsp_howto/timer.t	(revision a54541d8e382ca0d72e4b15101712681841c6666)
+++ doc/bsp_howto/timer.t	(revision 183369d86520e3880eec8ea306890e007cab7387)
@@ -16,5 +16,5 @@
 impact of specific minor changes.
 
-The gen68340 BSP also uses the TImer Driver to support a high performance
+The gen68340 BSP also uses the Timer Driver to support a high performance
 mode of the on-CPU UART.
 
Index: doc/networking/driver.t
===================================================================
--- doc/networking/driver.t	(revision a54541d8e382ca0d72e4b15101712681841c6666)
+++ doc/networking/driver.t	(revision 183369d86520e3880eec8ea306890e007cab7387)
@@ -18,10 +18,10 @@
 driver.  The source code for this driver is located in the
 @code{c/src/lib/libbsp/m68k/gen68360/network} directory in the RTEMS
-source code distribution.  You should have a copy of this driver at
-hand when reading the following notes.
+source code distribution.  Having a copy of this driver at
+hand when reading the following notes will help significantly.
 
 @section Learn about the network device 
 
-Before starting to write the network driver you need to be completely
+Before starting to write the network driver become completely
 familiar with the programmer's view of the device.
 The following points list some of the details of the
@@ -35,5 +35,5 @@
 
 @item If the device uses DMA, is it capable of forming a single
-outtoing packet from multiple fragments scattered in separate
+outgoing packet from multiple fragments scattered in separate
 memory buffers?
 
@@ -75,5 +75,5 @@
 @section Understand the network scheduling conventions
 
-When writing code for your driver transmit and receive tasks you must
+When writing code for the driver transmit and receive tasks,
 take care to follow the network scheduling conventions.  All tasks
 which are associated with networking share various
@@ -81,8 +81,8 @@
 of these structures the tasks
 execute only when they hold the network semaphore (@code{rtems_bsdnet_semaphore}).
-Your transmit and receive tasks must abide by this protocol which means you must
-be careful to avoid `deadly embraces' with the other network tasks.
-A number of routines are provided to make it easier for your code
-to conform to the network task scheduling conventions.
+The transmit and receive tasks must abide by this protocol.  Be very
+careful to avoid `deadly embraces' with the other network tasks.
+A number of routines are provided to make it easier for the network
+driver code to conform to the network task scheduling conventions.
 
 @itemize @bullet
@@ -91,5 +91,5 @@
 
 This function releases the network semaphore.
-Your task must call this function immediately before
+The network driver tasks must call this function immediately before
 making any blocking RTEMS request.
 
@@ -97,12 +97,12 @@
 
 This function obtains the network semaphore.
-If your task has released the network semaphore to allow other
-network-related tasks to run while your task blocks you must call this
-function to reobtain the semaphore immediately after the return from the
+If a network driver task has released the network semaphore to allow other
+network-related tasks to run while the task blocks, then this function must 
+be called to reobtain the semaphore immediately after the return from the
 blocking RTEMS request.
 
 @item @code{rtems_bsdnet_event_receive(rtems_event_set, rtems_option, rtems_interval, rtems_event_set *)}
-Your task should call this function when it wishes to wait for an event.
-This function releases the network semaphore,
+The network driver task should call this function when it wishes to wait
+for an event.  This function releases the network semaphore,
 calls @code{rtems_event_receive} to wait for the specified event
 or events and reobtains the semaphore.
@@ -111,5 +111,5 @@
 @end itemize
 
-@section Write your driver attach function
+@section Write the Driver Attach Function
 The driver attach function is responsible for configuring the driver
 and making the connection between the network stack
@@ -186,5 +186,5 @@
 
 
-@section Write your driver start function.
+@section Write the Driver Start Function.
 This function is called each time the network stack wants to start the
 transmitter.  This occures whenever the network stack adds a packet
@@ -197,5 +197,6 @@
 
 
-@section Write your driver initialization function.
+@section Write the Driver Initialization Function.
+
 This function should initialize the device, attach to interrupt handler, 
 and start the driver transmit and receive tasks.  The function
@@ -213,9 +214,11 @@
 Note that the network stack may call the driver initialization function more
 than once.
-Make sure you don't start multiple versions of the receive and transmit tasks.
-
-
-
-@section Write your driver transmit task.
+Make sure multiple versions of the receive and transmit tasks are not accidentally
+started.
+
+
+
+@section Write the Driver Transmit Task
+
 This task is reponsible for removing packets from the driver send queue and sending them to the device.  The task should block waiting for an event from the
 driver start function indicating that packets are waiting to be transmitted.
@@ -225,5 +228,5 @@
 
 
-@section Write your driver receive task.
+@section Write the Driver Receive Task
 This task should block until a packet arrives from the device.  If the
 device is an Ethernet interface the function @code{ether_input} should be called
@@ -235,5 +238,5 @@
 
 
-@section Write your driver interrupt handler.
+@section Write the Driver Interrupt Handler
 A typical interrupt handler will do nothing more than the hardware
 manipulation required to acknowledge the interrupt and send an RTEMS event
@@ -244,5 +247,5 @@
 
 
-@section Write your driver ioctl function.
+@section Write the Driver IOCTL Function
 This function handles ioctl requests directed at the device.  The ioctl
 commands which must be handled are:
@@ -276,7 +279,7 @@
 
 
-@section Write Your Driver Statistic-Printing Function
+@section Write the Driver Statistic-Printing Function
 This function should print the values of any statistic/diagnostic
-counters your driver may use.  The driver ioctl function should call
+counters the network driver may use.  The driver ioctl function should call
 the statistic-printing function when the ioctl command is
 @code{SIO_RTEMS_SHOW_STATS}.
