Browse Prior Art Database

Platform independent capture of Server System boot progress and errors

IP.com Disclosure Number: IPCOM000240919D
Publication Date: 2015-Mar-12
Document File: 7 page(s) / 117K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is the method to capture server system boot progress and errors

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 44% of the total text.

Page 01 of 7

Platform independent capture of Server System boot progress and errors

In a typical server system hardware, we have the boot code which triggers Service Processor (SP) code which in turn brings the machine to standby. In these servers we have an Operator-Panel hardware which has a two line 16 character LCD display along with some buttons. The Operator-Panel is used to see the state (EX: Progress/Error codes) and also select configuration/operations (EX: running mode, power transition, configuration changes) via buttons for the machine. This Operator-Panel is an embedded system with its own micro-processor. Communications between the Service Processor and the Operator-Panel in our implementation is via a multi-mastered IIC interface.

When system gets it's initial power-on-reset (POR), the embedded panel initializes and drives an indicator to the display to indicate the Operator-Panel and Service Processor hardware are functional. An examples of the indicators used would be a bouncing ball going across display. The bouncing ball would make way for the information only once the SP code has started. The bouncing ball indicator display would cease being displayed when the SP code is initialized and starts driving data to the panel via the PANEL

SP interface (IIC multi-mastered interface).

There is a couple of problems with this legacy design:

Very Early Kernel Boot Progress codes were not possible since communicating on the IIC interfaces as a multi-master requires lengthy setup. This resulted in a large execution window where no progress codes can be posted. The result here is that the embedded panel functional indicator (EX: Bouncing Ball) is displayed over a larger then desired window. Any failure in this window results in no information on the nature of the boot code failure being displayed.

Kernel Boot Progress communications to the panel was specific to early progress codes. Once the device drivers are fully loaded and functional and control is passed to the SP, the code no longer flowed through the early boot progress code. In effect code was written to hack in early progress codes as early as possible. Then this code path is abandoned once far enough along in the SP initialization to use regular device driver paths. A high level of effort is required in boot code to provide progress codes. Due to resource constraints and the buggy nature of trying to drive multi-mastered IIC communications within boot code it is desired to move away from early boot progress codes.

Kernel Progress codes are not portable from system to system (different series of server systems). The Service Processor chip and therefore the early boot code may be used across varied platforms that would have unique platform display requirements. It is advantages to not push progress code specifics into the Kernel boot code. The result is a less portable Kernel.

This article teaches to move away from IIC multi-master communication of early boot progress codes. The...