diff --git a/doc/bsp_howto/ChangeLog b/doc/bsp_howto/ChangeLog index 636cf95660..742f5d3ee0 100644 --- a/doc/bsp_howto/ChangeLog +++ b/doc/bsp_howto/ChangeLog @@ -1,3 +1,8 @@ +2003-05-21 Ralf corsepius + + * adaintr.t, ata.t, ide-ctrl.t, target.t: Various typo-fixes, Update + to reflect introduction of the cpukit. + 2003-01-28 Joel Sherrill * makefiles.t, support.t: Updated to reflect use of automake in diff --git a/doc/bsp_howto/adaintr.t b/doc/bsp_howto/adaintr.t index 26835ca882..e3980b2fef 100644 --- a/doc/bsp_howto/adaintr.t +++ b/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. diff --git a/doc/bsp_howto/ata.t b/doc/bsp_howto/ata.t index 507ae2dc17..851a41ee3b 100644 --- a/doc/bsp_howto/ata.t +++ b/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 -"AT Attachment Interface with Extentions (ATA-2)" X3T10/0948D revision 4c, +hardware independent implementation of ATA standard defined in working draft +"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 diff --git a/doc/bsp_howto/ide-ctrl.t b/doc/bsp_howto/ide-ctrl.t index ca23572cac..f5ece8507d 100644 --- a/doc/bsp_howto/ide-ctrl.t +++ b/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 diff --git a/doc/bsp_howto/target.t b/doc/bsp_howto/target.t index 026a2de302..5c285650fb 100644 --- a/doc/bsp_howto/target.t +++ b/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.