2003-05-21 Ralf corsepius <corsepiu@faw.uni-ulm.de>

* adaintr.t, ata.t, ide-ctrl.t, target.t: Various typo-fixes, Update
	to reflect introduction of the cpukit.

doc/bsp_howto/ChangeLog

@@ -1,3 +1,8 @@
+2003-05-21	Ralf corsepius <corsepiu@faw.uni-ulm.de>
+
+	* adaintr.t, ata.t, ide-ctrl.t, target.t: Various typo-fixes, Update
+	to reflect introduction of the cpukit.
+
 2003-01-28	Joel Sherrill <joel@OARcorp.com>
 
 	* makefiles.t, support.t: Updated to reflect use of automake in

doc/bsp_howto/adaintr.t

@@ -32,7 +32,7 @@ SIGFPE and SIGSEGV. These signals should be raised when a spurious
 or erroneous trap occurs.
 
 To enable gnat interrupt and error exception support for a particular 
-bsp, the following has to be done:
+BSP, the following has to be done:
 
 @enumerate
 
@@ -42,12 +42,12 @@ signal depending on the interrupt/trap number.
 @item Install the interrupt handler for all interrupts/traps that will be
 handled by gnat (including spurious).
 
-@item At startup, gnat calls @code{__gnat_install_handler()}. The bsp 
+@item At startup, gnat calls @code{__gnat_install_handler()}. The BSP 
 must provide this function which installs the interrupt/trap handlers.
 
 @end enumerate
 
-Which cpu-interrupt will generate which signal is implementation
+Which CPU-interrupt will generate which signal is implementation
 defined. There are 32 POSIX signals (1 - 32), and all except the
 three error signals (SIGILL, SIGFPE and SIGSEGV) can be used. I
 would suggest to use the upper 16 (17 - 32) which do not
@@ -63,7 +63,7 @@ done separately, typically by writing various device register.
 An example program (@code{irq_test}) is included in the
 Ada examples package to show how interrupts can be handled
 in Ada95. Note that generation of the test interrupt
-(@code{irqforce.c}) is bsp specific and must be edited.
+(@code{irqforce.c}) is BSP specific and must be edited.
 
 NOTE: The @code{irq_test} example was written for the SPARC/ERC32
 BSP.

doc/bsp_howto/ata.t

@@ -15,8 +15,8 @@ ATA device - physical device attached to an IDE controller
 @section Introduction
 
 ATA driver provides generic interface to an ATA device. ATA driver is
-hardware independant implementation of ATA standart defined in working draft
+hardware independent implementation of ATA standard defined in working draft
-"AT Attachment Interface with Extentions (ATA-2)" X3T10/0948D revision 4c, 
+"AT Attachment Interface with Extensions (ATA-2)" X3T10/0948D revision 4c, 
 March 18, 1996. ATA Driver based on IDE Controller Driver and may be used for 
 computer systems with single IDE controller and with multiple as well. Although
 current implementation has several restrictions detailed below ATA driver
@@ -29,7 +29,7 @@ commands are implemented
 @end itemize
 
 The reference implementation for ATA driver can be found in 
-@code{c/src/exec/libblock/src/ata.c}.  
+@code{cpukit/libblock/src/ata.c}.  
 
 @section Initialization
 
@@ -52,7 +52,7 @@ rtems_device_driver ata_initialize(
 
    for each IDE controller successfully initialized by the IDE Controller 
        driver
-     if the controller is interuupt driven
+     if the controller is interrupt driven
        set up interrupt handler 
 
      obtain information about ATA devices attached to the controller
@@ -67,7 +67,7 @@ rtems_device_driver ata_initialize(
 @end example
 
 Special processing of ATA commands is required because of absence of 
-multitasking enviroment during the driver initialization.
+multitasking environment during the driver initialization.
 
 Detected ATA devices are registered in the system as physical block devices
 (see libblock library description). Device names are formed based on IDE
@@ -118,7 +118,7 @@ typedef struct ata_req_s @{
 
 ATA driver supports separate ATA requests queues for each IDE
 controller (one queue per controller). The following structure contains 
-inforamtion about controller's queue and devices attached to the controller:
+information about controller's queue and devices attached to the controller:
 
 @example
 @group
@@ -128,7 +128,7 @@ inforamtion about controller's queue and devices attached to the controller:
  */
 typedef struct ata_ide_ctrl_s @{
     rtems_boolean present;   /* controller state */
-    ata_dev_t     device[2]; /* ata diveces description */
+    ata_dev_t     device[2]; /* ata devices description */
     Chain_Control reqs;      /* requests chain */
 @} ata_ide_ctrl_t;
 @end group
@@ -137,7 +137,7 @@ typedef struct ata_ide_ctrl_s @{
 Driver uses array of the structures indexed by the controllers minor
 number.
 
-The following struture allows to map an ATA device to the pair (IDE 
+The following structure allows to map an ATA device to the pair (IDE 
 controller minor number device is attached to, device number
 on the controller): 
 
@@ -176,14 +176,14 @@ typedef enum ata_msg_type_s @{
 All ATA driver functionality is available via ATA driver ioctl. Current
 implementation supports only two ioctls: BLKIO_REQUEST and
 ATAIO_SET_MULTIPLE_MODE. Each ATA driver ioctl() call generates an 
-ATA request which is appended to the apropriate controller queue depending
+ATA request which is appended to the appropriate controller queue depending
 on ATA device the request belongs to. If appended request is single request in
 the controller's queue then ATA driver event is generated.
 
 ATA driver task which manages queue of ATA driver events is core of ATA
 driver. In current driver version queue of ATA driver events implemented
 as RTEMS message queue. Each message contains event type, IDE controller
-minor number on which event happaned and error if an error occured. Events
+minor number on which event happened and error if an error occurred. Events
 may be generated either by ATA driver ioctl call or by ATA driver task itself.
 Each time ATA driver task receives an event it gets controller minor number
 from event, takes first ATA request from controller queue and processes it 

doc/bsp_howto/ide-ctrl.t

@@ -25,7 +25,7 @@ The reference implementation for an IDE Controller driver can
 be found in @code{$RTEMS_SRC_ROOT/c/src/libchip/ide}. This driver
 is based on the libchip concept and allows to work with any of the IDE 
 Controller chips simply by appropriate configuration of BSP. Drivers for a
-paticular IDE Controller chips locate in the following directories: drivers
+particular IDE Controller chips locate in the following directories: drivers
 for well-known IDE Controller chips locate into
 @code{$RTEMS_SRC_ROOT/c/src/libchip/ide}, drivers for IDE Controller chips
 integrated with CPU locate into
@@ -38,7 +38,7 @@ for that particular IDE Controller chip.
 
 @section Initialization
 
-IDE Controller chips used by a BSP are statically confiured into
+IDE Controller chips used by a BSP are statically configured into
 @code{IDE_Controller_Table}. The @code{ide_controller_initialize} routine is 
 responsible for initialization of all configured IDE controller chips.
 Initialization order of the chips based on the order the chips are defined in 
@@ -56,7 +56,7 @@ rtems_device_driver ide_controller_initialize(
 )
 @{
    for each IDE Controller chip configured in IDE_Controller_Table
-     if (BSP dependant probe(if exists) AND device probe for this IDE chip 
+     if (BSP dependent probe(if exists) AND device probe for this IDE chip 
         indicates it is present)
        perform initialization of the particular chip
        register device with configured name for this chip
@@ -73,7 +73,7 @@ number. This routine is not allowed to be called from an application.
 @example
 @group
 void ide_controller_read_register(rtems_device_minor_number minor,
-                                  unsigned32 reg, unsiged32 *value)
+                                  unsigned32 reg, unsigned32 *value)
 @{
   get IDE Controller chip configuration information from
   IDE_Controller_Table by minor number
@@ -92,7 +92,7 @@ number. This routine is not allowed to be called from an application.
 @example
 @group
 void ide_controller_write_register(rtems_device_minor_number minor,
-                                   unsigned32 reg, unsiged32 value)
+                                   unsigned32 reg, unsigned32 value)
 @{
   get IDE Controller chip configuration information from
   IDE_Controller_Table by minor number

doc/bsp_howto/target.t

@@ -26,7 +26,7 @@ into one of the following categories.
 This class of code includes the foundation
 routines for the executive proper such as the context switch and
 the interrupt subroutine implementations.  Sources for the supported
-processor families can be found in @code{c/src/exec/score/cpu}.
+processor families can be found in @code{cpukit/score/cpu}.
 A good starting point for a new family of processors is the
 @code{no_cpu} directory, which holds both prototypes and
 descriptions of each needed CPU dependent function. 
@@ -34,7 +34,7 @@ descriptions of each needed CPU dependent function.
 CPU dependent code is further subcategorized if the implementation is
 dependent on a particular CPU model.  For example, the MC68000 and MC68020
 processors are both members of the m68k CPU family but there are significant
-differents between these CPU models which RTEMS must take into account.
+differences between these CPU models which RTEMS must take into account.
 
 @section Board Dependent
 
@@ -115,7 +115,7 @@ The CPU dependent files in the RTEMS executive source code are found
 in the following directory:
 
 @example
-c/src/exec/score/cpu/@i{CPU}
+cpukit/score/cpu/@i{CPU}
 @end example
 
 where @i{CPU} is replaced with the CPU family name.