Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1998-09-30
2001-04-17
Powell, Mark R. (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C713S002000, C714S030000, C714S100000, C711S102000, C711S103000, C711S104000
Reexamination Certificate
active
06219828
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates in general to controlling a data processing system after startup, but before control is passed to the main operating system and in particular to use of an Open Firmware user interface as a debugging tool.
Still more particularly, the present invention relates to debugging an Open Firmware boot routine before the main operating system is installed.
2. Description of the Related Art
In most data processing systems (or computers), a Basic Input Output System (“BIOS”) is required at startup. BIOS is essential microcode that tests computer hardware at startup, hands over operation to the main operating system and handles data transfer between hardware devices in the data processing system. The BIOS is generally stored in non-volatile, read-only memory (“ROM”) so that it may be executed when the system is turned on. The combination of the stored microcode and hardware is termed “firmware.” Instructions, generally low level assembly code, are written in code as software and stored into ROM memory which then becomes part of the hardware in the computer.
Developers of “boot” microcode (microcode utilized to start a data processing system) usually employ both hardware and software tools to debug newly developed code.
Generally, the code language contains, or makes available, a specific debugger to correct errors in the new code. Errors may occur when the new code is loaded onto memory and at startup there may not be enough information available to diagnose and fix the problem.
Boot “firmware” is ROM based software that is automatically run when a data processing system is switched on. A primary function of boot firmware is to perform a few basic hardware tests, then load and execute (boot) the primary operating system. A secondary function included in the boot firmware is providing tools for debugging faulty hardware or software.
“Open Firmware” is a non-proprietary standard for boot firmware that is usable on different processors and buses and the terms Open Firmware and boot firmware will be utilized interchangeably. Open firmware is firmware that complies with IEEE Standard 1275-1990 and provides an interface independent of processor types. This allows a peripheral device added to the data processing system, to identify itself and supply a boot driver that will allow the device to be utilized on any system. Boot firmware conforming to IEEE Standard 1275-1990 also includes a user interface with debugging capabilities that allows operating systems and system loaders to utilize boot firmware to assist in a system configuration and initialization process.
IEEE Standard 1275-1990 also specifies a processor independent mechanism by which a system can interrogate and configure expansion devices and install device drivers.
In a firmware environment, boot firmware encodes drivers in a machine-independent language called Fcode, a byte-coded intermediate language for the Forth programming language. Forth is based on a stack-oriented “virtual machine” that may be implemented on virtually any computer and when testing newly developed Forth code, an existing Forth code debugger is utilized to resolve errors. Using Fcode, the boot process builds a device tree, which is a hierarchical data structure describing the system hardware.
Plug-in devices describe their own characteristics with Fcode and the characteristics are stored in the device tree.
Fcode drivers are compiled into system RAM for later execution and may be utilized on data processing systems with different processor types. When a boot firmware image (a copy of ROM based boot firmware) is loaded into system memory, the boot firmware interpreter evaluates and expands boot firmware byte code into machine codes. During the execution of the expansion from Fcode into machine codes, errors can occur due to new codes being added or a new device with Fcode being probed. These errors cause the Boot firmware to take exceptions and halt the system. Generally, there is not enough information to debug these errors. Most of the time, developers need to rely on hardware debug tools to resolve errors.
FIG. 3
depicts a high-level flow chart describing the boot process, utilizing Open Firmware, as is known in the prior art. The process begins with step
300
, which depicts power being turned on. The process continues to step
302
, which illustrates a loader within the boot firmware loading or copying the boot routine, in this case Open Firmware, into system memory. The process next passes to step
304
, which depicts the processor executing the boot routine that has been copied into system memory. The process then proceeds to step
306
which illustrates the processor executing the Forth interpreter. The process next passes to step
308
, which depicts the full Open Firmware image (copy) executing.
The process passes to step
310
, which illustrates Open Firmware exploring the system bus for devices. The process next proceeds to step
312
, which depicts Open Firmware building a device-tree by loading device drivers of system components (buses, plug-in devices, etc.) into system memory. This device tree represents physical connections between devices and may be utilized by the operating system to configure itself, locate particular devices, attach device drivers and so on.
The process next passes to step
314
, which depicts Open Firmware creating an execution environment (typically utilizing a Forth language compliant kernel) and loading the primary operating system to memory. At this point the primary operating system can utilize the Open Firmware drivers or it can load its own drivers and erase the boot image from memory. The process then continues to step
316
, which illustrates the operating system taking control of the data processing system.
Low level firmware debug is a very difficult and a common problem for the computer industry as a whole, often requiring hardware assistance. Generally, boot firmware has an interpreter that provides a set of programmable debugging features to allow system problems to be isolated in the event of failure.
It would be desirable therefore, to provide a debugging tool to debug the above mentioned errors during Boot firmware execution. Additionally, it would be desirable to maintain a firmware debugger in the system which may help to resolve errors when testing newly developed Boot firmware Forth code.
SUMMARY OF THE INVENTION
It is therefore one object of the present invention to provide a debugging tool that would remain resident in memory.
It is another object of the present invention to allow the debugging tool to be invoked by the boot firmware developer.
It is yet another object of the present invention to complement an existing Forth code debugger when testing newly developed boot firmware Forth code. The foregoing objects are achieved as is now described.
A first copy of Open Firmware is loaded into system memory to supply a debug function and a second copy of the same firmware is then loaded to provide functional code that is to be debugged. The first copy firmware image in system memory is designated as the resident debugging function.
Kernel code, within the image, sets up an executing environment for the debugger, such as system exception handlers and debug console enablement. Normal Open Firmware configuration variables are retrieved from Non-Volatile Random Access Memory (“NVRAM”) by the first copy and transmitted to the loader. The second copy of Open Firmware is loaded into system memory to the location specified by the configuration variables. The second copy firmware image is designated as a normal Open Firmware operation in the system. The second copy initially takes over all system exception handlers except instruction breakpoint exception, program interrupt exception and trace exception. The instruction breakpoint exception is utilized to invoke the first copy, or resident debugger, from the normal Open Firmware image during code debugging processes. The two copy debugging configuration is utilized in conjunction with
Booker Kelvin E.
Felsman Bradley Vaden Gunter & Dillon, LLP
International Business Machines - Corporation
Powell Mark R.
VanLeeuwen Leslie A.
LandOfFree
Method for using two copies of open firmware for self debug... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method for using two copies of open firmware for self debug..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for using two copies of open firmware for self debug... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2548339