Alpha Diagnostic Environment

Based on diags release 1.44
Stig Telfer, Alpha Processor Inc, 8 December 2000


Contents


Introduction

Some API motherboards, starting with the UP1000, have the ability embedded in their ROMs to test themselves and attempt to diagnose hardware defects. This is broadly known as the Alpha Diagnostic Environment. The objective of this system is to provide high levels of detail about low-level diagnostics, while remaining simple enough to require minimal user training. The Alpha architecture has design features which enable extremely powerful low-level diagnostic access.

Intended Users

The diagnostic environment has been developed with several design goals:

Additional Capabilities of Alpha Diagnostics

The Diagnostic firmware also offers extended functionality in other directions. Principally it adds the ability to boot an embedded operating system kernel (Linux) directly from ROM, bypassing the requirements for a BIOS to setup and control a boot device. This feature (referred to as DBLX) has some clear advantages in specific situations:

The Diagnostic firmware has added flexibility through the ability for the advanced user to download and execute test applets. In this way, tests conceivably could be developed to meet specific problems in the field that are not covered by the standard firmware release.

What the Alpha Diagnostics can't do

A system may have a fault which prevents it from making its first report. In these cases, Alpha Diagnostics relies on other reporting mechanisms. The CPU's internal BIST (built-in self-test) result is directly available on a processor pin, in case of CPU failure. If the power has failed, a power supply should independently report this.

High-level faults such as hard disk corruptions or operating system related issues are beyond the scope of this system. Complementary OS-level tests should be used.


Implementation Details

The firmware evolved from the source tree of the DEC Debug Monitor (DBM), but has moved in a direction taking it from being a development environment to being more suitable for unskilled users. This is done with the design goal of being a usable tool for diagnostic work in the field.

Component Modules

The diagnostics system consists of two levels. For the user the transfer from lower level to higher level is made with with the appearance of a single integrated system.

The diagnostics are built in these two modules because the low-level reset PAL code executes in an environment that doesn't assume the presence of any devices external to the EV6 core, including memory. Due to this, it is carefully written in PAL mode assembler. The high-level native diagnostics module is written in C and enjoys a richer execution environment. In particular, it depends on a memory system that is at least intermittently reliable for stack, data and code.

Architectural Features Exploited by Alpha Diagnostics

The Diagnostics take the user from the very lowest level at which interaction with the machine is feasible to the point where an operating system can be loaded. This is achieved by some unique features of the Alpha architecture:

Platform Availability

At the time of writing, Alpha Diagnostics is available for every API platform with the exception of the DP264. However, it is not shipped by default in every platform's firmware configuration.

Platforms shipped with Alpha Diagnostics include:

Platforms that support Alpha Diagnostics but ship without it include:

For the platforms listed above, is not difficult to upgrade the diagnostic firmware in the field.