1. Technical Field:
The present invention relates in general to data processing system testing and in particular to testing during startup or power-on of the data processing system. Still more particularly, the present invention relates to recording startup error data that is pertinent to system failure which would otherwise be unavailable for analysis.
2. Description of the Related Art:
Data processing systems utilize a set of routines stored in a read only memory ("ROM") that tests various system components during startup to determine if they are operating and connected properly. The routines are originally employed during the manufacturing process. If problems are detected, the data processing system user is alerted, usually by a display device indicating the error that occurred. If the routines, referred to as power-on self test ("POST"), are successful control is passed to the system's bootstrap loader which resides in the system's ROM.
"Boot" firmware is ROM-based software that controls a computer within a data processing system from the time it is turned on until the primary operating system receives control of the data processing system. Firmware is a term that describes microcode (software routines) stored in ROM. Instructions, generally low-level, are written in code as software, programmed into system ROM and then become part of the hardware in the actual data processing system. The combination of the stored microcode and hardware is termed "firmware."
The main function of boot firmware is to initialize the hardware and then boot (load and execute) the primary operating system of a data processing system (also referred to as a computer). Secondary functions include testing hardware, managing hardware configuration information and providing tools for debugging in case of faulty hardware or software.
As a computer is being manufactured, tests are performed regularly while the computer passes down the manufacturing line. In the manufacturing process, during early firmware execution (also known as initial program loading or "IPL"), right after power on or Power-on-Reset, the Input/Output ("I/O") subsystem is not configured.
Checkpoint is a term that usually applies to a sequence of instructions in a computer program that allows recording and identification of various errors that occur during startup. Checkpoints in power-on self test code are commonly utilized to aid in the diagnosis of system failure during the IPL process. Generally, the implication is that there is enough of the data processing system operating to get to a checkpoint register or device so the point of failure can be ascertained. But the checkpoint register is almost always in the I/O subsystem, requiring that most of the system be operational to display causes of errors (non-responsive components, wrong or defective connections). Additionally, the I/O subsystem is usually not configured right after power-on. As a result, a checkpoint display device may be unavailable and errors which cause a failure may not be displayed. If a system failed but was unable to display a POST checkpoint, one might have to replace a processor card, memory, I/O cards or motherboard before isolating the cause of failure. Therefore, when some hardware problems occur early in the manufacturing line, diagnostic information for debugging a problem that has gone unrecorded is severely limited.
Referring to FIG. 3, a process for detecting checkpoints in a motherboard manufacturing operation, is depicted. The process begins with step 300, which illustrates power applied to a motherboard on a manufacturing line. The power is applied to determine whether there are defects or errors in software or hardware on the motherboard. The process proceeds to step 302, which illustrates initializing the system onboard the motherboard and testing hardware and software applications. The process continues to step 304, which depicts a determination of whether an error checkpoint has occurred during startup. If no checkpoint was detected, the process proceeds to step 306, which illustrates continuing the manufacturing process.
If an error checkpoint is detected, the process instead proceeds to step 308, which depicts a determination of whether or not a checkpoint display device is connected (initialized). If not, the process proceeds to step 312, which illustrates manual replacement of components. The process then proceeds to step 300, which depicts the system being powered on to retest the motherboard with the suspected defective component replaced. If the checkpoint display device is initialized, the process continues instead from step 308 to step 310, which depicts the operator running diagnostic tests or a manual error analysis. The error is corrected and the process proceeds to step 306.
As indicated previously, non-availability of a checkpoint display device increases cost and manufacturing time by requiring manual detection and correction of errors that occur early in the startup process. It would be desirable therefore, to provide a logging feature that is built into the computer to store checkpoint information early in the startup process, before the I/O checkpoint display device becomes ready for use. The checkpoint diagnostic information would then be available to aid in a debugging process.