2-10
General Design Considerations
2.6 Power-On/Start-up
The first job during power-on/start-up is to test the reliability of the
config
data structure. The structure is checked for correct length and checksum.
If either of these is wrong, the SAF-TE software will not run. Nearly all
of the information in the
config
data structure is user-specific, and
virtually all of the firmware is
not
specific to any user, so the software
cannot signal that the
config
structure is corrupt. It is expected that the
users customizing this software will make changes to light a failure LED
or otherwise signal the general failure of the SAF-TE system for this
condition, as well as for other similar errors.
Once validated, the information in the
config
data structure can be used
to initialize the SCSI hardware, the TWS hardware, and the 52 I/O lines.
When initialization is completed, interrupts are enabled and normal
(background) processing begins.
2.7 Normal Processing
The background process first checks the health of the SCSI interrupt
level software. If unhealthy, the hardware is reinitialized and the SCSI
interrupt is enabled.
The background process handles the TWS polling if it is time. The
background process also makes one pass through the state machine
program to update the status of all the I/O pins. This process is repeated
indefinitely.
The SCSI interrupt level code attempts to handle all normal SCSI errors
in a straight-forward manner. If any abnormal errors occur, the interrupt
software takes the simplest approach - it goes bus free. This is always a
valid approach to errors by a SCSI target, plus it gets the LSI53C040
core off the bus as quickly as possible. Since there are few commands
and no variants, the SAF-TE protocol works well in a production
environment (the assumption is that issues relating to the host and target
software have been resolved). When the SCSI interrupt software goes
bus free, it signals the background process that it has done so by
disabling the SCSI interrupt.