Linux-Architecture-Reference/LoPAR/ch_system_reqs.xml

<?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>
          <row>
            <entry>
              <para>Coherent Platform Facility</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>