Browse Prior Art Database

Hardware Abstracted Communication Protocol for a Service Processor

IP.com Disclosure Number: IPCOM000118238D
Original Publication Date: 1996-Nov-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 2 page(s) / 77K

Publishing Venue

IBM

Related People

Nissen, JP: AUTHOR

Abstract

Disclosed is a flexible software architecture for a generic Service Processor (SP). This architecture allows application specific unique data to be defined for a generic service processor card. Service Processors are normally very specific to a machine type/family. This architecture allows a generic Service Processor card to be used in various machine types/families while still using the same communication format across them.

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

Hardware Abstracted Communication Protocol for a Service Processor

      Disclosed is a flexible software architecture for a generic
Service Processor (SP).  This architecture allows application
specific unique data to be defined for a generic service processor
card.  Service Processors are normally very specific to a machine
type/family.  This architecture allows a generic Service Processor
card to be used in various machine types/families while still using
the same communication format across them.

      The Service Processor communication protocol was defined with
growth in mind.  The protocol consists of a command byte followed by
a four byte address pointer and a single length indicator.  The
command byte defines if the action is a read or a write request.  The
four byte address indicates what particular command is being
attempted.  The length byte refers to how many data bytes should be
expected for a write or how many to return for a read.

      The SP protocol is run out of a dedicated dual port memory
space in the target system NVRAM.  The SP has access to the NVRAM, as
well as the system has access to the NVRAM.  The dual ported
structure allows the system to freely share data with the SP while
still providing a very loosely coupled system.  The system can run
without the SP and the SP can run without the system totally
functioning.

      All messages pertaining to the operating states of the system
are passed to the SP via the SP protocol.  As well, all SP monitored
events (temperature, voltages, communication parameters, etc...) can
be passed back to the system through the communication protocol.  In
older systems a unique protocol was defined for each application of a
service processor.  This protocol is defined and is meant to be
generic enough to work with very large systems as well as very small
uni-processor systems.  The four bytes of address defined in the SP
protocol allows up to 4GB of unique read/write commands to be
defined.  Presently, only about 17MB of the 4GB is actually defined
to known functions and the other space is reserved for...