You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
86 lines
4.4 KiB
XML
86 lines
4.4 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!--
|
|
Copyright (c) 2016, 2020 OpenPOWER Foundation
|
|
|
|
Licensed under the Apache License, Version 2.0 (the "License");
|
|
you may not use this file except in compliance with the License.
|
|
You may obtain a copy of the License at
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
Unless required by applicable law or agreed to in writing, software
|
|
distributed under the License is distributed on an "AS IS" BASIS,
|
|
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
See the License for the specific language governing permissions and
|
|
limitations under the License.
|
|
|
|
-->
|
|
<section xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
version="5.0"
|
|
xml:id="dbdoclet.50569337_66258">
|
|
|
|
<title>Introduction</title>
|
|
|
|
<para>RTAS provides a mechanism which helps OSs avoid the need for
|
|
platform-dependent code that checks for, or recovers from, errors or
|
|
exceptional conditions. The mechanism is used to return information about
|
|
hardware errors which have occurred as well as information about non-error
|
|
events, such as environmental conditions (for example, temperature or
|
|
voltage out-of-bounds) which may need OS attention. This permits RTAS to
|
|
pass hardware event information to the OS in a way which is abstracted from
|
|
the platform hardware. This mechanism primarily presents itself to the OS
|
|
via two RTAS functions,
|
|
<emphasis>event-scan</emphasis> and
|
|
<emphasis>check-exception</emphasis>, which are described further in
|
|
<xref linkend="dbdoclet.50569332_16852"/>. A further RTAS function,
|
|
<emphasis>rtas-last-error</emphasis>, is also provided to return
|
|
information about hardware failures detected specifically within an RTAS
|
|
call.</para>
|
|
|
|
<para>The
|
|
<emphasis>event-scan</emphasis> function is called periodically to check for
|
|
the presence or past occurrence of a hardware event, such as a soft failure
|
|
or voltage condition, which did not cause a program exception or interrupt
|
|
(for example, an ECC error detected and corrected by background scrubbing
|
|
activity). The
|
|
<emphasis>check-exception</emphasis> function is called to provide further
|
|
detail on what platform event has occurred when certain exceptions or
|
|
interrupts are signaled. The events reported by these two functions are
|
|
mutually exclusive on any given platform; that is, a platform may choose to
|
|
notify the OS of a particular event type either through
|
|
<emphasis>event-scan</emphasis> or through an interrupt and
|
|
<emphasis>check-exception</emphasis>, but not both.</para>
|
|
|
|
<para>Since firmware is platform-specific, it can examine hardware
|
|
registers, can often diagnose many kinds of hardware errors down to a root
|
|
cause, and may even perform some very limited kinds of error recovery on
|
|
behalf of the OS. The reporting format, described in this chapter, permits
|
|
firmware to report the type of error which has occurred, what entities in
|
|
the platform were involved in the error, and whether firmware has
|
|
successfully recovered from the error without the need for further OS
|
|
involvement. Firmware may not, in many cases, be able to determine all the
|
|
details of an error, so there are also returned values which indicate this
|
|
fact. Firmware may optionally provide extended error diagnostic
|
|
information, as described in
|
|
<xref linkend="dbdoclet.50569337_79682"/>.</para>
|
|
|
|
<para>The abstractions provided by this architecture enable the handling of
|
|
most platform errors and events without integrating platform-specific code
|
|
into each supported OS.</para>
|
|
|
|
<para><emphasis role="bold">Architecture Note:</emphasis> It is not a goal of the firmware to diagnose all
|
|
hardware failures. Most I/O device failures, for example, will be detected
|
|
and recovered by an associated device driver. Firmware attempts to
|
|
determine the cause of a problem and report what it finds, to aid the end
|
|
user (by providing meaningful diagnostic data for messages) and to prevent
|
|
the loss of error syndrome information. Firmware is never required to
|
|
correct any problem, but in some cases may attempt to do so. System vendors
|
|
who want more extensive error diagnosis may create OS error handlers which
|
|
contain specific hardware knowledge, or could use firmware to collect a
|
|
minimum set of error information which could then be used by diagnostics to
|
|
further analyze the cause of the error.</para>
|
|
|
|
</section>
|