Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
1998-09-30
2001-10-16
Ray, Gopal C. (Department: 2181)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C712S228000
Reexamination Certificate
active
06304983
ABSTRACT:
BACKGROUND OF THE INVENTION
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.
SUMMARY OF THE INVENTION
It is therefore one object of the present invention to determine early checkpoint information for a computer.
It is another object of the present invention to extend the coverage of the available checkpoint data in the system.
It is a further object of the present invention to provide storage within the data processing system to log the checkpoint information for later retrieval.
It is yet another object of the present invention to utilize the checkpoint information to aid in the debugging process.
The foregoing objects are achieved as is now described. A processor register is reserved by early firmware code to be employed for checkpoint logging or for storing diagnostic information at the time of failure before a checkpoint display device, usually contained within an I/O subsystem, is initialized. Early firmware codes are usually written in assembly language and the firmware of the present invention dedicates a processor register for logging checkpoint information. If a machine fails before any checkpoint, or point of failure, is displayed by a checkpoint display device, a dedicated processor register has logged any checkpoint or diagnostic information. The error information relating to the failure is obtained from the dedicated register through JTAG (Joint Task Action Group) scanning utilizing a processor debugging tool.
The above as well as additional objects, features, and advantages of the present invention will become apparent in the following detailed written description.
REFERENCES:
patent: 6032265 (2000-02-01), Oguro et al.
Checkpoint Register, J. A. Wetzel, IBM Technical Disclosure Bulletin, vol. 27, No. 4A, Sep. 1984, pp. 2231-2232.
Method to Utilize ROM-Based Power-on-Self-Test Code in Manufacturing Test, M.N. Day, J.T. Hanna, G. Morris and J. Zimmerman, IBM Technical Disclosure Bulletin, vol. 29, No. 3, Aug. 1986, pp. 1255-1257.
Lee Van Hoa
Randall David Lee
Bracewell & Patterson L.L.P.
International Business Machines - Corporation
Ray Gopal C.
VanLeeuwen Leslie A.
LandOfFree
Checkpoint logging without checkpoint display device... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Checkpoint logging without checkpoint display device..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Checkpoint logging without checkpoint display device... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2613907