systemsoftware
/
Linux-Architecture-Reference
34
1
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
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.
master
papr_2.9+
papr_2.7
lopar-2.9
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '0ca21985c2'
${ noResults }
Linux-Architecture-Reference/Platform/ch_system_reqs.xml

2698 lines
116 KiB
XML
Raw Blame History

<?xml version="1.0"?>
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xl="http://www.w3.org/1999/xlink"
xml:id="dbdoclet.50569327_31987"
version="5.0"
xml:lang="en">
<title>System Requirements</title>
<para>This chapter gives an operational overview of LoPAR systems and
introduces platform specific software and/or firmware components that are
required for OS support. This chapter also addresses some system level
requirements that are broad in nature and are fundamental to the architecture
described in later chapters. Lastly, a table of requirements is presented as a
guide for platform providers.</para>
<section xml:id="dbdoclet.50569327_34213">
<title>System Operation</title>
<section>
<title>Control Flow</title>
<para><xref linkend="dbdoclet.50569327_36627"/> is an example of typical
phases of operation from power-on to full system operation to termination. This
section gives an overview of the processes involved in moving through these
phases of operation. This section will introduce concepts and terms that will
be explained in more detail in the following chapters. Most requirements
relating to these processes will also appear in later chapters.</para>
<para>The discussion in this chapter will be restricted to systems with a
single processor. Refer to <xref linkend="dbdoclet.50569340_14972"/> for the
unique requirements relating to multiprocessor systems.</para>
<figure xml:id="dbdoclet.50569327_36627">
<title>Phases of Operation (example)</title>
<mediaobject>
<imageobject role="html">
<imagedata fileref="figures/PAPR-6.gif" format="GIF" scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%" fileref="figures/PAPR-6.gif" format="GIF" scalefit="1" width="100%"/>
</imageobject>
</mediaobject>
</figure>
</section>
<section xml:id="dbdoclet.50569327_marker-518472">
<title>POST</title>
<para>Power On Self Test (POST) is the process by which the
firmware tests those areas of the hardware that are critical to its ability to
carry out the boot process. It is not intended to be all-inclusive or to be
sophisticated in how it relates to the user. Diagnostics with these
characteristics will generally be provided as a service aid.</para>
<para><emphasis role="bold">Platform Implementation Note:</emphasis> The platform
may choose to utilize a service processor to assist in the implementation of
functions during various phases of operation. The service (or support)
processor is not a requirement of this architecture, but is usually seen in the
larger systems.</para>
</section>
<section>
<title>Boot Phase</title>
<para>The following sections describe the boot phase of operation. The
fundamental parts of the boot phase are:</para>
<orderedlist>
<listitem>
<para>Identify and configure system components.</para>
</listitem>
<listitem>
<para>Generate a device tree.</para>
</listitem>
<listitem>
<para>Initialize/reset system components.</para>
</listitem>
<listitem>
<para>Locate an OS boot image.</para>
</listitem>
<listitem>
<para>Load the boot image into memory.</para>
</listitem>
</orderedlist>
<section xml:id="sec_id_config_sys">
<title>Identify and Configure System Components</title>
<para>Firmware is generally written with a hardware in mind, so some
components and their configuration data can be hardcoded. Examples of these
components are: type of processor, cache characteristics, and the use of
imbedded components on the planar. This hardcoding is not a requirement, only a
practical approach to a part of this task.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_id_config_sys"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>The firmware must, by various means,
become aware of all components in the system associated with the boot process
and configure or reset those components into a known state (components include,
for example, buses, bridges, I/O Adapters (IOAs)<footnote xml:id="pgfId-1056022"><para>
See <xref linkend="dbdoclet.50569388_37308"/> for
the definition of an IOA.</para></footnote>,
and I/O devices).</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_id_config_sys"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para>The firmware must obtain certain system
information which is necessary to build the OF device tree from
&#x201C;walking&#x201D; the I/O buses (for example, identification of IOAs and
bridges).</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="sec_gen_dev_tree">
<title>Generate a Device Tree</title>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_gen_dev_tree"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>The firmware must build a device tree
and the OS must gain access to the device tree through Client Interface
Services (CIS).</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_gen_dev_tree"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para>Configuration information
(configuration variables) which are stored in non-volatile memory must be
stored under the partition names <emphasis role="bold"><literal>of-config</literal></emphasis> or
<emphasis role="bold"><literal>common</literal></emphasis>, depending on the nature of the information (see
<xref linkend="dbdoclet.50569333_15433"/>).</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="sec_init_reset_sys_comp">
<title>Initialize/Reset System Components</title>
<para>The OS requires devices to be in a known state at the time control
is transferred from the firmware. Firmware may gain control with the hardware
in various states depending on what has initiated the boot process.</para>
<itemizedlist>
<listitem>
<para>Normal boot: Initiated by a power-on sequence; all devices and
registers begin in a hardware reset state.</para>
</listitem>
<listitem>
<para>Reboot: Device state is unpredictable at the start of a
reboot.</para>
</listitem>
</itemizedlist>
<para>The hardware reset state for a device is an inactive state. An
inactive state is defined as a state that allows no system level activity;
there can be no bus activity, interrupt requests, or DMA requests possible from
the IOA that is in a reset state. Since the OS may configure devices in a
manner that requires very specific control over these functions to avoid
transitory resource conflicts, these functions should be disabled at the device
and not at a central controlling agent (for example, the interrupt controller).
Devices that do not share any resources may have these resources disabled at a
system level (for example, keyboard interrupts may be disabled at the interrupt
controller in standard configurations).</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_init_reset_sys_comp"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>IOAs must adhere to the reset states
given in <xref linkend="dbdoclet.50569327_14035"/> when control of the system
is passed from firmware to an OS.</para>
<table frame="all" pgwide="1" xml:id="dbdoclet.50569327_14035">
<?dbhtml table-width="75%" ?><?dbfo table-width="75%" ?>
<title>IOA Reset States</title>
<tgroup cols="3">
<colspec colname="c1" colwidth="20*"/>
<colspec colname="c2" colwidth="40*"/>
<colspec colname="c3" colwidth="40*"/>
<thead valign="middle">
<row>
<entry align="center">
<para>
<emphasis role="bold">Bus</emphasis>
</para>
</entry>
<entry align="center">
<para>
<emphasis role="bold">IOAs Left Open by OF</emphasis>
</para>
</entry>
<entry align="center">
<para>
<emphasis role="bold">Other IOAs</emphasis>
</para>
</entry>
</row>
</thead>
<tbody valign="middle">
<row>
<entry>
<para> PCI</para>
</entry>
<entry>
<para>Interrupts not active <?linebreak?>
No outstanding I/O operations<?linebreak?>
IOA is configured</para>
</entry>
<entry>
<para> The IOA is <emphasis>inactive:</emphasis></para>
<itemizedlist spacing="compact">
<listitem><para>I/O access response disabled</para></listitem>
<listitem><para>Memory access response disabled</para></listitem>
<listitem><para>PCI master access disabled</para></listitem>
<listitem><para>Interrupts not active</para></listitem>
</itemizedlist>
<para>IOA is reset (see note)</para>
</entry>
</row>
<row>
<entry>
<para> System</para>
</entry>
<entry>
<para> Configured per OF device tree</para>
<itemizedlist spacing="compact">
<listitem><para>Interrupts inactive</para></listitem>
<listitem><para>DMA inactive</para></listitem>
<listitem><para>No outstanding I/O operations</para></listitem>
</itemizedlist>
</entry>
<entry>
<para> The IOA is in hardware reset state (see note) or <emphasis>inactive</emphasis>:</para>
<itemizedlist spacing="compact">
<listitem><para>Interrupts inactive</para></listitem>
<listitem><para>DMA inactive</para></listitem>
</itemizedlist>
</entry>
</row>
</tbody>
</tgroup>
</table>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_init_reset_sys_comp"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para>The platform must include the root node
OF device tree property <emphasis role="bold"><literal>&#x201C;ibm,pci-full-cfg&#x201D;</literal></emphasis> with a
value of 1 and configure the configuration registers of all PCI IOAs and
bridges as specified by Requirement <xref linkend="dbdoclet.50569335_13568"/>.</para>
</listitem>
</varlistentry>
<varlistentry xml:id="dbdoclet.50569327_47242">
<term><emphasis role="bold">R1-<xref linkend="sec_init_reset_sys_comp"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
<listitem>
<para>Prior to passing control to the OS, the platform must initialize all processor registers to a value which, if
accessed, will not yield a machine check.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_init_reset_sys_comp"
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
<listitem>
<para>Prior to passing control to the OS, the
platform must initialize all registers not visible to the OS to a state that is
consistent with the system view represented by the OF device tree.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_init_reset_sys_comp"
xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
<listitem>
<para>During boot or reboot operations and
prior to passing control to the OS, the platform must initialize the interrupt
controller.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_init_reset_sys_comp"
xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
<listitem>
<para>Hardware must provide a mechanism,
callable by software, to hard reset all processors and I/O subsystems in order
to facilitate the implementation of the RTAS <emphasis>system-reboot</emphasis> function.</para>
</listitem>
</varlistentry>
</variablelist>
<para><emphasis role="bold">Platform Implementation Note:</emphasis> The platform
is required to reset the interrupt controller to avoid inconsistency among the
states of IOAs, the interrupt controller, and software interrupt handler
routines. The reset state is shown in <xref linkend="dbdoclet.50569327_14035"/>.</para>
<para><emphasis role="bold">Software and Firmware Implementation Note:</emphasis>
The conventional PCI configuration registers are further described in the
<xref linkend="dbdoclet.50569387_65468"/> and are copied into OF properties described
in the <xref linkend="dbdoclet.50569387_22451"/>. PCI-X configuration registers
are further described in the <xref linkend="dbdoclet.50569387_26550"/>. PCI
Express configuration registers are further described in the
<xref linkend="dbdoclet.50569387_66784"/>. PCI-X IOAs and bridges and PCI Express
IOAs, bridges, and switches are treated the same as conventional PCI IOAs and
bridges for purposes of generation of OF properties. </para>
<para><emphasis role="bold">Software and Firmware Implementation Note:</emphasis> In
reference to Requirement <xref linkend="dbdoclet.50569327_47242"/>, generally
the initial value of processor registers is contained in the processor binding.
However, some processors have deviations on register usage. Also, since some
register implementation is optional, all processors are not the same.</para>
</section>
<section xml:id="dbdoclet.50569327_28943">
<title>Locate an OS Boot Image </title>
<para>The OS boot image is located as described in
<xref linkend="LoPAR.DeviceTree"/>. A device and filename can be specified directly
from the command interpreter (the <emphasis>boot</emphasis> command) or OF
will locate the image through an automatic boot process controlled by
configuration variables. Once a boot image is located, the device path is set
in the device tree as the <emphasis role="bold"><literal>&#x201C;bootpath&#x201D;</literal></emphasis>
property of the <emphasis role="bold"><literal>chosen</literal></emphasis> node.</para>
<para>The devices searched by the automatic boot process are those
contained in the <emphasis role="bold"><literal>boot-device</literal></emphasis> configuration variable.
Implementations may choose to limit the number of boot device entries that are
searched. The root node device tree property
<emphasis role="bold"><literal>&#x201C;ibm,max-boot-devices&#x201D;</literal></emphasis> communicates the number of
<emphasis role="bold"><literal>boot-device</literal></emphasis> entries that the platform processes.</para>
<para>If multi-boot (multiple bootable OSs residing on the same platform) is supported,
a configuration variable instructs the firmware to display a multi-boot menu
from which the OS and bootpath are selected. See <xref linkend="LoPAR.DeviceTree"/>
for information relating to the multiboot process.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_28943"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>The platform must supply in the OF root
node the <emphasis role="bold"><literal>&#x201C;ibm,max-boot-devices&#x201D;</literal></emphasis> property.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section>
<title>Load the Boot Image into Memory</title>
<para>After locating the image, it is loaded into memory at the location
given by a configuration variable or as specified by the OS load image format.</para>
</section>
<section xml:id="dbdoclet.50569327_26247">
<title>Boot Process</title>
<para>The boot process is described in <xref linkend="LoPAR.DeviceTree"/>.
Steps in the process are reviewed here, but the
authoritative and complete description of the process is included in
<xref linkend="LoPAR.DeviceTree"/>. <xref linkend="dbdoclet.50569327_17087"/> is a
depiction of the boot flow showing the action of the f1, f5, and f6 function
keys. The figure should only be used as an aid in understanding the
requirements for LoPAR systems.</para>
<para>&#xA0;</para>
<figure xml:id="dbdoclet.50569327_17087">
<title>Boot Process</title>
<mediaobject>
<imageobject role="html">
<imagedata fileref="figures/PAPR-7.gif" format="GIF" scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%" fileref="figures/PAPR-7.gif" format="GIF" scalefit="1" width="100%"/>
</imageobject>
</mediaobject>
</figure>
<section xml:id="dbdoclet.50569327_marker-522627">
<title>The Boot Prompt</title>
<variablelist >
<varlistentry xml:id="dbdoclet.50569327_26836">
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_marker-522627"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>After the <emphasis role="bold"><literal>banner</literal></emphasis> step of the boot sequence, the platform display must present
a clearly visible graphical or text message (<emphasis>boot prompt</emphasis>), and
must provide a reaction window of at least 3 seconds that prompts the
user to activate various options including the f1, f5, and f6 control keys
detailed in this document.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_marker-522627"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para>The functions provided by f1, f5 and
f6 described in this chapter must be equivalently provided by the tty numeral
keys 1, 5, and 6, respectively when a serial terminal is attached.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_marker-522627"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
<listitem>
<para>The boot prompt must identify the
platform and communicate to the user that there are options that may be invoked
to alter the boot process.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="sec_sms_menu">
<title>The Menus</title>
<para>Once the boot prompt is displayed, the System Management Services
(SMS) menu can be invoked. SMS provides a user interface for utilities,
configuration, and the Multiboot Menu (as introduced in
<xref linkend="LoPAR.DeviceTree"/>) for boot/install and the OF command
interpreter.</para>
<para>The Multiboot menu is formatted so that block devices that
currently contain boot information are most easily selected by the user.
Because of the serial nature of byte devices, they should not be opened unless
specifically included in a boot list. The user may also wish to add devices to
the boot-device and/or diag-device configuration variables (boot lists) that
currently do not contain boot information. The Multiboot menu presents these
devices in a secondary manner.</para>
<para>If the Multiboot Menu boot/install option is chosen, OF will
execute the <literal>bootinfo.txt&lt;boot-script&gt;</literal> of the
selected OS, and if the user elects to make this the default, the
<emphasis role="bold"><literal>boot-command</literal></emphasis> variable will be set equal to the contents of
<literal>bootinfo.txt&lt;boot-script&gt;</literal>.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_sms_menu"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>The SMS menu must provide a means to
display the Multiboot Menu.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_sms_menu"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para>If, after the <emphasis>boot
prompt</emphasis> is displayed,
<emphasis role="bold"><literal>auto-boot?</literal></emphasis> <literal>= false</literal>
and <emphasis role="bold"><literal>menu?</literal></emphasis> <literal>= true</literal>,
the firmware must display the Multiboot Menu directly. </para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_sms_menu"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
<listitem>
<para>The Multiboot Menu must present all
potential boot device options, differentiating block devices that contain
locatable <emphasis>bootinfo objects</emphasis>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_sms_menu"
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
<listitem>
<para>Firmware must evaluate all
<emphasis>bootinfo objects</emphasis> at each invocation of the Multiboot Menu to ensure
that any modifications made by the OS will be included.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_sms_menu"
xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
<listitem>
<para>The Multiboot Menu must provide a
means to enter the currently selected boot option into the desired location
within the <emphasis role="bold"><literal>boot-device/boot-file</literal></emphasis> or
<emphasis role="bold"><literal>diag-device/diag-file</literal></emphasis> configuration variables.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_sms_menu"
xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
<listitem>
<para>The platform must provide a means to
delete individual boot options from the
<emphasis role="bold"><literal>boot-device/boot-file</literal></emphasis> and
<emphasis role="bold"><literal>diag-device/diag-file</literal></emphasis> configuration variables.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_sms_menu"
xrefstyle="select: labelnumber nopage"/>-7.</emphasis></term>
<listitem>
<para>The Multiboot Menu must provide an
option for the user to select whether or not to return to the Multiboot Menu on
each boot.</para>
</listitem>
</varlistentry>
</variablelist>
<para><emphasis role="bold">Firmware Implementation Note:</emphasis> Returning to the Multiboot Menu on
reboot is controlled with the <emphasis role="bold"><literal>auto-boot?</literal></emphasis> and
<emphasis role="bold"><literal>menu?</literal></emphasis> configuration variables.</para>
</section>
<section xml:id="sec_f1_key">
<title>The f1 Key</title>
<para>The boot process is further controlled by the
<emphasis role="bold"><literal>auto-boot?</literal></emphasis> and
<emphasis role="bold"><literal>menu?</literal></emphasis>
OF configuration variables and the f1 key.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_f1_key"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>If, after the <emphasis>boot
prompt</emphasis> is displayed, function key f1 is pushed or if
<emphasis role="bold"><literal>auto-boot?</literal></emphasis> <literal>= false</literal> and
<emphasis role="bold"><literal>menu?</literal></emphasis> <literal>= false</literal>, the firmware must display the
System Management Services (SMS) menu.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_f1_key"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para>The default value for the
<emphasis role="bold"><literal>auto-boot?</literal></emphasis> configuration variable must be
<literal>true</literal>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_f1_key"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
<listitem>
<para>The default value for the
<emphasis role="bold"><literal>menu?</literal></emphasis> configuration variable must be
<literal>false</literal>.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="sec_f5_f6_key">
<title>The f5 and f6 Keys</title>
<para>If <emphasis role="bold"><literal>auto-boot?</literal></emphasis> <literal>= true</literal>,
the commands specified by the <emphasis role="bold"><literal>boot-command</literal></emphasis> configuration
variable are executed.</para>
<para>If the <emphasis role="bold"><literal>boot</literal></emphasis> command has no arguments, IEEE
1275 states that the arguments are determined as follows:</para>
<itemizedlist>
<listitem>
<para>Normal Boot - If the
<emphasis role="bold"><literal>diagnostic-mode?</literal></emphasis>FCode
function returns <literal>false</literal>, the boot
device is given by <emphasis role="bold"><literal>boot-device</literal></emphasis> and the default boot
arguments are given by <emphasis role="bold"><literal>boot-file</literal></emphasis>.</para>
</listitem>
<listitem>
<para>Diagnostics Boot - If the <emphasis role="bold"><literal>diagnostic-mode?</literal></emphasis>
FCode function returns <literal>true</literal>, the boot device is given by
<emphasis role="bold"><literal>diag-device</literal></emphasis> and the default boot arguments are given by
<emphasis role="bold"><literal>diag-file</literal></emphasis>.</para>
</listitem>
</itemizedlist>
<para><emphasis role="bold">Platform Implementation Note:</emphasis>
<emphasis role="bold"><literal>boot-device</literal></emphasis>,
<emphasis role="bold"><literal>boot-file</literal></emphasis>,
<emphasis role="bold"><literal>diag-device</literal></emphasis> and
<emphasis role="bold"><literal>diag-file</literal></emphasis>
are potentially multi-entry strings. The
<emphasis role="bold"><literal>boot-command</literal></emphasis> searches the
devices specified in <emphasis role="bold"><literal>boot-device/diag-device</literal></emphasis> in the order
defined by the string for the <emphasis role="bold"><literal>boot-file/diag-file</literal></emphasis> to load
into system memory. Failure occurs only if no corresponding file is
found/usable on any of the specified devices.</para>
<para>Platforms give the user the ability to control the boot process
further with function keys f5 and f6 (within the window described in
Requirement <xref linkend="dbdoclet.50569327_26836"/>).</para>
<variablelist>
<varlistentry xml:id="dbdoclet.50569327_16622">
<term><emphasis role="bold">R1-<xref linkend="sec_f5_f6_key"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>If, after the <emphasis>boot prompt</emphasis> is displayed, function key f5 is pushed (and
<emphasis role="bold"><literal>auto-boot?</literal></emphasis> <literal>= true</literal>), then
<emphasis role="bold"><literal>diagnostic-mode?</literal></emphasis> must return <literal>true</literal> and the
<emphasis>default diagnostic device</emphasis> as defined in Requirements
<xref linkend="dbdoclet.50569327_17276"/> and
<xref linkend="dbdoclet.50569327_24271"/> must be used to locate bootable
media.</para>
</listitem>
</varlistentry>
<varlistentry xml:id="dbdoclet.50569327_25473">
<term><emphasis role="bold">R1-<xref linkend="sec_f5_f6_key"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para>If, after the <emphasis>boot prompt</emphasis> is displayed, function key f6 is pushed (and
<emphasis role="bold"><literal>auto-boot?</literal></emphasis> <literal>= true</literal>), then
<emphasis role="bold"><literal>diagnostic-mode?</literal></emphasis> must return <literal>true</literal> and
<emphasis role="bold"><literal>diag-device</literal></emphasis> must be used to locate the boot image, else
if <emphasis role="bold"><literal>diag-device</literal></emphasis> is empty, then its default as defined in
Requirements <xref linkend="dbdoclet.50569327_17276"/> and
<xref linkend="dbdoclet.50569327_24271"/> must be used to locate bootable
media.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_f5_f6_key"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
<listitem>
<para><emphasis role="bold"><literal>boot-command</literal></emphasis>
must default to <emphasis role="bold"><literal>boot</literal></emphasis> <literal>&lt;with no
arguments&gt;</literal>.</para>
</listitem>
</varlistentry>
<varlistentry xml:id="dbdoclet.50569327_17276">
<term><emphasis role="bold">R1-<xref linkend="sec_f5_f6_key"
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
<listitem>
<para><emphasis role="bold"><literal>boot-device</literal></emphasis> and
<emphasis role="bold"><literal>diag-device</literal></emphasis>
must default to the first devices of each type that
would be encountered by a search of the device tree.</para>
</listitem>
</varlistentry>
<varlistentry xml:id="dbdoclet.50569327_24271">
<term><emphasis role="bold">R1-<xref linkend="sec_f5_f6_key"
xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
<listitem>
<para>The search order for the
<emphasis role="bold"><literal>boot-device</literal></emphasis> and
<emphasis role="bold"><literal>diag-device</literal></emphasis>
defaults must be floppy, cdrom, tape, disk, network.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_f5_f6_key"
xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
<listitem>
<para><emphasis role="bold"><literal>boot-file</literal></emphasis> must
default to <literal>&lt;null&gt;</literal>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_f5_f6_key"
xrefstyle="select: labelnumber nopage"/>-7.</emphasis></term>
<listitem>
<para><emphasis role="bold"><literal>diag-file</literal></emphasis> must
default to <literal>diag</literal>.</para>
</listitem>
</varlistentry>
</variablelist>
<para><emphasis role="bold">Note:</emphasis> Requirement
<xref linkend="dbdoclet.50569327_16622"/> provides a method to invoke stand-alone
diagnostics or to start reinstallation without going through the menus.
Requirement <xref linkend="dbdoclet.50569327_25473"/> provides a method to boot
with on-line diagnostics.</para>
<para><emphasis role="bold">Software Implementation Note:</emphasis> Pressing either f5 or f6 at the
correct time will cause the contents of <emphasis role="bold"><literal>diag-file</literal></emphasis> to be
set into the <emphasis role="bold"><literal>&#x201C;bootargs&#x201D;</literal></emphasis> property of the
<emphasis role="bold"><literal>chosen</literal></emphasis> node of the device tree. The OS can recognize a
diagnostics boot request when it finds the <emphasis role="bold"><literal>&#x201C;diag&#x201D;</literal></emphasis>
substring in <emphasis role="bold"><literal>&#x201C;bootargs&#x201D;</literal></emphasis>.</para>
</section>
<section xml:id="sec_cd_boot">
<title>CDROM Boot</title>
<para>If the CDROM is the first bootable media found in the devices
listed in the bootlist (<emphasis role="bold"><literal>boot-device</literal></emphasis> strings), the CDROM
should boot without having to enter optional file specification information or
using the f5 function key normally used for diagnostic boot. This is
accomplished by having the appropriate <literal>bootinfo.txt</literal> file
specification in the CDROM entry in the bootlist.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_cd_boot"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>CDROM entries for the default OF
<emphasis role="bold"><literal>boot-device</literal></emphasis> and
<emphasis role="bold"><literal>diag-device</literal></emphasis>
configuration variables must include the standard block device
<literal>bootinfo.txt</literal> file specification as documented in
<xref linkend="LoPAR.DeviceTree"/> (<literal>\ppc\bootinfo.txt</literal>).</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="dbdoclet.50569327_20641">
<title>Tape Boot</title>
<para>Boot from tape is defined in <xref linkend="LoPAR.DeviceTree"/>.</para>
</section>
<section xml:id="sec_network_boot">
<title>Network Boot</title>
<para>The user selects from a list of network devices on the Multiboot
Menu and then selects the boot option. The user may be prompted for network
parameters (IP addresses, etc.) which are set as arguments in
<emphasis role="bold"><literal>boot-device</literal></emphasis> by the firmware. If the BOOTP protocol is used, the
BOOTREPLY packet contains the network parameters to be used for subsequent
transmissions (see <xref linkend="dbdoclet.50569387_31707"/> for details of
this process).</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_network_boot"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>If network boot is selected, firmware
must provide a means for the user to specify or override network parameters.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="dbdoclet.50569327_23654">
<title>Service Processor Boot</title>
<para>In platforms with a service processor, the user may call for a boot
using a local/remote connection to the service processor. The particular port
used for this remote session is sent to the firmware in a status message after
the service processor finishes POST. The port is identified in the
<emphasis role="bold"><literal>&#x201C;stdin&#x201D;</literal></emphasis>
and <emphasis role="bold"><literal>&#x201C;stdout&#x201D;</literal></emphasis>
properties in the <emphasis role="bold"><literal>chosen</literal></emphasis> node of the OF device tree.</para>
</section>
<section xml:id="dbdoclet.50569327_36194">
<title>Console Selection</title>
<para>During the boot process, firmware establishes the console to be
used for displaying status and menus. The following pseudocode describes the
console selection process:
<programlisting><![CDATA[IF there is a configuration change detected for "display", "keyboard" or "mouse"; type
devices OR if a console selection timeout occurred on the last boot,
IF Firmware can locate a supported console device,
Firmware will prompt the user to select a console and wait approximately 60 seconds
for a valid response.
IF a valid response is received within the 60 second timeout,
Use the selected console.
ELSE choose the Primary Serial Port.
ELSE choose the Primary Serial Port.
ELSE
IF input-device and output-device are valid,
Firmware will choose these devices for the console.
ELSE choose the Primary Serial Port.]]></programlisting></para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_36194"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>If a console has been selected during
the boot process, firmware must set the <emphasis role="bold"><literal>&#x201C;stdin&#x201D;</literal></emphasis>
and <emphasis role="bold"><literal>&#x201C;stdout&#x201D;</literal></emphasis> properties of the
<emphasis role="bold"><literal>chosen</literal></emphasis> node to the ihandles of this console&#x2019;s input and
output devices prior to passing control to the OS.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="sec_boot_retry">
<title>Boot Retry</title>
<para> For boot failures related to firmware trying to access a boot
device, it is appropriate for the platform to retry the boot operation,
especially in the case of booting from a network device. However, in platforms
which have a service processor, there are several other types of detected
errors for which a reboot retry may be appropriate; for example, checkstops or
loss of communication between firmware and the service processor. To ensure
that the user policy is followed, the coordination and counting of retry
attempts need to be interlocked between the service processor and boot
firmware. The most straightforward way to implement this is to have the boot
firmware inform the service processor of all failed boot attempts, and let the
service processor initiate the system reset (as it also would for checkstops or
hangs). This way the service processor can easily manage the retry count and
initiate a service dial-out if the boot retry limit is exceeded.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_boot_retry"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para><emphasis>Platform
Implementation:</emphasis> In platforms with service processors, retry of
failed boot operations must be coordinated between boot firmware and the
service processor, to ensure correct counting and handling of reboot retries
according to the service processor configuration reboot policies.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="sec_boot_failures">
<title>Boot Failures</title>
<para>Failure to boot occurs only when no corresponding file is found
which is usable on any device specified in the
<emphasis role="bold"><literal>boot-device</literal></emphasis>,
<emphasis role="bold"><literal>boot-file</literal></emphasis>,
<emphasis role="bold"><literal>diag-device</literal></emphasis>, or
<emphasis role="bold"><literal>diag-file</literal></emphasis> string being used.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_boot_failures"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>If an error occurs in a boot device
preventing boot from that device, and after all defined retries have occurred,
the failure must be reported as a POST error. </para>
</listitem>
</varlistentry>
<varlistentry xml:id="dbdoclet.50569327_89479">
<term><emphasis role="bold">R1-<xref linkend="sec_boot_failures"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para>If a boot device is physically
missing or lacks a boot record (for example, if a CDROM is not present in a
CDROM drive), then a POST error must be generated for this case, must not
result in the calling out of a boot device as being defective, and must not
result in a hardware service repair action to the device. </para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_boot_failures"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
<listitem>
<para>In Requirement
<xref linkend="dbdoclet.50569327_89479"/>, if it is not possible for a device to
distinguish between an actual device error, as opposed to a missing device or
boot record, then a POST error must be generated that indicates the possible
causes of the failure to boot from the device, and this POST error must not
imply that a hardware service repair action is required for the boot
device.</para>
</listitem>
</varlistentry>
</variablelist>
<para><emphasis role="bold">Implementation Note:</emphasis> All device errors of the
same type may be consolidated into a single POST log entry with multiple
location codes listed if needed. This architecture anticipates remote support
center notification of hardware errors. It is the intention that only
definitive boot device errors will be reported as requiring hardware repair.
This is meant to prevent service calls for systems for non-hardware errors such
as no tape in a tape drive.</para>
</section>
<section xml:id="dbdoclet.50569327_70628">
<title>Persistent Memory and Memory Preservation Boot
(Storage Preservation Option)</title>
<para>Selected regions of storage, or Logical Memory Blocks (LMBs), may
be optionally preserved across client program boot cycles. These LMBs are
denoted by the presence of the <emphasis role="bold"><literal>&#x201C;ibm,preservable&#x201D;</literal></emphasis>
property in their OF device tree <emphasis role="bold"><literal>/memory</literal></emphasis> node.
The client program registers the LMB with
the platform using the <emphasis>ibm,manage-storage-preservation</emphasis>
RTAS call if it wants the contents of the storage preserved across client boot
cycles (see also "Managing Storage Preservations" in
<xref linkend="LoPAR.RTAS"/> specification). The architectural intent of this
facility is to enable client programs to emulate persistent storage. This is
done by a client program registering preservable LMBs. Then, after a subsequent
boot cycle (perhaps due to error or impending power loss) the presence of the
<emphasis role="bold"><literal>&#x201C;ibm,preserved-storage&#x201D;</literal></emphasis> property in the
<emphasis role="bold"><literal>/rtas</literal></emphasis> node of the device tree indicates to the client
program that it has preserved memory. When the client program detects that it
has booted with preserved storage and that it might be necessary to preserve
the storage for long term, the client program is responsible for copying the
preserved data to long term persistent storage medium, and then clearing the
registration of the preserved LMBs to prevent potential corruption of the
persistent storage medium due to subsequent failures.</para>
<para>Upon reboot after such an operation, the
<emphasis role="bold"><literal>&#x201C;ibm,request-partition-shutdown&#x201D;</literal></emphasis> property is provided
in the <emphasis role="bold"><literal>/rtas</literal></emphasis> node with a value of 2, indicating that the
client program should save appropriate data and shutdown the partition.</para>
<para><emphasis role="bold">Implementation Note:</emphasis> How areas get chosen to
be marked as preservable is beyond the scope of this architecture.</para>
</section>
</section>
</section>
<section xml:id="sec_transfer_phase">
<title>Transfer Phase</title>
<para>The image is prepared for execution by checking it against certain
configuration variables; this may result in a reboot.</para>
<para>Once the OS gains control, it may use the CIS interface to learn
about the platform contents and configuration. The OS will generally build its
own version of this configuration data and may discard the OF code and device
tree in order to reclaim the space used by OF. A set of
platform-specific functions are provided by Run-Time Abstraction Services
(RTAS) which is instantiated by the OS invoking the
<emphasis role="bold"><literal>instantiate-rtas</literal></emphasis> method of the RTAS OF device tree node.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_transfer_phase"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>If any device tree property is presented
that contains a phandle value to identify a certain node in the device tree,
the device tree node so identified must contain the
<emphasis role="bold"><literal>&#x201C;ibm,phandle&#x201D;</literal></emphasis> property, and the value of the
<emphasis role="bold"><literal>&#x201C;ibm,phandle&#x201D;</literal></emphasis> property must match the
phandle value in the property identifying that node.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_transfer_phase"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para>If the <emphasis role="bold"><literal>&#x201C;ibm,phandle&#x201D;</literal></emphasis>
property is present in a device tree
node, the OS must use this value, and not the phandle value returned by a
client interface service, to associate this node with a device tree property
that uses a phandle value to identify this node.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_transfer_phase"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
<listitem>
<para>An OS must not assume that the
<emphasis role="bold"><literal>&#x201C;ibm,phandle&#x201D;</literal></emphasis> property, if present, corresponds to the
phandle used by or returned by OF client interface services. A phandle value
passed to a client interface service as an argument must have been obtained by
use of a client interface service, and not from a device tree property
value.</para>
</listitem>
</varlistentry>
</variablelist>
<para><emphasis role="bold">Note:</emphasis> If the <emphasis role="bold"><literal>&#x201C;ibm,phandle&#x201D;</literal></emphasis>
property exists, there are two &#x201C;phandle&#x201D; namespaces which must be kept separate. One is that
actually used by the OF client interface, the other is properties in the device
tree making reference to device tree nodes. These requirements are written to
maintain backward compatibility with older FW versions predating these
requirements; if the <emphasis role="bold"><literal>&#x201C;ibm,phandle&#x201D;</literal></emphasis> property
is not present, the OS may assume that any device tree properties which refer
to this node will have a phandle value matching that returned by client
interface services. It will be necessary to have the OSs ready for this
requirement before the firmware implementation.</para>
</section>
<section>
<title>Run-Time</title>
<para>During run-time, the OS has control of the system and will have
RTAS instantiated to provide low-level hardware-specific functions.</para>
</section>
<section>
<title>Termination</title>
<para>Termination is the phase during which the OS yields control of the
system and may return control to the firmware depending on the nature of the
terminating condition.</para>
<section>
<title>Power Off</title>
<para>If the user activates the system power switch, power may be removed
from the hardware immediately (switch directly controls the power supply) or
software may be given an opportunity to bring the system down in an orderly
manner (power management control of the power switch).</para>
<para>If power is removed from the hardware immediately, the OS will lose
control of the system in an undetermined state. Any I/O underway will be
involuntarily aborted and there is potential for data loss or system damage. A
shut-down process prior to power removal is highly recommended. </para>
<para>In most power managed systems, power switch activation is fielded
as a power management interrupt and the OS (through RTAS) is able to quiesce
the system before removing power. The OS may turn off system power using the
RTAS power-off function.</para>
</section>
<section>
<title>Reboot</title>
<para>The OS may cause the system to reset and reboot by calling the RTAS
system-reboot function.</para>
</section>
</section>
</section>
<section xml:id="dbdoclet.50569327_22507">
<title>Firmware</title>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_22507"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>Platforms must implement OF as defined in <xref linkend="LoPAR.DeviceTree"/>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_22507"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para>The OF User Interface must include the
following methods as specified in <xref linkend="dbdoclet.50569387_45524"/>,
Section 7.6:<emphasis role="bold"><literal>.registers</literal></emphasis>,
<emphasis role="bold"><literal>to</literal></emphasis>,
<emphasis role="bold"><literal>load</literal></emphasis>,
<emphasis role="bold"><literal>go</literal></emphasis>,
<emphasis role="bold"><literal>state-valid</literal></emphasis>
and <emphasis role="bold"><literal>init-program</literal></emphasis>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_22507"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
<listitem>
<para>Platforms must implement the Run-Time Abstraction Services (RTAS) as described in
<xref linkend="LoPAR.RTAS"/>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_22507"
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
<listitem>
<para>OSs must use OF and the RTAS functions to be
compatible with all platforms. </para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="sec_os_install">
<title>OS Installation</title>
<para>Installation of OSs will be accomplished through the Multiboot Menu
as follows:</para>
<orderedlist>
<listitem>
<para>The system boots or reboots normally; the user enters the
Multiboot Menu by one of the methods described herein.</para>
</listitem>
<listitem>
<para>The Multiboot Menu presents a list of all installation
devices.</para>
</listitem>
<listitem>
<para>The user selects &#x201C;install&#x201D; and an installation
device from the menu; firmware locates the bootinfo object or install image on
the selected installation device.</para>
</listitem>
<listitem>
<para>Firmware will execute <emphasis role="bold"><literal>init-program</literal></emphasis> and, if a
bootinfo object was found, firmware parses it, replaces the &lt;boot-script&gt;
entities with appropriate values and executes the script.</para>
</listitem>
<listitem>
<para>The OS gets control and selects the target device.</para>
</listitem>
<listitem>
<para>After the install process is determined to be successful, the OS
updates variables such as <emphasis role="bold"><literal>boot-device</literal></emphasis>,
<emphasis role="bold"><literal>boot-file</literal></emphasis>,
and <emphasis role="bold"><literal>boot-command</literal></emphasis>.</para>
</listitem>
<listitem>
<para>The OS adds the <emphasis role="bold"><literal>bootinfo-nnnn</literal></emphasis> configuration
variable to the NVRAM <emphasis role="bold"><literal>common</literal></emphasis> system partition.</para>
</listitem>
</orderedlist>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_os_install"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>The Multiboot Menu must provide an option for
OS installation that lists all possible installation devices. </para>
</listitem>
</varlistentry>
<varlistentry xml:id="dbdoclet.50569327_16806">
<term><emphasis role="bold">R1-<xref linkend="sec_os_install"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para>After the install process is determined to be successful, the OS
must set <emphasis role="bold"><literal>boot-device</literal></emphasis>,
<emphasis role="bold"><literal>boot-file</literal></emphasis>,
and <emphasis role="bold"><literal>boot-command</literal></emphasis>.</para>
</listitem>
</varlistentry>
</variablelist>
<section>
<title>Tape Install</title>
<para>The OF definition of installation from tape is defined in
<xref linkend="LoPAR.DeviceTree"/>.</para>
</section>
<section xml:id="sec_network_install">
<title>Network Install</title>
<para>Network install follows the same process as network boot with the
exception that after installation is complete, the OS will write
<emphasis role="bold"><literal>boot-device</literal></emphasis> with the target device information.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_network_install"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>If network install is selected, firmware
must provide a means for the user to override default network parameters.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
<section xml:id="dbdoclet.50569327_18162">
<title>Diagnostics</title>
<para>IBM Power&#xAE; system platforms may use IBM AIX&#xAE; Kernel-based
stand-alone diagnostics as their multi-OS common diagnostics package. Since AIX
will run on other vendors&#x2019; platforms which might not have permission to
use AIX diagnostics, the <emphasis role="bold"><literal>&#x201C;ibm,aix-diagnostics&#x201D;</literal></emphasis>
property indicates that AIX diagnostics are permitted (see "Root
Node Properties" in <xref linkend="LoPAR.DeviceTree"/>).</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_18162"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>If AIX diagnostics are supported on a
platform, then the firmware for that platform must include the property
<emphasis role="bold"><literal>&#x201C;ibm,aix-diagnostics&#x201D;</literal></emphasis> in the
<emphasis role="bold"><literal>root</literal></emphasis> node.</para>
</listitem>
</varlistentry>
</variablelist>
<para><emphasis role="bold">Software Implementation Note:</emphasis> Each OS may implement an OS-specific
run-time diagnostics package, but should, for purposes of consistency, adhere
to the error log formats in <xref linkend="LoPAR.Error"/>.</para>
</section>
<section xml:id="sec_platform_class">
<title>Platform Class</title>
<para>The <emphasis role="bold"><literal>&#x201C;ibm,model-class&#x201D;</literal></emphasis> OF property
is defined to classify platforms for planning, marketing, licensing, and
service purposes (see "Root Node Properties" in
<xref linkend="LoPAR.DeviceTree"/>).</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_platform_class"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>The <emphasis role="bold"><literal>&#x201C;ibm,model-class&#x201D;</literal></emphasis>
property must be included in the
platform&#x2019;s <emphasis role="bold"><literal>root</literal></emphasis> node.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="dbdoclet.50569327_19998">
<title>Security</title>
<para>Platforms will provide the user with options for a Power On Password
(POP) and a Privileged Access Password (PAP) and will have some optional
physical security features. </para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_19998"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para><emphasis role="bold">Platform
Implementation:</emphasis> Platforms must provide a <emphasis>Power On
Password</emphasis> (POP) capability which, when enforced, controls the
user&#x2019;s ability to power-on and execute the configured boot
sequence.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_19998"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para><emphasis role="bold">Platform
Implementation:</emphasis> Platforms must provide a <emphasis>Privileged
Access Password</emphasis> (PAP) capability which, when enforced, controls the
user&#x2019;s ability to alter the boot sequence using f5/f6, and to enter SMS
and the Multiboot Menu.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_19998"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
<listitem>
<para><emphasis role="bold">Platform
Implementation:</emphasis> If the PAP is absent or &lt;NULL&gt;, but the POP is
non-&lt;NULL&gt;, then the POP must act as the PAP.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_19998"
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
<listitem>
<para><emphasis role="bold">Platform
Implementation:</emphasis> Platforms must accept the PAP as a valid response to
a request to enter the POP.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_19998"
xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
<listitem>
<para><emphasis role="bold">Platform Implementation:</emphasis> If
there is a key switch implemented with a secure position, the
system must not complete the boot process regardless of the state of POP and
PAP when the switch is in this position.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_19998"
xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
<listitem>
<para><emphasis role="bold">Platform
Implementation:</emphasis> If a key switch is implemented and the switch is in
the <emphasis>maintenance (service)</emphasis> position, the POP and PAP must
<emphasis>not</emphasis> be enforced.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_19998"
xrefstyle="select: labelnumber nopage"/>-7.</emphasis></term>
<listitem>
<para><emphasis role="bold">Platform
Implementation:</emphasis> Platforms, except for rack mounted systems, must
provide a locking mechanism as an option which prevents the removal of the
covers.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_19998"
xrefstyle="select: labelnumber nopage"/>-8.</emphasis></term>
<listitem>
<para><emphasis role="bold">Platform Implementation:</emphasis> Platforms, except for rack mounted systems, must
provide a tie-down mechanism as an option which prevents the physical removal
of the system from the premises.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_19998"
xrefstyle="select: labelnumber nopage"/>-9.</emphasis></term>
<listitem>
<para><emphasis role="bold">Platform Implementation:</emphasis> Passwords and keyswitch positions must be
implemented in a manner that makes their values accessible to both OF and the
service processor.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_19998"
xrefstyle="select: labelnumber nopage"/>-10.</emphasis></term>
<listitem>
<para><emphasis role="bold">Platform Implementation:</emphasis> The OF configuration variable
<literal>security-password</literal> must be maintained to be equivalent to the
Privileged Access Password (PAP).</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_19998"
xrefstyle="select: labelnumber nopage"/>-11.</emphasis></term>
<listitem>
<para><emphasis role="bold">Platform
Implementation:</emphasis> If the PAP and <literal>security-password</literal>
are absent or &lt;NULL&gt;, <literal>security-mode</literal> must be set to
<emphasis role="bold"><literal>&#x201C;none&#x201D;</literal></emphasis>, otherwise <literal>security-mode</literal>
must be set to <emphasis role="bold"><literal>&#x201C;command&#x201D;</literal></emphasis>.</para>
</listitem>
</varlistentry>
<varlistentry xml:id="dbdoclet.50569327_76267">
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_19998"
xrefstyle="select: labelnumber nopage"/>-12.</emphasis></term>
<listitem>
<para><emphasis role="bold">Platform Implementation:</emphasis> If <literal>security-mode</literal>
is set to any value other than <emphasis role="bold"><literal>&#x201C;none&#x201D;</literal></emphasis> (such as
<emphasis role="bold"><literal>&#x201C;command&#x201D;</literal></emphasis> or <emphasis role="bold"><literal>&#x201C;full&#x201D;</literal></emphasis>),
it must be treated as <emphasis role="bold"><literal>security-mode=command</literal></emphasis>.</para>
<para><emphasis role="bold">Platform Implementation Notes:</emphasis></para>
<orderedlist>
<listitem>
<para>As defined here, the PAP and <emphasis role="bold"><literal>security-password</literal></emphasis> are
stronger than as specified in IEEE 1275 for
<emphasis role="bold"><literal>security-mode</literal></emphasis> <literal>= command</literal> in that
they are required for <emphasis>any</emphasis> command line operations, including
<emphasis role="bold"><literal>go</literal></emphasis> and
<emphasis role="bold"><literal>boot</literal></emphasis>. The PAP and
<emphasis role="bold"><literal>security-password</literal></emphasis> are not required to boot the system with default
parameters, however, and in this sense the intent of
<emphasis role="bold"><literal>security-mode</literal></emphasis> <literal>= command</literal> is achieved. There is currently no
implementation of
<emphasis role="bold"><literal>security-mode</literal></emphasis> <literal>= full</literal>.</para>
</listitem>
<listitem>
<para>If a service processor is provided, the requirements relating to
passwords are applicable in the service processor environment. Service
processor documentation refers to the POP as the General User Password and the
PAP as the Privileged User Password.</para>
</listitem>
</orderedlist>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="dbdoclet.50569327_38531">
<title>Endian Support</title>
<para>LoPAR platforms operate with either Big-Endian (BE) or Little-Endian
(LE) addressing. In Big-Endian systems, the address of a word in memory is the
address of the most significant byte (the &#x201C;big&#x201D; end) of the word.
Increasing memory addresses will approach the least significant byte of the
word. In Little-Endian (LE) addressing, the address of a word in memory is the
address of the least significant byte (the &#x201C;little&#x201D; end) of the
word.</para>
<para>All data structures used for communicating between the OS and the
platform (for example, RTAS and hypervisor calls) are Big-Endian format, unless
otherwise designated.</para>
<variablelist>
<varlistentry xml:id="dbdoclet.50569327_63128">
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_38531"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>Platforms must by default operate with Big-Endian addressing.</para>
</listitem>
</varlistentry>
<varlistentry xml:id="dbdoclet.50569327_72394">
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_38531"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para>Platforms that operate with Little-Endian addressing must make
System memory appear to be in Little-Endian format to all entities in the
system that may observe that image, including I/O.</para>
</listitem>
</varlistentry>
</variablelist>
<para><emphasis role="bold">Platform Implementation Notes:</emphasis></para>
<orderedlist>
<listitem>
<para>Some hardware (for example, bridges, memory controllers, and
processors) may have modal bits to allow those components to be used in
platforms which operate in Little-Endian mode. In this case, the hardware or
firmware will need to set those bits appropriately.</para>
</listitem>
<listitem>
<para>Requirement <xref linkend="dbdoclet.50569327_72394"/> may have an
impact on the processor chosen for the platform.</para>
</listitem>
</orderedlist>
</section>
<section xml:id="dbdoclet.50569327_81764">
<title>64-Bit Addressing Support</title>
<para>A 64-bit-addressing-capable platform is defined as one capable of
supporting System Memory and Memory Mapped I/O (MMIO) configured above 4 GB
(greater than 32 bits of real addressing). This means that all hardware
elements in the topology down to the Host Bridges are capable of dealing with a
real address range greater than 32 bits, and all Host Bridges are capable of
providing a translation mechanism for translating 32-bit I/O bus DMA addresses.
All platforms compliant with IBM
<citetitle>Power Architecture Platform Requirements (PAPR)</citetitle> version 2.3 and beyond are required to be
64-bit-addressing-capable.</para>
<para>A 64-bit-addressing-aware OS is an OS that can deal with a real
address space larger than 4GB. It must handle the 64-bit processor page table
format (required of all OSs), and must understand Host Bridge mechanisms and
Host Bridge OF methods for supporting System Memory greater than 4 GB. All OSs
compliant with IBM
<citetitle>Power Architecture Platform Requirements (PAPR)</citetitle> version 2.3 and beyond are required to be
64-bit-addressing-aware.</para>
</section>
<section xml:id="dbdoclet.50569327_13540">
<title>Minimum System Requirements</title>
<para>This section
summarizes the minimum hardware and functionality required for LoPAR
compliance.</para>
<para>The
term portable is used in this document to describe that class of systems that
is primarily battery powered and is easily carried by its user.</para>
<para>The term personal is used in this document to describe that class of systems that
is bound to a specific work area due to its size or power source, and whose use
is generally restricted to a single direct user or a small set of users.</para>
<para>The term server is used in this document to describe that class of systems that
supports a multi-user environment, providing a particular service such as file
storage, software repository, or remote processing capability.</para>
<para>Each of these classes may have unique requirements due to the way it
is used or which OS it generally employs and, for this reason, the requirements
in this document my have qualifiers based on the type of system being
developed.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_13540"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para><emphasis role="bold">(Requirement moved to
<xref linkend="dbdoclet.50569327_49366"/>)</emphasis></para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_13540"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para>A means of attaching a diskette drive must be
provided (may be through a connector or over a network) and the drive must have
the following characteristics:</para>
<orderedlist numeration="loweralpha">
<listitem>
<para>Media sense: Implementations must allow polling of the drive up to
100x per second to determine the presence of media in the drive.</para>
</listitem>
<listitem>
<para>Must accept media of type: 3.5" 1.44 MB MFM</para>
</listitem>
</orderedlist>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_13540"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
<listitem>
<para>A means of attaching a CD-ROM drive must be
provided (may be through a connector or over a network) and the drive must have
the following characteristics:</para>
<orderedlist numeration="loweralpha">
<listitem>
<para>ISO9600 compliant</para>
</listitem>
<listitem>
<para>Supports multi-session</para>
</listitem>
</orderedlist>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_13540"
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
<listitem>
<para>When a keyboard is provided, it must be
capable of generating at least 101 scan codes.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_13540"
xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
<listitem>
<para>When a mouse is provided, it must have at
least two buttons.</para>
</listitem>
</varlistentry>
<varlistentry xml:id="dbdoclet.50569327_91037">
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_13540"
xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
<listitem>
<para>The capability to generate a tone must be provided on portable
and personal platforms, and on server platforms which are not housed in rack
enclosures.</para>
</listitem>
</varlistentry>
<varlistentry xml:id="dbdoclet.50569327_71913">
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_13540"
xrefstyle="select: labelnumber nopage"/>-7.</emphasis></term>
<listitem>
<para>A Real Time Clock (RTC) must be
provide which must have the following characteristics:</para>
<orderedlist numeration="loweralpha">
<listitem>
<para>Is non-volatile</para>
</listitem>
<listitem>
<para>Runs continuously</para>
</listitem>
<listitem>
<para>Has a resolution of at least one second</para>
</listitem>
</orderedlist>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="dbdoclet.50569327_22252">
<title>Options and Extensions</title>
<para>Options are features that are covered by this architecture, but are
not necessarily required to be present on a given platform. Platforms that
implement options are required to conform to the definitions in this
architecture, so that an aware OS environment can recognize and support them.
Some options may be required on some platforms. Refer to
<xref linkend="dbdoclet.50569327_98052"/> for the disposition of currently defined
options, including requirements for implementation of some of these options on
some platforms. Note that in this table, &#x201C;optional&#x201D; does not mean
&#x201C;not required;&#x201D; see the description column of the table for more
information.</para>
<para>An extension is a feature that is added to this architecture and is
required on all platforms developed after a specified effective date. </para>
<para>Options and extensions will normally need to be dormant or invisible
in the presence of a non-aware OS environment. In general, this means that they
come up passively; that is, they are initialized to an inactive state and
activated by an aware OS.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_22252"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>Extensions and options must come up
passively unless otherwise specified in this architecture.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_22252"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para>Extensions and options that affect the OS
interface to the platform must be identified, when present, through some
architected means, such as OF device tree properties.</para>
<para>It is the responsibility of the product development teams to keep the
&#x201C;usage&#x201D; columns of <xref linkend="dbdoclet.50569327_98052"/> up
to date,</para>
</listitem>
</varlistentry>
</variablelist>
<table frame="all" pgwide="1" xml:id="dbdoclet.50569327_98052">
<title>LoPAR Optional Features </title>
<tgroup cols="4">
<colspec colname="c1" colwidth="30*" align="center"/>
<colspec colname="c2" colwidth="5*" align="center"/>
<colspec colname="c3" colwidth="5*" align="center"/>
<colspec colname="c4" colwidth="60*"/>
<thead valign="middle">
<row>
<entry morerows="1">
<para>
<emphasis role="bold">Option Name</emphasis>
</para>
</entry>
<entry nameend="c3" namest="c2">
<para>
<emphasis role="bold">Usage</emphasis>
</para>
</entry>
<entry morerows="1" align="center">
<para>
<emphasis role="bold">Description</emphasis>
</para>
</entry>
</row>
<row>
<entry><?dbfo orientation="90"?><?dbfo rotated-width="0.5in"?>
<para>
<emphasis role="bold">Base</emphasis>
</para>
</entry>
<entry><?dbfo orientation="90"?><?dbfo rotated-width="0.5in"?>
<para>
<emphasis role="bold">IBM Server</emphasis>
</para>
</entry>
</row>
<row>
<entry nameend="c4" namest="c1" align="left">
<para>
<emphasis role="bold">Usage Legend</emphasis> : NS =
Not Supported; O = Optional (see also Description); OR = Optional but
Recommended; R = Required; SD = See Description
</para>
</entry>
</row>
</thead>
<tbody valign="middle">
<row>
<entry>
<para> Symmetrical Multiprocessing (SMP)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> R</para>
</entry>
<entry>
<para> Required on MP platforms.</para>
</entry>
</row>
<row>
<entry>
<para> Multiboot</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> Required to support multiple versions of an OS.</para>
</entry>
</row>
<row>
<entry>
<para> PCI Hot Plug DR</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> OR</para>
</entry>
<entry>
<para> See <xref linkend="LoPAR.Virtualization"/> for more information. </para>
</entry>
</row>
<row>
<entry>
<para> Logical Resource Dynamic Reconfiguration (LRDR)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> OR</para>
</entry>
<entry>
<para><xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Enhanced I/O Error Handling (EEH)</para>
</entry>
<entry>
<para> OR SD</para>
</entry>
<entry>
<para> R</para>
</entry>
<entry>
<para> See <xref linkend="dbdoclet.50569330_34831"/> and
<xref linkend="dbdoclet.50569330_17337"/>. Requirements for platforms that implement
LPAR, regardless of the number of partitions, are contained in
<xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Error Injection (ERRINJCT)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> R</para>
</entry>
<entry>
<para> Required of servers which implement the EEH option.</para>
</entry>
</row>
<row>
<entry>
<para> Logical Partitioning (LPAR)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> R</para>
</entry>
<entry>
<para> See <xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Bridged-I/O EEH Support</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> R</para>
</entry>
<entry>
<para> EEH support for I/O structures which contain PCI to PCI
bridges or PCI Express switches. See <xref linkend="dbdoclet.50569330_56798"/>.
Required if EEH is supported.</para>
</entry>
</row>
<row>
<entry>
<para> PowerPC External Interrupt</para>
</entry>
<entry>
<para> R</para>
<para>SD</para>
</entry>
<entry>
<para> R</para>
<para>SD</para>
</entry>
<entry>
<para> May be virtualized; See <xref linkend="dbdoclet.50569331_37856"/>.</para>
</entry>
</row>
<row>
<entry>
<para> EXTI2C</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> See <xref linkend="LoPAR.RTAS"/> for more information on
support of I<superscript>2</superscript>C buses.</para>
</entry>
</row>
<row>
<entry>
<para> Firmware Assisted NMI (FWNMI)</para>
</entry>
<entry>
<para> R</para>
</entry>
<entry>
<para> R</para>
</entry>
<entry>
<para><xref linkend="LoPAR.RTAS"/>. </para>
</entry>
</row>
<row>
<entry>
<para> System Parameters</para>
</entry>
<entry>
<para> R</para>
</entry>
<entry>
<para> R</para>
</entry>
<entry>
<para><xref linkend="LoPAR.RTAS"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Capacity on Demand (CoD)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para><xref linkend="LoPAR.RTAS"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Predictive Failure Sparing</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para><xref linkend="LoPAR.RTAS"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Converged Location Codes</para>
</entry>
<entry>
<para> R</para>
</entry>
<entry>
<para> R</para>
</entry>
<entry>
<para> The Converged Location Codes option is required on all
platforms being developed. <xref linkend="dbdoclet.50569341_35066"/> and
Requirement <xref linkend="dbdoclet.50569341_25472"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Shared Processor LPAR (SPLPAR)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para><xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Reliable Command/Response Transport</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para><xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Logical Remote DMA (LRDMA)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para><xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Interpartition Logical LAN (ILLAN)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para><xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> ILLAN Backup Trunk Adapter</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para><xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> ILLAN Checksum Offload Support</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para><xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Checksum Offload Padded Packet Support</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> See <xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Virtual SCSI (VSCSI)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para><xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Virtual FC (VFC)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> See <xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Storage Preservation</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> NS</para>
</entry>
<entry>
<para><xref linkend="dbdoclet.50569327_70628"/> and "Managing
Storage Preservations" in <xref linkend="LoPAR.RTAS"/> specification.</para>
</entry>
</row>
<row>
<entry>
<para> Client Vterm</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> R</para>
</entry>
<entry>
<para> Required of all platforms that support LPAR, otherwise not
implemented. Provides a virtual &#x201C;Asynchronous&#x201D; IOA for connecting
to a server Vterm IOA, the hypervisor, or HMC (for example, to a virtual
console). See <xref linkend="LoPAR.Virtualization"/> for more
information.</para>
</entry>
</row>
<row>
<entry>
<para> Server Vterm</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> Allows a partition to serve a partner partition's client
Vterm IOA.</para>
</entry>
</row>
<row>
<entry>
<para> NUMA</para>
<para>Associativity Information</para>
</entry>
<entry>
<para> OR</para>
</entry>
<entry>
<para> OR</para>
</entry>
<entry>
<para> See <xref linkend="dbdoclet.50569346_35960"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Performance Tool Support</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> NS</para>
</entry>
<entry>
<para> Provides access to platform-level facilities for
performance tools running in a partition on an LPAR system. See
<xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> MSI (Message Signaled Interrupt)</para>
</entry>
<entry>
<para> SD</para>
</entry>
<entry>
<para> SD</para>
</entry>
<entry>
<para> Required for all platforms that support PCI Express. </para>
</entry>
</row>
<row>
<entry>
<para> ILLAN Buffer Size Control</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> See <xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Virtual Management Channel (VMC)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> See <xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Partition Suspension</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> Requires the Logical Partitioning, LRDR, and Update OF Tree options. </para>
</entry>
</row>
<row>
<entry>
<para> Partition Hibernation</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> Allows a partition to sleep for an extended period; during
this time the partition state is stored on secondary storage for later
restoration. Requires the Partition Suspension, ILLAN, and VASI options. </para>
</entry>
</row>
<row>
<entry>
<para> Partition Migration</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> Allows the movement of a logical partition from one
platform to another; the source and destination platforms cooperate to minimize
the time that the partition is non-responsive. Requires the Partition
Suspension, ILLAN, and VASI options. </para>
</entry>
</row>
<row>
<entry>
<para> Thread Join</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> Allows the multi-threaded caller to efficiently establish
a single threaded processing environment.</para>
</entry>
</row>
<row>
<entry>
<para> Update OF Tree</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> Allows the caller to determine which device tree nodes
changed due to a massive platform reconfiguration as happens during a partition
migration or hibernation.</para>
</entry>
</row>
<row>
<entry>
<para> Virtual</para>
<para>Asynchronous Services Interface (VASI)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> Allows an authorized virtual server partition (VSP) to
safely access the internal state of a specific partition. See
<xref linkend="LoPAR.Virtualization"/> for more details. Requires the Reliable
Command/Response Transport option.</para>
</entry>
</row>
<row>
<entry>
<para> Virtualized Real Mode Area (VRMA)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> Allows the OS to dynamically relocate, expand, and shrink
the Real Mode Area.</para>
</entry>
</row>
<row>
<entry>
<para> TC</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> Allows the OS to indicate that there is no need to search
secondary page table entry groups to determine a page table search has failed.
See <xref linkend="LoPAR.Virtualization"/> for more details.</para>
</entry>
</row>
<row>
<entry>
<para> Configure Platform Assisted Kernel Dump</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> Allows the OS to register and unregister kernel dump
information with the platform.</para>
</entry>
</row>
<row>
<entry>
<para> I/O Super Page</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> OR</para>
</entry>
<entry>
<para> Allows the OS to specify I/O pages that are greater than 4 KB in length.</para>
</entry>
</row>
<row>
<entry>
<para> Subordinate CRQ (Sub-CRQ) Transport</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> Support for the Subordinate CRQs as needed by some Virtual
IOAs. See <xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Cooperative Memory Over-commitment (CMO)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> The CMO option allows for partition participation in the
over-commitment of logical memory by the platform. See
<xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Partition Energy Management (PEM)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> Allows the OS to cooperate with platform energy
management. See <xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Multi-TCE-Table (MTT) </para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> Support for the Multi-TCE-Table Option. See
<xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Virtual Processor Home Node (VPNH)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> Provides substantially consistent virtual processor
associativity in a shared processor LPAR environment. See
<xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> IBM Active Memory&#x2122; Compression </para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> Allows the partition to perform active memory compression.</para>
</entry>
</row>
<row>
<entry>
<para> Virtual Network Interface Controller (VNIC)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> See <xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Expropriation Subvention Notification</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> Allows OS notification of a cooperative memory
overcommitment page fault see <xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Boost Modes</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> Allows the platform to communicate and the availability of
performance boost modes along with any ability to manage the same. See
<xref linkend="LoPAR.RTAS"/></para>
</entry>
</row>
<row>
<entry>
<para> Platform Resource Reassignment</para>
<para>Notification (PRRN)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para>
<xref linkend="dbdoclet.50569346_88496"/>
</para>
</entry>
</row>
<row>
<entry>
<para> Dynamic DMA Windows (DDW)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> Allows the creation of DMA Windows above 4 GB. See
<xref linkend="LoPAR.RTAS"/>.</para>
</entry>
</row>
<row>
<entry>
<para> Universally Unique Partition Identification Option (UUID)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para>
<xref linkend="LoPAR.DeviceTree"/> for information on ibm,partition-uuid.
</para>
</entry>
</row>
<row>
<entry>
<para> Platform Facilities Option (PFO)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> See <xref linkend="LoPAR.Virtualization"/> for more information.</para>
</entry>
</row>
<row>
<entry>
<para> Extended Cooperative Memory Overcommittment (XCMO)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> Introduces additional cooperative memory overcommitment
functions see <xref linkend="LoPAR.Virtualization"/></para>
</entry>
</row>
<row>
<entry>
<para> Memory Usage Instrumentation Option (MUI)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> See <xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
<row>
<entry>
<para>Block Invalidate Option</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para>Allows improved performance for removing page table entries representing a naturally aligned
block of virtual addresses.</para>
</entry>
</row>
<row>
<entry>
<para>Energy Management Tuning Parameters (EMTP)</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para>Reports the system Energy Management tuning values.</para>
</entry>
</row>
<row>
<entry>
<para>In-Memory Table Translation Option</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para> O</para>
</entry>
<entry>
<para>Provides support for the system wide Memory Management Unit
architecture introduced in POWER ISA 3.0</para>
</entry>
</row>
<row>
<entry>
<para>Hash Page Table Resize Option</para>
</entry>
<entry>
<para>O</para>
</entry>
<entry>
<para>O</para>
</entry>
<entry>
<para>Allows partitions to resize their HPT. See
<xref linkend="LoPAR.Virtualization"/>.</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</section>
<section xml:id="dbdoclet.50569327_34719">
<title>IBM LoPAR Platform Implementation Requirements</title>
<para>The tables in this section detail specific product requirements which
are not defined as an &#x201C;option&#x201D; in this architecture. The intent
is to define base requirements for these products, over and beyond what is
specified in <xref linkend="dbdoclet.50569327_98052"/> and elsewhere in this
architecture. </para>
<para>In addition, any options that are unique to specific implementations
(that is, not general usage), and which do not appear in
<xref linkend="dbdoclet.50569327_98052"/>, are listed in this section.</para>
<para>It is the responsibility of the product development teams to keep
these tables up to date.</para>
<section xml:id="sec_ibm_server_req">
<title>IBM Server Requirements</title>
<para>This section talks to the requirements for IBM LoPAR Compliant
server platforms. </para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ibm_server_req"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para><emphasis role="bold">For all IBM LoPAR Compliant
Platforms:</emphasis> The platform must implement the options marked as
&#x201C;required&#x201D; in the IBM Server column of
<xref linkend="dbdoclet.50569327_98052"/> and the additional functions as indicated
in <xref linkend="dbdoclet.50569327_49366"/> (that is, the &#x201C;Base&#x201D;
column of <xref linkend="dbdoclet.50569327_98052"/> is not sufficient).</para>
</listitem>
</varlistentry>
</variablelist>
<table frame="all" pgwide="1" xml:id="dbdoclet.50569327_49366">
<title>IBM Server Required Functions and Features </title>
<tgroup cols="3">
<colspec colname="c1" colwidth="45*"/>
<colspec colname="c2" colwidth="15*" align="center"/>
<colspec colname="c3" colwidth="40*"/>
<thead valign="middle">
<row>
<entry align="center">
<para>
<emphasis role="bold">Function/Feature</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Effective Date</emphasis>
</para>
</entry>
<entry align="center">
<para>
<emphasis role="bold">Description</emphasis>
</para>
</entry>
</row>
</thead>
<tbody valign="middle">
<row>
<entry>
<para> All IOA device drivers EEH enabled or EEH safe</para>
</entry>
<entry>
<para> 6/2004</para>
</entry>
<entry>
<para> Required even for systems running with just one partition.</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
<para>It is the responsibility of the product development teams to keep
<xref linkend="dbdoclet.50569327_49366"/> up to date. </para>
</section>
</section>
<section xml:id="sec_optional_behavior">
<title>Behavior for Optional and Reserved Bits and Bytes</title>
<para>Behavior of the OSs and platforms for bits and bytes in this
architecture that are marked as reserved or optional are defined here.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_optional_behavior"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>Bits and bytes which are marked as
&#x201C;optional&#x201D; by this architecture and which are not implemented by
the platform must be ignored by the platform on a <emphasis>Store</emphasis>
and must be returned as 0&#x2019;s on a <emphasis>Load</emphasis>, including
the reserved or optional bits of a partially implemented field. </para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_optional_behavior"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para>Bits and bytes which are marked as
&#x201C;reserved&#x201D; by this architecture must be ignored by the platform
on a <emphasis>Store</emphasis> and must be returned as 0&#x2019;s on a
<emphasis>Load</emphasis>, except that bits that are marked as
&#x201C;reserved&#x201D; and which were previously defined by the architecture
maybe be treated appropriately by legacy hardware (such bits in this
architecture will state the value that software must use henceforth).</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_optional_behavior"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
<listitem>
<para>Bits and bytes marked as
&#x201C;reserved&#x201D; must be set to 0 by the OS on a
<emphasis>Store</emphasis>, except as otherwise defined by the architecture, and must be
ignored on a <emphasis>Load</emphasis>.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</chapter>
Reference in New Issue View Git Blame Copy Permalink