Browse Prior Art Database

Pipelined Processor Boot Strap Procedure

IP.com Disclosure Number: IPCOM000108089D
Original Publication Date: 1992-Apr-01
Included in the Prior Art Database: 2005-Mar-22
Document File: 3 page(s) / 116K

Publishing Venue

IBM

Related People

Duncan, KJ: AUTHOR [+2]

Abstract

A method for performing an IPL (initial program load) of a pipelined microprocessor without having ROS (read-only storage) available is disclosed.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Pipelined Processor Boot Strap Procedure

       A method for performing an IPL (initial program load) of
a pipelined microprocessor without having ROS (read-only storage)
available is disclosed.

      This invention makes the following assumptions:
o    The microprocessor is scannable
o    There is a mechanism to "talk" to the microprocessor (RS-232
connection)

      The following sequence will allow a microprocessor to IPL
without having initial ROS available:  The microprocessor powers up
in an unknown state and is executing unknown instructions from
unknown addresses.  A HALT of the microprocessor is performed.  A
SCAN-IN of a known good microprocessor state (instruction pointer,
instruction pipeline, registers, etc.) is performed.  The above
instruction pipeline is filled with the following:
o    Enable memory
o    Write small interrupt handler into memory (able to receive/load
microprocessor initialization routine into memory)
o    Simple code loop (branches to itself)

      The microprocessor is now in a known state and a START is
performed.  The microprocessor initialization routine is then loaded
into memory via the RS-232 connection and the existing small
interrupt handler.  When the initialization routine is loaded into
memory, it is passed control and, from then on, everything looks as
though the IPL occurred via the ROS.

      All processors require code instructions to do any useful work.
If no instructions are available when the processor is ready to fetch
and execute them, then the processor will enter an unknown state
which is dependent upon what is "fetched" during the fetch cycle.  If
the memory which contains the code instructions or some path along
the way is failing, then the processor will enter this unknown state.

      Once it enters this unknown state, it is very difficult, if not
impossible, to determine the cause of the failure because in order to
obtain data about the failure we must be able to communicate with or
monitor the processor.

      By monitoring the processor, we can determine which
instructions are getting executed, if any, and make an educated guess
as to what the failure may be.  The failure may be due to a bad
memory module, a bad processor, a failing address/data line, etc.  By
communicating with the processor, we can determine in more detail
what is causing the failure.  This is accomplished by reading
internal registers, error logs, etc.

      Using current tools, we are only able to monitor the processor
...