<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright (c) 2016 OpenPOWER Foundation
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<chapter xmlns= "http://docbook.org/ns/docbook"
xmlns:xl="http://www.w3.org/1999/xlink"
version="5.0"
xml:lang="en"
xml:id="dbdoclet.50569368_91814">
<title > System Binding</title>
<section >
<title > LoPAR Boot Flow</title>
<para > This section gives a system boot process overview and defines the
enhancements to the standard OF boot process that are present in the boot
process for an LoPAR platform.</para>
<section >
<title > Boot Overview</title>
<para > The platform performs a normal OF boot (see
<xref linkend= "dbdoclet.50569387_45524" /> , as stated in the Core
Practice Document, Section 4.2.3, Start-up script evaluation. LoPAR
platforms provide an additional capability to assist the user in choosing
which of several OSs to boot. A key sequence can be used to interrupt the
normal boot flow and present the user with a
<emphasis > multiboot menu</emphasis> , which can be either graphical or
text-based at the discretion of the platform’ s firmware, from which
the user can choose one of the installed or installable OSs. Presenting
the user with this choice can also be made the default mode of operation
at platform boot time, by means of the
<emphasis role= "bold" > <literal > auto-boot?</literal> </emphasis> and
<emphasis role= "bold" > <literal > menu?</literal> </emphasis> configuration variables.</para>
<para > An overview of a platform boot sequence and the additions of the
<emphasis > multiboot menu</emphasis> are given below:</para>
<informalfigure >
<mediaobject >
<imageobject role= "html" >
<imagedata fileref= "figures/PAPR-60.gif" format= "GIF"
scalefit="1" />
</imageobject>
<imageobject role= "fo" >
<imagedata contentdepth= "100%" fileref= "figures/PAPR-60.gif"
format="GIF" scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</informalfigure>
<para > The boot flow described above occurs after all of the devices have
been probed (i.e., by the execution of
<emphasis role= "bold" > <literal > probe-all</literal> </emphasis> ); see
<xref linkend= "dbdoclet.50569368_23032" /> additional requirements for
<emphasis role= "bold" > <literal > probe-all</literal> </emphasis> method.</para>
<para > The boot sequence defaults to a normal boot if the boolean variable
<emphasis role= "bold" > <literal > auto-boot?</literal> </emphasis> is true and
<emphasis role= "bold" > <literal > diagnostic-mode?</literal> </emphasis> is false. In this situation, the
system shall then boot from information contained in the configuration
variables
<emphasis role= "bold" > <literal > boot-device</literal> </emphasis> and
<emphasis role= "bold" > <literal > boot-file</literal> </emphasis> .</para>
<para > From the boot sequence above, entry to the
<emphasis > multiboot menu</emphasis> may occur anywhere after step ‘ f’ ,
<emphasis role= "bold" > <literal > banner</literal> </emphasis> , if the platform key
sequence (<emphasis > multiboot menu</emphasis> ) has been depressed or in step
‘ i’ if the boolean variable
<emphasis role= "bold" > <literal > menu?</literal> </emphasis> is true.</para>
<section xml:id= "dbdoclet.50569368_23032" >
<title > Additional Requirements for probe-all Method</title>
<para > Before probing for plug-in devices, OF shall execute the
<emphasis role= "bold" > <literal > probe</literal> </emphasis> method, as with
<emphasis role= "bold" > <literal > execute-device-method</literal> </emphasis> , of any built-in device nodes.
The order of evaluation shall ensure that the
<emphasis role= "bold" > <literal > probe</literal> </emphasis> method of a parent device node is executed
before the
<emphasis role= "bold" > <literal > probe</literal> </emphasis> method of any of its children.</para>
<para >
<emphasis role= "bold" > Note:</emphasis> During this built-in probing, /rom nodes will
locate ROM based OSs. The FCode for these devices can publish their
<emphasis role= "bold" > <literal > “ bootinfo” </literal> </emphasis> properties that are used
during the multiboot scenario as described below.</para>
</section>
<section >
<title > LoPAR Multiboot</title>
<para > The boot choices identified to the user are defined by
<emphasis > bootinfo objects</emphasis> hich are located on various system
media. Each
<emphasis > bootinfo object</emphasis> contains information about one OS,
such as its name and description, an icon depicting it, and an OF command
sequence to load and execute it. The locations where
<emphasis > bootinfo objects</emphasis> can be found are specified by OF
<emphasis > device-specifiers</emphasis> that are the values of
configuration variables, the names of which are of the form
<emphasis role= "bold" > <literal > “ bootinfo-nnnnn” </literal> </emphasis> , where
<emphasis role= "bold" > <literal > “ nnnnn” </literal> </emphasis> is OS-specific. These
<emphasis > configuration variables</emphasis> are stored in the System
Partition in NVRAM and are published in the
<emphasis > device tree</emphasis> as properties under the
<emphasis role= "bold" > <literal > /options</literal> </emphasis> node. The
<emphasis > multiboot menu</emphasis> will use these
<emphasis > configuration variables</emphasis> to locate and parse
<emphasis > bootinfo</emphasis> to obtain the OS icon, description,
etc.</para>
<para > In addition to the
<emphasis role= "bold" > <literal > bootinfo-nnnnn</literal> </emphasis> configuration variables, the
<emphasis > multiboot menu</emphasis> will search the device tree for nodes
containing
<emphasis role= "bold" > <literal > “ bootinfo” </literal> </emphasis> properties, which specify that
the node can supply a
<emphasis > bootinfo object</emphasis> . This is particularly useful for OSs
contained in ROMs.</para>
<para >
<emphasis role= "bold" > Note:</emphasis> The order prescribed by probe-all guarantees
that these properties be created before the
<emphasis > multiboot menu</emphasis> has been invoked.</para>
<para > Different versions of the same OS may each have their own
<emphasis > bootinfo</emphasis> and associated
<emphasis > configuration variables</emphasis> . Although it is possible to
put
<emphasis > bootinfo</emphasis> in any media location that OF can read, this
specification defines standard locations for various types of media, to
allow the firmware to establish the
<emphasis > bootinfo configuration variables</emphasis> automatically in
many cases.</para>
</section>
<section xml:id= "dbdoclet.50569368_65183" >
<title > Bootinfo Configuration Variables</title>
<para > A
<emphasis > bootinfo configuration variable</emphasis> is any
<emphasis > configuration variable</emphasis> that meets the following
requirements:</para>
<itemizedlist >
<listitem >
<para > Its name is of the form
<emphasis role= "bold" > <literal > “ bootinfo-nnnnn” </literal> </emphasis> , where
<emphasis > nnnnn</emphasis> is a string of at most 22 characters from the
set of valid characters for OF configuration variable names. The exact
value of
<emphasis role= "bold" > <literal > “ nnnnn” </literal> </emphasis> for a particular OS may be chosen
by that OS. The naming convention for the OS should be chosen to avoid
possible naming conflicts between OS vendors.</para>
</listitem>
<listitem >
<para > Its value is an OF
<emphasis > device-specifier</emphasis> that identifies an object (e.g. disk
file, tape file, disk partition or
<emphasis role= "bold" > <literal > /rom</literal> </emphasis> child node) whose contents are a
<emphasis role= "bold" > <literal > “ bootinfo object” </literal> </emphasis> as defined
below.</para>
</listitem>
</itemizedlist>
</section>
<section >
<title > Bootinfo Properties</title>
<para > Any node in the device tree can have a
<emphasis role= "bold" > <literal > “ bootinfo” </literal> </emphasis> property whose value specifies
the arguments to use in opening that device in order to access its
<emphasis > bootinfo object</emphasis> .</para>
<para >
<emphasis role= "bold" > <literal > “ bootinfo” </literal> </emphasis> S</para>
<para >
<emphasis > property name</emphasis> locates the node’ s
<emphasis > bootinfo object</emphasis> </para>
<para >
<emphasis > prop-encoded-array</emphasis> : A string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> </para>
<para > The presence of this property signifies that the device has an
associated
<emphasis > bootinfo object</emphasis> . The value is a text string such
that when this device’ s node
<emphasis role= "bold" > <literal > open</literal> </emphasis> method is called, the value of text string that
is passed to the device’ s node
<emphasis role= "bold" > <literal > open</literal> </emphasis> method is
<emphasis role= "bold" > <literal > “ my-args” </literal> </emphasis> . When so opened, subsequent
calls to the node’ s
<emphasis role= "bold" > <literal > “ read” </literal> </emphasis> method will yield the contents of
the node’ s
<emphasis > bootinfo object</emphasis> .</para>
</section>
<section >
<title > Standard Locations for Bootinfo Objects</title>
<para > The standard locations for
<emphasis > bootinfo objects</emphasis> on various LoPAR media and
partition types is shown in the table below. An OS must put its
<emphasis > bootinfo object</emphasis> in the standard location in order to
guarantee interoperability with the LoPAR
<emphasis > multiboot menu</emphasis> mechanism.</para>
<table frame= "all" pgwide= "1" >
<title > Standard Pathnames for
<emphasis > bootinfo.txt</emphasis> File
</title>
<tgroup cols= "3" >
<colspec colname= "c1" colwidth= "33*" />
<colspec colname= "c2" colwidth= "33*" />
<colspec colname= "c3" colwidth= "33*" />
<thead >
<row >
<entry align= "center" >
<para >
<emphasis role= "bold" > Name</emphasis>
</para>
</entry>
<entry align= "center" >
<para >
<emphasis role= "bold" > Device/Partition</emphasis>
</para>
</entry>
<entry align= "center" >
<para >
<emphasis role= "bold" > Notes</emphasis>
</para>
</entry>
</row>
</thead>
<tbody >
<row >
<entry >
<para > Installation Media:</para>
</entry>
<entry >
<para >   </para>
</entry>
<entry >
<para >   </para>
</entry>
</row>
<row >
<entry >
<para > Any block device:</para>
</entry>
<entry >
<para > device:partition,\ppc\bootinfo.txt</para>
</entry>
<entry >
<para > Any file system format</para>
</entry>
</row>
<row >
<entry >
<para > Tape:</para>
</entry>
<entry >
<para > device:0 (Note 1)</para>
</entry>
<entry >
<para > Presence of bootinfo.txt is optional</para>
</entry>
</row>
<row >
<entry >
<para > ROM:</para>
</entry>
<entry >
<para > device:bootinfo</para>
</entry>
<entry >
<para > bootinfo is the value of the
<emphasis role= "bold" > <literal > “ bootinfo” </literal> </emphasis> property in a
<emphasis role= "bold" > /rom</emphasis> child node</para>
</entry>
</row>
<row >
<entry >
<para > Network:</para>
</entry>
<entry >
<para > Could specify bootinfo.txt or some other file from the
Bootp server</para>
</entry>
<entry >
<para > Specifying bootinfo.txt from the Bootp server is
optional</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
<para >
<emphasis role= "bold" > Note 1:</emphasis> If bootinfo.txt file is not present, file 0
should contain a program image file for a bootable tape.</para>
<para > Example of installed (
<emphasis role= "bold" > <literal > “ bootinfo-nnnnn” </literal> </emphasis> ) block device
(disk):</para>
<para > ALIAS EXAMPLE:</para>
<para > bootinfo-aix-4.3=disk:2 (The contents of partition 2, which is
probably a “ 0x41” partition, on the default disk, is the
<emphasis > bootinfo.txt</emphasis> file for a version of the AIX
OS.)</para>
<para > bootinfo-nt-4.0=disk:\os\winnt\bootinfo.txt</para>
<para > NON-ALIAS EXAMPLE:</para>
<para > bootinfo-aix-4.4=/pci@ff500000/pci3,1000@10/sd0,0:3 (The contents
of partition 3, which is probably a “ 0x41” partition, on the
SCSI disk at target 0 unit 0, is the
<emphasis > bootinfo.txt</emphasis> file for a version of the AIX
OS.)</para>
</section>
<section xml:id= "dbdoclet.50569368_26165" >
<title > Bootinfo Objects</title>
<para > The information used by OF to display information in the
<emphasis > multiboot menu</emphasis> and to
locate and process an OS load image is contained
within a sequence of text that is called a
<emphasis > bootinfo object</emphasis> . The text comprising the bootinfo
object uses SGML syntax, as defined in
<xref linkend= "dbdoclet.50569387_11453" /> , with tags identifying the
subordinate elements.</para>
<para > The following outline is a summary of the organization of the
<emphasis > bootinfo object</emphasis> . Elements at the same level do not
have any required order. The tags are illustrated in upper case, but
shall be processed in a case-insensitive manner.
<programlisting > <![CDATA[<CHRP-BOOT>
<DESCRIPTION >
....
</DESCRIPTION>
<OS-NAME >
....
</OS-NAME>
<BOOT-SCRIPT >
....
</BOOT-SCRIPT>
<ICON
SIZE=ww,hh
COLOR-SPACE=r,g,b
>
<BITMAP >
hh hh hh hh . . .
</BITMAP>
</ICON>
</CHRP-BOOT> ]]></programlisting> </para>
<para >
<emphasis role= "bold" > Notes:</emphasis>
</para>
<orderedlist >
<listitem >
<para > If ‘ SIZE’ is not present, assume default of 64,64.
If ‘ COLOR-SPACE’ is not present, assume default of
3,3,2.</para>
</listitem>
<listitem >
<para > Another <emphasis role= "bold" > <literal > < chrp-boot> </literal> </emphasis> tag sequence could define a different
boot selection</para>
</listitem>
<listitem >
<para > LoPAR platforms will recognize only the tags between the
beginning <emphasis role= "bold" > <literal > < chrp-boot> </literal> </emphasis> tag until the end < /chrp-boot> tag. If
a tag is unrecognized, the material will be ignored until the end tag.
Other non-<emphasis role= "bold" > <literal > < chrp-boot> </literal> </emphasis> tags may be supported in the future. These
additional selections would also be presented to the user as boot
options.</para>
</listitem>
</orderedlist>
<section >
<title > Bootinfo Entities</title>
<para > SGML provides “ entities” that provide symbolic names
for text. When the entity names are contained within & and
‘ ;’ , the entity is replaced with text as defined by the
entity; i.e., entities provide a “ macro” substitution
capability. The
<emphasis > bootinfo object</emphasis> may use entities to supply pathname
components that depend upon the location of the file. Also, entities have
been defined for the standard SMGL Tags for the presence of the
‘ < ‘ , ‘ & ’ and ‘ > ’ characters
in the text as & lt;, & amp; and & gt;. Within the
< BOOT-SCRIPT> element, the following entities are defined with
respect to the fully qualified pathname of the
<emphasis > bootinfo object</emphasis> :</para>
<variablelist >
<varlistentry >
<term > device</term>
<listitem >
<para > the device component.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > partition</term>
<listitem >
<para > the partition component.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > directory</term>
<listitem >
<para > the directory component.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > filename</term>
<listitem >
<para > the filename component.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > full-path</term>
<listitem >
<para > the entire fully qualified pathname.</para>
</listitem>
</varlistentry>
</variablelist>
<para > The fully qualified pathname could be represented by the following
text:
<programlisting > <![CDATA[&device;:[&partition;][,]&directory;&filename;]]> </programlisting> </para>
<para >
<emphasis role= "bold" > Note:</emphasis> Underlined portions illustrate where entities
are positioned within the full pathname.</para>
</section>
<section >
<title > Bootinfo Character Sets</title>
<para > The character set used by the bootinfo.txt file is ISO-8859-1
(Latin-1). Element tags and entity names are not case sensitive; all
other text is case sensitive.</para>
</section>
<section >
<title > Element Tag Descriptions</title>
<para > The following sections describe each of the element tags and how
they are used.</para>
</section>
<section >
<title > CHRP-BOOT Element</title>
<para > This element provides the grouping for each OS that is represented
within a single bootinfo.txt file. Multiple CHRP-BOOT sections are
allowed within a single bootinfo.txt file.</para>
</section>
<section >
<title > OS-NAME element</title>
<para > This element contains the complete name of the OS.</para>
</section>
<section >
<title > BOOT-SCRIPT element</title>
<para > This element contains an OF script that is executed when the OS
defined by this CHRP-BOOT section is selected to be loaded. Each line of
this element is processed as if it were entered from the input device of
the user interface. Typically, the last line of this script would contain
a
<emphasis role= "bold" > <literal > boot</literal> </emphasis> command; the pathname of the OS’ s load
image can be constructed with the entities described above.</para>
</section>
<section >
<title > ICON element</title>
<para > This element describes the OS icon that can be displayed by the
multi-boot process. The icon should be designed to be pleasant against a
light background.</para>
<para > The SIZE parameter consists of a two decimal numbers, separated by
a comma, that represent the width and height (in pixels) of the icon,
respectively. The default value is “ 64,64” </para>
<para > The COLOR-SPACE parameter consists of three decimal numbers,
separated by commas, that represent the number of bits for the red,
green, and blue components of each pixel. The default value is
“ 3,3,2” <superscript > 1</superscript> .</para>
<para >
<emphasis role= "bold" > Note 1:</emphasis> This version of LoPAR supports only a 3,3,2
icon color-space and 64,64 icon size. Other icon size’ s and
color-space’ s are reserved for future implementations.</para>
<para > If an icon is not stated, the platform will display a generic
system icon that is platform dependent.</para>
<section >
<title > BITMAP element</title>
<para > This element specifies the bitmap. It consists of a sequence of hex
digit pairs, each of which defines a pixel; white spaces is allowed
between pixel values. The number of hex digit pairs is defined by the
product of the width and height values of the SIZE parameter.</para>
<variablelist >
<varlistentry >
<term > <emphasis > icon string example:</emphasis> </term>
<listitem >
<para > <emphasis role= "bold" > <literal > < icon size=64,64
color-space=3,3,2> < bitmap> hh hh...</literal> </emphasis> </para>
<para > <emphasis role= "bold" > <literal > hh<superscript > 2</superscript> < /bitmap> < /icon> </literal> </emphasis> </para>
</listitem>
</varlistentry>
</variablelist>
<para >
<emphasis role= "bold" > Note 2:</emphasis> Hex string would be 8192 characters for a
size=64,64 in the above example.</para>
<para > For the two examples below, the tags have been indented and
separated by line feeds for each start/end tag pair to make a more
readable script style.</para>
<para >
<emphasis role= "bold" > AIX Bootinfo Object Example:</emphasis>
<programlisting > <![CDATA[<chrp-boot>
<description > AIX 4.2.D.0</description>
<os-name > AIX 4.2.D.0</os-name>
<boot-script > boot &device; :2</boot-script>
<icon size= 64,64 color-space= 3,3,2 > <bitmap > hh ... hh1</bitmap> </icon>
</chrp-boot> ]]></programlisting> </para>
<para > <emphasis role= "bold" > AIX Diagnostics Bootinfo Object Example:</emphasis>
<programlisting > <![CDATA[<chrp-boot>
<description > AIX 4.2.D.0 Diagnostics</description>
<os-name > AIX 4.2.D.0 Diagnostics</os-name>
<boot-script > boot &device; :2 diag</boot-script>
<icon size= 64,64 color-space= 3,3,2 > <bitmap > hh ... hh</bitmap> </icon>
</chrp-boot> ]]></programlisting> </para>
<para >
<emphasis role= "bold" > Note:</emphasis> 64x64 icon size would have 8192 hex string
characters in the "hh ... hh" field above.</para>
</section>
</section>
</section>
<section >
<title > Multiboot Menu</title>
<para > If the boot sequence is interrupted by the multiboot key sequence,
then the firmware shall present a
<emphasis > multiboot menu</emphasis> that provides at least the functions
listed below. The form of the menu (e.g. graphical or text- oriented) and
the selection mechanism (e.g. numbered choices, arrow keys, or mouse) are
platform-dependent.</para>
<para > Multiboot Required Functions:</para>
<itemizedlist >
<listitem >
<para > Locate all bootinfo objects specified by bootinfo configuration
variables and device node
<emphasis role= "bold" > <literal > “ bootinfo” </literal> </emphasis> properties. For each
<emphasis > bootinfo object</emphasis> , present a choice corresponding to
each valid <emphasis role= "bold" > <literal > < chrp-boot> </literal> </emphasis> section contained therein. For each such
choice, allow the user to either:</para>
<itemizedlist >
<listitem >
<para > Execute the contents of that
<emphasis > bootinfo object’ s</emphasis> <emphasis role= "bold" > <literal > < boot-script> </literal> </emphasis>
element.</para>
</listitem>
<listitem >
<para > Set the
<emphasis role= "bold" > <literal > boot-command</literal> </emphasis> configuration variable to the contents
of that
<emphasis > bootinfo object’ s</emphasis> <emphasis role= "bold" > <literal > < boot-script> </literal> </emphasis>
element.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem >
<para > Present a choice corresponding to each install device, which,
when invoked, will attempt to locate a bootinfo object at the
device’ s standard location (see Table 1).</para>
</listitem>
<listitem >
<para > Allow the user to manage configuration variables</para>
</listitem>
<listitem >
<para > Allow the user to invoke the OF user interface</para>
</listitem>
</itemizedlist>
<para > Additional options that could be implemented would be to provide a
means to get to diagnostics or specific platform options.</para>
<para > There shall be at least one key sequence to enter the multi-boot
platform function for an LoPAR platform.</para>
<para >
<emphasis role= "bold" > Note:</emphasis> OS have the responsibility to update the NVRAM
System Partition Variable to reflect a change where the
<emphasis > bootinfo.txt</emphasis> file is located; e.g., moving to a
different disk device. Also, the OS is responsible for maintaining the
contents of the
<emphasis > bootinfo.txt</emphasis> file.</para>
</section>
</section>
<section xml:id= "dbdoclet.50569368_25080" >
<title > Reboot-Command Variable Description</title>
<para > The OS can cause OF to execute a specified sequence of commands at
the next boot by setting the value of the
<emphasis role= "bold" > <literal > reboot-command</literal> </emphasis> configuration variable. LoPAR
firmware implementations shall implement the following configuration
variable.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > reboot-command(-- addr len)</emphasis> [N]</term>
<listitem >
<para > One time or temporary reboot command.</para>
<para > The value of this configuration variable is a string consisting of
zero or more lines of text, with lines separated by either
< return> , < linefeed> , or
< return> < linefeed> .</para>
<para > During firmware start-up, just prior to checking the
<emphasis role= "bold" > <literal > auto-boot?</literal> </emphasis> configuration variable for automatic
booting, the firmware shall check the value of
<emphasis role= "bold" > <literal > reboot-command</literal> </emphasis> . If the value is not the empty
string, the firmware shall save the value to a temporary location, set
<emphasis role= "bold" > <literal > reboot-command</literal> </emphasis> to the empty string, and evaluate the
saved value as though it were a series of user interface command
lines.</para>
<para > If the evaluation of
<emphasis role= "bold" > <literal > reboot-command</literal> </emphasis> returns without executing, the
firmware shall proceed with its normal start-up sequence. In typical
usage, however, the value of
<emphasis role= "bold" > <literal > reboot-command</literal> </emphasis> will include a
<emphasis role= "bold" > <literal > boot</literal> </emphasis> command that starts a client program and does
not return.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
<section >
<title > LoPAR Processor</title>
<para > OF defines a minimum cell size of 32 bits; therefore, only one cell
is necessary to represent addresses up to 4GB (32 bits). Two cells are
necessary to represent addresses above 4GB and within 64 bits. Also, two
cells are necessary to represent sizes greater than 4GB.</para>
<section >
<title > Processor Endian-ness Support</title>
<para > LoPAR requires the use of PA processors that support Big-Endian
storage format. LoPAR allows for the use of PA processors that support
Little-Endian storage format in addition to Big-Endian storage
format.</para>
</section>
<section >
<title > Multi-Threading Support</title>
<para > The processors used in some platforms support multiple threads of
execution. This processor model differs from Symmetric Multi-Processors
in that the multiple threads of execution share the processor hardware to
such an extent that operations on one thread can significantly affect the
performance of another tread of the same processor. Therefore, the
processor is represented with a single processor node having multiple
interrupt server numbers. The OS is then free to start and stop
multi-threading as the processing environment dictates. The client
interface call
<emphasis role= "bold" > <literal > start-cpu</literal> </emphasis> , operates on the full CPU as presented in
the device tree, upon successful completion, the started CPU is running
in single threaded mode, the active thread being the one associated with
the first interrupt server number in the
<emphasis role= "bold" > <literal > “ ibm,ppc-interrupt-server#s” </literal> </emphasis> property.
The client interface calls:
<emphasis role= "bold" > <literal > stop-self, idle-self, resume-cpu</literal> </emphasis> are all defined to
operate on the full CPU when called in single threaded mode, the behavior
of these calls if called with multiple threads active is implementation
dependent, it is suggested that the implementation deactivate all but one
thread before performing the call’ s standard function.</para>
</section>
</section>
<section >
<title > OF Platform Extensions</title>
<para > This section defines OF properties, methods, device tree structure
and Client Interface Service requirements for LoPAR platforms.</para>
<para > The naming conventions for IBM unique OF properties and devices are
as follows:</para>
<itemizedlist >
<listitem >
<para > Properties created for use only by IBM compatible implementations
must have the string
<emphasis role= "bold" > <literal > “ ibm,” </literal> </emphasis> as a prefix to the property
name.</para>
</listitem>
<listitem >
<para > Property names prefixed with the string
<emphasis role= "bold" > <literal > “ ibm,fw-” </literal> </emphasis> are reserved for and must be
controlled by the Firmware Area.</para>
</listitem>
<listitem >
<para > An IBM property name which does not have the firmware or AIX prefix
must be defined in this document unless documented elsewhere.</para>
</listitem>
<listitem >
<para > The value of a device
<emphasis role= "bold" > <literal > “ name” </literal> </emphasis> whether reported through the
compatible property or name property for a device implemented by IBM must
contain the string
<emphasis role= "bold" > <literal > “ IBM,” </literal> </emphasis> as a prefix unless it conforms to a
binding which specifies otherwise.</para>
</listitem>
</itemizedlist>
<section xml:id= "dbdoclet.50569368_13582" >
<title > Properties for Dynamic Reconfiguration</title>
<para > The following property, when present, replaces the following four properties:
<emphasis role= "bold" > <literal > “ ibm,drc-indexes” </literal> </emphasis> ,
<emphasis role= "bold" > <literal > “ ibm,drc-names” </literal> </emphasis> ,
<emphasis role= "bold" > <literal > “ ibm,drc-types” </literal> </emphasis> and
<emphasis role= "bold" > <literal > “ ibm,drc-power-domains” </literal> </emphasis> .
This property is defined for all dynamically reconfigurable platform nodes.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,drc-info” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> that defines all required DR information in a new format</para>
<para > <emphasis > prop-encoded-array</emphasis> : The first element of the array is the number of drc-info entries,
encoded with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> </para>
<para > The drc-info entry consists of the following elements:</para>
<itemizedlist mark= "none" >
<listitem >
<para > The <emphasis > drc-type</emphasis> encoded with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .
Examples include “MEM” “PHB” and “CPU”</para>
</listitem>
<listitem >
<para > The <emphasis > drc-name-prefix</emphasis> encoded with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .
Examples include “LMB” “PHB “ “CPU “ and “U8233.E8B.1000C9P-V1-C”</para>
</listitem>
<listitem >
<para > The <emphasis > drc-index-start</emphasis> encoded with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .
The first drc-index of the first entity in the sequence of
entities described by this <emphasis > ibm,drc-info entry</emphasis> .</para>
</listitem>
<listitem >
<para > The <emphasis > drc-name-suffix-start</emphasis> encoded with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .
The integer value that is to be converted to asci and appended to the
drc-name-prefix to create the complete
drc-name of the first entity in the sequence of entities
described by this <emphasis > ibm,drc-info entry</emphasis> .</para>
</listitem>
<listitem >
<para > The <emphasis > number-sequential-elements</emphasis> encoded with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .
The number of sequential entities described by this
<emphasis > ibm,drc-info entry</emphasis> .</para>
</listitem>
<listitem >
<para > The <emphasis > sequential-increment</emphasis> encoded with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .
The number by which to increment the drc-index and the name-suffix
for each sequential entity.</para>
</listitem>
<listitem >
<para > The <emphasis > drc-power-domain</emphasis> encoded with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</itemizedlist>
</listitem>
</varlistentry>
</variablelist>
<para > The following properties have been replaced by the
<emphasis role= "bold" > <literal > “ ibm,drc-info” </literal> </emphasis> but are documented
here for legacy purposes:</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,drc-indexes” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> denotes an integer index to be used to
communicate to the firmware what connector is to be operated upon for the
various RTAS calls used for DR.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , followed by a list of integers also
encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > For each DR connector, a unique integer index is provided which
uniquely identifies the DR connector for purposes of the
<emphasis > ibm,configure-connector</emphasis> ,
<emphasis > set-indicator,</emphasis> and
<emphasis > get-sensor</emphasis> RTAS calls. The first element of the array
is the number of connectors associated with the node. The second element
of the array is the index which represents the first connector associated
with the node, the third element the second connector, and so on until
all of the node’ s DR connectors are specified.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,my-drc-index” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> denotes an integer index (value of the
entry in the
<emphasis role= "bold" > <literal > “ ibm,drc-indexes” </literal> </emphasis> property) for the
connector between the node and the node’ s parent.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An array of integers encoded as
with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,drc-names” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> describes the external labeling of the
DR connectors.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , followed by a list of strings each
encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > For each DR connector, a unique human-readable name for a
connector. The first element of the array is the number of connectors
associated with the node. The second element of the array is the
human-readable name which represents the first connector associated with
the node, the third element the second connector, and so on until all of
the node’ s DR connectors are specified.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,drc-power-domains” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> gives the power domain number for each
connector associated with the node, which is the domain number to be used
in the
<emphasis role= "bold" > <literal > set-power-level</literal> </emphasis> RTAS call, if necessary.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , followed by a list of integers also
encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > For each DR connector, the power domain which will be controlled
for DR operations (the power domain in which the DRC resides), and which
will be used, if not -1, in the
<emphasis role= "bold" > <literal > set-power-level</literal> </emphasis> RTAS call for the connector. The
power domain number of -1 denotes a live-insertion power domain (in which
case, the
<emphasis role= "bold" > <literal > set-power-level</literal> </emphasis> RTAS call is not used). The first
element of the array is the number of connectors associated with this
node. The second element represents the domain number for the first
connector. The element following this is the domain number for the second
connector, and so on until all of the node’ s DR connectors are
specified.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,drc-types” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> , describes the type of each connector
associated with the node, in a human-readable form.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , followed by a list of strings each
encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The first element of the array is the number of connectors
associated with this node. The second element of the array is the
connector type of the first connector associated with the node, the third
element the second connector, and so on until all the node’ s DR
connectors are specified, and these elements will be one of the currently
defined connector types specified in
<xref linkend= "dbdoclet.50569368_97022" /> .</para>
<table frame= "all" pgwide= "1" xml:id= "dbdoclet.50569368_97022" >
<title > Currently Defined DR Connector Types</title>
<tgroup cols= "2" >
<colspec colname= "c1" colwidth= "15*" align= "center" />
<colspec colname= "c2" colwidth= "85*" />
<thead >
<row >
<entry >
<para >
<emphasis role= "bold" > Connector Type(character
string)</emphasis>
</para>
</entry>
<entry align= "center" >
<para >
<emphasis role= "bold" > Description</emphasis>
</para>
</entry>
</row>
</thead>
<tbody >
<row >
<entry >
<para > 1</para>
</entry>
<entry >
<para > A 32-bit, 5 Volt conventional PCI slot which accommodates
cards that operate up to 33 MHz Only.</para>
</entry>
</row>
<row >
<entry >
<para > 2</para>
</entry>
<entry >
<para > A 32-bit, 5 Volt conventional PCI slot which accommodates
cards that operate up to 33 MHz.</para>
</entry>
</row>
<row >
<entry >
<para > 3</para>
</entry>
<entry >
<para > A 32-bit, 3.3 Volt conventional PCI slot which
accommodates cards that operate up to 33 MHz Only.</para>
</entry>
</row>
<row >
<entry >
<para > 4</para>
</entry>
<entry >
<para > A 64-bit, 5 Volt conventional PCI slot which accommodates
cards that operate up to 33 MHz Only.</para>
</entry>
</row>
<row >
<entry >
<para > 5</para>
</entry>
<entry >
<para > A 64-bit, 5 Volt conventional PCI slot which accommodates
cards that operate up to 33 MHz.</para>
</entry>
</row>
<row >
<entry >
<para > 6</para>
</entry>
<entry >
<para > A 64-bit, 3.3 Volt conventional PCI slot which
accommodates cards that operate up to 33 MHz Only.</para>
</entry>
</row>
<row >
<entry >
<para > 7</para>
</entry>
<entry >
<para > A 32-bit, 3.3 Volt conventional PCI slot which
accommodates cards that operate up to 66 MHz. IOAs that operate
up to 66 MHz will only operate at frequencies above 33 MHz if
there are no 33 MHz IOAs on the same bus.</para>
</entry>
</row>
<row >
<entry >
<para > 8</para>
</entry>
<entry >
<para > A 64-bit, 3.3 Volt conventional PCI slot which
accommodates cards that operate up to 66 MHz. IOAs that operate
up to 66 MHz will only operate at frequencies above 33 MHz if
there are no 33 MHz IOAs on the same bus.</para>
</entry>
</row>
<row >
<entry >
<para > 9</para>
</entry>
<entry >
<para > Reserved</para>
</entry>
</row>
<row >
<entry >
<para > 10</para>
</entry>
<entry >
<para > Reserved</para>
</entry>
</row>
<row >
<entry >
<para > 11</para>
</entry>
<entry >
<para > A 32-bit PCI-X capable slot which accommodates cards that
operate up to 66 MHz</para>
</entry>
</row>
<row >
<entry >
<para > 12</para>
</entry>
<entry >
<para > A 32-bit PCI-X capable slot which accommodates cards that
operate up to 100 MHz</para>
</entry>
</row>
<row >
<entry >
<para > 13</para>
</entry>
<entry >
<para > A 32-bit PCI-X capable slot which accommodates cards that
operate up to 133 MHz</para>
</entry>
</row>
<row >
<entry >
<para > 14</para>
</entry>
<entry >
<para > A 64-bit PCI-X capable slot which accommodates cards that
operate up to 66 MHz</para>
</entry>
</row>
<row >
<entry >
<para > 15</para>
</entry>
<entry >
<para > A 64-bit PCI-X capable slot which accommodates cards that
operate up to 100 MHz</para>
</entry>
</row>
<row >
<entry >
<para > 16</para>
</entry>
<entry >
<para > A 64-bit PCI-X capable slot which accommodates cards that
operate up to 133 MHz</para>
</entry>
</row>
<row >
<entry >
<para > 17</para>
</entry>
<entry >
<para > A 64-bit PCI-X capable slot which accommodates cards that
operate up to 266 MHz</para>
</entry>
</row>
<row >
<entry >
<para > 18</para>
</entry>
<entry >
<para > A 64-bit PCI-X capable slot which accommodates cards that
operate up to 533 MHz</para>
</entry>
</row>
<row >
<entry >
<para > 19</para>
</entry>
<entry >
<para > A PCI Express Rev 1 slot with 1x lanes.</para>
</entry>
</row>
<row >
<entry >
<para > 20</para>
</entry>
<entry >
<para > A PCI Express Rev 1 slot with 2x lanes.</para>
</entry>
</row>
<row >
<entry >
<para > 21</para>
</entry>
<entry >
<para > A PCI Express Rev 1 slot with 4x lanes.</para>
</entry>
</row>
<row >
<entry >
<para > 22</para>
</entry>
<entry >
<para > A PCI Express Rev 1 slot with 8x lanes.</para>
</entry>
</row>
<row >
<entry >
<para > 23</para>
</entry>
<entry >
<para > A PCI Express Rev 1 slot with 16x lanes.</para>
</entry>
</row>
<row >
<entry >
<para > 24</para>
</entry>
<entry >
<para > A PCI Express Rev 1 slot with 32x lanes.</para>
</entry>
</row>
<row >
<entry >
<para > 25</para>
</entry>
<entry >
<para > A PCI Express Rev 2 slot with 1x lanes.</para>
</entry>
</row>
<row >
<entry >
<para > 26</para>
</entry>
<entry >
<para > A PCI Express Rev 2 slot with 2x lanes.</para>
</entry>
</row>
<row >
<entry >
<para > 27</para>
</entry>
<entry >
<para > A PCI Express Rev 2 slot with 4x lanes.</para>
</entry>
</row>
<row >
<entry >
<para > 28</para>
</entry>
<entry >
<para > A PCI Express Rev 2 slot with 8x lanes.</para>
</entry>
</row>
<row >
<entry >
<para > 29</para>
</entry>
<entry >
<para > A PCI Express Rev 2 slot with 16x lanes.</para>
</entry>
</row>
<row >
<entry >
<para > 30</para>
</entry>
<entry >
<para > A PCI Express Rev 2 slot with 32x lanes.</para>
</entry>
</row>
<row >
<entry >
<para > CPU</para>
</entry>
<entry >
<para > Logical CPU</para>
</entry>
</row>
<row >
<entry >
<para > MEM</para>
</entry>
<entry >
<para > Logical Memory Region</para>
</entry>
</row>
<row >
<entry >
<para > MEM-n</para>
<para > (where n is a</para>
<para > non-zero integer)</para>
</entry>
<entry >
<para > Extended Logical Memory Region(s). Used with the Reserved
Memory option.</para>
</entry>
</row>
<row >
<entry >
<para > PHB</para>
</entry>
<entry >
<para > Logical PCI Host Bridge</para>
</entry>
</row>
<row >
<entry >
<para > SLOT</para>
</entry>
<entry >
<para > Logical I/O slot</para>
</entry>
</row>
<row >
<entry >
<para > PORT</para>
</entry>
<entry >
<para > Logical Port</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,phandle” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> , defines the phandle for the
node.</para>
<para >
<emphasis > prop-encode-array</emphasis> : An integer encoded with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section >
<title > OF Root Node</title>
<para > This section defines additional properties and methods associated
with LoPAR platforms that OSs expect to find in the root node. Unit
addresses in an LoPAR system are limited to 60 bits in length
corresponding to the maximum real address supported by the POWER
processor architecture. The unit address of all non-system nodes that are
children of the root node shall have the same value each time the
platform is booted; i.e., shall be invariant for each boot
process.</para>
<para >
<emphasis role= "bold" > Notes:</emphasis>
</para>
<orderedlist >
<listitem >
<para > This requirement ensures that the PHB would have a stable unit
address. Violations of this rule may require reinstallation of an
OS.</para>
</listitem>
<listitem >
<para > The recommended practice is to generate a virtual unit address
for PHB nodes. This is done by giving a zero length to its first reg
property with an address that is selected such that it remains constant.
In single bridge platforms, the value is chosen based upon historical
precedent of the predecessor product. In multi-enclosure platforms, the
virtual unit address is based upon the manufacturing serial number to
insure uniqueness.</para>
</listitem>
</orderedlist>
<section xml:id= "dbdoclet.50569368_54493" >
<title > Root Node Properties</title>
<para > This section defines the additional properties or values which
shall be present in the root node unless otherwise specified.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ #address-cells” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> , encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , that specifies the number of cells
required to represent physical addresses on the processor bus. The value
of
<emphasis role= "bold" > <literal > “ #address-cells” </literal> </emphasis> for the processor bus
shall be 1 or 2 depending on whether there is any memory addressable at
or above 4GB’ s.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ #size-cells” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> , encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , that specifies the size of cells
required to represent physical addresses on the processor bus. The value
of
<emphasis role= "bold" > <literal > “ #size-cells” </literal> </emphasis> for the processor bus shall
be 1 or 2 depending on whether there is any memory addressable at or
above 4GB’ s.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ clock-frequency” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> , encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , that represents the primary system bus
speed (in hertz).</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,extended-clock-frequency” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> : Property that represents the primary
system bus speed in hertz of this node. This property allows the encoding
of multi-giga-hertz quantities.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : Consisting of two cells
(freq-hi, freq-lo) each encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , such that their combined value is
(freq-hi || freq-lo).</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ system-id” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> , encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> , that contains the identification of
the computer system (Reference the
<emphasis role= "bold" > <literal > “ name” </literal> </emphasis> property in
<xref linkend= "dbdoclet.50569387_45524" /> ). This string should be unique
across all systems and all manufacturers. An example of an address of
this form is “ 0nnnnnnmmmmmm” where nnnnnn is a sequence of 6
uppercase hexadecimal digits representing a 24-bit value that identifies
manufacturer and mmmmmm is a sequence of 6 uppercase hexadecimal digits
representing a 24-bit binary number assigned by the manufacturer to
assure uniqueness.</para>
<para >
<emphasis role= "bold" > Note:</emphasis> For platforms with built-in ethernet or other
IEEE 802-style interfaces, the 6-byte MAC address assigned to that
interface meets the requirements and could be used as the
system-id.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ model” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> that is a printable string identifying
the manufacturer and model number of the platform.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : Text string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The value of this property is a vendor dependent string which
identifies this platform via its manufacturer and model number.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ device_type” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> that is a printable string identifying
the platform as LoPAR Compliant.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : Text string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The value of this property is a string,
<emphasis role= "bold" > <literal > “ chrp” </literal> </emphasis> which identifies the platform is
LoPAR Compliant.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,lpar-capable” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> indicates that the platform is capable
of supporting logical partitioning and is only present on such systems.
This property is, however, present even if the platform is not currently
configured for logical partition operation.</para>
<para > <emphasis > prop-encoded-array</emphasis> : < NULL> </para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,converged-loc-codes” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> indicates that the platform supports
the “ Converged Location Code” option. This property shall be
present only on platforms that support the “ Converged Location
Code” option.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : < NULL> </para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,max-boot-devices” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> indicates the maximum number of
boot-device entries that the OF automatic boot code will process (entries
after this number are ignored). Platforms that do not present this
property default to process a maximum of 5 entries.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : an integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,aix-diagnostics” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> indicates that the platform is capable
running AIX diagnostics.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : < NULL> </para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,diagnostic-lic” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> , presented to partitions authorized to
perform diagnostic operations, that indicates that the platform is
designed to use the specified license internal code package for
diagnostic services.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : one or more encapsulated package
handles encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,io-server-lic” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> indicates that the platform is designed
to use the specified license internal code package for I/O
services.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : one or more encapsulated package
handles encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,plat-res-int-priorities” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> that designates to the client program
that the platform has reserved one or more interrupt priorities for its
own use.</para>
<para >
<emphasis > prop-encoded-value</emphasis> : one or more (
<emphasis > interrupt priority, range</emphasis> ) pairs, where
<emphasis > interrupt priority</emphasis> is a single cell hexidecimal
number between 0x00 and 0xFF, and
<emphasis > range</emphasis> is an integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that represents the number of contiguous
interrupt priorities that have been reserved by the platform for its
internal use.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,eeh-default” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> indicates the platform’ s default
setting for the EEH option.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that represents the platform’ s
default setting for the EEH option. The defined states are:</para>
<para > 0= The platform boots up with the EEH option disabled.</para>
<para > 1= The platform boots up with the EEH option enabled.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,model-class” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> to indicate the platform class.</para>
<para > <emphasis > prop-encoded-array</emphasis> : string encoded as defined in
<xref linkend= "dbdoclet.50569368_33018" /> .</para>
<table frame= "all" pgwide= "1" xml:id= "dbdoclet.50569368_33018" >
<title > Example Encoding Strings</title>
<?dbhtml table-width="50%" ?>
<?dbfo table-width="50%" ?>
<tgroup cols= "2" >
<colspec colname= "c1" colwidth= "50*" align= "center" />
<colspec colname= "c2" colwidth= "50*" align= "center" />
<thead >
<row >
<entry >
<para >
<emphasis role= "bold" > Encoded String</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > Platform Class</emphasis>
</para>
</entry>
</row>
</thead>
<tbody >
<row >
<entry >
<para > C5</para>
</entry>
<entry >
<para > Blade/Entry</para>
</entry>
</row>
<row >
<entry >
<para > D5</para>
</entry>
<entry >
<para > Entry</para>
</entry>
</row>
<row >
<entry >
<para > E5</para>
</entry>
<entry >
<para > Entry</para>
</entry>
</row>
<row >
<entry >
<para > F5</para>
</entry>
<entry >
<para > Mid-range</para>
</entry>
</row>
<row >
<entry >
<para > G5</para>
</entry>
<entry >
<para > High-end</para>
</entry>
</row>
<row >
<entry >
<para > H5</para>
</entry>
<entry >
<para > High-end</para>
</entry>
</row>
<row >
<entry >
<para > P5</para>
</entry>
<entry >
<para > obsolete</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,partition-no” [S]</literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> to define the partition number of this particular
logical partition as established by the Hardware Management
Console.</para>
<para > <emphasis > prop-encoded-array</emphasis> : The logical partition number is a one cell
integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,partition-name” [S]</literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> to define the partition name of this particular
logical partition as established by the Hardware Management
Console.</para>
<para > <emphasis > prop-encoded-array</emphasis> : A NULL terminated string.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,platform-hardware-notification” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> indicating to the OS the presence of
hardware for which the OS may need to take action. This property exists
to notify the OS of hardware elements on the platform which may require
special handling by the OS, such as in response to a hardware
errata.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> followed by a list of strings encoded as
with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The first element represents the number of strings to follow in the
property. Each string in the array names a hardware element that may
require the OS to take specific action. The intention is that the string
is to name the hardware element being reported. It is not the intention
to define (or even hint at) the action that the OS must take. It is
expected that some source outside this document will contain a cross
reference between these strings and documentation such as hardware errata
notes which define the action the OS must take.</para>
<para > If the
<emphasis role= "bold" > <literal > “ ibm,platform-hardware-notification” </literal> </emphasis>
property is provided and a string begins with the < name> field of the
<emphasis role= "bold" > <literal > “ name” </literal> </emphasis> (see
<xref linkend= "dbdoclet.50569374_59715" /> ) property in the
<emphasis > CPU</emphasis> nodes followed by an underscore, the characters
following the underscore are a hexadecimal representation of the contents
of a Processor Version Register that the platform may contain.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,fault-behavior” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> to define the behavior of the Error Log
indicator relative to FRU faults.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer encoded as with
encode-int that represents how the Error Log indicator should be handled
when a FRU fault is detected.</para>
<para > Property non-existent -- The OS may set FRU Fault and Error Log
indicators for all errors (those it detected and those that the platform
reports to the OS).</para>
<para > Property exists with a value of 1 -- The OS only sets FRU Fault and
Error Log indicators for errors it detects.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,fru-9006-deactivate” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> to define whether or not the OS should
deactivate 9006 indicators that it has activated.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer encoded as with
encode-int that represents how the OS should behave relative to FRU Fault
indicator deactivation.</para>
<para > Property non-existent -- The OS is responsible for deactivating FRU
level 9006 indicators that it has activated.</para>
<para > Property exists with a value of 1 -- The OS should not deactivate
FRU level 9006 indicators that it has activated, but is allowed to do so
(firmware does not block). The deactivation of the FRU level 9006
indicators is platform and service procedure dependent.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ compatible” [S]</literal> </emphasis> </term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> that conveys the platform architecture
identifiers.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : The concatenation, with
<emphasis role= "bold" > <literal > encode+</literal> </emphasis> , of an arbitrary number of text strings,
each encoded with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > Specifies a list of platform architectures with which this platform
is compatible. This is used by a client program when it is trying to
determine the appropriate support for this platform. This property shall
include the substring “ LoPAR-< LoPAR
version> -< Manufacturer> -< Manufacturer Version> ”
where < LoPAR version> is the text (without blanks) after the word
“ Version” on the cover page of the LoPAR specification that
the platform adheres to, < Manufacturer> is a unique string
identifying the manufacturer of the platform (see the OF standard
description of the
<emphasis role= "bold" > <literal > “ name” </literal> </emphasis> property for suggestions), and
< Manufacturer_Version> is defined by the manufacturer of the
platform.</para>
<para >
<emphasis role= "bold" > Note:</emphasis> In order to comply with the OF Standard
description of the
<emphasis role= "bold" > <literal > “ compatible” </literal> </emphasis> property, implementations
should place the “ LoPAR-< LoPPR
version> -< Manufacturer> -< Manufacturer Version> ”
substring after values that were present in the
<emphasis role= "bold" > <literal > “ compatible” </literal> </emphasis> property prior to the
inclusion of the “ LoPAR-< LoPAR
version> -< Manufacturer> -< Manufacturer Version> ”
substring.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,max-vios-function-level” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> to define the maximum vios function
level that a client shall permit.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that represents the maximum VIOS level
that the client shall negotiate. See
<xref linkend= "LoPAR.Virtualization" /> for the definition of the
values of this property.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,partition-performance-parameters-level” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> to define the level of partition
performance parameter reporting supported by the platform.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer encoded as with
encode-int that represents the level of partition performance parameter
reporting supported by the platform (See
<xref linkend= "dbdoclet.50569368_69425" /> ).</para>
<table frame= "all" pgwide= "1" xml:id= "dbdoclet.50569368_69425" >
<title > Level of Partition Performance Parameter Reporting
Supported</title>
<?dbhtml table-width="75%" ?>
<?dbfo table-width="75%" ?>
<tgroup cols= "2" >
<colspec colname= "c1" colwidth= "30*" align= "center" />
<colspec colname= "c2" colwidth= "70*" />
<thead >
<row >
<entry >
<para >
<emphasis role= "bold" > Partition Performance Parameter
Level</emphasis>
</para>
</entry>
<entry align= "center" >
<para >
<emphasis role= "bold" > Description</emphasis>
</para>
</entry>
</row>
</thead>
<tbody >
<row >
<entry >
<para > 0</para>
</entry>
<entry >
<para > Base Level</para>
</entry>
</row>
<row >
<entry >
<para > 1</para>
</entry>
<entry >
<para > Addition of Processor Virtualization Resource Allocations
to H_GET_PPP and Virtualization Processor idle count to
H_PIC</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,preconfigure-usb-kvm” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> the presence of which indicates that
the platform requires the operating system to force configuration of the
USB keyboard/mouse nodes during its configuration phase.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : < NULL> </para>
<para > This property, when present in the root node, indicates that the
platform requires the operating system to force pre-configuration of USB
keyboard/mouse nodes internally during its configuration phase. This
property is presented only by platforms with a KVM switch that desire to
force configuration by one or more target operating systems that do not
fully support dynamic addition of USB keyboard and mouse unless the USB
keyboard and mouse are actually seen during the operating system
configuration phase, but may be present even if the KVM switch is not
present when the device tree is inspected. Forced pre-configuration is
needed since the operating system may not actually see the USB keyboard
and mouse during its configuration phase due to the KVM switch that the
platform uses only shows USB keyboard and mouse when those devices are
actually switched to the appropriate KVM switch port.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,enable-ci64-capable” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> to define the platform supports the
<emphasis role= "bold" > <literal > “ ibm,enable-ci64” </literal> </emphasis> method in the Client
Interface.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : None, this is a name only
property.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,migratable-partition” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> indicating that the platform supports
the potential migration of this partition.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : < NULL> </para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,extended-address” </literal> </emphasis> [S]</term>
<listitem >
<para >
<emphasis > property name</emphasis> indicates this platform supports
Peripheral Memory Spaces, Peripheral I/O Spaces, and SCA spaces above 4
GB.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : < none> </para>
<para > This property must be present.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,ignore-hp-po-fails-for-dlpar” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> to define that the OS may ignore
failures of Hot Plug power off and isolate operations during a DLPAR
remove operation. See also Note 2 in
<xref linkend= "LoPAR.Virtualization" /> .</para>
<para >
<emphasis > prop-encoded-array</emphasis> : None, this is a name only
property.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,managed-address-types” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> that conveys the platform's supported
types of external addresses that are reprogrammable.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : The concatenation, with
<emphasis role= "bold" > <literal > encode+</literal> </emphasis> , of an arbitrary number of text strings as
described in
<xref linkend= "dbdoclet.50569368_71702" /> , each encoded with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<table frame= "all" pgwide= "1" xml:id= "dbdoclet.50569368_71702" >
<title > Address types supported in
<emphasis role= "bold" > <literal > “ ibm,managed-address-types” </literal> </emphasis>
property</title>
<?dbhtml table-width="75%" ?>
<?dbfo table-width="75%" ?>
<tgroup cols= "2" >
<colspec colname= "c1" colwidth= "40*" align= "center" />
<colspec colname= "c2" colwidth= "60*" align= "center" />
<thead >
<row >
<entry >
<para >
<emphasis role= "bold" > Text String</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > Description</emphasis>
</para>
</entry>
</row>
</thead>
<tbody >
<row >
<entry >
<para > ethernet_mac</para>
</entry>
<entry >
<para > Ethernet MAC address</para>
</entry>
</row>
<row >
<entry >
<para > ethernet_vlan</para>
</entry>
<entry >
<para > Ethernet VLAN ID (for default traffic)</para>
</entry>
</row>
<row >
<entry >
<para > san_wwn</para>
</entry>
<entry >
<para > Fibre Channel World Wide Name (covers both Port &
Node names)</para>
</entry>
</row>
<row >
<entry >
<para > sas_wwid</para>
</entry>
<entry >
<para > SAS IOA's WWID value</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,service-indicator-mode” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> indicates in which service indicator
mode the platform is operating.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : an integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that represents the mode. Defined values
are:</para>
<itemizedlist >
<listitem >
<para > 0 = Platform is operating in the Guiding Light mode.</para>
</listitem>
<listitem >
<para > 1 = Platform is operating in the Lightpath mode.</para>
</listitem>
</itemizedlist>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,guid-partition-table” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> indicates that the partition supports disks
with the GUID Partition Table.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : < NULL> </para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,linux-le-capable” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> indicates that the partition is capable of
supporting boot of Little Endian Linux.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : < NULL> </para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,partition-uuid” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> specifies a universally unique identifier for this partition.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : A string of data as described below, encoded as with
<emphasis role= "bold" > encode-string</emphasis> </para>
<para > The Universally Unique IDentifier (UUID) option provides each partition with a
Universally Unique Identifier that is persisted by the platform across partition
reboots, reconfigurations, OS reinstalls, partition migration, hibernation etc.
The UUID is a 16 byte string of format fields and random bits as defined in
<xref linkend= "dbdoclet.50569332_20419" /> .</para>
<para > The random bits are generated in an implementation-dependent manner to
achieve a projected probability of collision of not greater than one in 2<superscript > 60</superscript> .</para>
<table frame= "all" pgwide= "1" xml:id= "dbdoclet.50569332_20419" >
<title > UUID Format</title>
<tgroup cols= "4" >
<colspec colname= "c1" colwidth= "25*" />
<colspec colname= "c2" colwidth= "25*" />
<colspec colname= "c3" colwidth= "25*" />
<colspec colname= "c4" colwidth= "25*" />
<thead >
<row >
<entry >
<para >
<emphasis role= "bold" > Field</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > Byte:Bit</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > Size (Bits)</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > Values</emphasis>
</para>
</entry>
</row>
</thead>
<tbody >
<row >
<entry >
<para > Version</para>
</entry>
<entry >
<para > 0:0</para>
</entry>
<entry >
<para > 1</para>
</entry>
<entry >
<para > 0: Initial Version</para>
<para > 1: Reserved</para>
</entry>
</row>
<row >
<entry >
<para > Random Bits</para>
</entry>
<entry >
<para > 0:1 thru 5:7</para>
</entry>
<entry >
<para > 47</para>
</entry>
<entry >
<para > Random Bits</para>
</entry>
</row>
<row >
<entry >
<para > Generation Method</para>
</entry>
<entry >
<para > 6:0-3</para>
</entry>
<entry >
<para > 4</para>
</entry>
<entry >
<para > 0b0000 Never Used</para>
<para > 0b0100 Random Generated</para>
<para > All other values are reserved</para>
</entry>
</row>
<row >
<entry >
<para > Random Bits</para>
</entry>
<entry >
<para > 6:4 - 7:7</para>
</entry>
<entry >
<para > 12</para>
</entry>
<entry >
<para > Random Bits</para>
</entry>
</row>
<row >
<entry >
<para > Variant</para>
</entry>
<entry >
<para > 8:0-1</para>
</entry>
<entry >
<para > 2</para>
</entry>
<entry >
<para > 0b10 DCE Variant UUID</para>
<para > All other values are reserved</para>
</entry>
</row>
<row >
<entry >
<para > Random Bits</para>
</entry>
<entry >
<para > 8:2 - 15:7</para>
</entry>
<entry >
<para > 62</para>
</entry>
<entry >
<para > Random Bits</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
<para > For the GET_PARTNER_UUID subfunction (See <xref linkend= "LoPAR.Virtualization" /> ), the data is
represented as 16 bytes as described in <xref linkend= "dbdoclet.50569332_20419" /> .</para>
<para > For the ibm,partition-uuid property, the data is represented as a string of
hexadecimal characters, with hyphens added for readability.
Hexadecimal values a through f are lower case. An example of the string
representation of the UUID is 648a9ca6-1fb4-4f7e-9436-14d015f3dd74</para>
</listitem>
</varlistentry>
</variablelist>
<para >
<emphasis role= "bold" > Implementation Notes:</emphasis>
</para>
<orderedlist >
<listitem >
<para > In the absence of this property, the determination of how the OS
is to behave is made by the platform presenting or not presenting FRU
Fault indicators to the OS see chapter
<xref linkend= "LoPAR.Error" /> . In the case where there are
no FRUs owned by the partition, the OS will not observe any FRU Fault
indicators assigned, even when the platform is operating in the Lightpath
mode.</para>
</listitem>
<listitem >
<para > Presenting this property does not imply any relaxation of the
requirements spe3cified in chapter
<xref linkend= "LoPAR.Error" /> .</para>
</listitem>
</orderedlist>
</section>
<section xml:id= "dbdoclet.50569368_10192" >
<title > Properties of the Children of Root</title>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,9009-domain” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> that defines the index for a 9009 reset
component indicator, and if it exists, the corresponding 9009 sensor, for
the node in which the property exists. Multiple nodes may have the same
index, indicating that they belong to the same reset domain; including
nodes which are not descendents of the node which contains this property.
Descendents of a node containing this property will be in the same reset
domain.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer encoded as with
<emphasis role= "bold" > <literal > encode-phys</literal> </emphasis> that represents the index for the
indicator, and if it exists, for the corresponding sensor.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,associativity” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> to define the associativity domains for this
resource.</para>
<para > <emphasis > prop-encoded-array</emphasis> : One or more associativity lists. Each
associativity list consisting of a number of entries integer (N) encoded
as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> followed by N integers encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> each representing an associativity domain
number.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id= "dbdoclet.50569368_13649" >
<title > Root Node Methods</title>
<para > This section defines methods associated with the platform via
“ /” (the
<emphasis > root</emphasis> node).</para>
<para >
<emphasis role= "bold" > Boot Loader Note:</emphasis> The suggested behavior for boot
loader client programs:</para>
<orderedlist >
<listitem >
<para > Check the <emphasis role= "bold" > <literal > “ ibm,rpa-client-config” </literal> </emphasis>
property to see if
the platform recognized the “ ignore-my-settings” bit in the
boot loader image i.e. YABOOT for LINUX.</para>
</listitem>
<listitem >
<para > If recognized, check for existence of
<emphasis role= "bold" > <literal > “ ibm,client-architecture-support” </literal> </emphasis>
and invoke that method with the
<!-- TODO: complete/correct this sentence -->
<emphasis role= "bold" > <literal > >ibm,???</literal> </emphasis> compatible (wording???) with the Real Base and Real Size constraints of the
kernel being loaded.</para>
</listitem>
<listitem >
<para > If that method did not exist, invoke
“ PROCESS-ELF-HEADER” from /packages/elf-loader with a
simulated ELF-header that the Linux kernel is compatible with.</para>
</listitem>
</orderedlist>
<para >
<emphasis role= "bold" > <literal > ibm,client-architecture-support (ibm,architecture.vec --
err?</literal> </emphasis> )</para>
<para > This method is called via the call-method
<emphasis > Client Interface Service</emphasis> , prior to starting other
partition processors or threads, to communicate to the platform, via the
<emphasis role= "bold" > <literal > ibm,architecture.vec</literal> </emphasis> structure, the architecture
options that are supported by the client program. Based upon this
knowledge the platform configures itself and the device tree to represent
the most functional programming environment supported by the combination
of the platform, client program and user specified constraints. If
multiple partition processors or threads are active at the time of the
<emphasis role= "bold" > <literal > ibm,client-architecture-support</literal> </emphasis> method call, or an
error is detected in the format of the
<emphasis role= "bold" > <literal > ibm,architecture.vec</literal> </emphasis> structure, the
<emphasis role= "bold" > <literal > err?</literal> </emphasis> boolean shall be
<emphasis > TRUE;</emphasis> else
<emphasis role= "bold" > <literal > FALSE</literal> </emphasis> . The
<emphasis role= "bold" > <literal > ibm,architecture.vec</literal> </emphasis> input parameter is the starting
address of a self defining structure in contiguous memory. Some bits
within the
<emphasis role= "bold" > <literal > ibm,architecture.vec</literal> </emphasis> structure option vectors
represent policies. When set, and an associated condition is detected,
the
<emphasis role= "bold" > <literal > ibm,client-architecture-support</literal> </emphasis> method does not
return and processing continues as with a boot failure of the client
program. The LoPAR architecture options that are selected by this method
are communicated in the value of the
<emphasis role= "bold" > <literal > “ ibm,architecture-vec-5” </literal> </emphasis> property of the
<emphasis role= "bold" > <literal > /chosen</literal> </emphasis> node.</para>
<para > To ensure the greatest level of interoperability, the client
program should constrain itself to using the set of instructions and
environment specified for first level interrupt handlers, see Book III of
the
<xref linkend= "dbdoclet.50569387_99718" /> , while not attempting access
to potentially optional SPRs or the MSR prior to invoking the
<emphasis role= "bold" > <literal > ibm,client-architecture-support</literal> </emphasis> root node
method.</para>
<para >
<emphasis role= "bold" > Architecture and Implementation Notes:</emphasis>
</para>
<itemizedlist >
<listitem >
<para > Most of the
<emphasis role= "bold" > <literal > IBM,RPA-Client-Config</literal> </emphasis> ELF header functionality is
subsumed by the
<emphasis role= "bold" > <literal > ibm,client-architecture-support</literal> </emphasis> root method. However,
the
<emphasis role= "bold" > <literal > ibm,client-architecture-support</literal> </emphasis> root method does not
support the functionality specified through the ns.min-load field of the
<emphasis role= "bold" > <literal > IBM,RPA-Client-Config</literal> </emphasis> ELF header. Supporting firmware
implementations are prepared to move themselves out of the way when
loading client programs.</para>
</listitem>
<listitem >
<para > When booting a client program, firmware processes an
<emphasis > IBM,RPA-Client-Config</emphasis> ELF header if present; a
subsequent call of the
<emphasis role= "bold" > <literal > ibm,client-architecture-support</literal> </emphasis> root method with
conflicting values in the
<emphasis role= "bold" > <literal > ibm,architecture.vec</literal> </emphasis> structure, overrides the
configuration variables set by the ELF header.</para>
</listitem>
</itemizedlist>
<para >
<emphasis role= "bold" > <literal > Formal definition of ibm,architecture.vec:</literal> </emphasis>
</para>
<para >
<emphasis role= "bold" > <literal > ibm,architecture.vec =</literal> </emphasis> a
<emphasis role= "bold" > <literal > PVR-list</literal> </emphasis> :
<emphasis role= "bold" > <literal > Number-of-option-vectors</literal> </emphasis> :
<emphasis role= "bold" > <literal > option-vectors</literal> </emphasis> [Number-of-option-vectors + 1]</para>
<para >
<emphasis role= "bold" > <literal > PVR-list</literal> </emphasis> =
<emphasis role= "bold" > <literal > Terminator-list-entry</literal> </emphasis> |
<emphasis role= "bold" > <literal > Non-terminator-list: Terminator-list-entry</literal> </emphasis> </para>
<para >
<emphasis role= "bold" > <literal > Non-terminator-list = Non-terminal-list-entry |
Non-terminal-list-entry : Non-terminator-list</literal> </emphasis>
</para>
<para >
<emphasis role= "bold" > <literal > List-entry</literal> </emphasis> =
<emphasis role= "bold" > <literal > 4-byte-mask</literal> </emphasis> :
<emphasis role= "bold" > <literal > 4-byte-PVR-value</literal> </emphasis> </para>
<para >
<emphasis role= "bold" > <literal > Terminator-list-entry</literal> </emphasis> =
<emphasis role= "bold" > <literal > List-entry</literal> </emphasis> such that !
<emphasis role= "bold" > <literal > 4-byte-mask</literal> </emphasis> &
<emphasis role= "bold" > <literal > 4-byte-PVR-value != 0x00000000</literal> </emphasis> </para>
<para >
<emphasis role= "bold" > <literal > Non-terminator-list-entry = List-entry</literal> </emphasis> such that !
<emphasis role= "bold" > <literal > 4-byte-mask & 4-byte-PVR-value ==
0x00000000</literal> </emphasis> </para>
<para >
<emphasis role= "bold" > <literal > Number-of-option-vectors =</literal> </emphasis> The number of option
vectors is n+1 where n is the numeric value of the byte (byte value of
0x00 represents one option vector)</para>
<para >
<emphasis role= "bold" > <literal > option-vector</literal> </emphasis> (option-vectors number 1-255): 1 byte
length of the option vector where the number of bytes in the option
vector (including the first byte of length) is n+2 where n is the numeric
value of the byte (byte value of 0x00 represents a two byte option vector
-- one length byte and one bit-vector byte) followed by 1-256 bytes of
<emphasis role= "bold" > <literal > bit-vector</literal> </emphasis> .</para>
<para >
<emphasis role= "bold" > <literal > option-vector</literal> </emphasis> (option-vector number 256): is special
in that it is reserved for expansion. The first byte is again the number
of option vectors in the vector expansion (see definition of
<emphasis role= "bold" > <literal > Number-of-option-vectors</literal> </emphasis> above). This is followed by
1-255
<emphasis role= "bold" > <literal > option-vectors</literal> </emphasis> (see definition above) and potentially
a 256th
<emphasis role= "bold" > <literal > option-vector</literal> </emphasis> which is again an expansion option
vector, and so on.</para>
<para >
<emphasis role= "bold" > <literal > bit-vector</literal> </emphasis> : The structure of a bit vector is vector
specific, in general support for most options are indicated by setting a
specific bit to a 1, see
<xref linkend= "dbdoclet.50569368_10077" /> .</para>
<para > The
<emphasis role= "bold" > <literal > PVR-list</literal> </emphasis> of the
<emphasis role= "bold" > <literal > ibm,architecture.vec</literal> </emphasis> structure is processed for the
PVR value of each processor that the client program may be exposed to
until either a
<emphasis role= "bold" > <literal > List-entry</literal> </emphasis> allows the process to continue, or the
<emphasis role= "bold" > <literal > Terminator-list-entry</literal> </emphasis> has been processed. If no
<emphasis role= "bold" > <literal > List-entry</literal> </emphasis> allows the process to continue, then the
<emphasis role= "bold" > <literal > ibm,client-architecture-support</literal> </emphasis> method terminates
partition operation as with a boot failure. A
<emphasis role= "bold" > <literal > List-entry</literal> </emphasis> allows the process to continue if either
of the two following conditions hold.</para>
<orderedlist >
<listitem >
<para > (Processor-PVR-value &
<emphasis role= "bold" > <literal > List-entry[4-byte-mask]) == (List-entry[4-byte-PVR-value] &
List-entry[4-byte-mask])</literal> </emphasis> /*The client program explicitly
supports the processor implementation */</para>
</listitem>
<listitem >
<para > If (the processor requires no client support for errata)
& &
<emphasis role= "bold" > <literal > (Logical-Processor-PVR-value & List-entry[4-byte-mask]) ==
(List-entry[4-byte-PVR-value] & List-entry[4-byte-mask])</literal> </emphasis> /*
Client program specifies support for this level of architecturally
compliant processors */</para>
</listitem>
</orderedlist>
<para >
<emphasis role= "bold" > <literal > List-entry</literal> </emphasis> values of special interest (these are
<emphasis role= "bold" > <literal > Terminator-list-entry</literal> </emphasis> values):</para>
<itemizedlist >
<listitem >
<para > 0x00000000 0xFFFFFFFF Single entry list that matches any PVR
value</para>
</listitem>
<listitem >
<para > 0xFF000000 0x0FFFFFFF Single entry list that matches all
architecturally compliant processors.</para>
</listitem>
</itemizedlist>
<table frame= "all" pgwide= "1" xml:id= "dbdoclet.50569368_10077" >
<title > ibm,architecture.vec option vectors</title>
<tgroup cols= "5" >
<colspec colname= "c1" colwidth= "10*" align= "center" />
<colspec colname= "c2" colwidth= "10*" align= "center" />
<colspec colname= "c3" colwidth= "10*" align= "center" />
<colspec colname= "c4" colwidth= "10*" align= "center" />
<colspec colname= "c5" colwidth= "60*" align= "center" />
<thead >
<row >
<entry >
<para >
<emphasis role= "bold" > Option Array</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > Option Vector</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > Byte Number</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > Bit Number</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > Description</emphasis>
</para>
</entry>
</row>
</thead>
<tbody >
<row >
<entry morerows= "18" >
<para > Base</para>
</entry>
<entry morerows= "18" >
<para > 1</para>
<para > PowerPC Server Processor Architecture Level 6</para>
</entry>
<entry morerows= "7" >
<para > 1</para>
</entry>
<entry >
<para > 0</para>
</entry>
<entry >
<para > Ignore<superscript > <xref linkend= "note.ignore" xrefstyle= "select: nopage" /> </superscript> </para>
</entry>
</row>
<row >
<entry >
<para > 1</para>
</entry>
<entry >
<para > Cessation Policy<superscript > <xref linkend= "note.cessation" xrefstyle= "select: nopage" /> </superscript> </para>
</entry>
</row>
<row >
<entry >
<para > 2</para>
</entry>
<entry morerows= "5" >
<para > Reserved for Expansion (0b0)</para>
</entry>
</row>
<row >
<entry >
<para > 3</para>
</entry>
</row>
<row >
<entry >
<para > 4</para>
</entry>
</row>
<row >
<entry >
<para > 5</para>
</entry>
</row>
<row >
<entry >
<para > 6</para>
</entry>
</row>
<row >
<entry >
<para > 7</para>
</entry>
</row>
<row >
<entry morerows= "7" >
<para > 2</para>
</entry>
<entry >
<para > 0</para>
</entry>
<entry >
<para > 2.00</para>
</entry>
</row>
<row >
<entry >
<para > 1</para>
</entry>
<entry >
<para > 2.01</para>
</entry>
</row>
<row >
<entry >
<para > 2</para>
</entry>
<entry >
<para > 2.02</para>
</entry>
</row>
<row >
<entry >
<para > 3</para>
</entry>
<entry >
<para > 2.03</para>
</entry>
</row>
<row >
<entry >
<para > 4</para>
</entry>
<entry >
<para > 2.04</para>
</entry>
</row>
<row >
<entry >
<para > 5</para>
</entry>
<entry >
<para > 2.05</para>
</entry>
</row>
<row >
<entry >
<para > 6</para>
</entry>
<entry >
<para > 2.06</para>
</entry>
</row>
<row >
<entry >
<para > 7</para>
</entry>
<entry >
<para > 2.07</para>
</entry>
</row>
<row >
<entry morerows= "1" >
<para > 3</para>
</entry>
<entry >
<para > 0</para>
</entry>
<entry >
<para > 2.08</para>
</entry>
</row>
<row >
<entry >
<para > 1-7</para>
</entry>
<entry >
<para > Reserved for Expansion (0b0)</para>
</entry>
</row>
<row >
<entry >
<para > 4-256</para>
</entry>
<entry nameend= "c5" namest= "c4" >
<para > Reserved for Expansion</para>
</entry>
</row>
<row >
<entry morerows= "18" >
<para > Base</para>
</entry>
<entry morerows= "18" >
<para > 2</para>
<para > Open Firmware</para>
</entry>
<entry morerows= "7" >
<para > 1</para>
</entry>
<entry >
<para > 0</para>
</entry>
<entry >
<para > Ignore<superscript > <xref linkend= "note.ignore" xrefstyle= "select: nopage" /> </superscript> </para>
</entry>
</row>
<row >
<entry >
<para > 1</para>
</entry>
<entry >
<para > Reserved</para>
</entry>
</row>
<row >
<entry >
<para > 2</para>
</entry>
<entry >
<para > real-mode</para>
</entry>
</row>
<row >
<entry >
<para > 3</para>
</entry>
<entry morerows= "4" >
<para > Reserved for Expansion (0b0)</para>
</entry>
</row>
<row >
<entry >
<para > 4</para>
</entry>
</row>
<row >
<entry >
<para > 5</para>
</entry>
</row>
<row >
<entry >
<para > 6</para>
</entry>
</row>
<row >
<entry >
<para > 7</para>
</entry>
</row>
<row >
<entry >
<para > 2-3</para>
</entry>
<entry >
<para > 0-15</para>
</entry>
<entry >
<para > Reserved for Expansion (0x0000)</para>
</entry>
</row>
<row >
<entry >
<para > 4-7</para>
<para > real-base</para>
</entry>
<entry >
<para > 0-31</para>
</entry>
<entry >
<para > OF real starting address or -1 for platform
default</para>
</entry>
</row>
<row >
<entry >
<para > 8-11</para>
<para > real-size</para>
</entry>
<entry >
<para > 0-31</para>
</entry>
<entry >
<para > Maximum OF size or -1 for platform default</para>
</entry>
</row>
<row >
<entry >
<para > 12-15</para>
<para > virt-base</para>
</entry>
<entry >
<para > 0-31</para>
</entry>
<entry >
<para > OF starting virtual address or -1 for platform default
(valid for real-mode = 0)</para>
</entry>
</row>
<row >
<entry >
<para > 16-19</para>
<para > virt-size</para>
</entry>
<entry >
<para > 0-31</para>
</entry>
<entry >
<para > Maximum OF virtual size or -1 for platform default (valid
for real-mode = 0)</para>
</entry>
</row>
<row >
<entry >
<para > 20-23</para>
<para > load-base</para>
</entry>
<entry >
<para > 0-31</para>
</entry>
<entry >
<para > Starting address of the client program load or -1 for
platform default</para>
</entry>
</row>
<row >
<entry >
<para > 24-27</para>
<para > min-rma-size</para>
</entry>
<entry >
<para > 0-31</para>
</entry>
<entry >
<para > Minimum size of RMA in MB<superscript > <xref linkend= "dbdoclet.50569368_24293" xrefstyle= "select: nopage" /> </superscript> </para>
<para > (total bytes = N*(2**20))</para>
</entry>
</row>
<row >
<entry >
<para > 28-31</para>
<para > min-load</para>
</entry>
<entry >
<para > 0-31</para>
</entry>
<entry >
<para > Minimum client code to load at load-base or -1 for full
client program at load base</para>
</entry>
</row>
<row >
<entry >
<para > 32</para>
<para > min-rma%</para>
</entry>
<entry >
<para > 0-8</para>
</entry>
<entry >
<para > RMA size => M% * Partition_memory_size where M is the
value of this 8 bit field<superscript > <xref linkend= "dbdoclet.50569368_24293" xrefstyle= "select: nopage" /> </superscript> </para>
</entry>
</row>
<row >
<entry >
<para > 33</para>
<para > max-pft-size</para>
</entry>
<entry >
<para > 0-8</para>
</entry>
<entry >
<para > The maximum size of the hash page table as 2**n
17< n< 46</para>
</entry>
</row>
<row >
<entry >
<para > 34-256</para>
</entry>
<entry >
<para > Reserved for Expansion</para>
</entry>
<entry >
<para >   </para>
</entry>
</row>
<row >
<entry morerows= "16" >
<para > Base</para>
</entry>
<entry morerows= "16" >
<para > 3</para>
<para > IBM PowerPC Server Processor Options<superscript > <xref linkend= "note.opt6" xrefstyle= "select: nopage" /> </superscript> </para>
</entry>
<entry morerows= "7" >
<para > 1</para>
</entry>
<entry >
<para > 0</para>
</entry>
<entry >
<para > Ignore<superscript > <xref linkend= "note.ignore" xrefstyle= "select: nopage" /> </superscript> </para>
</entry>
</row>
<row >
<entry >
<para > 1</para>
</entry>
<entry >
<para > Cessation Policy<superscript > <xref linkend= "note.cessation" xrefstyle= "select: nopage" /> </superscript> </para>
</entry>
</row>
<row >
<entry >
<para > 2</para>
</entry>
<entry morerows= "5" >
<para > Reserved for Expansion (0b0)</para>
</entry>
</row>
<row >
<entry >
<para > 3</para>
</entry>
</row>
<row >
<entry >
<para > 4</para>
</entry>
</row>
<row >
<entry >
<para > 5</para>
</entry>
</row>
<row >
<entry >
<para > 6</para>
</entry>
</row>
<row >
<entry >
<para > 7</para>
</entry>
</row>
<row >
<entry morerows= "7" >
<para > 2</para>
</entry>
<entry >
<para > 0</para>
</entry>
<entry >
<para > Floating Point</para>
</entry>
</row>
<row >
<entry >
<para > 1</para>
</entry>
<entry >
<para > VMX</para>
</entry>
</row>
<row >
<entry >
<para > 2</para>
</entry>
<entry >
<para > Decimal Floating Point</para>
</entry>
</row>
<row >
<entry >
<para > 3</para>
</entry>
<entry >
<para > Decimal Floating Point Facility (The value of the ibm,dfp
property indicates the architecture level of the
facility.)</para>
</entry>
</row>
<row >
<entry >
<para > 4</para>
</entry>
<entry morerows= "3" >
<para > Reserved for Expansion (0b0)</para>
</entry>
</row>
<row >
<entry >
<para > 5</para>
</entry>
</row>
<row >
<entry >
<para > 6</para>
</entry>
</row>
<row >
<entry >
<para > 7</para>
</entry>
</row>
<row >
<entry >
<para > 3-256</para>
</entry>
<entry nameend= "c5" namest= "c4" >
<para > Reserved for Expansion</para>
</entry>
</row>
<row >
<entry morerows= "9" >
<para > Base</para>
</entry>
<entry morerows= "9" >
<para > 4</para>
<para > LoPAR Implementation</para>
</entry>
<entry morerows= "7" >
<para > 1</para>
</entry>
<entry >
<para > 0</para>
</entry>
<entry >
<para >   </para>
</entry>
</row>
<row >
<entry >
<para > 1</para>
</entry>
<entry >
<para > Cessation Policy<superscript > <xref linkend= "note.cessation" xrefstyle= "select: nopage" /> </superscript> </para>
</entry>
</row>
<row >
<entry >
<para > 2</para>
</entry>
<entry >
<para > ibm,change-msi busy: If set, the client program supports RTAS
ibm,change-msi returning a -2 (Call again) or 990x (Extended delay)</para>
</entry>
</row>
<row >
<entry >
<para > 3</para>
</entry>
<entry morerows= "4" >
<para > Reserved for Expansion (0b0)</para>
</entry>
</row>
<row >
<entry >
<para > 4</para>
</entry>
</row>
<row >
<entry >
<para > 5</para>
</entry>
</row>
<row >
<entry >
<para > 6</para>
</entry>
</row>
<row >
<entry >
<para > 7</para>
</entry>
</row>
<row >
<entry >
<para > 2</para>
</entry>
<entry >
<para > 0-7</para>
</entry>
<entry >
<para > Minimum VP entitled capacity percentage * 100 (if absent
assume 10%)</para>
</entry>
</row>
<row >
<entry >
<para > 2-256</para>
</entry>
<entry nameend= "c5" namest= "c4" >
<para > Reserved for Expansion</para>
</entry>
</row>
<row >
<entry morerows= "18" >
<para > Base</para>
</entry>
<entry morerows= "18" >
<para > 5</para>
<para > LoPAR or OF Options<superscript > <xref linkend= "note.opt5" xrefstyle= "select: nopage" /> </superscript> </para>
</entry>
<entry morerows= "7" >
<para > 1</para>
</entry>
<entry >
<para > 0</para>
</entry>
<entry >
<para > Ignore<superscript > <xref linkend= "note.ignore" xrefstyle= "select: nopage" /> </superscript> </para>
</entry>
</row>
<row >
<entry >
<para > 1</para>
</entry>
<entry >
<para > Cessation Policy<superscript > <xref linkend= "note.cessation" xrefstyle= "select: nopage" /> </superscript> </para>
</entry>
</row>
<row >
<entry >
<para > 2</para>
</entry>
<entry >
<para > 64 bit PE TCEs : If set, the client program supports <emphasis > ibm,query-pe-dma-window</emphasis>
returning a 64-bit value for PE TCEs</para>
</entry>
</row>
<row >
<entry >
<para > 3</para>
</entry>
<entry morerows= "4" >
<para > Reserved for Expansion (0b0)</para>
</entry>
</row>
<row >
<entry >
<para > 4</para>
</entry>
</row>
<row >
<entry >
<para > 5</para>
</entry>
</row>
<row >
<entry >
<para > 6</para>
</entry>
</row>
<row >
<entry >
<para > 7</para>
</entry>
</row>
<row >
<entry morerows= "7" >
<para > 2</para>
</entry>
<entry >
<para > 0</para>
</entry>
<entry >
<para > Logical Partitioning: If set the client program supports
logical partitioning and associated hcall()s; else the client
program shall be run with the hypervisor bit on.<superscript > <xref linkend= "note.hypervisor" xrefstyle= "select: nopage" /> </superscript> </para>
</entry>
</row>
<row >
<entry >
<para > 1</para>
</entry>
<entry >
<para > Shared Processor Logical Partitioning: If set the client
program supports the Shared Processor LPAR Option and may be
run with that option enabled; else the Shared Processor LPAR
Option shall be disabled for this partition.</para>
</entry>
</row>
<row >
<entry >
<para > 2</para>
</entry>
<entry >
<para > ibm,dynamic-reconfiguration-memory: If set the client
program supports the
<emphasis role= "bold" > <literal > “ ibm,dynamic-reconfiguration-memory” </literal> </emphasis>
property and it may be presented in the device tree; else, the partition
memory shall be represented with individual
<emphasis > memory</emphasis> nodes.</para>
</entry>
</row>
<row >
<entry >
<para > 3</para>
</entry>
<entry >
<para > Large Pages: If this bit is set, the client supports
pages larger than 4 KB; else, the platform shall represent all
of memory as mapped via 4 K pages.</para>
</entry>
</row>
<row >
<entry >
<para > 4</para>
</entry>
<entry >
<para > Alpha Partition<superscript > <xref linkend= "note.alpha" xrefstyle= "select: nopage" /> </superscript> </para>
</entry>
</row>
<row >
<entry >
<para > 5</para>
</entry>
<entry >
<para > Tolerate long delays in H_MIGRATE_DMA</para>
</entry>
</row>
<row >
<entry >
<para > 6</para>
</entry>
<entry >
<para > Client supports donating dedicated processor
cycles</para>
</entry>
</row>
<row >
<entry >
<para > 7</para>
</entry>
<entry >
<para > PCI Express/MSI Support: If set, the client supports PCI
Express implementations utilizing Message Signaled Interrupts
(MSIs).</para>
</entry>
</row>
<row >
<entry morerows= "2" >
<para > 3</para>
</entry>
<entry >
<para > 0</para>
</entry>
<entry >
<para > On input to ibm,client-architecture-support a non-zero
value indicates that the client supports the I/O Super Page
Option (Support of > 4K I/O pages) (Includes extensions to
H_MIGRATE_DMA for > 4K I/O pages and > 256 xlates).
See <xref linkend= "LoPAR.Virtualization" /> .</para>
<para > In the
<emphasis role= "bold" > <literal > ibm,architecture-vec-5</literal> </emphasis> property of the
<emphasis role= "bold" > <literal > /chosen</literal> </emphasis> node, a non-zero value indicates
that the platform supports the I/O Super Page Option (Support
of > 4K I/O pages).</para>
</entry>
</row>
<row >
<entry >
<para > 1-4</para>
</entry>
<entry >
<para > On input to ibm,client-architecture-support this field
shall be zero.</para>
<para > In the
<emphasis role= "bold" > <literal > ibm,architecture-vec-5</literal> </emphasis> property of the
<emphasis role= "bold" > <literal > /chosen</literal> </emphasis> node, this field represents the
implementation dependent number of xlates entries supported per
migration operation as: 256 * 2**N.
See <xref linkend= "LoPAR.Virtualization" /> .</para>
</entry>
</row>
<row >
<entry >
<para > 5-7</para>
</entry>
<entry >
<para > On input to ibm,client-architecture-support this field
shall be zero.</para>
<para > In the
<emphasis role= "bold" > <literal > ibm,architecture-vec-5</literal> </emphasis> property of the
<emphasis role= "bold" > <literal > /chosen</literal> </emphasis> node, this field represents the
implementation dependent number of simultaneous migration
options supported as: 2**N.
See <xref linkend= "LoPAR.Virtualization" /> .</para>
</entry>
</row>
<row >
<entry morerows= "26" >
<para > Base</para>
<para >   </para>
</entry>
<entry morerows= "26" >
<para > 5</para>
<para > LoPAR or OF Options<superscript > <xref linkend= "note.opt5" xrefstyle= "select: nopage" /> </superscript> </para>
<para >   </para>
</entry>
<entry morerows= "3" >
<para > 4</para>
</entry>
<entry nameend= "c5" namest= "c4" >
<para > Cooperative Memory Over-commitment Option Control</para>
</entry>
</row>
<row >
<entry >
<para > 0</para>
</entry>
<entry >
<para > The value of 1 enables the Cooperative Memory
Over-commitment Option</para>
</entry>
</row>
<row >
<entry >
<para > 1</para>
</entry>
<entry >
<para > The value of 1 enables the Extended Cooperative Memory
Over-commit Option</para>
</entry>
</row>
<row >
<entry >
<para > 2-7</para>
</entry>
<entry >
<para > Reserved for Expansion</para>
</entry>
</row>
<row >
<entry morerows= "3" >
<para > 5</para>
</entry>
<entry nameend= "c5" namest= "c4" >
<para > Associativity Information Option Control</para>
</entry>
</row>
<row >
<entry >
<para > 0</para>
</entry>
<entry >
<para > = the “ Form value” of the
<emphasis role= "bold" > <literal > “ ibm,associativity” </literal> </emphasis> and
<emphasis role= "bold" > <literal > “ ibm,associativity-reference-points” </literal> </emphasis>
properties. See <xref linkend= "LoPAR.Platform" /> for further details.</para>
</entry>
</row>
<row >
<entry >
<para > 1</para>
</entry>
<entry >
<para > Platform Resource Reassignment Notification (Affinity
Change)</para>
</entry>
</row>
<row >
<entry >
<para > 2-7</para>
</entry>
<entry >
<para > Reserved for Expansion</para>
</entry>
</row>
<row >
<entry morerows= "8" >
<para > 6</para>
</entry>
<entry nameend= "c5" namest= "c4" >
<para > Binary Option Controls</para>
</entry>
</row>
<row >
<entry >
<para > 0</para>
</entry>
<entry >
<para > Enable MTT Option</para>
<para > See
<xref linkend= "LoPAR.Virtualization" /> .</para>
</entry>
</row>
<row >
<entry >
<para > 1</para>
</entry>
<entry >
<para > Reserved</para>
</entry>
</row>
<row >
<entry >
<para > 2</para>
</entry>
<entry >
<para > Enable Active Memory Compression</para>
</entry>
</row>
<row >
<entry >
<para > 3</para>
</entry>
<entry >
<para > Reserved for Expansion</para>
</entry>
</row>
<row >
<entry >
<para > 4</para>
</entry>
<entry >
<para > Reserved for Expansion</para>
</entry>
</row>
<row >
<entry >
<para > 5</para>
</entry>
<entry >
<para > Enable Hotplug Interrupts<?linebreak?>
See Hot Plug Events in <xref linkend= "LoPAR.Error" /> .</para>
</entry>
</row>
<row >
<entry >
<para > 6</para>
</entry>
<entry >
<para > Enable Support for Multiple Hotplug Slots per PHB</para>
</entry>
</row>
<row >
<entry >
<para > 7</para>
</entry>
<entry >
<para > Reserved for Expansion</para>
</entry>
</row>
<row >
<entry >
<para > 7</para>
</entry>
<entry >
<para >   </para>
</entry>
<entry >
<para > Reserved for Expansion</para>
</entry>
</row>
<row >
<entry >
<para > 8</para>
</entry>
<entry >
<para >   </para>
</entry>
<entry >
<para > Reserved for Expansion</para>
</entry>
</row>
<row >
<entry morerows= "1" >
<para > 9-12</para>
</entry>
<entry nameend= "c5" namest= "c4" >
<para > Max Processors Supported<?linebreak?>
(For legacy support, if this byte is not present the
partition is limited to a maximum of 64 processors)</para>
</entry>
</row>
<row >
<entry >
<para > 0-31</para>
</entry>
<entry >
<para > 32 bit unsigned integer maximum number of OF device tree
nodes of type “ cpu” that may be presented to this
partition.</para>
</entry>
</row>
<row >
<entry >
<para > 13-14</para>
</entry>
<entry >
<para > 0-7 & 0-7</para>
</entry>
<entry >
<para > Highest Base LoPAR Level Supported as the binary
contents of 13.14<?linebreak?>
(i.e. level 4.15 would be encoded as 0x040F)</para>
</entry>
</row>
<row >
<entry morerows= "4" >
<para > 15-16</para>
</entry>
<entry nameend= "c5" namest= "c4" >
<para > Memory Reference Instrumentation</para>
</entry>
</row>
<row >
<entry >
<para > 0</para>
</entry>
<entry >
<para > Reference History Array</para>
</entry>
</row>
<row >
<entry >
<para > 1</para>
</entry>
<entry >
<para > Access Rate Array</para>
</entry>
</row>
<row >
<entry >
<para > 2</para>
</entry>
<entry >
<para > Affinity Domain Access Log</para>
</entry>
</row>
<row >
<entry >
<para > 3-15</para>
</entry>
<entry >
<para > Reserved for Expansion</para>
</entry>
</row>
<row >
<entry morerows= "9" >
<para > Base</para>
<para >   </para>
</entry>
<entry morerows= "9" >
<para > 5</para>
<para > LoPAR or OF Options<superscript > <xref linkend= "note.opt5" xrefstyle= "select: nopage" /> </superscript> </para>
<para >   </para>
</entry>
<entry morerows= "4" >
<para > 17-20</para>
</entry>
<entry nameend= "c5" namest= "c4" >
<para > Platform Facilities Enable – Value of 0b1 indicates
facility is enabled</para>
</entry>
</row>
<row >
<entry >
<para > 0</para>
</entry>
<entry >
<para > Random Number Generator</para>
</entry>
</row>
<row >
<entry >
<para > 1</para>
</entry>
<entry >
<para > Compression Engine</para>
</entry>
</row>
<row >
<entry >
<para > 2</para>
</entry>
<entry >
<para > Encryption Engine</para>
</entry>
</row>
<row >
<entry >
<para > 3-31</para>
</entry>
<entry >
<para > Reserved for Expansion -- Value = 0b0</para>
</entry>
</row>
<row >
<entry >
<para > 21</para>
</entry>
<entry >
<para > 0-7</para>
</entry>
<entry >
<para > Sub-Processor Representation Level --</para>
<para > Defined Values:<?linebreak?>
0: Sub-Processors not supported<?linebreak?>
1: 1,2,or 4 Sub-Processors supported<?linebreak?>
2-255 Reserved</para>
</entry>
</row>
<row >
<entry morerows= "2" >
<para > 22</para>
</entry>
<entry >
<para > 0</para>
</entry>
<entry >
<para > If set the client program supports the
<emphasis role= "bold" > <literal > “ ibm,dynamic-memory-v2” </literal> </emphasis>
property in the
<emphasis role= "bold" > <literal > “ ibm,dynamic-reconfiguration-memory” </literal> </emphasis>
node and it may be presented in the device tree;
else, the <emphasis role= "bold" > <literal > “ ibm,dynamic-memory” </literal> </emphasis>
property shall be represented.</para>
</entry>
</row>
<row >
<entry >
<para > 1</para>
</entry>
<entry >
<para > If set the client program supports the
<emphasis role= "bold" > <literal > “ ibm,drc-info” </literal> </emphasis>
property definition and it may be presented in the device tree;
else, the <emphasis role= "bold" > <literal > “ ibm,drc-indexes” </literal> </emphasis> ,
<emphasis role= "bold" > <literal > “ ibm,drc-types” </literal> </emphasis> ,
<emphasis role= "bold" > <literal > “ ibm,drc-names” </literal> </emphasis> , and
<emphasis role= "bold" > <literal > “ ibm,drc-power-domains” </literal> </emphasis> properies shall be presented.</para>
</entry>
</row>
<row >
<entry >
<para > 2-7</para>
</entry>
<entry >
<para > Reserved for Expansion</para>
</entry>
</row>
<row >
<entry >
<para > 23-256</para>
</entry>
<entry nameend= "c5" namest= "c4" >
<para > Reserved for Expansion</para>
</entry>
</row>
<row >
<entry morerows= "20" >
<para > Base</para>
</entry>
<entry morerows= "17" >
<para > 6</para>
<para > Hints</para>
</entry>
<entry morerows= "7" >
<para > 1</para>
</entry>
<entry >
<para > 0</para>
</entry>
<entry morerows= "7" >
<para > Reserved for Expansion (0b0)</para>
</entry>
</row>
<row >
<entry >
<para > 1</para>
</entry>
</row>
<row >
<entry >
<para > 2</para>
</entry>
</row>
<row >
<entry >
<para > 3</para>
</entry>
</row>
<row >
<entry >
<para > 4</para>
</entry>
</row>
<row >
<entry >
<para > 5</para>
</entry>
</row>
<row >
<entry >
<para > 6</para>
</entry>
</row>
<row >
<entry >
<para > 7</para>
</entry>
</row>
<row >
<entry morerows= "7" >
<para > 2</para>
</entry>
<entry >
<para > 0</para>
</entry>
<entry >
<para > Secondary Page Table Entry Group: If set, the client does
not use secondary page table entry groups; else the client may
use secondary page table entry groups.</para>
</entry>
</row>
<row >
<entry >
<para > 1</para>
</entry>
<entry morerows= "6" >
<para > Reserved</para>
</entry>
</row>
<row >
<entry >
<para > 2</para>
</entry>
</row>
<row >
<entry >
<para > 3</para>
</entry>
</row>
<row >
<entry >
<para > 4</para>
</entry>
</row>
<row >
<entry >
<para > 5</para>
</entry>
</row>
<row >
<entry >
<para > 6</para>
</entry>
</row>
<row >
<entry >
<para > 7</para>
</entry>
</row>
<row >
<entry >
<para > 3</para>
</entry>
<entry >
<para > 0-7</para>
</entry>
<entry >
<para > OS Name: Represents the name of the client OS. Defined
values include:<?linebreak?>
0x0: Reserved<?linebreak?>
0x1: AIX<?linebreak?>
0x2: Linux<?linebreak?>
0x3-0xFF: Reserved for Expansion</para>
</entry>
</row>
<row >
<entry >
<para > 4-256</para>
</entry>
<entry nameend= "c5" namest= "c4" >
<para > Reserved for Expansion</para>
</entry>
</row>
<row >
<entry >
<para > 7</para>
<para > OS Identification</para>
</entry>
<entry >
<para > 1-256</para>
</entry>
<entry nameend= "c5" namest= "c4" >
<para > An ASCII character formatted null terminated string that
describes the client operating system. The string shall be
human readable and may be displayed on the console.</para>
</entry>
</row>
<row >
<entry >
<para > 8-255</para>
</entry>
<entry nameend= "c5" namest= "c3" >
<para > Reserved for Expansion</para>
</entry>
</row>
<row >
<entry >
<para > 256</para>
</entry>
<entry nameend= "c5" namest= "c3" >
<para > Reserved for Expansion to the first Extension Option
Array</para>
</entry>
</row>
<row >
<entry >
<para > Extensions 1-N</para>
</entry>
<entry nameend= "c5" namest= "c2" >
<para > Reserved for Expansion</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
<para > <emphasis role= "bold" > Notes:</emphasis> </para>
<orderedlist >
<listitem xml:id= "note.ignore" >
<para > The Ignore Policy bit indicates that the client program assumes
all responsibility for the options represented by the option vector. The
firmware is to configure the platform at the highest level consistent
with its configuration variables and ignore the rest of the specific
option vector. An option vector with the Ignore Policy bit set need be no
longer than two bytes (size=0, data = 0b1ddd dddd where d = don’ t
care).</para>
</listitem>
<listitem xml:id= "note.cessation" >
<para > The Cessation Policy Bit determines if the partition continues
to run if the platform must operate with an option enabled that is not
explicitly supported by the client program as represented by the option
vector setting. If the Cessation Policy Bit is 1, then processing halts
as with a boot failure. If the Cessation Policy Bit is 0 then client
program processing continues if the unsupported option is initialized to
a benign state and stays in that state unless an aware program activates
the option, and the option does not appear in the device tree. If an
unsupported option cannot be initialized to a benign state, then
processing halts with a boot failure. Following are the detailed
definitions of benign state for selected bit vectors.</para>
<itemizedlist >
<listitem >
<para > For option vector numbers 1 “ PowerPC Server Processor
Architecture Level” and 3 “ IBM PowerPC Server Processor
Extensions” the benign state is defined as unable to generate
exceptions, mask errors, or present covert channel exposures.</para>
</listitem>
<listitem >
<para > For option vector number 5 “ LoPAR Options” Byte 2
bit 5 “ Alpha Partition” The Cessation Policy bit is not
applicable.</para>
</listitem>
<listitem >
<para > For option vector number 2 “ Open Firmware” the
Cessation Policy Bit is not defined, the platform either accommodates the
values defined in the option vector or proceeds as with boot
failure.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem xml:id= "dbdoclet.50569368_24293" >
<para > The Initial size
of the RMA is set to the greater of the values indicated by bytes 24-27
or 32 of option vector number 2 “ Open Firmware” or minimum
RMA size supported by the platform and capped by the maximum memory
defined for the partition and the maximum size of the RMA supported by
the platform. The respective selected values are reported in the length
of the first
<emphasis > memory</emphasis> property.</para>
</listitem>
<listitem xml:id= "note.alpha" >
<para > The Alpha flag only applies to the first partition of a non HMC
managed system and activates overrides to the partition's I/O resource
allocation as defined in the partition definition.</para>
<itemizedlist >
<listitem >
<para > If the system is HMC managed, the flag is ignored and the client
program gets the resources assigned by its partition definition (no
overrides are activated).</para>
</listitem>
<listitem >
<para > If the partition is not the first partition, the flag is ignored
and the client program gets the resources assigned by the partition
definition (no overrides are activated).</para>
</listitem>
<listitem >
<para > If the Alpha flag applies, and is set, then the partition gets a
VMC virtual I/O device in its device tree regardless of its partition
definition (Override to include VMC is activated).</para>
</listitem>
<listitem >
<para > If the Alpha flag applies, and is not set, then the partition
does not get a VMC virtual I/O device in its device tree regardless of
its partition definition (Override to remove VMC is activated) and it
gets all the physical I/O resources in its device tree regardless of its
partition definition (Override to include all physical I/O is activated).
Note this condition requires that any other platform partitions be
terminated.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem xml:id= "note.opt5" >
<para > Given that the Ignore policy bit is off and the partition
continues to run, the options and values presented in by this option
vector and supported/chosen by the platform firmware are reported in the
<emphasis role= "bold" > <literal > “ ibm,architecture-vec-5” </literal> </emphasis> property of the
<emphasis role= "bold" > <literal > /chosen</literal> </emphasis> node.</para>
</listitem>
<listitem xml:id= "note.opt6" >
<para > Option vector number 1 “ PowerPC Server Processor
Architecture Level” and the property that reports the chosen value
(i.e.,
<emphasis role= "bold" > <literal > “ cpu-version” </literal> </emphasis> ) represent the operational
base architectural level of the processors -- that is without regard to
enabled processor architectural options. Option vector number 3
“ IBM PowerPC Server Processor Extensions” and option specific
properties that report the chosen values represent the active processor
architectural options. Some processor implementations may not support all
combinations of these two option vectors. The firmware shall activate the
highest level of processor support, consistent with partition attributes,
that does not exceed the most restrictive of the two option vectors. Note
the Cessation Policy bit may allow operation where the lowest level of
processor support still exceeds the most restrictive case.</para>
</listitem>
<listitem xml:id= "note.hypervisor" >
<para > If a client program does not support logical partitioning no
other client programs may be running simultaneously on the platform. The
platform may impose further restrictions beyond the scope of LoPAR. If
the platform honors the client program restriction of not supporting
logical partitioning, upon return the logical real address equals the
platform real address. If the platform can not honor the restriction, the
processing terminates as with a boot failure. The cessation policy option
vector bit has no effect upon logical partitioning option vector
bit.</para>
</listitem>
</orderedlist>
</section>
<section xml:id= "dbdoclet.50569368_40198" >
<title > ROM Node(s)</title>
<para > The ROM Node(s), when present to represent optional platform read
only memory containing directly executable platform firmware, shall be a
child or children of the root node.</para>
<section >
<title > ROM Node Properties</title>
<para > Each ROM Node shall have the following properties:</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ name” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> that denotes a ROM Node.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : A string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The value of this property shall be
<literal > “ rom” </literal> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> to define a unit-address for the
node.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : One (
<emphasis > phys-addr, size</emphasis> ) pair.</para>
<para > The
<emphasis > phys-addr</emphasis> of this property shall be the starting
physical address of this ROM and the
<emphasis > size</emphasis> value shall be 0. The
<emphasis > size</emphasis> =0 prevents a conflict with the
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> of this node’ s
children.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ #address-cells” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> to define the address space
representation of child nodes.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : an integer, encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> . Its value shall be identical to that of
this node’ s parent’ s
<emphasis role= "bold" > <literal > “ #address-cells” </literal> </emphasis> value.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ranges” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> to define the address range that is
decoded by this
<emphasis role= "bold" > <literal > /rom</literal> </emphasis> node.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : One (
<emphasis > child-phys</emphasis> ,
<emphasis > parent-phys</emphasis> ,
<emphasis > size</emphasis> ) triple, where
<emphasis > child-phys</emphasis> equals
<emphasis > parent-phys</emphasis> and the number of cells of each
corresponds to the parent’ s
<emphasis role= "bold" > <literal > “ #address-cells” </literal> </emphasis> value.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ available” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> to define available ROM
resources.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : Arbitrary number of
<emphasis > phys-addr, size</emphasis> pairs.
<emphasis > Phys</emphasis> -
<emphasis > addr</emphasis> is a
<emphasis > phys.hi...phys.lo</emphasis> list of integers, each integer
encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .
<emphasis > Size</emphasis> is one or more integers, each encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > The value of this property defines resources, managed by this
package, that are currently available for use by a client program.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ write-characteristic” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> defines the ROM Technology.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : a string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> , where the value could equal
<emphasis role= "bold" > <literal > “ flash” </literal> </emphasis> ,
<emphasis role= "bold" > <literal > “ eeprom” </literal> </emphasis> ,
<emphasis role= "bold" > <literal > “ rom” </literal> </emphasis> or
<emphasis role= "bold" > <literal > “ nvram” </literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ cacheable” </literal> </emphasis> [S]</term>
<listitem >
<para > OF standard property indicating that the ROM is cacheable.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : < none> .</para>
<para > The presence of this property indicates that the ROM is
cacheable.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section >
<title > ROM Node Methods</title>
<para > If one or more ROM nodes are present, they shall each implement the
following standard methods per
<xref linkend= "dbdoclet.50569387_45524" /> , Section 3.6.1. The
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> property is used to determine which
ROM the standard methods apply to for multiple ROM’ s.</para>
<para > The following methods must be defined by
<emphasis role= "bold" > <literal > /rom</literal> </emphasis> node.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > open</literal> </emphasis> (-- true) [M]</term>
<listitem >
<para > Standard method to prepare the ROM Node for subsequent use.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > close</literal> </emphasis> (--) [M]</term>
<listitem >
<para > Standard method to close the previously opened ROM Node.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > decode-unit</literal> </emphasis>
(addr len -- phys.lo...phys.hi) [M]</term>
<listitem >
<para > Standard method to convert text unit-string to physical address.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > encode-unit</literal> </emphasis>
(phys.lo...phys.hi -- unit-str unit-len) [M]</term>
<listitem >
<para > Standard method to convert physical address to text unit-string.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > probe</literal> </emphasis> (--) [M]</term>
<listitem >
<para > OF method used at boot time to probe all ROM’ s.</para>
<para > The
<emphasis role= "bold" > <literal > probe</literal> </emphasis> method for ROM Nodes shall probe for FCode
images within the address space defined by its
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> property as defined herein. For
each page within its address space, look for a valid FCode image. A valid
FCode image is defined to start with an FCode-header (see section 5.2.2.5
in
<xref linkend= "dbdoclet.50569387_45524" /> ) where the first byte is
<emphasis role= "bold" > <literal > start1</literal> </emphasis> , the format byte is 0x08, the length field
indicates that the FCode program is contained within the address space of
the
<emphasis role= "bold" > <literal > /rom</literal> </emphasis> node, and where the checksum is correct. (This
probing must take into account the possibility that the ROM image is in
the opposite endian-ness from which OF is currently running.)</para>
<para > If such an FCode image is found, a new child node shall be created
by executing
<emphasis role= "bold" > <literal > new-device</literal> </emphasis> and
<emphasis role= "bold" > <literal > set-args</literal> </emphasis> , the FCode image copied to memory (taking
into account the endian-ness) and the copy evaluated with
<emphasis role= "bold" > <literal > byte-load</literal> </emphasis> . (The FCode program can use
<emphasis role= "bold" > <literal > my-unit</literal> </emphasis> to create its
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> property.). The arguments used by
<emphasis role= "bold" > <literal > set-args</literal> </emphasis> are defined to be 0,0,unit-str, unit-len
where unit-str is a text string representation of the physical address
location for the FCode Image and unit-len is the length of the FCode
Image.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
<section >
<title > ROM Child Node(s)</title>
<para > This section describes the properties and methods for a ROM Child
Node.</para>
<section >
<title > ROM Child Node Properties</title>
<para > The following properties must be created by
<emphasis role= "bold" > <literal > /rom</literal> </emphasis> child nodes.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ name” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> that denotes a ROM child node.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : A string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > Some physical ROM implementations may not fully decode their entire
address range. This could lead to multiple images of the ROM to appear at
different addresses, due to the “ aliasing” of the ROM image.
To prevent multiple device nodes from appearing in the device tree, the
FCode for such ROMs should look for an already existing peer node that
represents their image. This could be done, for example, by checking that
any of the peer of the child of its parent node has a
<emphasis role= "bold" > <literal > “ name” </literal> </emphasis> property value that is the same as
this node’ s FCode would create.</para>
<para > If such a node is found, the FCode should “ abort” the
evaluation of its FCode (e.g., by executing an
<emphasis role= "bold" > <literal > end0</literal> </emphasis> ) before creating its
<emphasis role= "bold" > <literal > “ name” </literal> </emphasis> property. OF shall remove a node
when the FCode evaluation for the node does not result in a
<emphasis role= "bold" > <literal > “ name” </literal> </emphasis> property being defined.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> that defines the child node address
range for a ROM image(s).</para>
<para >
<emphasis > prop-encoded-array</emphasis> : List of (
<emphasis > phys-addr, size</emphasis> ) specifications.</para>
<para >
<emphasis > Phys-addr</emphasis> is encoded as with
<emphasis role= "bold" > <literal > encode-phys</literal> </emphasis> , and
<emphasis > size</emphasis> is encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> . The
<emphasis > phys-addr</emphasis> is a base address of the ROM image and
<emphasis > size</emphasis> is the length of the ROM image.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section >
<title > ROM Child Node Methods</title>
<para > The following methods must be defined by
<emphasis role= "bold" > <literal > /rom</literal> </emphasis> child nodes.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > open</literal> </emphasis> (-- true) [M]</term>
<listitem >
<para > Standard method to prepare this device for subsequent use.</para>
<para > The
<emphasis role= "bold" > <literal > open</literal> </emphasis> method must be prepared to parse
<emphasis > my-args</emphasis> for the case(s) when the node is being opened
in order to access “ files” ; e.g., when the bootinfo.txt file
is being accessed during the
<emphasis > multiboot menu</emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > close</literal> </emphasis> (--) [M]</term>
<listitem >
<para > Standard method to close the previously opened device.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > load</literal> </emphasis> (addr -- len) [M]</term>
<listitem >
<para > Standard method to load an image. The image must be one that is
recognized by the OF
<emphasis role= "bold" > <literal > init-program</literal> </emphasis> method. It is strongly recommended that
the ELF format be used, since it has the mechanism to specify
configuration variable requirements of an OS.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
</section>
<section >
<title > Run Time Abstraction Services (RTAS) Node</title>
<para > This system node is a child of
<emphasis role= "bold" > <literal > “ /” </literal> </emphasis> (root). This section defines
properties and methods for the RTAS node. The RTAS Node shall not have
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> or
<emphasis role= "bold" > <literal > “ ranges” </literal> </emphasis> properties.</para>
<section xml:id= "dbdoclet.50569368_41461" >
<title > RTAS Node Properties</title>
<para > This section describes the
<emphasis > rtas</emphasis> node properties.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ name” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> that denotes the RTAS node.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : A string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The value of this property shall be
<literal > “ rtas” </literal> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ rtas-event-scan-rate” </literal> </emphasis> [S]</term>
<listitem >
<para >
<emphasis > property name</emphasis> that is the rate at which an OS should
read indicator/sensor/error data</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer, encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> </para>
<para > The value of this property shall be a number indicating the desired
rate for reading sensors and/or error information in calls per minute.
This number is platform dependent.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ rtas-indicators” </literal> </emphasis> [S]</term>
<listitem >
<para >
<emphasis > property name</emphasis> that indicates indicators are
implemented.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An array of paired integers (
<emphasis > token maxindex</emphasis> ), each encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > The values for this property is a list of integers that are the
token values (
<emphasis > token</emphasis> ) for the defined indicators and the number of
indicators (
<emphasis > maxindex</emphasis> ) for that token which are implemented (see
<xref linkend= "LoPAR.RTAS" /> ) on the platform.</para>
<para >
<emphasis role= "bold" > Note:</emphasis> The indicator indices for a given token are
numbered 0... maxindex-1.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ rtas-sensors” </literal> </emphasis> [S]</term>
<listitem >
<para >
<emphasis > property name</emphasis> that indicates sensors are
implemented.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An array of paired integers (
<emphasis > token maxindex</emphasis> ), each encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > The values for this property is a list of integers that are the
token values (
<emphasis > token</emphasis> ) for the defined sensors and the number of
sensors (
<emphasis > maxindex</emphasis> ) for that token which are implemented (see
<xref linkend= "LoPAR.RTAS" /> ) on the platform.</para>
<para >
<emphasis role= "bold" > Note:</emphasis> The sensor indices for a given token are
numbered 0 ... maxindex-1.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ rtas-version” </literal> </emphasis> [S]</term>
<listitem >
<para >
<emphasis > property name</emphasis> describes version information for the
RTAS implementation.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer, encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > The value of this property shall denote the version the RTAS
implementation. For this version, the integer shall be as defined in this
architecture.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ rtas-size” </literal> </emphasis> [S]</term>
<listitem >
<para >
<emphasis > property name</emphasis> is the size of the RTAS memory
image.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer, encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > The value of this property shall be the amount of contiguous real
system memory required by RTAS, in bytes.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ rtas-display-device” </literal> </emphasis> [S]</term>
<listitem >
<para >
<emphasis > property name</emphasis> identifies RTAS Display Device</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer, encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > The value of this property shall be the
<emphasis > phandle</emphasis> of the device node used by the RTAS
display-character function.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ rtas-error-log-max” </literal> </emphasis> [S]</term>
<listitem >
<para >
<emphasis > property name</emphasis> identifies maximum size of an extended
error log entry.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer, encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > The value of this property shall be the maximum size of an extended
error log entry, in bytes.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ power-on-max-latency” </literal> </emphasis> [S]</term>
<listitem >
<para >
<emphasis > property name</emphasis> specifies a future power on time
capability.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer, encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > The value of this property specifies the capability of the hardware
to control the delay of system power on in days. If the property is
present, the value shall indicate the maximum delay or latency in days.
If the property is not present, the maximum delay or latency is 28
days.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,preserved-storage” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> specifies that the client program was
loaded with one or more LMBs preserved from a previous client
program.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : None, this is a name only
property.</para>
<para > The client program may wish to save the contents of the preserved
LMBs and deregister the LMBs for preservation.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,scan-log-directory” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> specifies that the platform supports
the scan-log directory option.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : None, this is a name only
property.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,indicator-</literal> </emphasis> <emphasis > < token> </emphasis> <emphasis role= "bold" > <literal > ” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> to provide a FRU location code for
identifying each indicator.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : an array of
<emphasis > maxindex</emphasis> + 1 strings, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,sensor-</literal> </emphasis> <emphasis > < token> </emphasis> <emphasis role= "bold" > <literal > ” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> to provide a FRU location code for
identifying each physical sensor.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : an array of
<emphasis > maxindex</emphasis> + 1 strings, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,display-line-length” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> to provide the length of a display line
in number of characters.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : an integer, encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,display-number-of-lines” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> to provide the number of lines in the
display.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : an integer, encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,display-truncation-length” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> , when provided, specifies the length to
which each line to be display is truncated, based on which line of the
physical display on which the line is displayed. When the truncation
length is greater than the length specified in the
<emphasis role= "bold" > <literal > “ ibm,display-line-length” </literal> </emphasis> property, then
the platform provides a platform-dependent method of displaying the line
to the user.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An array of integers, each
encoded as with encode-int. The number of integers corresponds to the
number of lines, as defined by the
<emphasis role= "bold" > <literal > “ ibm,display-number-lines” </literal> </emphasis> property. The
first integer refers to the truncation length for the first physical line
of the display, the second to the second physical line, and so on.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,form-feed” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> to provide an indication of the
form-feed capability.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : a character, NULL (0x00) if
form-feed is not supported and np (0x0C) if form-feed is supported,
encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,environmental-sensors” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> describes the environmental sensors
which are available to an application.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An array of paired integers
(token maxindex), each encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,flash-block-version” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> in the
<emphasis > /rtas</emphasis> node indicates the block list format to be
used.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> . Value is 0x01 for the discontiguous
block list. (If a new version of the block list is ever required, other
values could be defined.)</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,errinjct-tokens” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> defines the error inject functions implemented on
this platform.</para>
<para > <emphasis > prop-encoded-array</emphasis> : List of (errinjct-token-name,
errinjct-token-value) specifications.</para>
<para > errinjct-token-name: A string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > errinjct-token-value: is encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,lrdr-capacity” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> in the
<emphasis > /rtas</emphasis> node identifies the dynamic reconfiguration
capabilities of the partition</para>
<para >
<emphasis > prop-encoded-array</emphasis> : A triple consisting of phys,
size, and one integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> </para>
<para > The phys (of size #address-cells) communicates the maximum address
in bytes and therefore, the most memory that can be allocated to this
partition.</para>
<para > The size (of size #size-cells) communicates the increment (quantum
of logical memory dynamic reconfiguration).</para>
<para > The first integer communicates the maximum number of processors
(implied quantum of 1).</para>
<para >
<emphasis role= "bold" > Note:</emphasis> Some implementations depend upon the presence
and value of a second integer. Future extensions to this property should
not define a second integer for new purposes.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,hypertas-functions” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> of the
<emphasis > /rtas</emphasis> node, defines the platform’ s implemented
hypervisor RTAS function sets.</para>
<para > <emphasis > prop-encoded-array</emphasis> : List of Hypervisor-RTAS-function-set
specifications.</para>
<para > Each Hypervisor-RTAS-function-set specification is a byte string
encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,dma-delay-time” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> to define the time delay need to ensure outstanding
DMA operations targeting migrated pages have completed.</para>
<para > <emphasis > prop-encoded-array</emphasis> : A one cell integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that represents the number of
micro-seconds that the OS should wait prior to reusing migrated DMA read
target pages.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,associativity-reference-points” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> to define the associativity reference points for the
<emphasis role= "bold" > <literal > “ ibm,associativity” </literal> </emphasis>
properties of this platform.</para>
<para > <emphasis > prop-encoded-array</emphasis> : A list of one or more integers cell(s) encoded
as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,max-associativity-domains” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> to define the maximum number associativity domains
for this platform.</para>
<para > <emphasis > prop-encoded-array</emphasis> : An associativity list such that all values are
the maximum that the platform supports in that location. The
associativity list consisting of a number of entries integer (N) encoded
as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> followed by N integers encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> each representing maximum number
associativity domains the platform supports at that level.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,request-partition-shutdown” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> to specify that the partition was
rebooted in the forced fire hose dump mode.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that represents the platform’ s
partition shutdown configuration variable. The defined states are:</para>
<para > 0 = The platform boots with no request to save appropriate data nor
shutdown the partition.</para>
<para > 1 = The platform boots with a conditional request to save
appropriate data and shutdown the partition. The client program should
check for an EPOW sensor state of 3 and if present, it should save
appropriate data and shutdown the partition. If the EPOW sensor state of
3 is not present, then the partition should initiate a reboot since the
device tree will be incomplete.</para>
<para > 2 = The platform boots with a mandatory request to the client
program to save appropriate data and shutdown the partition.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,integrated-stop-self” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> indicating that prior to placing a
processor in the stopped state, the platform flushes and disables any
caches/memory exclusively used by the issuing processor.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : NULL</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,rks-hcalls” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> : indicating the hcalls that are
implemented with a reduced kill set. Absence of this property indicates
that only hcalls that are specified as always having a reduced kill set
provide that semantic.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : A one to N byte bit vector, bit
positions representing hcall()s (see
<xref linkend= "dbdoclet.50569368_69500" /> ) that present a reduced kill
set per their architectural specification.</para>
<table frame= "all" pgwide= "1" xml:id= "dbdoclet.50569368_69500" >
<title > <emphasis role= "bold" > <literal > “ ibm,rks-hcalls” </literal> </emphasis> bit vector to hcall map</title>
<?dbhtml table-width="75%" ?>
<?dbfo table-width="75%" ?>
<tgroup cols= "3" >
<colspec colname= "c1" colwidth= "33*" align= "center" />
<colspec colname= "c2" colwidth= "33*" align= "center" />
<colspec colname= "c3" colwidth= "33*" align= "center" />
<thead >
<row >
<entry >
<para >
<emphasis role= "bold" > Byte Number</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > Bit Number</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > hcall</emphasis>
</para>
</entry>
</row>
</thead>
<tbody >
<row >
<entry morerows= "7" >
<para > 0</para>
</entry>
<entry >
<para > 0</para>
</entry>
<entry morerows= "1" valign= "middle" >
<para > 0b11 for H_CONFER & H_PROD</para>
</entry>
</row>
<row >
<entry >
<para > 1</para>
</entry>
</row>
<row >
<entry >
<para > 2</para>
</entry>
<entry valign= "middle" >
<para > Set to 1 if H_PURR is implemented with a reduced volatile
kill set of r3 & r4; else set to 0.</para>
</entry>
</row>
<row >
<entry >
<para > 3</para>
</entry>
<entry morerows= "4" valign= "middle" >
<para > Reserved for future expansion (0b0)</para>
</entry>
</row>
<row >
<entry >
<para > 4</para>
</entry>
</row>
<row >
<entry >
<para > 5</para>
</entry>
</row>
<row >
<entry >
<para > 6</para>
</entry>
</row>
<row >
<entry >
<para > 7</para>
</entry>
</row>
<row >
<entry >
<para > 1-N</para>
</entry>
<entry nameend= "c3" namest= "c2" >
<para > Reserved for future expansion</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,reset-capabilities” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> indicates what capabilities the
platform supports relative to the ibm,set-slot-reset RTAS call, when that
RTAS call is implemented.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer encoded as with
encode-int that represents the functions supported in the
<emphasis > ibm,set-slot-reset</emphasis> RTAS call</para>
<para > 0 = Platform supports Functions 0 and 1 supported.</para>
<para > 1 = Platform supports Functions 0, 1, and 3.</para>
<para > <emphasis role= "bold" > Note:</emphasis> The absence of this property implies the platform supports
Functions 0 and 1 for the
<emphasis > ibm,set-slot-reset</emphasis> RTAS call, when that RTAS call is
implemented.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,configure-kernel-dump-sizes” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> specifies that the Platform Assisted
Kernel Dump option is supported for sections described by this
property.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : For each dump section type
supported, a 32 bit cell which defines the ID of a supported section
followed by two 32-bit cells which gives the size of the section in bytes
(not including any disk headers.)</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,configure-kernel-dump-version” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> specifies that the Platform Assisted
Kernel Dump option is supported for versions described by this
property.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : Contains a 16-bit cell describing
the minimum kernel dump version supported by the firmware followed by a
16-bit cell describing the maximum kernel dump version supported by the
firmware.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,kernel-dump” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> specifies the presence of a registered
kernel dump in the Platform Assisted Kernel Dump option.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : Contains the description of the
registered kernel dump in the format described in
<xref linkend= "LoPAR.RTAS" /> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,read-slot-reset-state-functions” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> specifies the implementation of certain
input or output fields in the
<emphasis > ibm,read-slot-reset-state2</emphasis> RTAS call. If this
property does not exist, then the
<emphasis > ibm,read-slot-reset-state2</emphasis> RTAS call implements only
the first 3 inputs and the first 4 outputs (
<emphasis > Number Inputs</emphasis> is required to be 3 and the
<emphasis > Number Outputs</emphasis> is required to be 4), as defined in
<xref linkend= "LoPAR.RTAS" /> .</para>
<para >
<emphasis > prop-encoded-array</emphasis> : Contains a 32 bit cell, with the
bits defined as follows:</para>
<para > Bits 0-29: Reserved (value of 0).</para>
<para > Bit 30: When a value of 1, the
<emphasis > ibm,read-slot-reset-state2</emphasis> RTAS call checks the
<emphasis > Number Outputs</emphasis> and the implements the 5th output (
<emphasis > Number Outputs</emphasis> of 5), as defined by
<xref linkend= "LoPAR.RTAS" /> .</para>
<para > Bit 31: When a value of 1, the
<emphasis > ibm,read-slot-reset-state2</emphasis> RTAS call implements the
first 3 inputs and the first 4 outputs (
<emphasis > Number Inputs</emphasis> of 3 and the
<emphasis > Number Outputs</emphasis> of 4), as defined in
<xref linkend= "LoPAR.RTAS" /> . This bit is always required
to be a value of 1 when this property is implemented.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,change-msix-capable” </literal> </emphasis> </term>
<listitem >
<para >
<emphasis > property name</emphasis> indicating the platform supports the
<emphasis > ibm,change-msi</emphasis> RTAS call with
<emphasis > Number of Outputs</emphasis> equal to 4 and
<emphasis > Functions</emphasis> 3, 4, and 5.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : < none> </para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section >
<title > <literal > /RTAS</literal> node DR Sensors and Indicators</title>
<para > The following sensors and indicators are defined for the /RTAS node
for the DR option.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ 9003” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > sensor token</emphasis> , the existence of this token number
denotes that the platform supports the 9003 “ DR entity sense”
sensor.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ 9001” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > indicator token</emphasis> , the existence of this token number
denotes that the platform supports the 9001 “ isolation state”
indicator.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ 9002” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > indicator token</emphasis> , the existence of this token number
denotes that the platform supports the 9002 “ dr-indicator”
indicator used to guide operators in the physical add or removal of
hardware.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ 9003” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > indicator token</emphasis> , the existence of this token number
denotes that the platform supports the 9003
“ allocation-state” indicator.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,extended-os-term” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property-name</emphasis> indicating that the platform supports
extended
<emphasis > ibm,os-term</emphasis> behavior as described in
<xref linkend= "LoPAR.RTAS" /> .</para>
<para > <emphasis > prop-encoded-array</emphasis> : encode-null</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section >
<title > RTAS Function Property Names</title>
<para > This section defines the property names associated with the various
RTAS functions defined by
<xref linkend= "LoPAR.RTAS" /> .
<xref linkend= "LoPAR.RTAS" /> should be used as the reference
for RTAS Functions currently implemented. Each RTAS function that a
platform implements shall
be represented by its own function property,
who’ s value is the
<emphasis > token</emphasis> used to invoke the function on an RTAS
call.</para>
<para > The formal property definition for each such property is of the
form:</para>
<para >
<emphasis > property name</emphasis> specifies the name of the RTAS function
-- such as:</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ nvram-fetch” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > prop-encoded-array</emphasis> : The value,
<emphasis > token</emphasis> , is an integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > If an RTAS function is implemented, there is a property name which
corresponds to its function name. The value of this property is a
<emphasis > token</emphasis> . This
<emphasis > token</emphasis> , when passed to RTAS via its
<emphasis > rtas-call</emphasis> interface (see below), invokes the named
RTAS function. If a RTAS function is not implemented, there will not be a
property corresponding to that function name. See the
<xref linkend= "LoPAR.RTAS" /> for more information about RTAS
functions.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,termno” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> of the
<emphasis > /rtas</emphasis> node defines the virtual terminal numbers
available for use by this partition.</para>
<para > <emphasis > prop-encoded-array</emphasis> : A pair of integers encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , the first being the value
of the lowest termno in a contiguous range of supported values, the second being the
number of termno values supported.</para>
<para > <emphasis role= "bold" > Note:</emphasis> The number of supported termno values is
implementation dependent -- the minimum number is one.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,hypertas_functions” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> of the /RTAS node, defines the
platform’ s implemented hypervisor RTAS function sets.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : List of
<emphasis > Hypervisor-RTAS-function-set</emphasis> specifications.</para>
<para > Each
<emphasis > Hypervisor-RTAS-function-set</emphasis> specification is a byte
string encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section >
<title > RTAS Node Methods</title>
<para > The
<emphasis role= "bold" > <literal > instantiate-rtas</literal> </emphasis> or
<emphasis role= "bold" > <literal > instantiate-rtas-64</literal> </emphasis> method is invoked by the OS to
instantiate the RTAS functionality. This is accomplished via the
call-method
<emphasis > Client Interface Service</emphasis> . If the platform supports
the
<emphasis role= "bold" > <literal > ibm,client-architecture-support</literal> </emphasis> root node method, and
that method has not been called prior to the call of the
<emphasis role= "bold" > <literal > instantiate-rtas</literal> </emphasis> or
<emphasis role= "bold" > <literal > instantiate-rtas-64</literal> </emphasis> methods, then the platform shall
operate at the least functional level supported by the platform.</para>
<para >
<emphasis role= "bold" > Note:</emphasis> Platforms should provide a manual override
capability to allow most functional level allowed by the partition
configuration in the event that a client program does not call the
<emphasis role= "bold" > <literal > ibm,client-architecture-support</literal> </emphasis> root node method
prior to the instantiation of RTAS.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > instantiate-rtas</literal> </emphasis> (rtas-base-address -- rtas-call) [M]</term>
<listitem >
<para > Invoking the
<emphasis role= "bold" > <literal > instantiate-rtas</literal> </emphasis> method binds the RTAS environment to
a given location in System Memory and initializes the RTAS environment.
The in parameter,
<emphasis > rtas-base-address</emphasis> , is the physical address to which
the RTAS environment is to be bound. This call indicates that RTAS is
instantiated in a 32-bit mode. The amount of contiguous real memory that
should be allocated for the RTAS environment is given by the value of the
<emphasis role= "bold" > <literal > “ rtas-size” </literal> </emphasis> property.</para>
<para > Upon completion of the
<emphasis role= "bold" > <literal > instantiate-rtas</literal> </emphasis> method, an entry point address,
<emphasis > rtas-call</emphasis> , is returned. The value of
<emphasis > rtas-call</emphasis> specifies the physical address of the entry
point into RTAS for future RTAS function calls.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > instantiate-rtas-64</literal> </emphasis> (rtas-base-address -- rtas-call) [M]</term>
<listitem >
<para > Invoking the optional
<emphasis role= "bold" > <literal > instantiate-rtas-64</literal> </emphasis> method binds the RTAS environment
to a given location in System Memory and initializes the RTAS
environment. The in parameter,
<emphasis > rtas-base-address</emphasis> , is the physical address to which
the RTAS environment is to be bound. This call indicates that RTAS is
instantiated in a 64-bit mode. The amount of contiguous real memory that
should be allocated for the RTAS environment is given by the value of the
<emphasis role= "bold" > <literal > “ rtas-size” </literal> </emphasis> property.</para>
<para > Upon completion of the
<emphasis role= "bold" > <literal > instantiate-rtas-64</literal> </emphasis> method, an entry point address,
<emphasis > rtas-call</emphasis> , is returned. The value of
<emphasis > rtas-call</emphasis> specifies the physical address of the entry
point into RTAS for future RTAS function calls.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
<section xml:id= "dbdoclet.50569368_31401" >
<title > Properties of the Node of type cpu</title>
<para > When the platform implements the LPAR option the following
properties are required of the /cpus node</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > ibm,pft-size</literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> of the children of type
“ cpu” of the
<emphasis > /cpus</emphasis> node, defines the size of the processor’ s
page frame table.</para>
<para > <emphasis > prop-encoded-array</emphasis> : A pair of integers encoded as
with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , the first being the NUMA CEC Cookie (up
to a maximum of (2
<emphasis > 16</emphasis> )-1) the second being the base 2 log of the size
of the page frame table in bytes.</para>
<para >
<emphasis role= "bold" > Notes:</emphasis>
</para>
<orderedlist >
<listitem >
<para > On single CEC platforms, the NUMA CEC Cookie value is
zero.</para>
</listitem>
<listitem >
<para > Due to constraints caused by initial memory allocations, and
other running partitions, the firmware may not be able to allocate a
node’ s PFT for the full size requested in the PFT_size
configuration variable. The
<emphasis role= "bold" > <literal > “ ibm,pft-size” </literal> </emphasis> property of course
reflects the actual size allocated.</para>
</listitem>
<listitem >
<para > The partitions running on multiple NUMA nodes would have
multiple PFTs which did not look alike due to the difference in mapping
local and remote page frames.)</para>
</listitem>
</orderedlist>
</listitem>
</varlistentry>
</variablelist>
<para > To support dynamic addition and removal of processors, the /cpus
node contains either the
<emphasis > ibm,drc-info</emphasis> property or the following set of four properties:
<emphasis > ibm,drc-types</emphasis> (cpu),
<emphasis > ibm,drc-indexes ibm,drc-names</emphasis> and
<emphasis > ibm,drc-power-domains</emphasis> (-1's). These properties have
entries for the maximum number of dynamically reconfigurable processors
that the platform supports for the specific OS image.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,ppc-interrupt-server#s” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> : Defines the single processor server
numbers associated with this processor. Placing the numerical equivalent
of one of these quantities into the server# field of an XIVR directs
associated interrupts to this processor. The first server number is
associated with the “ primary processor thread” any subsequent
numbers are associated with the secondary. etc. hardware threads that the
processor may implement.</para>
<para > <emphasis > prop-encoded-array</emphasis> : A list of one or more integers
in the range of 0 to
<literal > 2</literal> <superscript > “ ibm,interrupt-server#-size” </superscript>
encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > <emphasis role= "bold" > Note:</emphasis> In order to achieve optimal performance,
processor server numbers should be activated in the order that they are
presented in the
<emphasis role= "bold" > <literal > “ ibm,ppc-interrupt-server#s” </literal> </emphasis> property and
deactivated in the reverse order.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,ppc-interrupt-gserver#s” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> : Defines the multiple processor global
server numbers to which this processor belongs. Placing the numerical
equivalent of one of these quantities into the server# field of an XIVR
directs associated interrupts to one of the processors in that
group.</para>
<para > <emphasis > prop-encoded-array</emphasis> : A list of (
<emphasis > server#, gserver#s</emphasis> ) specification pairs. the first
integer specifies a single processor
<emphasis > server#</emphasis> as presented in the node’ s
<emphasis role= "bold" > <literal > “ ibm,ppc-interrupt-server#s” </literal> </emphasis> property,
followed by an integer with a value less than or equal to 2
<emphasis role= "bold" > <literal > <superscript > “ ibm,interrupt-server#-size” </superscript> </literal> </emphasis>
encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that specifies the global server queue
that also may present interrupts to the interrupt management area
associated with the
<emphasis > server#</emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,sub-processors” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : the sub-processor configuration that
is running on this processor. In the absence of this property, this
processor may not be divided into sub-processors.</para>
<para > <emphasis > prop-encoded-array</emphasis> : a series of three or more
integers each encoded as with encode-int. The value of the first integer
indicates how many integers follow (the value 2 indicates that two
integers follow). The second integer indicates the number of
sub-processors that are running on this processor. If the processor is
not divided into sub-processors the value of the second integer shall be
1, two sub-processors shall be represented by the value 2, four
sub-processors shall be represented by the value 4 and so on. The third
integer indicates the maximum number of sub-processors that could be
configured to run on this processor.</para>
<para > Client programs shall ignore subsequent integers beyond those
defined at the time they were written.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section >
<title > Extensions for LoPAR I/O Sub-Systems</title>
<para > LoPAR I/O sub-system events may be signaled in a variety of ways
depending upon platform capabilities. In order of increasing
functionality:</para>
<orderedlist >
<listitem >
<para > Events are universally fatal, and are signaled via
checkstop.</para>
</listitem>
<listitem >
<para > After being enabled, the effected section enters freeze state
signalling this state with a return of all 1’ s to any MMIO load
instruction (If not enabled functionality of the specific section reverts
to #1. Presence of
<emphasis > ibm,set-eeh-option</emphasis> RTAS call denotes platforms that
support this level of functionality.)</para>
</listitem>
<listitem >
<para > An extension to #2 above wherein, after being enabled for a
specific section of the I/O sub-system, additional event conditions may
be reported and events are signaled using an external interrupt. The
platform’ s capability to support this level of functionality is
reported by the inclusion of the
<emphasis role= "bold" > <literal > “ ibm,i/o-events-capable” </literal> </emphasis> property (see
definition below) in nodes where enabling control may be
exercised.</para>
</listitem>
</orderedlist>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,i/o-events-capable” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> indicating that I/O sub-system events
detected by the hardware represented by this node in the device tree may
be singled with an I/O event interrupt if enabled.</para>
<para > <emphasis > prop-encoded-array</emphasis> : 0 to N interrupt specifiers (per
the definition of interrupt specifiers for the node’ s interrupt
parent).</para>
<para > When no interrupt specifiers are present, then the interrupt, if
enabled, is signaled via the interrupt specifier given in the
<emphasis role= "bold" > <literal > I/O-events</literal> </emphasis> child node of the
<emphasis role= "bold" > <literal > /events</literal> </emphasis> node.</para>
<para > To perform certain management functions, it is necessary to quiesce
segments of the platform’ s I/O infrastructure, such quiescence
domains are not representable by a strict tree structure. The
<emphasis role= "bold" > <literal > “ ibm,io-quiesce-domains” </literal> </emphasis> property relates
the membership of the various elements of a platform’ s I/O
sub-system to such quiescence domains.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,io-quiesce-domains” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> indicating the I/O quiesce domains of
which this device, and all devices under this device (if any), is a
member.</para>
<para > <emphasis > prop-encoded-array</emphasis> : List of one or more
domain-id’ s to which this device belongs, and to which all devices
under this device (if any) belongs. Domain-id's are encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
</variablelist>
<para > Virtual I/O that does not take up physical address locations is
represented in a device sub tree for which the
<emphasis role= "bold" > <literal > “ #size-cells” </literal> </emphasis> and
<emphasis role= "bold" > <literal > “ #address-cells” </literal> </emphasis> properties are zero and
one, respectively. However, the ibm dma-window properties, such as
<emphasis role= "bold" > <literal > “ ibm,dma-window” </literal> </emphasis> and
<emphasis role= "bold" > <literal > “ ibm,my-dma-window” </literal> </emphasis> , need to contain
real size and address fields. The number of cells for these real size and
address fields need to be non-zero.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,#dma-size-cells” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> to define the package’ s dma
address
<emphasis > size</emphasis> format.</para>
<para > <emphasis > prop-encoded-array</emphasis> : number encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > The property value specifies the number of cells that are used to
encode the size field of ibm dma-window properties. If the
<emphasis role= "bold" > <literal > “ ibm,#dma-size-cells” </literal> </emphasis> property is
missing, the default value is the
<emphasis role= "bold" > <literal > “ #size-cells” </literal> </emphasis> property for the package.
If both the
<emphasis role= "bold" > <literal > “ ibm,#dma-size-cells” </literal> </emphasis> and
<emphasis role= "bold" > <literal > “ #size-cells” </literal> </emphasis> properties are missing,
refer to the
<emphasis role= "bold" > <literal > “ #size-cells” </literal> </emphasis> property definition in the
<xref linkend= "dbdoclet.50569387_45524" /> for the default value.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,#dma-address-cells” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> to define the package’ s dma
address format.</para>
<para > <emphasis > prop-encoded-array</emphasis> : number encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > The property value specifies the number of cells that are used to
encode the physical address field of ibm dma-window properties. If the
<emphasis role= "bold" > <literal > “ ibm,#dma-address-cells” </literal> </emphasis> property is
missing, the default value is the
<emphasis role= "bold" > <literal > “ #address-cells” </literal> </emphasis> property for the
package. If both the
<emphasis role= "bold" > <literal > “ ibm,#dma-address-cells” </literal> </emphasis> and
<emphasis role= "bold" > <literal > “ #address-cells” </literal> </emphasis> properties are missing,
refer to the
<emphasis role= "bold" > <literal > “ #address-cells” </literal> </emphasis> property definition in
the
<xref linkend= "dbdoclet.50569387_45524" /> for the default value.</para>
</listitem>
</varlistentry>
</variablelist>
<section >
<title > PCI Host Bridge Nodes</title>
<para > This section describes the PCI Host Bridge (PHB) properties which
are added or modified for an LoPAR implementation. Refer to
<xref linkend= "dbdoclet.50569387_22451" /> for the base PCI properties and
methods. For each platform PCI Host Bridge, a
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> property shall be present in the
respective PCI Node.</para>
<para >
<emphasis role= "bold" > Note:</emphasis> Since the standard RTAS PCI configuration
access services do not have separate arguments identifying the PCI host
bridge to which a service applies, platforms with multiple PCI host
bridges must assign them unique bus numbers. An OS must not reassign bus
numbers if it expects to make subsequent use of the any RTAS PCI
configuration access services.</para>
<para > To support dynamic addition and removal of PHBs, the / node
contains either the
<emphasis > ibm,drc-info</emphasis> property or the following set of four properties:
<emphasis > ibm,drc-types</emphasis> (phb),
<emphasis > ibm,drc-indexes ibm,drc-names</emphasis> and
<emphasis > ibm,drc-power-domains</emphasis> (-1's). These properties have
entries for the maximum number of dynamically reconfigurable PHBs that
the platform supports for the specific OS image.</para>
<section xml:id= "dbdoclet.50569368_43390" >
<title > PCI Host Bridge Properties</title>
<para > For each PHB in the platform (called a PCI Bus Controller in the
<emphasis > PCI Bus binding</emphasis> ), a PCI Host Bridge Node shall
be defined as a child node of the system bus, in
accordance with
<xref linkend= "dbdoclet.50569387_22451" /> . Each PCI PHB Node shall have
a Unit Address defined in the
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> property that is unique and
persistent from each boot-to-boot. One way for the platform to meet this
requirement is to supply a virtual Unit Address based upon a unique
identifier stored in the hardware. In this case, the size field of the
first
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> property phys-address, size pair
shall be zero. The following properties are modified or added by this
architecture and shall apply to each of these nodes.</para>
<para > Each PHB shall also have the
<emphasis role= "bold" > <literal > “ used-by-rtas” </literal> </emphasis> property, since RTAS is
used for PCI Configuration.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ranges” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> defines this PHB’ s physical
address ranges.</para>
<para > <emphasis > prop-encoded-array</emphasis> : Two or more (
<emphasis > child-phys, parent-phys, size</emphasis> )
specifications.</para>
<para > This property is mandatory for PCI Host Bridges in LoPAR
implementations. The property value consists of four (
<emphasis > child-phys, parent-phys, size</emphasis> ) specifications, as
described in
<xref linkend= "dbdoclet.50569387_45524" /> .</para>
<para > The first specification shall specify the configured address and
size of this PHB’ s I/O Space. (I/O Space is shown as
“ BIOn” to “ TIOn” in
<xref linkend= "LoPAR.Platform" /> "Address Map" section.) The
second specification shall specify the configured address and size of
this PHB’ s Memory Space. (Memory Space is shown as
“ BPMn” to “ TPMn” in the Common Hardware Reference
Platform Architecture.)</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ model” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> indicating this PHB’ s
manufacturer, part number, and revision level. This property shall be
present if this PHB does not supply the following standard PCI
configuration properties which represent the values of standard PCI
configuration registers:
<emphasis role= "bold" > <literal > “ vendor-id” </literal> </emphasis> ,
<emphasis role= "bold" > <literal > “ device-id” </literal> </emphasis> , and
<emphasis role= "bold" > <literal > “ revision-id” </literal> </emphasis> .</para>
<para >
<emphasis > prop-encoded-array</emphasis> : Text string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The value of this property is a vendor dependent string which
uniquely identifies this PHB and is correlated to its manufacturer, part
number, and revision level. (see
<xref linkend= "dbdoclet.50569387_45524" /> for more information.) The
string value is device dependent, but shall supply information sufficient
to identify the part to a level equivalent to the level achievable via
the standard PCI configuration registers:
<emphasis role= "bold" > <literal > “ vendor-id” </literal> </emphasis> ,
<emphasis role= "bold" > <literal > “ device-id” </literal> </emphasis> , and
<emphasis role= "bold" > <literal > “ revision-id” </literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ 64-bit-addressing” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicates this PHB’ s capability
to address more than 4 GB of memory.</para>
<para > <emphasis > prop-encoded-array</emphasis> : < none> </para>
<para > This property shall be present indicating that the PHB supports
addressing more than 4 GB of memory (required for all
<emphasis role= "bold" > <literal > PHB</literal> </emphasis> nodes).</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ external-control” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicates this PHB’ s ability to
support the PA external control facility.</para>
<para > <emphasis > prop-encoded-int</emphasis> : List of integers, each encoded as
with <emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > The property value, if present, is a list of Resource ID’ s
the version of the PA external control facility supports. This property
shall be present if this PHB supports the PA external control facility,
otherwise the property shall be absent.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,tce-alloc-info” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> indicates the addresses of platform pre
allocated TCE table space.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : One to N
<emphasis > phys-addr, size</emphasis> pair(s). The first pair represents
the memory area allocated by the platform for the TCE tables associated
with this PHB. Any subsequent pairs represent memory areas that the OS
should avoid using to minimize performance impacts.</para>
<para > <emphasis > Phys-addr</emphasis> is encoded as with
<emphasis role= "bold" > <literal > encode-phys</literal> </emphasis> the number of cells for
<emphasis > phys</emphasis> corresponds to
<emphasis role= "bold" > <literal > “ #address-cells” </literal> </emphasis> value applicable to this
node.</para>
<para > <emphasis > size</emphasis> the number of cells for
<emphasis > size</emphasis> corresponds to the
<emphasis role= "bold" > <literal > “ #cell-size” </literal> </emphasis> value applicable to this
node.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,max-completion-latency” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> indicates the maximum DMA Read
completion latency for IOAs under this PHB.</para>
<para > <emphasis > prop-encoded-array</emphasis> : Integer, encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > This property, when present (for example, see Requirement
<xref linkend= "LoPAR.Platform" /> ), indicates the maximum DMA
Read completion latency for IOAs under this PHB, in microseconds. For
plug-in adapters, the latency value does not include latency of any
additional PCI fabric (for example, PCI Express switches) on the plug-in
adapter.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,extended-address” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicates this platform supports
Peripheral Memory Spaces, Peripheral I/O Spaces, and SCA spaces above 4
GB.</para>
<para > <emphasis > prop-encoded-array</emphasis> : < none> </para>
<para > This property must be present in all PHB nodes.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,pcie-link-width-stats” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> indicates the collection of PCI Express
link-width capabilities and measurements at the PE below the PHB.</para>
<para > <emphasis > prop-encoded-array</emphasis> : 2 integers encoded with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> </para>
<para > The first integer represents the maximum PCI Express lane-width at
the Partitionable Endpoint.</para>
<para > The second integer represents the actual PCI Express lane-width at
the Partitionable Endpoint.</para>
<para > <emphasis role= "bold" > Implementation Note:</emphasis> In some cases, a PCIe device may
train at a different width depending on the speed capabilities of the
link.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,pcie-link-speed-stats” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> indicates the collection of PCI Express
link-speed capabilities and measurements at the PE below the PHB.</para>
<para > <emphasis > prop-encoded-array</emphasis> : 2 integers encoded with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> . The value of each integer is
based on which bit is set to reflect link speed according to the Supported Link Speed Vector
segment of the Link Capabilities 2 Register as defined in the PCI Express Capability Structure
chapter of the <xref linkend= "dbdoclet.50569387_66784" /> . In the 3.0 version of that
specification, the supported values are 0x1 (bit 0) = 2.5 GT/s, 0x2 (bit 1) = 5.0 GT/s, and 0x4 (bit 2) = 8.0 GT/s.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,max-rtce-mappings” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : for platforms that support the hcall-migrate function
set and more than a single Redirected RDMA mapping per virtual TCE, this property indicates
that there are limits to the number if such multiple Redirected RDMA mappings when used
by children of this PHB as indicated by the property value.</para>
<para > <emphasis > prop-encoded-array</emphasis> : Maximum number of Redirected RTCE mappings encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
</variablelist>
<section xml:id= "dbdoclet.50569368_69645" >
<title > Properties for Children of PCI Host Bridges</title>
<para > The following properties are defined for PCI host bridges and their
children.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ 133mhz-capable” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> : The presence of this property
indicates the device’ s capability of operating at 133 megahertz.
Only present if PCI-X Status Register bit 17 is set.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : None.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ 266mhz-capable” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> : The presence of this property
indicates the device’ s capability of operating at 266 megahertz.
Only present if PCI-X Status Register bit 30 is set.</para>
<para > <emphasis > prop-encoded-array</emphasis> : None.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ 533mhz-capable” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> : The presence of this property
indicates the device’ s capability of operating at 533 megahertz.
Only present if PCI-X Status Register bit 31 is set.</para>
<para > <emphasis > prop-encoded-array</emphasis> : None.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,msi-ranges” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : Defines the Message Signaled
Interrupt interrupt source number (as returned by H_XIRR) range(s)
assigned to this unit using the MSI capability structure. (Note this
property is only supplied if the package is assigned one or more message
signaled interrupt numbers at boot time using the MSI capability
structure, those packages assigned level sensitive interrupts include the
standard interrupts property.) The platform firmware assigns the
interrupt source numbers in order to the first N Message Signaled
Interrupt configuration spaces of the adapter, setting the associated
configuration spaces, in accordance with the platform's hardware
configuration, to produce the interrupt source numbers specified.</para>
<para > <emphasis > prop-encoded-array</emphasis> : List of one or more (int-number,
range) specifications.</para>
<para > <emphasis > Int-number</emphasis> is the first interrupt source number in a
contiguous range of interrupt source numbers encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > <emphasis > Range</emphasis> is the one based count of consecutive interrupt
source numbers that compose the specified range of interrupt source
numbers, encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,msi-x-ranges” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> defines the Message Signaled Interrupt
interrupt source number (as returned by H_XIRR) range(s) assigned to this
IOA function using the MSI-X capability structure. (Note this property is
only supplied if the package is assigned one or more message signaled
interrupt numbers at boot time using MSI-X capability structure, those
packages assigned level sensitive interrupts include the standard
interrupts property.) The platform firmware assigns the interrupt source
numbers in order to the first N MSI-X vectors of the IOA function,
setting the associated configuration spaces and MSI-X vectors, in
accordance with the platform's hardware configuration, to produce the
interrupt source numbers specified.</para>
<para > <emphasis > prop-encoded-array</emphasis> : List of one or more (int-number,
range) specifications.</para>
<para > <emphasis > Int-number</emphasis> is the first interrupt source number in a
contiguous range of interrupt source numbers encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > <emphasis > Range</emphasis> is the one based count of consecutive interrupt
source numbers that compose the specified range of interrupt source
numbers, encoded as with encode-int.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,req#msi” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : Defines the number of Message
Signaled Interrupts requested by the adapter as communicated in its MSI
capability structure. This number may be greater than the number of
Message Signaled Interrupts actually assigned by the firmware.</para>
<para > <emphasis > prop-encoded-array</emphasis> : number of requested interrupts
encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,req#msi-x” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : Defines the number of MSI-X Interrupts
requested by the adapter as communicated in the Table Size field of the
MSI-X Capability Structure for the adapter. This number may be greater
than the number of MSI-X interrupts actually assigned by the
firmware.</para>
<para > <emphasis > prop-encoded-array</emphasis> : number of requested MSI-X
interrupts encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,connector-type” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> to identify the connectors associated with a built-in
IOA that supports wrap test. This property must be provided if there is
more than one connector for the same IOA on the platform.</para>
<para > <emphasis > prop-encoded-array</emphasis> : the concatenation, with
<emphasis role= "bold" > <literal > encode+</literal> </emphasis> , of an arbitrary number of text strings,
each encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,wrap-plug-pn” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> to provide the part number(s) of the wrap plug(s)
required for testing built-in IOAs with the default connector or the
connectors specified in
<emphasis role= "bold" > <literal > “ ibm,connector-type” </literal> </emphasis> . If this property
is provided in the same node with an
<emphasis role= "bold" > <literal > “ ibm,connector-type” </literal> </emphasis> property, there is a
one-to-one correspondence between the strings in each property. If this
property is provided without an
<emphasis role= "bold" > <literal > “ ibm,connector-type” </literal> </emphasis> property, there is
assumed to be only one connector for the device (default connector) and
this property should contain only one string. If multiple wrap plugs may
be used with the same connector, their part numbers shall be represented
in the same string, separated by commas.</para>
<para > <emphasis > prop-encoded-array</emphasis> : the concatenation, with
<emphasis role= "bold" > <literal > encode+</literal> </emphasis> , of an arbitrary number of text strings,
each encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,pci-config-space-type” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : Indicates if the platform supports
access to an extended configuration address space from the PHB up to and
including this node.</para>
<para > 0 = Platform supports only an eight bit register number for
configuration address space accesses.</para>
<para > 1 = Platform supports a twelve bit register number for
configuration address space accesses.</para>
<para > This property may be provided in all
<emphasis role= "bold" > <literal > PHB</literal> </emphasis> nodes and their children.</para>
<para > <emphasis role= "bold" > Note:</emphasis> The absence of this property implies the platform supports
only an eight bit register number for configuration address space
accesses.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,reserved-explanation” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> indicates why this PHB's
<emphasis role= "bold" > <literal > “ status” </literal> </emphasis> property contains the value of
<literal > “ reserved” </literal> or
<literal > “ reserved-uninitialized” </literal> .</para>
<para > <emphasis > prop-encoded-array</emphasis> : Text string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The property value, when present, can have the values specified in
<xref linkend= "dbdoclet.50569368_79030" /> .</para>
<table frame= "all" pgwide= "1" xml:id= "dbdoclet.50569368_79030" >
<title > Values
<emphasis role= "bold" > <literal > “ ibm,reserved-explanation” </literal> </emphasis> </title>
<?dbhtml table-width="75%" ?>
<?dbfo table-width="75%" ?>
<tgroup cols= "2" >
<colspec colname= "c1" colwidth= "50*" align= "center" />
<colspec colname= "c2" colwidth= "50*" align= "center" />
<thead >
<row >
<entry >
<para >
<emphasis role= "bold" > Value</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > Explanation</emphasis>
</para>
</entry>
</row>
</thead>
<tbody >
<row >
<entry >
<para > storage-system-io</para>
</entry>
<entry >
<para > Reserved for storage system product use</para>
</entry>
</row>
<row >
<entry >
<para > pcix-over-pcie</para>
</entry>
<entry >
<para > PCIe device is abstracted as a PCIx device in the device
tree for legacy compatibility</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,pe-total-#msi” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> defines the maximum number of Message
Signaled Interrupts (MSI plus MSI-X) that are available to the PE below
this device tree node. This number only indicates the number of available
interrupts, not the number assigned. The number assigned for an IOA may
be obtained by Function 0 (Query only) of the
<emphasis > ibm,change-msi</emphasis> RTAS call.</para>
<para > <emphasis > prop-encoded-array</emphasis> : Maximum number of interrupts
encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,ehci-boot-supported” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : indicates if this IOA function for
USB 2.0 (EHCI) supports devices beneath it to be used for boot.</para>
<para > <emphasis > prop-encoded-array</emphasis> : None.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,pe-reset-is-flr” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : The presence of this property in the
PCI Express function’ s OF Device Tree node indicates that the
platform will use the Function Level Reset (FLR) of the function to reset
the function when the
<emphasis > ibm,set-slot-reset</emphasis> RTAS call is used to reset the PE,
and not the PCI Express Hot Reset.</para>
<para > <emphasis > prop-encoded-array</emphasis> : None.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,ddw-applicable” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : The Dynamic DMA Windows option RTAS
calls may be used against the PE below this node.</para>
<para > <emphasis > prop-encoded-array</emphasis> : A list of three integers encoded
as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > This property may be provided in all PHB nodes or bridge nodes that
are the PHB’ s children. Separate properties must exist for each PE
that can participate in the DDW option (exists in the node above the PE).
The existence of this property in any node, indicates that the platform
supports the Dynamic DMA Windows option for the platform and for the PE
below that node. Lack of this property in the bridge node above a PE
indicates that the DDW option RTAS calls are not applicable to that PE.
The values in the property are defined as follows:</para>
<para > The first integer represents the token to be used for the
<emphasis > ibm,query-pe-dma-window</emphasis> RTAS call.</para>
<para > The second integer represents the token to be used for the
<emphasis > ibm,create-pe-dma-window</emphasis> RTAS call.</para>
<para > The third integer represents the token to be used for the
<emphasis > ibm,remove-pe-dma-window</emphasis> RTAS call.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,ddw-extensions” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : Extensions to the Dynamic DMA Windows
option RTAS calls may be used against the PE below this node.</para>
<para > <emphasis > prop-encoded-array</emphasis> : A list of integers encoded as
with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > This property may be provided in all PHB nodes or bridge nodes that
are the PHB’ s children. Separate properties shall exist for each PE
that can participate in the extensions to the DDW option (exists in the
node above the PE). The existence of this property in any node, indicates
that the platform supports the extensions to the Dynamic DMA Windows
option for the platform and for the PE below that node. Lack of this
property in the bridge node above a PE indicates that the extensions of
the DDW option RTAS calls are not applicable to that PE. This property is
designed to be extended in the future by adding integers to the end of
the list, reading software should be prepared to handle earlier versions
of the property that will have a short list as well as ignore longer
lists from later versions than it was designed to handle. The values in
the property are defined as follows:</para>
<para > The first integer represents the number of extensions implemented.
Subsequent integers represent values associated with each extension such
as a token for an additional RTAS call or an architectural level of an
extended interface. The value of one indicates that only a single
extension is implemented as specified by the second integer in the list.
<xref linkend= "LoPAR.RTAS" /> provides the definition of the
subsequent integers as defined for the LoPAR level of the DDW
option.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > ibm,h-get-dma-xlates-supported</literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : to identify those PHBs for which
H_GET_DMA_XLATES is supported on all child LIOBNs.</para>
<para > <emphasis > prop-encoded-array</emphasis> : < none> </para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > ibm,h-get-dma-xlates-limited-supported</literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : to identify those PHBs for which
H_GET_DMA_XLATES_LIMITED is supported on all child LIOBNs.</para>
<para > <emphasis > prop-encoded-array</emphasis> : < none> </para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id= "dbdoclet.50569368_94451" >
<title > LPAR Option Properties</title>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,dma-window” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> to define the bus address window
children of this bridge may use for dma.</para>
<para > <emphasis > prop-encoded-array</emphasis> : One (
<emphasis > logical-bus-number, phys</emphasis> ,
<emphasis > size</emphasis> ) triple where the logical bus number (LIOBN) is
a one cell cookie representing the unique range of TCE entries assigned
to this bridge encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , the number of cells for
<emphasis > phys</emphasis> corresponds to the node’ s
<emphasis role= "bold" > <literal > “ ibm,#dma-address-cells” </literal> </emphasis> value while the
number of cells for
<emphasis > size</emphasis> corresponds to the
<emphasis role= "bold" > <literal > “ ibm,#dma-size-cells” </literal> </emphasis> for this
node.</para>
<para > <emphasis role= "bold" > Implementation Note:</emphasis> Platforms that support PHB level
granularity of IO assignment to partitions place the
<emphasis role= "bold" > <literal > “ ibm,dma-window” </literal> </emphasis> property in the PHB
node, while platforms that support slot level granularity place the
<emphasis role= "bold" > <literal > “ ibm,dma-window” </literal> </emphasis> property in the bridge
node that creates the per slot bus isolation.</para>
<para > <emphasis role= "bold" > Note:</emphasis> The first element of the ibm,dma-window triple
(the LIOBN) is used as a parameter to firmware DMA setup routines to
identify the specific I/O address space (TCE table) to be
referenced.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,is-vf” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> to define that the node represents an
I/O Virtualized instance of an I/O adapter.</para>
<para > <emphasis > prop-encoded-array</emphasis> : A one cell value that represents the LoPAR
architectural level of the virtualization:</para>
<table frame= "all" pgwide= "1" >
<title > “ <emphasis > ibm,is-vf</emphasis> ” Values</title>
<?dbhtml table-width="50%" ?>
<?dbfo table-width="50%" ?>
<tgroup cols= "2" >
<colspec colname= "c1" colwidth= "50*" align= "center" />
<colspec colname= "c2" colwidth= "50*" align= "center" />
<thead >
<row >
<entry >
<para >
<emphasis role= "bold" > Value:</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > Description:</emphasis>
</para>
</entry>
</row>
</thead>
<tbody >
<row >
<entry >
<para > 0</para>
</entry>
<entry >
<para > Not used</para>
</entry>
</row>
<row >
<entry >
<para > 1</para>
</entry>
<entry >
<para > Per LoPAR</para>
</entry>
</row>
<row >
<entry >
<para > All others</para>
</entry>
<entry >
<para > Reserved</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
</section>
</section>
<section >
<title > Memory Node</title>
<para > This section defines the LoPAR modifications to the OF /
<emphasis > memory</emphasis> node. In LoPAR, the memory allocated to an OS
image may be divided into a number of allocation units called
“ regions” or “ Logical Memory Blocks (LMB). An OS image
may be dynamically allocated additional regions or may be asked to
release regions. Each LMB is either represented in the device tree by its
own /
<emphasis > memory</emphasis> node or by an entry in
<emphasis role= "bold" > <literal > /ibm,dynamic-reconfiguration-memory</literal> </emphasis> nodes (see
<xref linkend= "dbdoclet.50569368_28484" /> ). The /
<emphasis > memory</emphasis> node that refers to the storage starting at
real address zero (
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> property starting at the value
zero) always remains allocated to an OS image. The client program is
initially loaded into this storage, called the RMA, that is represented
by the first value of the
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> property of this first /
<emphasis > memory</emphasis> node. Additional storage regions may each be
represented by their own /
<emphasis > memory</emphasis> node that includes dynamic reconfiguration
(DR) properties or by an entry in <emphasis role= "bold" > <literal > /ibm,dynamic-reconfiguration-memory</literal> </emphasis> nodes.</para>
<para > To support dynamic addition and removal of regions, the / node
contains either the
<emphasis > ibm,drc-info</emphasis> property or the following set of four properties:
<emphasis > ibm,drc-types</emphasis> (MEM),
<emphasis > ibm,drc-indexes ibm,drc-names</emphasis> and
<emphasis > ibm,drc-power-domains</emphasis> (-1's). These properties have
entries for the maximum number of dynamically reconfigurable regions that
the platform supports for the specific OS image.</para>
<section >
<title > Properties of the memory Node</title>
<para > In addition to the standard properties defined for the
<emphasis role= "bold" > <literal > /memory</literal> </emphasis> node, the following are required for each
node representing a dynamically allocable memory region. Platforms that
support the dynamic reconfiguration of memory regions represent each such
logical memory block with its own
<emphasis role= "bold" > <literal > /memory</literal> </emphasis> node. Any new memory granted to an OS image
is done so with a new
<emphasis role= "bold" > <literal > /memory</literal> </emphasis> node, and OS images may free memory only in
full blocks represented by one of its currently held
<emphasis role= "bold" > <literal > /memory</literal> </emphasis> nodes.</para>
<para > The value of
<emphasis role= "bold" > <literal > “ #address-cells” </literal> </emphasis>
for this node is 1.</para>
<para > The value of
<emphasis role= "bold" > <literal > “ #size-cells” </literal> </emphasis>
for this node is 0 because the children of this node do not consume any physical
address space.</para>
<para > The
<emphasis role= "bold" > <literal > “ ibm,my-drc-index” </literal> </emphasis> property as defined in
<xref linkend= "dbdoclet.50569368_13582" /> .</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,preservable” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> that denotes the platform’ s
ability to preserve the contents of the storage represented by this
node.</para>
<para > <emphasis > prop-encoded-array</emphasis> : A integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that represents
the ability of the platform to preserve the contents of the storage.</para>
<para > All non-negative values represents the expected length of time, in
minutes, that the platform can sustain the state of the storage. A value
of 0 indicates the storage is not preservable and the client program may
not register this storage for preservation, this is the assumed state if the
<emphasis role= "bold" > <literal > “ preservable” </literal> </emphasis>
property is not present. The largest positive number represents an indefinite
retention time as provided by such technologies as flash storage.</para>
<para > Negative values indicate that the storage is preservable as long as
external power is maintained, perhaps by an external battery not directly
integrated into the platform.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,preserved” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> that denotes the preservation state of
the contents of the storage represented by this node.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that represents the preservation state of
the storage. The defined states are:</para>
<para > 0= The storage was not registered for preservation and thus not
preserved. This is the assumed state if the
<emphasis role= "bold" > <literal > “ preserved” </literal> </emphasis> property is not present. This
is also the state if the platform has lost knowledge of the preservation
registration state of the storage.</para>
<para > 1= The storage was registered for preservation and is has been
preserved since the client program last modified it.</para>
<para > 2= The storage was registered for preservation, however, the
contents have not been preserved.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,expected#pages” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> that denotes the number of pages that
the client program is expected to use to virtually map the LMB
represented by this node.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that represents the log base 2 of the
expected number of virtual pages that the client program will use to map
the LMB represented by this node.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,no-h-migrate-dma” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> that designates that the memory in the
<emphasis > memory</emphasis> node in which this property resides cannot
have the H_MIGRATE_DMA hcall() used against it.</para>
<para > <emphasis > prop-encoded-value</emphasis> : < none> this is a name only
property.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id= "dbdoclet.50569368_28484" >
<title > ibm,dynamic-reconfiguration-memory</title>
<para > This device tree node defines an alternative means to represent a
number of dynamically-reconfigurable logical memory blocks (LMBs). This
node must only be generated by OF when instructed to do so by the client
program in the ELF header. All memory which is not subject to dynamic
reconfiguration (such as the RMA) is represented in
<emphasis role= "bold" > <literal > /memory</literal> </emphasis> node(s).</para>
<para > This node is a child of root. This node does not have a unit
address or
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> property.</para>
<para > The following properties are defined.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,lmb-size” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> that defines the size of each
dynamically reconfigurable LMB.</para>
<para > <emphasis > prop-encoded-array</emphasis> : An integer encoded as with
<emphasis role= "bold" > <literal > encode-phys</literal> </emphasis> that represents the size in bytes of each
LMB.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,associativity-lookup-arrays” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> that defines a lookup array in which to
find the
<emphasis > ibm,associativity-array</emphasis> property value for the
LMBs.</para>
<para > <emphasis > prop-encoded-array</emphasis> : The number M of associativity
lists encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , the number N of entries per
associativity list encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , followed by M associativity lists each
of length N integers encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > This property is used to duplicate the function of the
<emphasis role= "bold" > <literal > “ ibm,associativity” </literal> </emphasis> property in a
<emphasis role= "bold" > <literal > /memory</literal> </emphasis> node. Each “ assigned” LMB
represented has an index valued between 0 and M-1 which is used as in
index into this table to select which associativity list to use for the
LMB. “ unassigned” LMBs are place holders for potential DLPAR
additions, for which the associativity list index is meaningless and is
given the reserved value of -1. This static property, need only contain
values relevant for the LMBs presented in the
<emphasis role= "bold" > <literal > “ ibm,dynamicreconfiguration-memory” </literal> </emphasis> node;
for a dynamic LPAR addition of a new LMB, the device tree fragment
reported by the
<emphasis > ibm,configure-connector</emphasis> RTAS function is a /memory
node, with the inclusion of the
<emphasis role= "bold" > <literal > “ ibm,associativity” </literal> </emphasis> device tree property
defined in
<xref linkend= "dbdoclet.50569368_10192" /> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,dynamic-memory” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> that defines memory subject to dynamic
reconfiguration.</para>
<para > <emphasis > prop-encoded-array</emphasis> : The number N of LMB list entries
defined at boot time, encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , followed by N LMB list entries.</para>
<para > An LMB list entry consists of the following elements. There is one
LMB list entry per LMB represented.</para>
<para > Logical address of the start of the LMB, encodes as with
<emphasis role= "bold" > <literal > encode-phys</literal> </emphasis> . This corresponds to the first words in
the
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> property in a
<emphasis role= "bold" > <literal > /memory</literal> </emphasis> device tree node.</para>
<para > DRC index of the LMB, encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> . This corresponds to the
<emphasis role= "bold" > <literal > “ ibm,my-drc-index” </literal> </emphasis> property in a
<emphasis role= "bold" > <literal > /memory</literal> </emphasis> device tree node.</para>
<para > Four (4) bytes reserved for future expansion of flag.</para>
<para > Associativity list index for the LMB, encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> . This is used as an index into
<emphasis role= "bold" > <literal > “ ibm,associativity-lookup-arrays” </literal> </emphasis>
property defined above to retrieve the associativity list for the LMB. The associativity
list corresponds to the
<emphasis role= "bold" > <literal > “ ibm,associativity” </literal> </emphasis> property in a
<emphasis role= "bold" > <literal > /memory</literal> </emphasis> device tree node.</para>
<para > A flags word, encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> . This word represents 32 boolean flags.
As of this definition, flag bits are defined to correspond to the
<emphasis role= "bold" > <literal > “ ibm,preservable” </literal> </emphasis> and
<emphasis role= "bold" > <literal > “ ibm,preserved” </literal> </emphasis> properties in a
<emphasis role= "bold" > <literal > /memory</literal> </emphasis> device tree node. This definition allows for
additional flags to be added in the future.</para>
<para > The following bits in the “ flags word” above are
defined.</para>
<table frame= "all" pgwide= "1" xml:id= "table_flag_word" >
<title > Flag Word</title>
<tgroup cols= "3" >
<colspec colname= "c1" colwidth= "20*" align= "center" />
<colspec colname= "c2" colwidth= "20*" align= "center" />
<colspec colname= "c3" colwidth= "60*" />
<tbody >
<row >
<entry >
<para > Name</para>
</entry>
<entry >
<para > Bit Position</para>
</entry>
<entry align= "center" >
<para > Description</para>
</entry>
</row>
<row >
<entry >
<para > preserved</para>
</entry>
<entry >
<para > 0x00000001</para>
</entry>
<entry >
<para > If b'0', corresponds to the
<emphasis role= "bold" > <literal > “ ibm,preserved” </literal> </emphasis> property having
a zero value.</para>
<para > If b'1', corresponds to the
<emphasis role= "bold" > <literal > “ ibm,preserved” </literal> </emphasis> property having
a non-zero value, and the preserved_state bit below indicates
the state of preservation.</para>
</entry>
</row>
<row >
<entry >
<para > preservable</para>
</entry>
<entry >
<para > 0x00000002</para>
</entry>
<entry >
<para > If b'0', corresponds to the
<emphasis role= "bold" > <literal > “ ibm,preservable” </literal> </emphasis> property
having a zero value.</para>
<para > If b'1', corresponds to the
<emphasis role= "bold" > <literal > “ ibm,preservable” </literal> </emphasis> property
having a non-zero value.</para>
</entry>
</row>
<row >
<entry >
<para > preserved_state</para>
</entry>
<entry >
<para > 0x00000004</para>
</entry>
<entry >
<para > If b'0', corresponds to the
<emphasis role= "bold" > <literal > “ ibm,preserved” </literal> </emphasis> property having
a 0x1 value.</para>
<para > If b'1', corresponds to the
<emphasis role= "bold" > <literal > “ ibm,preserved” </literal> </emphasis> property having
a 0x2 value (and, in the old binding, the LMB having a status
of “ fail” ).</para>
</entry>
</row>
<row >
<entry >
<para > assigned</para>
</entry>
<entry >
<para > 0x00000008</para>
</entry>
<entry >
<para > If b'1', this LMB is assigned to the partition as of boot
time. If b'0', this LMB is not assigned to the partition as of
boot time.</para>
</entry>
</row>
<row >
<entry >
<para > No H_MIGRATE_DMA</para>
</entry>
<entry >
<para > 0x00000010</para>
</entry>
<entry >
<para > If b'0', corresponds to non-existence of the
<emphasis role= "bold" > <literal > “ ibm,no-h-migrate-dma” </literal> </emphasis> in the
<emphasis > memory</emphasis> node.</para>
<para > If b'1', corresponds to existence of the
<emphasis role= "bold" > <literal > “ ibm,no-h-migrate-dma” </literal> </emphasis> in the
<emphasis > memory</emphasis> node.</para>
</entry>
</row>
<row >
<entry >
<para > DRC invalid</para>
</entry>
<entry >
<para > 0x00000020</para>
</entry>
<entry >
<para > If b'0', the DRC field of
<emphasis role= "bold" > <literal > “ ibm,dynamic-memory” </literal> </emphasis> property
is valid or the DRC values for the set of
<emphasis role= "bold" > <literal > “ ibm,dynamic-memory-v2” </literal> </emphasis>
property are valid.</para>
<para > If b'1', the DRC field of
<emphasis role= "bold" > <literal > “ ibm,dynamic-memory” </literal> </emphasis> property
is invalid or the DRC values for the set of
<emphasis role= "bold" > <literal > “ ibm,dynamic-memory-v2” </literal> </emphasis>
property are invalid.</para>
</entry>
</row>
<row >
<entry >
<para > Associativity Index</para>
</entry>
<entry >
<para > 0x00000040</para>
</entry>
<entry >
<para > If b'0', the Associativity List Index field of
<emphasis role= "bold" > <literal > “ ibm,dynamic-memory” </literal> </emphasis> property
or <emphasis role= "bold" > <literal > “ ibm,dynamic-memory-v2” </literal> </emphasis> is valid.</para>
<para > If b'1', the Associativity List Index field of
<emphasis role= "bold" > <literal > “ ibm,dynamic-memory” </literal> </emphasis> property
or <emphasis role= "bold" > <literal > “ ibm,dynamic-memory-v2” </literal> </emphasis> is invalid.</para>
</entry>
</row>
<row >
<entry >
<para > Reserved Memory</para>
</entry>
<entry >
<para > 0x00000080</para>
</entry>
<entry >
<para > If b'0', corresponds to the
<emphasis role= "bold" > <literal > “ status” </literal> </emphasis> property having a
value of “ okay” .</para>
<para > If b'1', corresponds to the
<emphasis role= "bold" > <literal > “ status” </literal> </emphasis> property having a
value of “ reserved” .</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,dynamic-memory-v2” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> that defines memory subject to dynamic
reconfiguration with data in version 2 format.</para>
<para > <emphasis > prop-encoded-array</emphasis> : The number N of LMB set entries, encoded with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> ,
followed by N LMB set entries.</para>
<para > The <emphasis > number-of-sequential-lmbs</emphasis> encoded with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .
The number of LMBs in the set.</para>
<para > The <emphasis > starting-logical-address</emphasis> encoded with
<emphasis role= "bold" > <literal > encode-phys</literal> </emphasis> .
The logical address of the first LMB in the set.</para>
<para > The <emphasis > starting-drc-index</emphasis> encoded with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .
The drc-index of the first LMB in the set.</para>
<para > The <emphasis > associativity-index</emphasis> encoded with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .
All LMBs within the set share the same associativity.</para>
<para > The <emphasis > flags</emphasis> word encoded with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .
All LMBs within the set share the same flag value. The bits in the flags word are defined in
<xref linkend= "table_flag_word" /> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,memory-flags-mask” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> that defined which flags in the
“ flags word” above are defined in this version of this
architecture.</para>
<para > <emphasis > prop-encoded-array</emphasis> : An integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> with all flag bits recognized by this
version of this architecture having a b'1' value. For this version, the
value will be 0x000000FF.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,memory-preservation-time” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> that defined the time value that would
appear in the
<emphasis role= "bold" > <literal > “ ibm,preservable” </literal> </emphasis> property in the old
bindings for a preservable LMB.</para>
<para > <emphasis > prop-encoded-array</emphasis> : An integer value encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that represents the expected length of
time, in minutes, that the platform can sustain the state of power for a
preservable LMB. The largest positive number represents an indefinite
retention time as provided by such technologies as flash storage. A value
zero indicates that no memory will be marked as preservable.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
<section >
<title > Memory Controller Nodes</title>
<para > This section describes
<emphasis role= "bold" > <literal > memory-controller</literal> </emphasis> nodes and their properties. NUMA
configurations, have multiple
<emphasis role= "bold" > <literal > memory-controller</literal> </emphasis> nodes in the device tree one for
each Central Electronics Complex (CEC). In dynamic reconfiguration NUMA
environments, these
<emphasis > /memory-controller</emphasis> nodes are subject to standard
LoPAR dynamic reconfiguration operations and contain standard LoPAR
dynamic reconfiguration properties.</para>
<section >
<title > Memory Controller Node Properties</title>
<para > No nodes of type
<emphasis role= "bold" > <literal > memory-controller</literal> </emphasis> shall be defined anywhere in the
device tree when the platform fully abstracts the memory controller and
the OS has no access to the memory controller (typically when running in
a partition). Otherwise, one or more nodes of type
<emphasis role= "bold" > <literal > memory-controller</literal> </emphasis> shall be defined as a child of
“ /” (the root) and shall not have a
<emphasis role= "bold" > <literal > “ ranges” </literal> </emphasis> property. The following
properties shall apply to each of these nodes. If the platform does not
abstract the functions of a platform's multiple memory controllers via
firmware (such as RTAS) then the platform shall
include a node of type
<emphasis role= "bold" > <literal > memory-controller</literal> </emphasis> for each Memory Controller in the
platform.</para>
<para > A Memory Controller can also have the
<emphasis role= "bold" > <literal > “ used-by-rtas” </literal> </emphasis> property (see
<xref linkend= "dbdoclet.50569368_31220" /> ), if it has functions
abstracted by RTAS.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ device_type” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard <emphasis > property name</emphasis> that denotes a Memory Controller
node.</para>
<para > <emphasis > prop-encoded-array</emphasis> : A string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The value of this property shall be
<literal > “ memory-controller” </literal> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> defines the base physical address and
size of this Memory Controller’ s addressable register space.</para>
<para > <emphasis > prop-encoded-array</emphasis> : One (
<emphasis > phys-address, size</emphasis> ) pair where
<emphasis > phys-address</emphasis> is encoded as with
<emphasis role= "bold" > <literal > encode-phys</literal> </emphasis> , and
<emphasis > size</emphasis> is encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > The property value shall be the base physical address and size of
this Memory Controller’ s register space.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ model” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard <emphasis > property name</emphasis> indicating this Memory
Controller’ s manufacturer, part number and revision level.</para>
<para > <emphasis > prop-encoded-array</emphasis> : Text string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The value of this property is a vendor dependent string which
uniquely identifies this Memory Controller and shall be correlated to its
manufacturer, part number, and revision level. (see Core document for
more information.)</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ external-control” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicates this Memory
Controller’ s ability to support the PA external control
facility.</para>
<para > <emphasis > prop-encoded-int</emphasis> : List of integers, each encoded as
with <emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > The property value, if present, is a list of Resource ID’ s
the version of the PA external control facility supports. This property
shall be present if this Memory Controller supports the PA external
control facility, otherwise the property shall be absent.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ error-checking” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard <emphasis > property name</emphasis> defines the error checking capability
of the node.</para>
<para > <emphasis > prop-encoded-array</emphasis> : a string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> , where the value could equal
“ none” , “ ecc” , or “ parity” .</para>
<para > The value of
<emphasis role= "bold" > <literal > “ #address-cells” </literal> </emphasis>
for this node is 1.</para>
<para > The value of
<emphasis role= "bold" > <literal > “ #size-cells” </literal> </emphasis> for this node is 0 because
the children of this node do not consume any physical address
space.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
<section >
<title > <literal > IBM,memory-module</literal> Nodes</title>
<para > Memory packaged on DIMMs or DIMM like modules are represented in
the device tree with
<emphasis role= "bold" > <literal > IBM,memory-module</literal> </emphasis> nodes. These nodes represent
physical packages, these packages do not necessarily map directly to a
memory address range.</para>
<para > No nodes of type
<emphasis role= "bold" > <literal > IBM,memory-module</literal> </emphasis> shall be defined anywhere in the
device tree when the platform supports dynamic VPD via the RTAS
<emphasis > ibm,get-vpd</emphasis> service. Instead the VPD that would
normally be reported via the
<emphasis role= "bold" > <literal > “ ibm,vpd” </literal> </emphasis> property in these nodes shall
be reported by
<emphasis > ibm,get-vpd</emphasis> .</para>
<section xml:id= "dbdoclet.50569368_27720" >
<title > Properties for Memory Modules</title>
<para > Memory modules appear as children of the
<emphasis > memory</emphasis> node or, for platforms supporting memory DR
operations (either logical or physical), the
<emphasis role= "bold" > <literal > memory-controller</literal> </emphasis> node of the device tree. This
section defines properties for the
<emphasis role= "bold" > <literal > IBM,memory-module</literal> </emphasis> nodes and additional properties for
the
<emphasis > memory</emphasis> and
<emphasis role= "bold" > <literal > memory-controller</literal> </emphasis> nodes.</para>
</section>
<section >
<title > <literal > IBM,memory-module</literal> Node Properties</title>
<para > An
<emphasis role= "bold" > <literal > IBM,memory-module</literal> </emphasis> node is a child of the
<emphasis > memory</emphasis> node or, for platforms supporting memory DR
operations (either logical or physical), the
<emphasis role= "bold" > <literal > memory-controller</literal> </emphasis> node.</para>
<para > The
<emphasis role= "bold" > <literal > “ name” </literal> </emphasis>
of the node is “ IBM,memory-module” </para>
<para > The
<emphasis role= "bold" > <literal > “ device_type” </literal> </emphasis>
of the node is “ IBM,memory-module” </para>
<para > The
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis>
standard property for an
<emphasis role= "bold" > <literal > IBM,memory-module</literal> </emphasis> node is its memory module number
which is an arbitrary OF selected enumeration.</para>
<para > The
<emphasis role= "bold" > <literal > “ ibm,size” </literal> </emphasis>
property for an
<emphasis role= "bold" > <literal > IBM,memory-module</literal> </emphasis> node is an integer which is less
than 4GB and which by itself indicates the size of the memory module, in
bytes, if the memory module is smaller than 4GB and if
<emphasis role= "bold" > <literal > “ status” </literal> </emphasis> is
<emphasis role= "bold" > <literal > “ okay” </literal> </emphasis> or
<emphasis role= "bold" > <literal > “ fail” </literal> </emphasis> .</para>
<para > If the memory module is larger than or equal to 4GB in size, then
the
<emphasis role= "bold" > <literal > “ ibm,size-upper” </literal> </emphasis>
property for an
<emphasis role= "bold" > <literal > IBM,memory-module</literal> </emphasis> node is present in addition to the
<emphasis role= "bold" > <literal > “ ibm,size” </literal> </emphasis> property. This property is an
integer which is multiplied times 4GB and then added to the value of the
<emphasis role= "bold" > <literal > “ ibm,size” </literal> </emphasis> property to get the size of
the module, in bytes. The property
<emphasis role= "bold" > <literal > “ ibm,size-upper” </literal> </emphasis> is not required if the
memory module size is less than 4GB.</para>
<para > The
<emphasis role= "bold" > <literal > “ status” </literal> </emphasis>
standard property for an
<emphasis role= "bold" > <literal > IBM,memory-module</literal> </emphasis> node may have one of the following
string values:</para>
<itemizedlist >
<listitem >
<para > <emphasis role= "bold" > <literal > “ okay” </literal> </emphasis> for a good memory module</para>
</listitem>
<listitem >
<para > <emphasis role= "bold" > <literal > “ fail” </literal> </emphasis> for a bad memory module</para>
</listitem>
<listitem >
<para > <emphasis role= "bold" > <literal > “ fail-no-matched-pair” </literal> </emphasis> for a missing
memory module if one of a pair is missing</para>
</listitem>
<listitem >
<para > <emphasis role= "bold" > <literal > “ fail-unsupport” </literal> </emphasis> for an unsupported
memory module</para>
</listitem>
<listitem >
<para > <emphasis role= "bold" > <literal > “ fail-partial” </literal> </emphasis> for a bad memory module
where part of the memory on the module is bad and has not been configured
and part of the memory is good and has been configured.</para>
</listitem>
<listitem >
<para >
<emphasis role= "bold" > <literal > “ fail-excess-memory” </literal> </emphasis> for
<emphasis role= "bold" > <literal > “ okay” </literal> </emphasis> memory modules that are not
configured because they exceed the system memory addressability of the
platform.</para>
</listitem>
<listitem >
<para >
<emphasis role= "bold" > <literal > “ disabled” </literal> </emphasis> for a memory module that has
been manually deconfigured.</para>
</listitem>
</itemizedlist>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,mem-banks” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> defines the number of memory banks
contained within the memory module.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : an integer, encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , which describes whether this is a 1, 2,
or 4-bank module, with a corresponding value of 1, 2 or 4 and so on to
match the number of banks in the physical device.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,mem-type” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> defines the memory module type.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : a string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> , that describes the type of module,
with values of
<emphasis role= "bold" > <literal > “ FP” </literal> </emphasis> (Fast Page),
<emphasis role= "bold" > <literal > “ EDO” </literal> </emphasis> (Extended Data Out), or
<emphasis role= "bold" > <literal > “ SDRAM” </literal> </emphasis> (Synchronous DRAM).</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,mem-err-det” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> defines the type of error detection
mechanism supported by the module</para>
<para > <emphasis > prop-encoded-array</emphasis> : a string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> , with values of
<emphasis role= "bold" > <literal > “ none” </literal> </emphasis> ,
<emphasis role= "bold" > <literal > “ parity” </literal> </emphasis> , or
<emphasis role= "bold" > <literal > “ ECC” </literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,mem-speed” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> defines the access or clock speed
supported by the module, in picoseconds</para>
<para >
<emphasis > prop-encoded-array</emphasis> : an integer, encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , which describes the access or clock
speed supported by the module, in picoseconds.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
<section >
<title > Interrupt Controller Nodes</title>
<para > This section describes the properties for the LoPAR interrupt
controller node. If an interrupt controller node includes the
<emphasis role= "bold" > <literal > “ used-by-rtas” </literal> </emphasis> property, then the
platform includes firmware code for accessing the interrupt
controller.</para>
<para > For LSIs, the platform shall adhere to the
<xref linkend= "dbdoclet.50569387_67880" /> interrupt structure OF
representation.</para>
<section >
<title > PowerPC External Interrupt Controller Nodes</title>
<para > This section describes the properties for the PowerPC External
Interrupt Controller nodes. PowerPC interrupt controllers are normally
packaged inside other system chips, however, they are logically
represented in the device tree by two or more independent interrupt
controller nodes. Each node reports either the interrupt source layer
resources that are housed in a single Bus Unit Controller (BUC) e.g. host
bridge, or logical equivalent, or a subset of the resources associated
with the platform’ s interrupt presentation layer. The node per BUC
and presentation layer subset divisions provides a foundation for dynamic
reconfiguration.</para>
<para > At a dynamic reconfiguration event, such as adding an IO drawer, or
removing a processor, the interrupt controller nodes associated with the
added or removed hardware will also be added or removed. Therefore.
platforms should report, in individual nodes, each interrupt controller
that occupies a separate physical package. And OSs should expect a fine
granularity of interrupt controller reporting.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,interrupt-domain” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> that denotes a PowerPC External
Interrupt Domain</para>
<para > <emphasis > prop-encoded-array</emphasis> : An integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
</variablelist>
<section xml:id= "dbdoclet.50569368_26927" >
<title > PowerPC External Interrupt Presentation Controller Node
Properties</title>
<para > The following properties apply to this node.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ name” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> that denotes a PowerPC External
Interrupt Controller.</para>
<para > <emphasis > prop-encoded-array</emphasis> : A string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The value of this string shall be
<literal > “ interrupt-controller” </literal> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ device_type” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> that indicates an Interrupt
Controller.</para>
<para > <emphasis > prop-encoded-array</emphasis> : A string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The value of this property shall be
<literal > “ PowerPC-External-Interrupt-Presentation” </literal> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> defines the base physical address(s)
and size(s) of this PowerPC External Interrupt Presentation layer’ s
registers.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : List of (
<emphasis > phys-addr, size</emphasis>
<emphasis > )</emphasis> specifications.</para>
<para >
<emphasis > Phys-addr</emphasis> is encoded as with
<emphasis role= "bold" > <literal > encode-phys</literal> </emphasis> , and
<emphasis > size</emphasis> is encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > The entries shall represent the base address of a single set of
PowerPC External Interrupt Presentation Layer Registers of the Interrupt
Management Area. There shall be one entry for each interrupt server queue
supported by this unit. The order of the entries shall correspond to the
entries in the
<emphasis role= "bold" > <literal > “ ibm,interrupt-server-ranges” </literal> </emphasis> property
described below.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ compatible” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> to define alternate
<emphasis role= "bold" > <literal > “ name” </literal> </emphasis> property values.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : The concatenation, with
<emphasis role= "bold" > <literal > encode+</literal> </emphasis> , of an arbitrary number of text strings,
each encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The property value shall include
<emphasis role= "bold" > <literal > “ IBM,ppc-xicp” </literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,interrupt-buid-size” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : Defines the number of bits
implemented in the concatenation of the BUID fields.</para>
<para >
<emphasis > prop-encoded-value</emphasis> : An integer in the range of 9 to
20 encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > As platforms grow in size so as to require use of larger BUIDs
(values of the
<emphasis role= "bold" > <literal > “ ibm,interrupt-buid-size” </literal> </emphasis>
property greater than 9) the platform engineers need to interlock with their OS
providers to ensure support.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,interrupt-server-ranges” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > Property name</emphasis> that defines the interrupt server
number(s) and range(s) handled by this unit.</para>
<para > <emphasis > prop-encoded-array</emphasis> : List of (<emphasis > server#, range</emphasis> ) specifications.</para>
<para > <emphasis > Server#</emphasis> is encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> in the range of 0 - 2
<superscript > the largest value of the
“ ibm,interrupt-server#-size” property contained in the device
tree</superscript> .</para>
<para > <emphasis > Range</emphasis> is encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > The first entry in this list shall contain the
<emphasis > server#</emphasis> associated with the first
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> property entry. The
<emphasis > server#</emphasis> corresponds to a value of a processor’ s
<emphasis role= "bold" > <literal > “ ibm,ppc-interrupt-server#s” </literal> </emphasis> property.
The range shall be the number of contiguous
<emphasis > server#</emphasis> s supported by the unit (this also
corresponds to the number of
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> entries).</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ interrupt-controller” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> to indicate an interrupt (sub-)tree
root.</para>
<para > <emphasis > prop-encoded-array</emphasis> : < none> The presence of
this property indicates that this node represents an interrupt
controller.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ model” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> indicating this unit’ s
manufacturer, part number, and revision level.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : Text string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The value of this property shall be a string which uniquely
identifies the interrupt controller and shall be correlated to the
manufacturer, part number, and revision level. This value is device
dependent (see the Core document for more information).</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id= "dbdoclet.50569368_69563" >
<title > PowerPC External Interrupt Source Controller Node
Properties</title>
<para > Interrupt source controller resources as represented by
<emphasis role= "bold" > <literal > “ interrupt-ranges” </literal> </emphasis> ,
<emphasis role= "bold" > <literal > “ #interrupt-cells” </literal> </emphasis> , and
<emphasis role= "bold" > <literal > “ ibm,interrupt-server#-size” </literal> </emphasis> properties
may be reported in stand-alone interrupt source controller nodes or in
other logical equivalent nodes which contain the
<emphasis role= "bold" > <literal > “ interrupt-controller” </literal> </emphasis> property. The
following properties apply to these nodes.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ name” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> that denotes a PowerPC External
Interrupt Controller.</para>
<para > <emphasis > prop-encoded-array</emphasis> : A string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The value of this string shall be
<literal > “ interrupt-controller” </literal> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ device_type” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> that indicates the specific flavor of
Interrupt Source Controller.</para>
<para > <emphasis > prop-encoded-array</emphasis> : A string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The value of this property shall be one of the following:</para>
<para > <literal > “ PowerPC-LSI-Source” </literal> <?linebreak?>
For Level Sensitive Interrupt source controllers.</para>
<para > <literal > “ PowerPC-MSI-Source” </literal> <?linebreak?>
For Message Sensitive Interrupt source controllers such as used
with PCI MSI.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> defines the base physical address(s)
and size(s) of this PowerPC External Interrupt Source if any.</para>
<para > <emphasis > prop-encoded-array</emphasis> : List of (
<emphasis > phys-addr, size</emphasis> ) specifications.</para>
<para > <emphasis > Phys-addr</emphasis> is encoded as with
<emphasis role= "bold" > <literal > encode-phys</literal> </emphasis> , and
<emphasis > size</emphasis> is encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > If the
<emphasis role= "bold" > <literal > “ device-type” </literal> </emphasis> of the interrupt source
controller is
<emphasis role= "bold" > <literal > “ PowerPC-MSI-Source” </literal> </emphasis> , then the last
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> entry shall correspond to the
interrupt controller’ s 4 byte Message Interrupt Input Port.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ compatible” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> to define alternate
<emphasis role= "bold" > <literal > “ name” </literal> </emphasis> property values.</para>
<para > <emphasis > prop-encoded-array</emphasis> : The concatenation, with
<emphasis role= "bold" > <literal > encode+</literal> </emphasis> , of an arbitrary number of text strings,
each encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The property value shall include
<emphasis role= "bold" > <literal > “ ibm,ppc-xics” </literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ interrupt-ranges” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> that defines the interrupt number(s)
and range(s) handled by this unit.</para>
<para > <emphasis > prop-encoded-array</emphasis> : List of (
<emphasis > int-number, range</emphasis> ) specifications.</para>
<para > <emphasis > Int-number</emphasis> is encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para >
<emphasis > Range</emphasis> is encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > The first entry in this list shall contain the
<emphasis > int-number</emphasis> associated with the first
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> property entry. The
<emphasis > int-number</emphasis> is the value representing the interrupt
source as would appear in the PowerPC External Interrupt Architecture
XISR. The range shall be the number of sequential interrupt numbers which
this unit can generate.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ interrupt-controller” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> to indicate an interrupt (sub-)tree
root.</para>
<para > <emphasis > prop-encoded-array</emphasis> : < none> The presence of
this property indicates that this node represents an interrupt
controller.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ model” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> indicating this unit’ s
manufacturer, part number, and revision level.</para>
<para > <emphasis > prop-encoded-array</emphasis> : Text string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The value of this property shall be a string which uniquely
identifies the interrupt controller and shall be correlated to the
manufacturer, part number, and revision level. This value is device
dependent (see the Core document for more information).</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ #interrupt-cells” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard <emphasis > property name</emphasis> to define the number of cells in an
<emphasis > interrupt-specifier</emphasis> within an interrupt
domain.</para>
<para > <emphasis > prop-encoded-array</emphasis> : An integer, encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , that denotes the number of cells
required to represent an interrupt specifier in its child nodes.</para>
<para > The value of this property for the PowerPC External Interrupt
option shall be 2. Thus all interrupt specifiers (as used in the standard
<emphasis role= "bold" > <literal > “ interrupts” </literal> </emphasis> property) shall consist of
two cells, each containing an integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> . The first integer represents the
interrupt number the second integer is the trigger code: 0 for edge
triggered, 1 for level triggered.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,interrupt-server#-size” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : Defines the number of bits
implemented in the concatenation of the server#extension and server#
fields.</para>
<para > <emphasis > prop-encoded-value</emphasis> : An integer in the range of 8 to
24 encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > As platforms grow in size so as to require use of the
server#extension field (values of the
<emphasis role= "bold" > <literal > “ ibm,interrupt-server#-size” </literal> </emphasis>
property greater than 8) the platform engineers need to interlock with their OS
providers to ensure support.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
</section>
<section >
<title > Additional Node Properties</title>
<para > Additional properties and methods are defined in this section for
LoPAR binding adapters and/or devices.</para>
<section >
<title > Interrupt Properties</title>
<para > The properties in this section shall be implemented for any device
that can present an interrupt for an LoPAR platform implementation. The
platform shall adhere to the
<xref linkend= "dbdoclet.50569387_67880" /> definition for the interrupt
structure.</para>
</section>
<section xml:id= "dbdoclet.50569368_31220" >
<title > Miscellaneous Node Properties</title>
<para > This section defines properties which support devices, adapter and
buses with geographical information. These properties shall be present
for an LoPAR platform.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ built-in” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard <emphasis > property name</emphasis> : Any device that connects to an
industry standard I/O expansion bus attached through a non-standard
connector.</para>
<para > <emphasis > prop-encoded-string</emphasis> : < none> .</para>
<para > <emphasis role= "bold" > Note:</emphasis> This property will also include platform
‘ riser’ cards.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ used-by-rtas” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard <emphasis > property name</emphasis> : Indicates the device can be in use by
an RTAS Function Call.</para>
<para > <emphasis > prop-encoded-int</emphasis> : Presence of property indicates a
device may have an I/O or resource conflict with a RTAS Function
Call.</para>
</listitem>
</varlistentry>
</variablelist>
<para > The use of the
<emphasis role= "bold" > <literal > “ slot-names” </literal> </emphasis> property defined below is
deprecated in favor of the
<emphasis role= "bold" > <literal > “ ibm,loc-code” </literal> </emphasis> property.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ slot-names” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> : Describes external labeling of
adapter/device connectors.</para>
<para > <emphasis > prop-encoded-array</emphasis> : An integer, encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , followed by a list of strings, each
encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The integer portion of the property value is a bitmask of available
connectors; for each connector associated with the adapter/device, the
bit corresponding to that connector’ s ID number is set from
least-significant to most-significant ID number. The number of following
strings is the same as the number of connectors; the first string gives
the platform nomenclature or label for the connector with the smallest ID
number, and so on.</para>
<para >
<emphasis role= "bold" > Note:</emphasis> Each device that has a connector should
identify the order and contents of the list of strings in a
binding.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,loc-code” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> to provide location code(s) for the
Field Replacable Unit.</para>
<para > <emphasis > prop-encoded-array</emphasis> : an arbitrary number of strings,
encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,vpd” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> to provide Vital Product Data (VPD)
information as defined in
<xref linkend= "LoPAR.Platform" /> .</para>
<para >
<emphasis > prop-encoded-array</emphasis> : the concatenation, with
<emphasis role= "bold" > <literal > encode+</literal> </emphasis> , of one or more pairs of elements, the first
element of each pair being an integer (representing the length of the
second element) encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , and the second element of each pair
being a series of bytes (the VPD data) encoded as with
<emphasis role= "bold" > <literal > encode-bytes</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,loc-code-map” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > prop-name</emphasis> to identify that the interface may have
child nodes, which may or may not be present in the device tree, that
have a physical location code based on their unit-address.</para>
<para > <emphasis > prop-encoded-array</emphasis> : A list of pairs (unit-address,
location-code). The unit-address is the child device node's
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> property string-encoded according
to the parent node's architecture and encoded as with encode-string. The
location-code is the child device node's
<emphasis role= "bold" > <literal > “ ibm,loc-code” </literal> </emphasis> property encoded as with
encode-string.</para>
<para > If a child device under this node has a matching unit-address, the
location code corresponds to the physical location of that child
device.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
<section xml:id= "dbdoclet.50569368_18247" >
<title > <literal > /aliases</literal> Node</title>
<para > A <emphasis > device alias</emphasis> , or simply
<emphasis > alias</emphasis> , is a shorthand representation of a
<emphasis > device-path</emphasis> .
<emphasis > Aliases</emphasis> are properties of the
<emphasis role= "bold" > <literal > aliases</literal> </emphasis> node, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> . Aliases are typically used by a user
to facilitate not specifying a long path name at the User Interface
‘ ok’ prompt.</para>
<para > An implementation of OF for an LoPAR platform shall provide the
following aliases as properties of the
<emphasis role= "bold" > <literal > aliases</literal> </emphasis> node, if the corresponding device
exists:</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ disk” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicating the device path of the
factory default disk that is the preferred boot disk<footnote xml:id= "pgfId-585989" >
<para > <emphasis role= "bold" > Implementation Note:</emphasis> The preferred
boot disk should be the disk
that results in the fastest boot time. Implementations might
automatically spin up a disk at system power on and provide mechanisms
for firmware to report that disk in this property.</para>
</footnote> for the platform.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ tape” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicating the device path of the
factory default tape.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ cdrom” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicating the device path of the
factory default CDROM.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ keyboard” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicating the device path to the
keyboard to be used for the User Interface.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ mouse” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicating the device path to the mouse
to be used for the User Interface.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ screen” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicating the device path to the
screen to be used for the User Interface.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ pc-keyboard” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicating the device path of the
factory default PC-style keyboard.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ pc-mouse” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicating the device path of the
factory default PC-style mouse.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ adb-keyboard” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicating the device path of the
factory default ADB-style keyboard.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ adb-mouse” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicating the device path of the
factory default ADB-style mouse.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ scsi” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicating the device path of the
factory default built-in SCSI device.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ com1” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicating the device path of the
factory default 16550-style serial port known as
“ com1.” </para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ com2” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicating the device path of the
factory default 16550-style serial port known as “ com2.” </para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ scca” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicating the device path of the
factory default SCC-style serial port known as “ SCCA.” </para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ sccb” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicating the device path of the
factory default SCC-style serial port known as “ SCCB.” </para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ floppy” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicating the device path of the
factory default floppy drive.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ net” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicating the device path of the
factory default built-in network interface controller.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ rtc” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicating the device path of the
factory default real-time-clock chip.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ nvram” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> indicating the device path of the
factory default NVRAM.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id= "dbdoclet.50569368_38112" >
<title > <literal > /event-sources</literal> Node</title>
<para > The
<emphasis role= "bold" > <literal > /event-sources</literal> </emphasis> node describes the possible RTAS Error
and Event Classes for interrupts. The
<emphasis role= "bold" > <literal > /event-sources</literal> </emphasis> node shall be defined to be a child of
the root device tree node if the platform supports any event interrupts.
The following properties shall be defined for this node:</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ name” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> that denotes the Event Sources.</para>
<para > <emphasis > prop-encoded-array</emphasis> : A string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The value of this string shall be
<literal > “ event-sources” </literal> .</para>
<para > When events are reported as virtual interrupts there shall be a
node of
<emphasis role= "bold" > <literal > device_type
“ PowerPC-External-Interrupt-Presentation” </literal> </emphasis> from
which the virtual interrupt source BUID size can be obtained. Also the
<emphasis role= "bold" > <literal > event-sources</literal> </emphasis> node represents the interrupt source
node for virtual event interrupts and thus the following properties shall
be defined for this node:</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ interrupt-controller” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard <emphasis > property name</emphasis> : to indicate the events interrupt tree
root.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : < none> The presence of
this property indicates that this node represents a source of virtual
interrupts. Encoded with
<emphasis > encode-null</emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ #interrupt-cells” </literal> </emphasis> [S]</term>
<listitem >
<para > Refer to the definition of the
<emphasis role= "bold" > <literal > “ #interrupt-cells” </literal> </emphasis> property for nodes of
<emphasis role= "bold" > <literal > device_type “ PowerPC-LSI-Source” </literal> </emphasis> for
information about the definition of this property for virtual event
interrupts.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ interrupt-ranges” </literal> </emphasis> [S]</term>
<listitem >
<para > Refer to the definition of the
<emphasis role= "bold" > <literal > “ interrupt-ranges” </literal> </emphasis> property for nodes of
device_type
<emphasis role= "bold" > <literal > “ PowerPC-LSI-Source” </literal> </emphasis> for information
about the definition of this property for virtual event
interrupts.</para>
<para > Children of
<emphasis role= "bold" > <literal > /event-sources</literal> </emphasis> present the interrupt specifiers
associated with the reporting of platform events. LoPAR platforms have
historically implied the default value of
<emphasis role= "bold" > <literal > “ #interrupt-cells” </literal> </emphasis> of 1 to report the
associated interrupt specifiers without the interrupt trigger specifier.
However, all new designs shall present interrupt specifiers with explicit
trigger level values.</para>
</listitem>
</varlistentry>
</variablelist>
<section >
<title > Child nodes of the Event Sources Node</title>
<para > The following specify standard child nodes of the
<emphasis role= "bold" > <literal > /event-sources</literal> </emphasis> node. These nodes could be present in
an LoPAR platform.</para>
<para > Children of the
<emphasis role= "bold" > <literal > /event-sources</literal> </emphasis> node specify the interrupt specifiers
associated with the reporting of platform events. Interrupt designs shall
use the 1275 standard
<emphasis role= "bold" > <literal > “ interrupts” </literal> </emphasis> property as configured to
report the interrupt specifier for the platforms PowerPC interrupt
controller. The interrupt specifiers if the
<emphasis role= "bold" > <literal > “ interrupts” </literal> </emphasis> property indicates one or
more interrupt source numbers that are used to report event
conditions.</para>
<section >
<title > internal-errors</title>
<para > The presence of the node indicates that all or some of the function
has been implemented and will be reported using an interrupt.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ name” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> that denotes the internal error’ s
events.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : A string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The value of this string shall be
<literal > “ internal-error” </literal> .</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section >
<title > epow-events</title>
<para > The presence of the node indicates that all or some of the function
has been implemented and will be reported using an interrupt.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ name” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> that denotes the EPOW events.</para>
<para > <emphasis > prop-encoded-array</emphasis> : A string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The value of this string shall be
<literal > “ epow-events” </literal> .</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section >
<title > ibm,io-events</title>
<para > The presence of the node indicates that all or some of the function
has been implemented and will be reported using an interrupt.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ name” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> that denotes the I/O sub-system
events.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : A string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The value of this string shall be
<literal > “ ibm,io-events” </literal> .</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
<section >
<title > hot-plug-events</title>
<para > The presence of the node indicates that all or some of the function
has been implemented and will be reported using an interrupt. </para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ name” </literal> </emphasis> </term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> that denotes the hot-plug
events.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : A string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The value of this string shall be
<literal > “ hot-plug-events” </literal> .</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
<section >
<title > <literal > /reserved</literal> Node</title>
<para > This section defines a reserved node which shall have a
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> property which allocates addresses
(on the bus of which it is a child) which is intended to be a place to
identify hardware registers that do not otherwise belong to a recognized
device.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ name” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> that denotes reserved addresses that do
not belong to a recognized device.</para>
<para > <emphasis > prop-encoded-array</emphasis> : A string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The value of this string shall be
<literal > “ reserved” </literal> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ device_type” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> that indicates the device type.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : Text string, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The value of this property shall be
<literal > “ reserved” </literal> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> defines a hardware register address and
range of addresses not intended for OS (OS) use.</para>
<para > <emphasis > prop-encoded-array</emphasis> : List of (
<emphasis > phys-addr, size</emphasis> ) specifications.</para>
<para > <emphasis > Phys-addr</emphasis> is a (phys.lo ... phys.hi) sequence equal
to <emphasis role= "bold" > <literal > #address-cells</literal> </emphasis> , encoded as with
<emphasis role= "bold" > <literal > encode-phys</literal> </emphasis> .</para>
<para >
<emphasis > size</emphasis> is a sequence equal to
<emphasis role= "bold" > <literal > #size-cells</literal> </emphasis> encoded as with
<emphasis > encode-size</emphasis> .</para>
<para > The first entry in this list shall be a hardware register address (
<emphasis > phys-addr</emphasis> ) and a range of hardware addresses (
<emphasis > size</emphasis> ) that is not intended for OS usage. Successive
entries in this list shall be additional hardware addresses not intended
for OS usage.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id= "dbdoclet.50569368_11392" >
<title > <literal > /chosen</literal> Node</title>
<para > This section lists additional properties as required under the
<emphasis role= "bold" > <literal > /chosen</literal> </emphasis> node with the following text in a manner that
is consistent with
<xref linkend= "dbdoclet.50569387_45524" /> , Section 3.5.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ nvram” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard <emphasis > property name</emphasis> that defines the package
<emphasis > Ihandle</emphasis> for CHRP NVRAM.</para>
<para > <emphasis > prop-encoded-array</emphasis> : an integer, as encoded with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , that is the package
<emphasis > Ihandle</emphasis> the CHRP NVRAM.</para>
<para > <emphasis role= "bold" > Note:</emphasis> The nvram Node identified in the /chosen Node
shall support a size method as specified in
<xref linkend= "dbdoclet.50569387_27008" /> , Section 7.2. The size method
will return a value that is the total platform NVRAM size.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,rpa-client-config” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> that defines the processed fields of
the client program’ s <emphasis role= "bold" > <literal > IBM,RPA-Client-Config</literal> </emphasis> ELF note section.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : an array of integers encoded as
with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , that consist of the fields of the note
section that the firmware processed prior to loading the client
program.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,architecture-vec-5” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : that presents the values of the
option vector #5 negotiated by the
<emphasis > ibm,client architecture-support</emphasis> method. Presence of
this property signifies that the client program load module invoked the
<emphasis > ibm,client architecture-support</emphasis> method.</para>
<para > <emphasis > prop-encoded-array</emphasis> : An array of bytes having the
format of the fifth option vector from
<xref linkend= "dbdoclet.50569368_10077" /> representing the value chosen
by the <emphasis > ibm,client architecture-support</emphasis> method.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,client-architecture-support-reboot” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : that indicates that one or more
reboots have occurred in this boot sequence in order to adjust the
platform settings to match the specification in the
<emphasis role= "bold" > <literal > “ ibm,client-architecture-support” </literal> </emphasis> open
firmware method or the <emphasis role= "bold" > <literal > IBM,RPA-Client-Config</literal> </emphasis> ELF header note. Note this
property is not included for the first boot in a sequence.</para>
<para > <emphasis > prop-encoded-array</emphasis> : encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that specifies the number of reboots that
have occurred in this boot sequence in order to adjust the platform
settings to match the specification in the
<emphasis role= "bold" > <literal > “ ibm,client-architecture-support” </literal> </emphasis> open
firmware method or the <emphasis role= "bold" > <literal > IBM,RPA-Client-Config</literal> </emphasis> ELF header note.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section >
<title > <literal > /vdevice</literal> Node</title>
<para > The node of type vdevice is a child of the root node. It is only
present in trees that also include the
<emphasis role= "bold" > <literal > “ ibm,hypertas_functions” </literal> </emphasis> property. It,
and its children represent the virtualized devices that are implemented
by the platform firmware. Virtualized devices do not surface to a client
program a direct hardware interface. They do not appear to take up space
in the client program’ s address map. Standard property names
associated with the
<emphasis > /vdevice</emphasis> node have special values as specified
below.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ #address-cells” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that specifies the number of cells
required to represent a child bus address. Shall have the value of 1.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ #size-cells” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that specifies the number of cells
required to encode the size field of a child’ s reg property. Shall
have the value of 0 indicating that no child node may actually take
physical address space.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ name” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> string encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> that defines the name of node. The
value shall be the string “ vdevice” .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ device_type” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> string encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> that defines the device type of the
node. The value shall be the string “ vdevice” .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,max-virtual-dma-size” </literal> </emphasis> </term>
<listitem >
<para > Vendor unique
<emphasis > property name</emphasis> indicating the maximum size virtual dma
transfer size supported by the platform</para>
<para > <emphasis > prop-encoded-array</emphasis> : a single integer encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,migration-control” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> that indicates when platform firmware
supports the ability for an I/O server partition to delay the migration
of a partition to a different server in order to let any in progress I/O
to be completed. Specifically, this property indicates that the
DISABLE_MIGRATION and ENABLE_MIGRATION subfunctions of the H_VIOCTL
hypervisor call are supported.</para>
<para > <emphasis > prop-encoded-array</emphasis> : None, this is a name only
property.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,reserved-virtual-addresses” </literal> </emphasis> </term>
<listitem >
<para > Vendor unique
<emphasis > property name</emphasis> indicating ranges of the client program
virtual address space that are reserved for platform use.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : one or more pairs of
abbreviated-virtual-address, virtual-address-length specifications
representing the origin and length respectively of a reserved virtual
address range.</para>
<para > <emphasis > abbreviated-virtual-address</emphasis> : Consists of two integers
encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> representing the high order and low order
32 bits respectively of the 64 bit abbreviated virtual address. The full
virtual address is the abbreviated-virtual-address concatenated with 3
low order bytes of 0x00.</para>
<para > <emphasis > virtual-address-length</emphasis> : Consists of a single integer
encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> representing the number of consecutive 4K
pages contained within the range.</para>
</listitem>
</varlistentry>
</variablelist>
<section xml:id= "dbdoclet.50569368_26956" >
<title > Children of the <literal > /vdevice</literal> Node</title>
<para > The children of the
<emphasis > /vdevice</emphasis> node represent the individual virtual
devices.</para>
<para > Children of the
<emphasis > /vdevice</emphasis> node that support dma operations contain a
the
<emphasis role= "bold" > <literal > “ ibm,my-dma-window” </literal> </emphasis> property as defined
below:</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,my-dma-window” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> that defines the bus address window(s)
that this IOA may use for its dma.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : One or more (
<emphasis > logical-I/O-bus-number, phys</emphasis> ,
<emphasis > size</emphasis> ) triple(s) where the logical bus number is a
one cell cookie representing the unique range of TCE entries assigned to
this IOA encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , the number of cells for
<emphasis > phys</emphasis> corresponds to the node’ s
<emphasis role= "bold" > <literal > “ ibm,#dma-address-cells” </literal> </emphasis> value while the
number of cells for
<emphasis > size</emphasis> corresponds to the
<emphasis role= "bold" > <literal > “ ibm,#dma-size-cells” </literal> </emphasis> for this node. The
first triple represents the TCE range available for mapping local memory,
while the second triple, if it exists, is where remote memory mapped by
remote partitions appears. The size field of the second triple shall be
equal to the size field of the corresponding remote partition’ s
first triple.</para>
<para > The
<emphasis role= "bold" > <literal > “ ibm,my-dma-window” </literal> </emphasis> property is the per
device equivalent of the
<emphasis role= "bold" > <literal > “ ibm,dma-window” </literal> </emphasis> property found in nodes
representing bus bridges.</para>
<para > Children of the
<emphasis > /vdevice</emphasis> node share the ability to display unique
capabilities as represented by the following properties.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,async-dma-required” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> indicates that the virtual device
requires the use of asynchronous virtual DMA interfaces (see
<xref linkend= "dbdoclet.50569387_85757" /> for definition of asynchronous
virtual DMA interfaces).</para>
<para > <emphasis > prop-encoded-array</emphasis> : None, this is a name only
property.</para>
<para > Children of the
<emphasis > /vdevice</emphasis> node which act a a server to other virtual
client devices, display the following property.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,vserver” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> indicates that the virtual device is a
server to virtual devices.</para>
<para > <emphasis > prop-encoded-array</emphasis> : None, this is a name only
property.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,mac-address-filters” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> specifies the number of non-broadcast
multicast MAC filters supported by the implementation.</para>
<para > <emphasis > prop-encoded-array</emphasis> : an integer in the range of 0-255
encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,trunk-adapter” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> that indicates that the virtual device
is a trunk adapter server to the logical LAN.</para>
<para > <emphasis > prop-encoded-array</emphasis> : None, this is a name only
property.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,illan-options” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : The existence of this property is
required when any of the ILLAN sub-options are implemented and indicates
that the H_ILLAN_ATTRIBUTES hcall() is implemented, and that hcall() is
then used to determine which ILLAN options are implemented.</para>
<para > <emphasis > prop-encoded-array</emphasis> : None, this is a name only
property.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,vf-loc-code” </literal> </emphasis> </term>
<listitem >
<para > Vendor unique <emphasis > property name</emphasis> indicating the physical device
virtual function upon which the vnic-server runs. The value is that of the
<emphasis role= "bold" > <literal > “ ibm,loc-code” </literal> </emphasis>
property of the physical device virtual function.</para>
<para > <emphasis > prop-encoded-array</emphasis> : an arbitrary number of strings, encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,vnic-mode” </literal> </emphasis> </term>
<listitem >
<para > Vendor unique <emphasis > property name</emphasis> that represents the operational
mode in which the vnic-server runs.</para>
<para > <emphasis > prop-encoded-array</emphasis> : a single byte, encoded as with
<emphasis role= "bold" > <literal > encode-bytes</literal> </emphasis> .</para>
<para > Defined values:</para>
<itemizedlist >
<listitem >
<para > 0: backing device is dedicated to one VNIC client</para>
</listitem>
<listitem >
<para > 1: backing device is shared by multiple VNIC clients</para>
</listitem>
<listitem >
<para > 2-255: reserved</para>
</listitem>
</itemizedlist>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,vnic-client-mac” </literal> </emphasis> </term>
<listitem >
<para > Vendor unique <emphasis > property name</emphasis> that represents the MAC
address of a given vNIC server's client.</para>
<para > <emphasis > prop-encoded-array</emphasis> : 6 bytes, encoded as with
<emphasis role= "bold" > <literal > encode-bytes</literal> </emphasis> .</para>
</listitem>
</varlistentry>
</variablelist>
<section >
<title > Virtual Teletype Device</title>
<para > The virtual teletype device allows communication through the
platform’ s attached Hardware System Console. There is one such
virtual device node for each virtual terminal enumerated by the
<emphasis role= "bold" > <literal > “ ibm,termno” </literal> </emphasis> property. The unit addresses
of the virtual teletype devices shall correspond to the enumeration
presented in the
<emphasis role= "bold" > <literal > “ ibm,termno” </literal> </emphasis> property. Such virtual
terminals, as represented by the
<emphasis role= "bold" > <literal > “ ibm,termno” </literal> </emphasis> property, are intended for
the use of the client program and shall not be marked
<emphasis role= "bold" > <literal > “ used-by-rtas” </literal> </emphasis> . Similarly they may be
“ chosen” as the default input and output device.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ name” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> that defines the device name. The value
shall be the string
<emphasis role= "bold" > <literal > “ vty” </literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard <emphasis > property name</emphasis> to define a unit address for the node.
One (
<emphasis > phys-addr, size</emphasis> ) pair. The
<emphasis > phys-addr</emphasis> is the unit address of the device
(corresponding to one of the virtual terminals enumerated by the
<emphasis role= "bold" > <literal > “ ibm,termno” </literal> </emphasis> property), and the
<emphasis > size</emphasis> shall have a length of zero.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ device_type” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard <emphasis > property name</emphasis> encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> to specify the device type. The value
shall be the string
<emphasis role= "bold" > <literal > “ serial” </literal> </emphasis> indicating that the device
emulates a serial terminal.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ compatible” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> to specify the device driver
compatibility. The value shall be one of the strings specified in
<xref linkend= "dbdoclet.50569368_46297" /> .</para>
<table frame= "all" pgwide= "1" xml:id= "dbdoclet.50569368_46297" >
<title > Virtual tty compatibility strings</title>
<?dbhtml table-width="75%" ?>
<?dbfo table-width="75%" ?>
<tgroup cols= "2" >
<colspec colname= "c1" colwidth= "40*" />
<colspec colname= "c2" colwidth= "60*" />
<thead >
<row >
<entry align= "center" >
<para >
<emphasis role= "bold" > Compatible property String
Value</emphasis>
</para>
</entry>
<entry align= "center" >
<para >
<emphasis role= "bold" > Comments</emphasis>
</para>
</entry>
</row>
</thead>
<tbody >
<row >
<entry >
<para >
<emphasis role= "bold" > <literal > “ hvterm1” </literal> </emphasis>
</para>
</entry>
<entry >
<para > Standard client virtual tty protocol</para>
</entry>
</row>
<row >
<entry >
<para >
<emphasis role= "bold" > <literal > “ hvterm2” </literal> </emphasis>
</para>
</entry>
<entry >
<para > Standard server virtual tty protocol</para>
</entry>
</row>
<row >
<entry >
<para >
<emphasis role= "bold" > <literal > “ hvterm-protocol” </literal> </emphasis>
</para>
</entry>
<entry >
<para > Client virtual tty protocol extended for control of
modems etc.</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
<para > See
<xref linkend= "LoPAR.Error" /> for further detail on this
virtual device.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section >
<title > Children of
<literal > /vdevice</literal> node defined in other documents</title>
<para > Like children of the pci bus node, children of
<emphasis > /vdevice</emphasis> may be defined by their own binding
documents or via binding sections/tables in their device specifications.
For example, the binding information for the LoPAR Interpartition
Logical LAN, Virtual SCSI, and Virtual Terminal can be found in the
appropriate sections of this document. The virtualization of traditional
physical devices repositions their associated device tree nodes to be
children of
<emphasis > /vdevice</emphasis> . Examples include NVRAM and Real Time Clock
(RTC) devices which are defined by
<xref linkend= "dbdoclet.50569387_27008" /> .</para>
</section>
</section>
</section>
<section >
<title > Barrier Synchronization Facility</title>
<para > This section describes the OF node that represents the optional
Barrier Synchronization Register (BSR) facility. If the platform provides
a BSR facility it provides the
<emphasis > ibm,bsr</emphasis> node as a child of
<emphasis > /</emphasis> (root). If the platform provides a client program
with multiple independent facilities, it represents each such facility
with a separate node. A given facility may have multiple representations
through parallel windows. Each window of a given facility is represented
by a separate
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> property value. The following
properties are the minimum required, optional support such as dynamic
reconfiguration will add properties per requirements called out in the
<xref linkend= "LoPAR.Virtualization" /> .</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ name” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> that defines the device name. The value
shall be the string
<emphasis role= "bold" > <literal > “ ibm,bsr” </literal> </emphasis> for legacy implementations and
<emphasis role= "bold" > <literal > “ ibm,bsr2” </literal> </emphasis> for POWER8 implementations and
beyond.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> to define the addresses for the
facility window(s).</para>
<para >
<emphasis > prop-encoded-array</emphasis> : One or more (
<emphasis > phys-addr, size</emphasis> ) pair(s). The
<emphasis > phys-addr</emphasis> , encoded as with
<emphasis role= "bold" > <literal > encode-phys</literal> </emphasis> , is the starting address (4 K aligned) of
the window. The
<emphasis > size</emphasis> , encoded in the number of cells specified by
<emphasis role= "bold" > <literal > “ #size-cells” </literal> </emphasis> of the parent, is the
length of the corresponding window.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ device_type” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> to specify the device type. The value
shall be the string
<emphasis role= "bold" > <literal > “ ibm,bsr” </literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ compatible” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> to specify the device driver
compatibility. The value shall be the string
<emphasis role= "bold" > <literal > “ ibm,bsr” </literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,#lock-bytes” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : Indicates the number of lock bytes
per line of the BSR facility.</para>
<para > <emphasis > prop-encoded-array</emphasis> : One or more integers encoded as
with <emphasis role= "bold" > <literal > encode-int</literal> </emphasis> . When the facility has multiple windows,
as represented by multiple values of the
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> property, then there is a
corresponding number of integers, each integer representing the number of
lock bytes per line of the corresponding window.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,lock-stride” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : Indicates the number of bytes between
the beginning of lock lines in the BSR facility.</para>
<para > <emphasis > prop-encoded-array</emphasis> : One or more integers encoded as
with <emphasis role= "bold" > <literal > encode-int</literal> </emphasis> . When the facility
has multiple windows, as represented by multiple values of the
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> property, then there is a
corresponding number of integers, each integer representing the number of
bytes to the beginning of the next lock line in the corresponding
window.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section >
<title > Nodes of device_type <literal > “ block” </literal> and
<literal > “ byte” </literal> </title>
<para > This section describes the OF nodes that provide access to storage
devices in block or byte commands. This applies to such nodes with and
without a
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> property.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,write-supported” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : Indicates the driver supports write
functionality and has been verified by IBM. The use of the write function
without this property is discouraged.</para>
<para > <emphasis > prop-encoded-array</emphasis> : None, this is a name only
property.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,16byte-cdb-supported” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : Indicates the driver supports using
the 16 byte Command Descriptor Block format, which is needed to access
above 2 TB on 512 byte block-sized media.</para>
<para > <emphasis > prop-encoded-array</emphasis> : None, this is a name only
property.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section >
<title > <literal > /ibm,platform-facilities</literal> </title>
<para > The node of type
<emphasis role= "bold" > <literal > ibm,platform-facilities</literal> </emphasis> is a child of the root node.
It and its children represent the non-CPU platform computational
facilities that are available. Platform facilities do not take up space
in the client program’ s address map. Standard property names
associated with the
<emphasis > /ibm,platformfacilities</emphasis> node have special values as
specified below.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ #address-cells” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that specifies the number of cells
required to represent a child bus address. Shall have the value of
1.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ #size-cells” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that specifies the number of cells
required to encode the size field of a child’ s reg property. Shall
have the value of 0 indicating that no child node may actually take
physical address space.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ name” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> string encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> that defines the name of node. The
value shall be the string
<emphasis role= "bold" > <literal > “ ibm,platform-facilities” </literal> </emphasis> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ device_type” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> string encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> that defines the device type of the
node. The value shall be the string
<emphasis role= "bold" > <literal > “ ibm,platform-facilities” </literal> </emphasis> .</para>
<para > Some platform facilities configurations allow multiple facilities
to share a common pool of interrupt server numbers. Individual operations
specify which interrupt server number from the pool shall be used to
signal completion of the operation. To represent such a configuration,
the
<emphasis > /ibm,platformfacilities</emphasis> node may either represent an
interrupt source controller for its children or the interrupt source
controller associated with the shared pool may be represented by a
PowerPC External Interrupt Source Controller Node as an additional child
node of the
<emphasis role= "bold" > <literal > /ibm,platform-facilities</literal> </emphasis> node
(<xref linkend= "dbdoclet.50569368_69563" /> ). Additionally, the node
representing the platform facilities Interrupt Source Controller shall
contain the
<emphasis role= "bold" > <literal > “ ibm,interrupt-pool” </literal> </emphasis> property, and all
platform facilities that share the common pool of interrupts shall
contain the
<emphasis role= "bold" > <literal > “ ibm,shared-interrupt-pool” </literal> </emphasis> property.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,interrupt-pool” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : that indicates this interrupt
controller provides a shared pool of interrupt source numbers.</para>
<para > <emphasis > property encoded array</emphasis> : single cell encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that represents the type of shared
interrupt pool being represented: Defined values are: 0 with all other
values reserved.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,max-async-ops-per-processor” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : that indicates for the partition the
allowed maximum number of outstanding operations for the platform
facility based upon the number of processors currently allocated to the
partition. The total allowable number of such operations outstanding
across all partition processors is the product of the value of
<emphasis role= "bold" > <literal > “ ibm,max-async-ops-per-processor” </literal> </emphasis> and the
number of nodes of type cpu in the current partition device tree.</para>
<para > <emphasis > property encoded array</emphasis> : single cell encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> </para>
</listitem>
</varlistentry>
</variablelist>
<section >
<title > Children of the <literal > /ibm,platform-facilities</literal> Node</title>
<para > The children of the
<emphasis role= "bold" > <literal > /ibm,platform-facilities</literal> </emphasis> node represent the
individual platform facilities. Standard property names associated with
the children of the
<emphasis role= "bold" > <literal > /ibm,platform-facilities</literal> </emphasis> node have special values as
specified below. Note the children of the
<emphasis role= "bold" > <literal > /ibm,platform-facilities</literal> </emphasis> node shall contain the
following standard properties with their standard definitions:</para>
<itemizedlist >
<listitem >
<para > <emphasis role= "bold" > <literal > “ compatible” </literal> </emphasis> </para>
</listitem>
<listitem >
<para > <emphasis role= "bold" > <literal > “ name” </literal> </emphasis> The defined Values for the
<emphasis role= "bold" > <literal > “ name” </literal> </emphasis> property of children of
<emphasis role= "bold" > <literal > /ibm,platform-facilities</literal> </emphasis> are (were # is the version
number of the interface):</para>
<itemizedlist >
<listitem >
<para > <emphasis role= "bold" > <literal > ibm,random-v#</literal> </emphasis> Random number generator</para>
</listitem>
<listitem >
<para > <emphasis role= "bold" > <literal > ibm,compression-v#</literal> </emphasis> Compression/Decompression
engine</para>
</listitem>
<listitem >
<para > <emphasis role= "bold" > <literal > ibm,sym-encryption-v#</literal> </emphasis> Symmetric encryption/decryption
engine</para>
</listitem>
<listitem >
<para > <emphasis role= "bold" > <literal > ibm,asym-encryption-v#</literal> </emphasis> Asymmetric
encryption/decryption engine</para>
</listitem>
<listitem >
<para > <emphasis role= "bold" > <literal > ibm,memory-utilization-instrumentation-v#</literal> </emphasis> Memory
usage information</para>
</listitem>
</itemizedlist>
</listitem>
<listitem >
<para > <emphasis role= "bold" > <literal > “ status” </literal> </emphasis> </para>
</listitem>
</itemizedlist>
<para > <emphasis role= "bold" > Optionally</emphasis> the children of the
<emphasis role= "bold" > <literal > /ibm,platform-facilities</literal> </emphasis> node may contain as
appropriate the following standard properties with their standard
definitions:</para>
<itemizedlist >
<listitem >
<para > <emphasis role= "bold" > <literal > “ interrupts” </literal> </emphasis> </para>
</listitem>
</itemizedlist>
<para > <emphasis role= "bold" > Additionally</emphasis> the children of the
<emphasis role= "bold" > <literal > /ibm,platform-facilities</literal> </emphasis> node may contain as
appropriate the following unique properties:</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,resource-id” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : that indicates the platform facility
resource identification handle.</para>
<para > <emphasis > property encoded array</emphasis> : single cell encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> </para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,max-sync-cop” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : that indicates the maximum
characteristics of the parameters for a synchronous call of the platform
facility. These characteristics are represented as a series of integers
encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that
may grow over time as platform
facilities evolve. The absence of this property indicates that
synchronous operations are not allowed for the given child.</para>
<para >
<emphasis > property encoded array</emphasis> : a series of zero or more or
more cells each encoded as with
<emphasis > encode-int.</emphasis> The interpretation of the series of
integers is unique per the value of the
<emphasis role= "bold" > <literal > “ name” </literal> </emphasis> property:</para>
<itemizedlist >
<listitem >
<para > For the Random number generator: NULL value indicating that all
calls are synchronous</para>
</listitem>
<listitem >
<para > For the compression/decompression engine: Two series of cells the
first series of cells represents the maximums that can be synchronously
compressed. The second series of cells represents the maximums that can
be synchronously decompressed.</para>
<itemizedlist >
<listitem >
<para > The first cell in each series contains the count of the number of
data length, scatter/gather elements pairs that follow – each being
of the form</para>
<itemizedlist >
<listitem >
<para > One cell data byte length</para>
</listitem>
<listitem >
<para > One cell total number of scatter/gather elements</para>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
<listitem >
<para > For the symmetric encryption/decryption engine: the series of
cells report for each function code (FC) and mode combination the maximum
amount of data and scatter/gather list elements that can be processed
with a given key length. Thus the array consists of 1-N sub sequences
each of the form:</para>
<itemizedlist >
<listitem >
<para > First cell contains the FC field</para>
</listitem>
<listitem >
<para > Second cell contains the mode field</para>
</listitem>
<listitem >
<para > Third cell contains the count of the number of key length, data
length, scatter/gather elements triples that follow – each being of
the form:</para>
<itemizedlist >
<listitem >
<para > One cell key bit length</para>
</listitem>
<listitem >
<para > One cell data byte length</para>
</listitem>
<listitem >
<para > One cell total number of scatter/gather elements</para>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,max-sg-len” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : that indicates the maximum byte length
of a scatter/gather list for the platform facility.</para>
<para >
<emphasis > property encoded array</emphasis> : single cell encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> </para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,shared-interrupt-pool” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> : that provides an indirect pointer to
the node representing the shared interrupt pool used by this
facility.</para>
<para > <emphasis > property encoded array</emphasis> : the phandle of the node
representing the PowerPC External Interrupt Source Controller that
sources the interrupts of the shared interrupt pool used by this
facility.</para>
</listitem>
</varlistentry>
</variablelist>
<itemizedlist >
<listitem >
<para > For the memory utilization instrumentation facility node the following properties are defined:</para>
</listitem>
</itemizedlist>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,mui-associativity-mapping” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> to define the mapping between Memory Usage
Instrumentation Affinity Log Array entries and their associated associativity strings.</para>
<para > <emphasis > property encoded array</emphasis> : An integer (L) encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> followed by L sets ALA map entries.</para>
<para > Each ALA map entry consisting of:</para>
<itemizedlist >
<listitem >
<para > An integer (ALAentry) encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis>
as would be found in the affinity_log record for the return buffer
from the H_RETURN_PAGEINFO hcall() followed by;</para>
</listitem>
<listitem >
<para > An integer (M) encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis>
that represents the type of source of the reference
(defined values are presented below). Sources of a general
type are grouped together, so that if the
client program does not recognize a given specific type,
it can still categorize via the more general
type of source:</para>
<itemizedlist spacing= "compact" >
<listitem >
<para > 0-100,000,000 CPU</para>
</listitem>
<listitem >
<para > 100,000,001 – </para>
</listitem>
<listitem >
<para > 200,000,001 – </para>
</listitem>
<listitem >
<para > All other values reserved (may be grouped together as an unknown source type).</para>
</listitem>
</itemizedlist>
<para > Followed by:</para>
</listitem>
<listitem >
<para > An integer (N) encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis>
followed by N associativity lists.</para>
</listitem>
<listitem >
<para > Each associativity list consisting of a number of entries integer (P) encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis>
followed by P integers encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis>
each representing an associativity
domain number.</para>
</listitem>
</itemizedlist>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ ibm,mui-ranges” </literal> </emphasis> </term>
<listitem >
<para > <emphasis > property name</emphasis> to define the implementation specific
ranges of memory utilization instrumentationmeasures.</para>
<para > <emphasis > property encoded array</emphasis> : An integer (N) encoded as with
encode-int
which communicates the number of pairs of range values, each being an integer encoded as with
encode-int
which represent the implementation limits of a given measure. See
<xref linkend= "table_mui_range_limits" />
for details. The reader is to ignore values pairs beyond those it was designed to use.
If the value of N is zero the MUI measures are not available.</para>
</listitem>
</varlistentry>
</variablelist>
<table xml:id= "table_mui_range_limits" >
<?dbhtml table-width="75%" ?>
<?dbfo table-width="75%" ?>
<title > <emphasis role= "bold" > <literal > “ ibm,mui-associativity-mapping” </literal> </emphasis> range limits</title>
<tgroup cols= "3" >
<colspec colname= "c1" colwidth= "10*" align= "center" />
<colspec colname= "c2" colwidth= "20*" align= "center" />
<colspec colname= "c3" colwidth= "70*" />
<thead >
<row >
<entry >
<para > Pair #</para>
</entry>
<entry >
<para >   </para>
</entry>
<entry >
<para >   </para>
</entry>
</row>
</thead>
<tbody valign= "middle" >
<row >
<entry >
<para > 1</para>
</entry>
<entry >
<para > MIN/MAX</para>
</entry>
<entry >
<para > The minimum and maximum supported value of the HUC field
which is the power of 2 multiplier of microseconds that defines the
History Bit Array update period.</para>
</entry>
</row>
<row >
<entry >
<para > 2</para>
</entry>
<entry >
<para > 0/MAX</para>
</entry>
<entry >
<para > The number of bits implemented in the HBA.</para>
</entry>
</row>
<row >
<entry >
<para > 3</para>
</entry>
<entry >
<para > 0/MAX</para>
</entry>
<entry >
<para > Access rate in accesses per millisecond.</para>
</entry>
</row>
<row >
<entry >
<para > 4</para>
</entry>
<entry >
<para > 0/MAX</para>
</entry>
<entry >
<para > Page Age; the MAX value is the number of Page Age Granules
which saturates the page age counter.</para>
</entry>
</row>
<row >
<entry >
<para > 5</para>
</entry>
<entry >
<para > 0/MAX</para>
</entry>
<entry >
<para > Remote Reference; the MAX value is the number of implemented ALA entries.</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</section>
</section>
</section>
<section xml:id= "dbdoclet.50569368_56107" >
<title > Symmetric Multi-Processors (SMP)</title>
<para > LoPAR platforms can have Symmetric Multi-Processor (SMP)
Configurations. In addition to the processor node properties defined in
<xref linkend= "dbdoclet.50569374_59715" /> , a SMP Configuration will
utilize the
<emphasis > /cpus</emphasis> node as explained in
<xref linkend= "dbdoclet.50569368_35974" /> </para>
<section xml:id= "dbdoclet.50569368_35974" >
<title > SMP Platform Device Tree Structure</title>
<para > OF requires that multiple instances of any device that appears more
than once in the device tree must be unique and distinguishable by means
of their
<emphasis role= "bold" > <literal > “ reg” </literal> </emphasis> properties. For LoPAR platforms,
processors shall not be directly attached to the main physical bus (root
node (“
<emphasis > /</emphasis> ” )). Instead, cpu devices shall be children
of the
<emphasis > /cpus</emphasis> node.</para>
<para > The
<emphasis > /cpus node</emphasis> shall have one child node of device type
cpu for each processor. The
<emphasis > ihandle</emphasis> of the “ executing” processor
shall
be published in the
<emphasis role= "bold" > <literal > “ cpu” </literal> </emphasis> property of the
<emphasis role= "bold" > <literal > /chosen</literal> </emphasis> node.</para>
<para >
<emphasis role= "bold" > Note:</emphasis> The properties of a cpu device are already
defined in
<xref linkend= "dbdoclet.50569374_59715" /> . The only change for symmetric
multiprocessor (SMP) systems is that there will be a cpu device node
under the
<emphasis > /cpus</emphasis> node for each individual processor. Other
properties of the cpu devices shall
conform with the requirements stated in
<xref linkend= "dbdoclet.50569374_59715" /> .</para>
</section>
<section >
<title > SMP Properties</title>
<para > The following properties are for a PA SMP environment. These SMP
properties will be under the
<emphasis > /cpus</emphasis> Node.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ slot-names” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> that describes platform labeling of
plug-in cpu/processor card slots.</para>
<para > <emphasis > prop-encoded-array</emphasis> : An integer, encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , followed by a list of strings, each
encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > The integer portion of the property value is a bitmask of possible
processors; for each add-in slot on the bus, the bit corresponding to
that slot’ s ID number is set from least-significant to
most-significant ID number. The number of following strings is the same
as the number of slots; the first string gives the platform nomenclature
for the slot with the smallest ID number, and so on. The CPU’ s
<emphasis role= "bold" > <literal > “ slot-names-index” </literal> </emphasis> property can be used
as an index into the bitmask integer of this property. The absence of
this property indicates that no slots are present.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ smp-enabled” </literal> </emphasis> [S]</term>
<listitem >
<para > <emphasis > property name</emphasis> that indicates a platform can be SMP
enabled.</para>
<para > <emphasis > prop-encoded-array</emphasis> : < NULL> </para>
<para > The presence of this property signifies that the platform is SMP
enabled, even if it only has one processor.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section >
<title > Processor Node</title>
<para > The following properties are for a PA SMP environment. This SMP
property will be under each
<emphasis role= "bold" > <literal > /cpu</literal> </emphasis> Node.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ slot-names-index” </literal> </emphasis> [S]</term>
<listitem >
<para >
<emphasis > property name</emphasis> : Identifies each cpu with a unique
number.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An integer, encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > The value of this integer is a platform unique number with a range
from 0 to
<emphasis > n-1</emphasis> for each CPU where
<emphasis > n</emphasis> is the number of slots. This number is used to
index into the
<emphasis role= "bold" > <literal > “ slot-names” </literal> </emphasis> property to identify the
value of the string associated with the slot name.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
<section >
<title > Device Power Management Properties/Methods</title>
<para > This section defines standard platform node properties, device node
properties, and methods related to power management. The properties and
methods of this section shall be implemented on any platform which supports
power management except where noted. However, it is still being enhanced.
OS providers who want to ensure that the data needed for their power
management policies is included should contact the authors of this
document.</para>
<section >
<title > System Node Properties</title>
<para > The following defines properties are to be associated with the rtas
and the power-management-events nodes of the device tree.</para>
<section >
<title > Properties assigned to the RTAS node</title>
<para > Power domains are a feature of platforms which support power
management. Within the OF device tree, power domains are represented by a
power domain identifier which is defined to be an integer in the range 0
... n-1, where n is the number of power domains on the platform.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ power-domains-tree” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> which defines the power domain
hierarchy for this platform.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An array of integers, each
encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> , that is a flattened representation of
the power domain dependency tree.</para>
<para > The array consists of a number of tuples, one for each power domain
defined on the platform. Each tuple consists of the power domain
identifier domain#, followed by the number of power levels #levels
supported by the domain, followed by an array of tuples, one for each
level. These tuples consist of a level identifier level, followed by the
number of power sources from which the domain draws power, followed by an
array of tuples (power-source-id, power). The power domain tuple is
terminated by the number of children #children followed by a list of the
domain identifiers of each child. The power values are expressed in
milliamperes and include only the power consumed by support logic not
represented as devices in the device tree including any RTAS abstracted
devices within the particular power domain.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ power-domains-controllers” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> which defines the power domain
controllers present on this platform.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : an array of integers, each
encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > Each integer is the
<emphasis > phandle</emphasis> of the device tree node that functions as the
power domain controller for a domain. A single controller may serve as
the control point for multiple domains (the architecture calls them power
domain control points). Each device which serves as a controller encodes
the
<emphasis role= "bold" > <literal > “ controls-power-domain” </literal> </emphasis> property.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ power-domains-names” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> used to define the user readable names
for the power domains.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : an array of strings, each
encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> , that are the user readable names for
the domains.</para>
<para > The number of strings matches the number of domains and there is a
one-to-one correspondence between the entries in the
<emphasis role= "bold" > <literal > “ power-domain-controllers” </literal> </emphasis> property and
the entries in this array.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ platform-power-sources” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> defining the platform power
sources.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : an array of integers, each
encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > The array is structured as a number of tuples. Each of these tuples
consists of the values source-voltage, (given in millivolts), peak-power,
continuous-use-power (both expressed in milliamperes supplied at the
stated voltage), and conversion-efficiency (expressed in percent).</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ power-sources-names” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> defining the platform power source
names.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : an array of strings, each
encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> , that are the user readable names for
the power sources.</para>
<para > The number of strings match the number of power sources and is in
one-to-one correspondence to the entries in the
<emphasis role= "bold" > <literal > “ platform-power-sources” </literal> </emphasis> property.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ platform-battery-sources” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> defining the batteries utilized by a
platform.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : an array of integers, each
encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > Each value in this array is the manufacturer’ s rated capacity
of the battery expressed in milliwatt-hours.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ battery-sources-names” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> defining the human-readable identifier
of the batteries utilized by a platform.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : an array of strings, each
encoded as with
<emphasis role= "bold" > <literal > encode-string</literal> </emphasis> .</para>
<para > Each entry in this array corresponds one-for-one with the batteries
defined in the
<emphasis role= "bold" > <literal > “ platform-battery-sources” </literal> </emphasis> property.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section >
<title > Properties of the power-management-events node</title>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ power-type” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> defining the power management event
types implemented on a specific platform.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : an array of integers, each
encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
<section >
<title > Device Properties</title>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ power-domains” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> , indicating the power domains of which
this device is a member.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : List of one or more
<emphasis > domain-id’ s</emphasis> to which this device belongs.
<emphasis > Domain-id’ s</emphasis> is encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > The
<emphasis role= "bold" > <literal > “ power-domains” </literal> </emphasis> property should only list
the
<emphasis > domain-id’ s</emphasis> of the lowest power domain tree
nodes in which this device has membership. If the device is a member of
the default power domain 0 alone, this property does not need to be
provided.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ device-power-states” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> which describes the power states this
device supports.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : An array of integers, each
encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that defines the supported power states
for this device.</para>
<para > This property shall be provided for each physical device which has
multiple power states, if platform firmware provides device power state
information.</para>
<para > The array consists of an integer representing the initial device
power state after reset, followed by the number of power sources from
which the device draws power, followed by an arbitrary number of tuples,
one for each supported power state of the device. Each tuple consists of
the state, followed by an array of tuples (power-source-id, power) giving
the average power consumption from each power source during active use.
This is followed by another array of tuples (power-source-id, power)
giving the idle power consumption for each power source. Each power state
tuple is terminated by the maximum expected power usage lifetime in
seconds for the device if it were to remain in that state. The value
power is stated in the millamperes consumed at the voltage supplied by
the power source.</para>
<para > The value state shall be further constrained to have the following
semantics:</para>
<table frame= "all" pgwide= "1" >
<title > Semantics of device state values</title>
<?dbhtml table-width="75%" ?>
<?dbfo table-width="75%" ?>
<tgroup cols= "2" >
<colspec colname= "c1" colwidth= "20*" align= "center" />
<colspec colname= "c2" colwidth= "80*" />
<thead >
<row >
<entry >
<para >
<emphasis role= "bold" > Value</emphasis>
</para>
</entry>
<entry align= "center" >
<para >
<emphasis role= "bold" > Semantics</emphasis>
</para>
</entry>
</row>
</thead>
<tbody >
<row >
<entry >
<para > 100</para>
</entry>
<entry >
<para > This is the device’ s most responsive state.</para>
</entry>
</row>
<row >
<entry >
<para > 20-99</para>
</entry>
<entry >
<para > The device is functional. The range represents a range of
performance.</para>
</entry>
</row>
<row >
<entry >
<para > 11-19</para>
</entry>
<entry >
<para > Reserved</para>
</entry>
</row>
<row >
<entry >
<para > 10</para>
</entry>
<entry >
<para > Device is not operational, but retains its internal
functional parameters.</para>
</entry>
</row>
<row >
<entry >
<para > 1-9</para>
</entry>
<entry >
<para > Reserved</para>
</entry>
</row>
<row >
<entry >
<para > 0</para>
</entry>
<entry >
<para > Device not functional, may lose internal functional
parameters.</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
<para > The semantics of device power states may be further defined by
device type specific bindings.</para>
<para > The interaction of the defined semantics of device power state and
domain power level is defined in
<xref linkend= "dbdoclet.50569368_42921" /> . Those combinations not marked
are disallowed.</para>
<table frame= "all" pgwide= "1" xml:id= "dbdoclet.50569368_42921" >
<title > Combinations of Device Power State/Domain Power
Level</title>
<?dbhtml table-width="80%" ?>
<?dbfo table-width="80%" ?>
<tgroup cols= "6" >
<colspec colname= "c1" colwidth= "16*" align= "center" />
<colspec colname= "c2" colwidth= "16*" align= "center" />
<colspec colname= "c3" colwidth= "16*" align= "center" />
<colspec colname= "c4" colwidth= "16*" align= "center" />
<colspec colname= "c5" colwidth= "16*" align= "center" />
<colspec colname= "c6" colwidth= "16*" align= "center" />
<thead >
<row >
<entry morerows= "0" nameend= "c2" namest= "c1" >
<para >
<emphasis role= "bold" >   </emphasis>
</para>
</entry>
<entry nameend= "c6" namest= "c3" >
<para >
<emphasis role= "bold" > Device Power State</emphasis>
</para>
</entry>
</row>
</thead>
<tbody >
<row >
<entry morerows= "3" valign= "middle" >
<para >   </para>
<para > Domain Power Level</para>
</entry>
<entry >
<para > Full On</para>
</entry>
<entry >
<para > Allowed</para>
</entry>
<entry >
<para > Allowed</para>
</entry>
<entry >
<para > Allowed</para>
</entry>
<entry >
<para > Allowed</para>
</entry>
</row>
<row >
<entry >
<para > Reduced</para>
</entry>
<entry >
<para >   </para>
</entry>
<entry >
<para > Allowed</para>
</entry>
<entry >
<para > Allowed</para>
</entry>
<entry >
<para > Allowed</para>
</entry>
</row>
<row >
<entry >
<para > Freeze</para>
</entry>
<entry >
<para >   </para>
</entry>
<entry >
<para >   </para>
</entry>
<entry >
<para > Allowed</para>
</entry>
<entry >
<para > Allowed</para>
</entry>
</row>
<row >
<entry >
<para > Off</para>
</entry>
<entry >
<para >   </para>
</entry>
<entry >
<para >   </para>
</entry>
<entry >
<para >   </para>
</entry>
<entry >
<para > Allowed</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ device-state-transitions” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> that describes the legal power state
transitions supported by the device.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : an array of integers, each
encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that defines the legal power state
transitions for this device.</para>
<para > The array is structured as a number of tuples, one for each
possible transition. Each tuple consists of the starting state, followed
by the destination state, followed by an array of tuples
(power-source-id, power), one for each power source, followed by the time
required to make the transition in microseconds, followed by the maximum
count allowed for this transition. The starting state and destination
state are values defined in the
<emphasis role= "bold" > <literal > “ device-power-states” </literal> </emphasis> property. The value
power is stated in the millamperes consumed. This property shall be
provided if platform firmware provides device power state
information.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ power-sources” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> which designates this device as a
consumer of power sourced from a defined power source.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : an array of integers, each
encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that gives the list of power sources to
which this device is connected.</para>
<para > The values are indices into the platform-power-sources data
structure. This property shall be provided if platform firmware provides
device power state information.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ power-management-mapping” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> that defines device power states and
commands.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : an array of integers as encoded
with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> .</para>
<para > This optional property provides a device dependent mapping between
device power state and commands which the device driver sends to its
device. Also provides information concerning which device power states
are supported for each of the four domain power levels. See the device
type binding for a definition of the property value.</para>
</listitem>
</varlistentry>
</variablelist>
<section >
<title > Properties for Power Domain Control Points</title>
<para > The following are specific to devices which can act as power domain
control points.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > “ controls-power-domains” </literal> </emphasis> [S]</term>
<listitem >
<para > Standard
<emphasis > property name</emphasis> which designates the domains over which
this device exercises control.</para>
<para >
<emphasis > prop-encoded-array</emphasis> : an array of integers, each
encoded as with
<emphasis role= "bold" > <literal > encode-int</literal> </emphasis> that defines the domains for which this
device can act a power domain control point.</para>
<para > A single device may serve as multiple logical control
points.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
<section >
<title > Power Management Related Methods</title>
<para > This section defines methods associated with device tree nodes
which serve as power domain controllers (the architecture calls them
control points).</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > <literal > set-power-level</literal> </emphasis> (domain# level -- actual-level) [M]</term>
<listitem >
<para > This method is only present for power domain controllers. The
domain# is the power domain whose power level is altered, and level is
the desired level. actual-level reports the level to which the domain was
actually set.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > get-power-level</literal> </emphasis> (domain# -- level) [M]</term>
<listitem >
<para > This method is only present for power domain controllers. The
domain# is the power domain that is being queried. level is the current
level at which the domain is now operating.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > <literal > system-off</literal> </emphasis> (--) [M]</term>
<listitem >
<para > Method to turn the system off. This method is attached to the root
node of the device tree and is only present in a platform with software
control over system power.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
<section >
<title > Configuration of Platform Resources</title>
<para > Any computer platform is composed of standard components which are
invariant (platform ‘ built-in’ standard I/O and power
management), optional components which are detectable (a second processor,
for example), and configurable components which are self-identifying
(system memory, for example). Most computer platforms also provide one or
more industry standard I/O buses which allow the insertion of specialized
functional adapter cards. These buses generally support a method for
automatic identification, interrogation, and option selection of installed
adapter cards.</para>
<para > A Platform shall
also have the capability of configuring power
management resources, if power management is implemented by the platform,
as defined in
<xref linkend= "dbdoclet.50569368_25051" /> .</para>
<section xml:id= "dbdoclet.50569368_25051" >
<title > Power Management Resource Configuration</title>
<para > For a platform which supports device power management, all platform
power management related information shall be resident in the OF device
tree prior to the transfer phase of software operation (see the
definition of transfer phase in
<xref linkend= "LoPAR.Platform" /> ). Dummy devices shall be
placed in the device tree for all standard I/O bus connectors which are
not in use to provide a node to assign the slot-names, power-domains, and
power-sources properties.</para>
<para > Ultimately, the goal is that pluggable devices would not only
identify themselves to platform firmware but would also provide all
applicable power management related information. As an interim solution,
a utility shall be provided either in the platform firmware ROM or
supplied as a loadable OF utility on external media. This utility
interacts with a person to obtain power management information concerning
plug-in adapters and peripherals.</para>
<section >
<title > Power Management Information Utility</title>
<para > Any platform capable of being expanded via the addition of
power-managed devices shall provide a device power management information
utility. The purpose of the utility is to allow a person (end-user or
system developer) to enter power management related device properties of
plug-in adapters and peripherals which have no mechanism to automatically
report this information to firmware or system software. The need for this
utility will disappear as standard protocols are developed for
interrogating pluggable adapters and devices to provide power management
related information.</para>
<para > In the most general case, the devices to be added to a node
representing a standard bus or I/O port are in the form of multilevel
subtrees. The root of this subtree specifies the path to the node in the
device tree where the subtree is to be grafted.</para>
<para > The utility determines the path to the node at which to graft the
new devices by interacting with a person to receive the information. The
utility uses the
<emphasis role= "bold" > <literal > “ slot-names” </literal> </emphasis> property to identify the
location of the device for which it needs information. For example, the
utility might prompt the user with, “ Enter the name of the first
device attached to the external scsi connector labeled
‘ SCSI1’ .” </para>
<para > A data structure describing the subtree is stored in NVRAM. The
root node of this subtree contains an
<emphasis role= "bold" > <literal > “ in-graft-node” </literal> </emphasis> property which specifies
the path to the parent node where the subtree is to be grafted into the
OF device tree.</para>
<para > As adapters and devices are enhanced to support the automatic
reporting of power management information the parent node would supply a
method query-power-management-attributes which can be used by firmware to
obtain this information without the need for this utility. Any
information obtained by direct device interrogation may update that
supplied via the PM NVRAM partition.</para>
</section>
<section >
<title > PM Configuration Process</title>
<para > When the platform is booted after a configuration change and the
newly inserted adapter does not support the automatic reporting of power
management information, firmware should prompt the user asking if he
wishes to supply this information or potentially forfeit some or all of
the power management capabilities of the device.</para>
<para > The utility records the information it obtains in the NVRAM Power
Management Configuration Partition (NVRAM Signature of 0x71 and name
<emphasis > pm-config</emphasis> ). On a subsequent reboot, platform
firmware uses the information saved in NVRAM to fill out the device tree
adding new nodes and their properties, as well as adding properties and
updating the values of properties of existing device tree nodes.</para>
</section>
<section xml:id= "dbdoclet.50569368_35341" >
<title > PM Configuration Format</title>
<para > The NVRAM power management configuration partition is designed to
be accessed primarily by firmware, but the partition is designated global
and the format is specified to allow a third party to write a power
management information utility which runs on the booted OS.</para>
<para > The data field of the power management NVRAM partition shall be
defined as follows:</para>
<para > The data field is composed of a header, followed by a number of
fixed length data blocks, and finally a variable length property list
area. The length of the header and each data block is 8 bytes. The data
blocks use 16-bit integer offsets into the partition as pointers to the
data blocks and into the property list area. The base of this offset is
the beginning of the partition. This effectively limits the size of the
PM configuration area to 64 KB. If more space is required, additional PM
configuration partitions may be provided. Each pointer into the property
list area locates the start of a NULL-terminated string which represents
a list of property name/value pairs.</para>
<para > The following table specifies the format of the header:</para>
<table frame= "all" pgwide= "1" >
<title > Power Management Configuration Data Header</title>
<tgroup cols= "3" >
<colspec colname= "c1" colwidth= "20*" align= "center" />
<colspec colname= "c2" colwidth= "20*" align= "center" />
<colspec colname= "c3" colwidth= "60*" />
<thead >
<row >
<entry >
<para >
<emphasis role= "bold" > Field</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > Size</emphasis>
</para>
</entry>
<entry align= "center" >
<para >
<emphasis role= "bold" > Description</emphasis>
</para>
</entry>
</row>
</thead>
<tbody >
<row >
<entry >
<para > Version</para>
</entry>
<entry >
<para > 1 byte</para>
</entry>
<entry >
<para > Designates the version of the PM Partition data area
format</para>
</entry>
</row>
<row >
<entry >
<para > Subtree_ptr</para>
</entry>
<entry >
<para > 2 bytes</para>
</entry>
<entry >
<para > Pointer to the first data block which describes a device
subtree</para>
</entry>
</row>
<row >
<entry >
<para > Property_ptr</para>
</entry>
<entry >
<para > 2 bytes</para>
</entry>
<entry >
<para > Pointer to first data block which describes a property
list to be added to the base platform device tree</para>
</entry>
</row>
<row >
<entry >
<para > Reserved</para>
</entry>
<entry >
<para > 3 bytes</para>
</entry>
<entry >
<para > Reserved</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
<para > The PM Partition data area format value shall be 1.</para>
<para > The following table specifies the format of the data blocks:</para>
<table frame= "all" pgwide= "1" >
<title > Data Block Format</title>
<tgroup cols= "3" >
<colspec colname= "c1" colwidth= "20*" align= "center" />
<colspec colname= "c2" colwidth= "20*" align= "center" />
<colspec colname= "c3" colwidth= "60*" />
<thead >
<row >
<entry >
<para >
<emphasis role= "bold" > Field</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > Size</emphasis>
</para>
</entry>
<entry align= "center" >
<para >
<emphasis role= "bold" > Description</emphasis>
</para>
</entry>
</row>
</thead>
<tbody >
<row >
<entry >
<para > Block_type</para>
</entry>
<entry >
<para > 1 byte</para>
</entry>
<entry >
<para > Designates the data block type</para>
</entry>
</row>
<row >
<entry >
<para > Data Block Data</para>
</entry>
<entry >
<para > 7 bytes</para>
</entry>
<entry >
<para > Remainder of data block, format specific to data block
type</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
<para > Two data blocks are defined: one defining a device node and a
second defining properties to be added to the base platform device
tree.</para>
<para > The data block type field shall have the value 1 for a data block
which describes a device node. The data block type field shall have a
value 2 for a data block which describes a property.</para>
<table frame= "all" pgwide= "1" >
<title > Node Data Block Format</title>
<tgroup cols= "3" >
<colspec colname= "c1" colwidth= "20*" align= "center" />
<colspec colname= "c2" colwidth= "20*" align= "center" />
<colspec colname= "c3" colwidth= "60*" />
<thead >
<row >
<entry >
<para >
<emphasis role= "bold" > Field</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > Size</emphasis>
</para>
</entry>
<entry align= "center" >
<para >
<emphasis role= "bold" > Description</emphasis>
</para>
</entry>
</row>
</thead>
<tbody >
<row >
<entry >
<para > Block_type</para>
</entry>
<entry >
<para > 1 byte</para>
</entry>
<entry >
<para > This field shall contain the value 0x01</para>
</entry>
</row>
<row >
<entry >
<para > Prop_list_ptr</para>
</entry>
<entry >
<para > 2 bytes</para>
</entry>
<entry >
<para > Pointer to a NULL terminated string containing the
property list for this node</para>
</entry>
</row>
<row >
<entry >
<para > Child_ptr</para>
</entry>
<entry >
<para > 2 bytes</para>
</entry>
<entry >
<para > Pointer to a data block defining a child node of this
node. This pointer will be equal to 0x0000 if this node has no
children.</para>
</entry>
</row>
<row >
<entry >
<para > Sibling_ptr</para>
</entry>
<entry >
<para > 2 bytes</para>
</entry>
<entry >
<para > Pointer to a data block defining a sibling node of this
node. This pointer will be equal to 0x0000 if this node has no
siblings.</para>
</entry>
</row>
<row >
<entry >
<para > Reserved</para>
</entry>
<entry >
<para > 1 byte</para>
</entry>
<entry >
<para > Reserved</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
<table frame= "all" pgwide= "1" >
<title > Property Data Block Format</title>
<tgroup cols= "3" >
<colspec colname= "c1" colwidth= "20*" align= "center" />
<colspec colname= "c2" colwidth= "20*" align= "center" />
<colspec colname= "c3" colwidth= "60*" />
<thead >
<row >
<entry >
<para >
<emphasis role= "bold" > Field</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > Size</emphasis>
</para>
</entry>
<entry align= "center" >
<para >
<emphasis role= "bold" > Description</emphasis>
</para>
</entry>
</row>
</thead>
<tbody >
<row >
<entry >
<para > Block_type</para>
</entry>
<entry >
<para > 1 byte</para>
</entry>
<entry >
<para > This field shall contain the value 0x02</para>
</entry>
</row>
<row >
<entry >
<para > Node_path</para>
</entry>
<entry >
<para > 2 bytes</para>
</entry>
<entry >
<para > Pointer to a NULL terminated string giving the path name
of the node to which the designated property list
belongs.</para>
</entry>
</row>
<row >
<entry >
<para > Property_list_ptr</para>
</entry>
<entry >
<para > 2 bytes</para>
</entry>
<entry >
<para > Pointer to a NULL terminated string containing the
property list to be assigned to the designated node.</para>
</entry>
</row>
<row >
<entry >
<para > Reserved</para>
</entry>
<entry >
<para > 3 byte</para>
</entry>
<entry >
<para > Reserved</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
<para > The first node of a subtree shall have a
<emphasis role= "bold" > <literal > “ name” </literal> </emphasis> property equal to “ /”
and shall specify the
<emphasis role= "bold" > <literal > “ in-graft-node” </literal> </emphasis> property. The child_ptr
of this data block points to the first in a list of data blocks which
describe the nodes which make up the subtree to be grafted onto the
system tree.</para>
<para > The final area of the partition is a set of NULL terminated strings
which represent property name/value pair lists. The last string in this
area will be terminated by at least two NULL bytes. The property list for
each node shall provide all the required PM properties and their values.
These include
<emphasis role= "bold" > <literal > “ power-domains” </literal> </emphasis> ,
<emphasis role= "bold" > <literal > “ device-power-states” </literal> </emphasis> ,
<emphasis role= "bold" > <literal > “ device-state-transitions” </literal> </emphasis> ,
<emphasis role= "bold" > <literal > “ power-sources” </literal> </emphasis> ,
<emphasis role= "bold" > <literal > “ power-management-mapping” </literal> </emphasis> , and
<emphasis role= "bold" > <literal > “ controls-power-domains” </literal> </emphasis> .</para>
</section>
</section>
</section>
<section >
<title > Client Program Requirements</title>
<para > For LoPAR platforms, the client program requirements are defined in
<xref linkend= "dbdoclet.50569374_59715" /> , with the following
modifications. OF Client Programs for an LoPAR platform shall execute in
32-bit mode with an OF cell size of 1.</para>
<section >
<title > Load Address</title>
<para > The client’ s load address is specified by the value of the
<emphasis role= "bold" > <literal > load-base</literal> </emphasis> Configuration Variable. The value of
<emphasis role= "bold" > <literal > load-base</literal> </emphasis> defines the default load address for
<emphasis > client programs</emphasis> when using the
<emphasis role= "bold" > <literal > load</literal> </emphasis> method.
<emphasis role= "bold" > <literal > Load-base</literal> </emphasis> shall be a real address in real mode or a
virtual address in virtual mode. Note that this address represents the
area, within the first LMB, into which the client program file will be
read by
<emphasis role= "bold" > <literal > load</literal> </emphasis> ; it does not correspond to the addresses at
which the program will be executed. All of physical memory from
<emphasis role= "bold" > <literal > load-base</literal> </emphasis> to either the start of OF physical memory
or the end of physical memory, whichever comes first, shall be available
for loading the client program.</para>
<para >
<emphasis role= "bold" > Note:</emphasis> The load-base address represents the area into
which the client program will be read by load and does not correspond to
the address at which the program will be executed.</para>
</section>
<section >
<title > Initial Register Values</title>
<para > The “ Initial Register Values” specified in the PA
Binding (see
<xref linkend= "dbdoclet.50569374_59715" /> ) are modified as
follows:</para>
<itemizedlist >
<listitem >
<para > r3 -- shall be 0 on client program entry</para>
</listitem>
<listitem >
<para > r4 -- shall be 0 on client program entry</para>
</listitem>
</itemizedlist>
</section>
<section >
<title > I/O Devices State</title>
<para > With the exception of the stdin and stdout devices, OF shall close
all devices with the following conditions true:</para>
<para > All Devices - no DMA and not interrupting</para>
<para > Normal I/O Devices - not responding to access PCI
Adapter/Devices</para>
<para > HOST Bridges - responding to config cycles and passing through
config cycles to children</para>
<para > RTAS Devices - contract with OF to leave in state to perform
intended function</para>
</section>
<section xml:id= "dbdoclet.50569368_14286" >
<title > Client Program Format</title>
<para > The data format of a client program compliant with this
specification shall be either ELF (Executable and Linkage Format) as
defined by
<xref linkend= "dbdoclet.50569387_38836" /> , and extended by
<xref linkend= "dbdoclet.50569368_33033" /> , or PE (Portable Executable)
as defined by
<xref linkend= "dbdoclet.50569387_18190" /> . The standard ELF format
contains explicit indication as to the program's execution modes (e.g.,
32- or 64-bit, Big- or Little-Endian). LoPAR only supports the 32-bit
version (i.e., ELFCLASS32) for 32 and 64 bit platforms.</para>
<para >
<emphasis role= "bold" > Note:</emphasis> Other client program formats may be supported,
in an implementation specific manner, by an OF implementation.</para>
<para > A standard client program shall be statically linked, requiring no
relocation of the image. The program's entry point (e_entry) shall
contain the address of the first PA instruction of the client program. It
is the responsibility of the client program to establish the appropriate
value of the TOC (r2), if necessary.</para>
<para >
<emphasis role= "bold" > Note:</emphasis> The entry point is the address of the first
instruction of the client program, not that of a procedure
descriptor.</para>
<section >
<title > ELF-Format</title>
<para > This section defines how OF recognizes and prepares to execute an
ELF-Format Program.</para>
<section xml:id= "dbdoclet.50569368_33033" >
<title > ELF Note Section</title>
<para > Part of the process of loading a client program involves verifying
its environmental requirements (e.g., endian-ness and address translation
mode) against the current firmware configuration. The client’ s
endian-ness can be directly determined by examining the ELF EI-DATA
value; ELFDATA2LSB (1) implies Little-Endian while ELFDATA2MSB (2)
implies Big-Endian. However, the other client requirements (e.g., address
translation mode) are defined by means of an ELF Note Section (PT_NOTE),
pointed to by the program header. The following describes the format of
the Note Section for a client program file.</para>
<para > As defined by
<xref linkend= "dbdoclet.50569387_38836" /> , an ELF file can be
“ annotated” by means of Note Sections within the executable
file. A Note Section contains a “ header” followed by a
(possibly NULL) “ descriptor” , as follows:</para>
<informalfigure >
<mediaobject >
<imageobject role= "html" >
<imagedata fileref= "figures/PAPR-61.gif" format= "GIF"
scalefit="1" />
</imageobject>
<imageobject role= "fo" >
<imagedata contentdepth= "100%" fileref= "figures/PAPR-61.gif"
format="GIF" scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</informalfigure>
<para >
<emphasis role= "bold" > Note:</emphasis> The endian format of the values corresponds to
the endian-ness specified by the EI-DATA field of the file.</para>
<para > The format of a Note Section header can be described by an OF
struct as:</para>
<programlisting > < ![CDATA[struct \ Note Section header for OF
/L field ns.namesz \ length of ns.name, including NULL
/L field ns.descrsz
/L field ns.type
0 field ns.name \ NULL-terminated, /L padded]]></programlisting>
<section >
<title > 1275 PowerPC Note Definition</title>
<para > The ns.name field of the PowerPC OF Note Section shall be
<emphasis role= "bold" > <literal > “ PowerPC” </literal> </emphasis> ; the ns.type field n shall be
0x1275.</para>
<para > Following the Note Section header is a descriptor (desc); the
length (in bytes) of the descriptor is specified by a word in the Note
Section’ s header (descsz). The interpretation of the descriptor
depends upon the kind of Note Section in which it is contained. For the
PowerPC OF note, the format of the Note Section’ s descriptor can be
described by an OF struct, as follows:</para>
<programlisting > <![CDATA[struct \ Note Section descriptor for CHRP OF</para>
/L field ns.real-mode
/L field ns.real-base
/L field ns.real-size
/L field ns.virt-base
/L field ns.virt-size
/L field ns.load-base]]></programlisting>
<para > If the
<emphasis role= "bold" > <literal > ns.load-base</literal> </emphasis> value is not -1, then that value is
compared against the current value of the
<emphasis role= "bold" > <literal > load-base</literal> </emphasis> configuration variable. If they are equal
no further action is taken. If they are not equal then the
<emphasis role= "bold" > <literal > load-base</literal> </emphasis> configuration variable is set to the value
of
<emphasis role= "bold" > <literal > ns.load-base</literal> </emphasis> and the system is rebooted.</para>
<para >
<emphasis role= "bold" > Note:</emphasis> DATA field of the file.</para>
</section>
<section >
<title > 1275 IBM,RPA-Client-Config Note Definition</title>
<para > The ns.name field of the LoPAR Client Program Configuration Note
Section shall be
<emphasis role= "bold" > <literal > “ IBM,RPA-Client-Config” </literal> </emphasis> ; the ns.type
field shall be 0x12759999.</para>
<para > The format and requirements associated with this ELF Note Section
are designed to allow for expandability of the section definition (by
adding fields to the end of the section) while retaining forward and
backward compatibility for both the 1275 firmware and Client Program.
When the 1275 firmware code recognizes the
<emphasis role= "bold" > <literal > “ IBM,RPA-Client-Config” </literal> </emphasis> note, it creates
a property named
<emphasis role= "bold" > <literal > “ ibm,rpa-client-config” </literal> </emphasis> within the
<emphasis role= "bold" > <literal > /chosen</literal> </emphasis> node reads into this property and interprets
the lesser of the descriptor size or the maximum size of the descriptor
that was defined when the firmware was built. Should the note contain a
smaller descriptor than was defined when the firmware was built, the
firmware assumes default values for the missing descriptor fields. In
this way, new fields may be defined, and the four cases of
firmware/client program work as follows:</para>
<para > New Firmware/New Client Program:</para>
<para > Client Program Header Note contains old plus new fields.</para>
<para > Firmware reads all the new header and places it in
<emphasis role= "bold" > <literal > “ ibm,rpa-client-config” </literal> </emphasis> property.</para>
<para > Client Program gets feed back that new fields were interpreted by
reading property in
<emphasis role= "bold" > <literal > /chosen</literal> </emphasis> .</para>
<para > Old Firmware/Old Client Program:</para>
<para > Client Program Header Note contains old fields.</para>
<para > Firmware reads all the old definition header and places it in
<emphasis role= "bold" > <literal > “ ibm,rpa-client-config” </literal> </emphasis> property.</para>
<para > Client Program gets feed back that the expected fields were
interpreted by reading property in
<emphasis role= "bold" > <literal > /chosen</literal> </emphasis> .</para>
<para > New Firmware/Old Client Program:</para>
<para > Client Program Header Note contains only old fields.</para>
<para > Firmware reads only the descriptor length defined in the note
header, and places it in
<emphasis role= "bold" > <literal > “ ibm,rpa-client-config” </literal> </emphasis> property.</para>
<para > Client Program gets feed back on the fields that were interpreted
by reading property in
<emphasis role= "bold" > <literal > /chosen</literal> </emphasis> .</para>
<para > Firmware uses default values for any missing fields.</para>
<para > Old Firmware/New Client Program:</para>
<para > Client Program Header Note contains old plus new fields.</para>
<para > Firmware reads only the length that it was defined when it was
built, and places it in
<emphasis role= "bold" > <literal > “ ibm,rpa-client-config” </literal> </emphasis> property.</para>
<para > Client Program gets feed back that new fields were interpreted by
reading property in
<emphasis role= "bold" > <literal > /chosen</literal> </emphasis> , those missing fields indicate function not
implemented by the platform.</para>
<para > Following the Note Section header is a descriptor (desc); the
length (in bytes) of the descriptor is specified by a word in the Note
Section’ s header (descsz). The interpretation of the descriptor
depends upon the kind of Note Section in which it is contained. For the
ELF header note named <emphasis role= "bold" > <literal > IBM,RPA-Client-Config</literal> </emphasis> of type 1275, the format of
the Note Section’ s descriptor can be described by an OF struct, as
follows:</para>
<programlisting > < ![CDATA[struct \ Note Section descriptor for OF
/L field ns.lparaffinity \= “0/1” (default assumption to be “N”)
/L field ns.min-rmo-size \Minimum size of the Real Mode Accessible Storage
\ Area in MB
/L field ns.min-rmo-percent \Minimum percentage of total storage that must be
\ Real Mode Accessible
/L field ns.max-pft-size \Maximum size of the hardware page frame table as
\ a power of 2
/L field ns.splpar \= “0/1” (default assumption to be “N”)
/L field ns.min-load \The minimum amount of code that must be loaded at
\ load-base.
\ (default value -1)
/L field ns.new-mem-def \Flag to indicate use of
\ ibm,dynamic-reconfiguration-memory definition.
\ (default value 0)
/L field ns.ignore-my-client-config \Flag: 1 = do not change boot configuration
\ variables based upon the values in this
\ header.
\ (default value 0)
/L field ns.large-page-ready \Flag to indicate the partition OS is prepared for
\ large pages.
/L field ns.force_alpha_mode]]></programlisting>
<para > <emphasis role= "bold" > Note:</emphasis> The size of the /L field is based off of
e_ident (EI_CLASS) i.e. is 4 for ELFCLASS32.</para>
<para > The
<emphasis role= "bold" > <literal > ns.lparaffinity</literal> </emphasis> field is a binary flag whose valid
values are 0 or 1. If the field is not one of these valid values the
value is assumed to be 0. If the character value is 1, the client program
requests that the platform provide all available affinity
information.</para>
<para > The
<emphasis role= "bold" > <literal > ns.min-rmo</literal> </emphasis> field specifies the minimum amount of real
mode addressable storage (in bytes times 2
<emphasis > 20</emphasis> ) that the client program needs to operate. The
<emphasis role= "bold" > <literal > ns.min-rmo-percent</literal> </emphasis> field specifies the minimum
percentage (valid values 0-100) of storage that must be real mode
addressable for the client program to operate. The platform shall start
the client program with a quantity of real mode accessible storage
(starting at location 0) of at least the ceiling of these two
values.</para>
<para > The
<emphasis role= "bold" > <literal > ns.max-pft-size</literal> </emphasis> field value specifies the largest
hardware Page Frame Table (in bytes times</para>
<para > 2
<emphasis role= "bold" > <literal > ns.max-pft-size</literal> </emphasis> ) that the client program can
support. The firmware shall not start a client program with a PFT larger
than this amount The minimum value is 18, the platform ignores the field
if the value is less than 18 and uses the platform defined default
value.</para>
<para > The
<emphasis role= "bold" > <literal > ns.splpar</literal> </emphasis> field is a binary flag whose valid values
are 0 or 1. If the field is not one of these valid values the value is
assumed to be 0. If the field’ s value is 1, the client program
supports running in shared processor logical partitioning mode. If the
character value is not 1 and the partition is running in shared processor
mode, platform firmware reports a platform-specific error code and halts
the boot. However, if the client-program does not contain an
<emphasis role= "bold" > <literal > IBM,RPA-Client-Config</literal> </emphasis>
note, firmware assumes the OS supports shared
processor logical partition mode. This exception only applies to the
<emphasis role= "bold" > <literal > ns.slpar</literal> </emphasis> field.</para>
<para > The
<emphasis role= "bold" > <literal > ns.min-load</literal> </emphasis> field specifies the minimum amount of the
client program load module that must be loaded at
<emphasis role= "bold" > <literal > load-base</literal> </emphasis> . If this value is a -1 then the entire
load module must be loaded starting at
<emphasis role= "bold" > <literal > load-base</literal> </emphasis> else the client program load fails. The
default value is assumed to be -1. If the value of is greater than the
platform can support client program load fails. Given that the platform
can load the minimum amount of the client program load module at
<emphasis role= "bold" > <literal > load-base</literal> </emphasis> , it loads the amount up to the boundary
specified by
<emphasis role= "bold" > <literal > ns.min-load</literal> </emphasis> starting at
<emphasis role= "bold" > <literal > load-base</literal> </emphasis> , then it loads the rest of the load module
into contiguous storage at a location selected by platform firmware
(default, if possible, is that the residual is loaded immediately
following the first segment resulting in a single segment load).</para>
<para > The
<emphasis role= "bold" > <literal > ns.new-mem-def</literal> </emphasis> field is a flag which indicates if the
ibm,dynamic-reconfiguration-memory representation of reconfigurable
memory may be used. The default value 0x00000000 indicates the new
definition may not be used. The value 0x00000001 indicates the new
definition may be used. The value 0x00000001 indicates the original version of the new definition may be used.
The value 0x00000002 indicates the version 2 of the new definition may be used.
All other values are reserved for future use.</para>
<para > The
<emphasis role= "bold" > <literal > ns.large-page-ready</literal> </emphasis> field is a flag which indicates
if the partition OS is prepared to support large pages. The default value
0x00000000 indicates that the OS is not prepared for large pages. The
value 0x00000001 indicates that the OS is prepared for large pages. All
other values are reserved for future use.</para>
<para > If this variable indicates that the OS is not prepared for large
pages and large pages are present in the partition configuration,
platform firmware reports a platform-specific error code which indicates
this mismatch between the partition configuration and the OS
capabilities, removes all large pages from the device tree, and continues
the OS boot.</para>
<para > If the value of the
<emphasis role= "bold" > <literal > ns.ignore-my-client-config</literal> </emphasis> variable is 0x00000001,
platform firmware must not examine the value of
<emphasis role= "bold" > <literal > ns.large-page-ready</literal> </emphasis> until the client program calls
the PROCESS-ELF-HEADER method. The decision to continue boot should then
be made based on the value of the
<emphasis role= "bold" > <literal > ns.large-page-ready</literal> </emphasis> flag in the updated ELF head
passed by this method.</para>
<para > The
<emphasis role= "bold" > <literal > ns.force_alpha_mode</literal> </emphasis> field is a flag which indicates
that a non-HMC managed I/O services partition with partition management
support (VMC) configuration is being requested. The default value of
0x00000000 indicates that the client expects to run in a configuration
which is not an I/O services partition configuration. If the partition
configuration is not compatible with this setting, the system will be
rebooted as a single partition which owns all of the system resources. On
reboot, the original partition configuration will be reinstated. The
value 0x0000001 indicates that the client is expecting to be executed in
a non-HMC managed I/O services partition with partition management
support (VMC). If the partition is not in this mode, the system will be
rebooted in this mode. In the case that the ns.force_alpha_mode flag is
compatible with the partition configuration, the boot process will
continue. This flag will be ignored when the system is HMC
managed.</para>
</section>
</section>
<section xml:id= "dbdoclet.50569368_24653" >
<title > Recognizing ELF-Format Programs</title>
<para > The
<emphasis role= "bold" > <literal > init-program</literal> </emphasis> shall recognize client program images
that conform to all the requirements listed below as
“ ELF-format” programs.</para>
<para > In the description below, field names refer to fields within the
ELF “ file header” structure, which is assumed to begin at
load-base, and offsets are relative to the beginning of that structure.
Multi-byte numerical fields are interpreted according to the endianess
specified by the “ data” field at offset 5.</para>
<orderedlist numeration= "loweralpha" >
<listitem >
<para > The “ e_ident” field (at offset 0) contains the
string “ \7fELF” , where '\7f'’ is a byte whose value is
(hex) 7f. This indicates the beginning of an ELF file header.</para>
</listitem>
<listitem >
<para > The “ EI_CLASS” field (at offset 4) contains the
value 1. This indicates the 32-bit variant of the ELF format.</para>
</listitem>
<listitem >
<para > The “ e-type” field (at offset 16) contains the
value 2. This indicates that the ELF image is executable.</para>
</listitem>
<listitem >
<para > The “ e_machine” field (at offset 18) contains the
value 20. This indicates that the ELF image is for the PA instruction
set.</para>
</listitem>
<listitem >
<para > The “ e_version” field (at offset 20) contains the
value 1.</para>
</listitem>
<listitem >
<para > The “ e_flags” field (at offset 36) contains the
value 0.</para>
</listitem>
</orderedlist>
</section>
<section xml:id= "dbdoclet.50569368_30006" >
<title > Preparing ELF-Format Programs for Execution</title>
<para > Upon recognition of the client program image at load-base as an
ELF-format program, init-program shall prepare the program for execution
by performing the following sequence of steps.</para>
<para > In the description below, the fields mentioned by name are within
ELF “ program header” structures, unless specified
otherwise.</para>
<orderedlist numeration= "loweralpha" >
<listitem >
<para > Search for an ELF “ note” section of type
“ 1275” as defined in the section “ ELF Note
Section” . If one is found, and the values specified by its
descriptor do not match the firmware's current operating mode, set the
appropriate configuration variables to the values specified in the note
section descriptor, and restart the firmware so that it will re-execute
the
<emphasis role= "bold" > <literal > boot</literal> </emphasis> command that resulted in the execution of
<emphasis role= "bold" > <literal > init-program</literal> </emphasis> .</para>
</listitem>
<listitem >
<para > Set the p_paddr field for each PT_LOAD segment equal to its
p_vaddr field value if
<emphasis > real-mode?</emphasis> is false and p_paddr is -1. This
effectively maps these segments v=r.</para>
</listitem>
<listitem >
<para > Allocate and map, if required, sufficient physical memory for
all program segments of type PT_LOAD (i.e. whose “ p_type”
field contains the value 1) listed in the ELF image's program headers.
Note that all PT_LOAD program segments that have a p_paddr value that
matches their location in physical memory need not be moved, but the
memory that they occupy must be claimed. This special case is added to
allow large program images to be loaded without the 2x memory required to
move the segments.</para>
</listitem>
<listitem >
<para > Copy the program headers to a “ safe” location to
guard against the possibility of them being overwritten by the following
steps.</para>
</listitem>
<listitem >
<para > For each program segment of type “ PT_LOAD” :</para>
<orderedlist >
<listitem >
<para > Copy, if required, the initialized portion of the program
segment from its current location in the loaded image to the location
given by the section's “ p_paddr” field.</para>
</listitem>
<listitem >
<para > Fill the rest of the segment with zero bytes (i.e., fill
“ p_memsz - p_filez” bytes beginning at the address
“ p_paddr + p_filesz” ).</para>
</listitem>
<listitem >
<para > If <emphasis > real-mode?</emphasis> is false, then map the program segment to
the virtual address specified by p_vaddr.</para>
</listitem>
</orderedlist>
</listitem>
<listitem >
<para > Set the saved program state so that subsequent execution of
<emphasis role= "bold" > <literal > “ go” </literal> </emphasis> will begin execution at the address
given by the “ e_entry” field in the ELF file header. The
e_entry field is a physical address if
<emphasis > real-mode?</emphasis> is
<emphasis role= "bold" > <literal > TRUE</literal> </emphasis> and is a virtual address if
<emphasis > real-mode?</emphasis> is
<emphasis role= "bold" > <literal > false</literal> </emphasis> .</para>
</listitem>
</orderedlist>
<para > The implementation need not take precautions to ensure that the
process of copying and zeroing program segments does not overwrite the
portions of the load image that have not yet been copied. In order to
guarantee correct copying, the value of the
<emphasis role= "bold" > <literal > load-base</literal> </emphasis> configuration variable and the destination
addresses of the various sections must be such that such overwriting does
not occur. One sufficient condition is that the region of memory
beginning at
<emphasis role= "bold" > <literal > load-base</literal> </emphasis> , of size equal to the size of the loaded
image, be disjoint from the regions of memory to which the program
segments are copied and zero-filled. Another sufficient condition is to
specify a
<emphasis role= "bold" > <literal > load-base</literal> </emphasis> in the Notes Section (PT_NOTE) that ensures
that the PT_LOAD segments are loaded at the address required by their
program headers and thus are not moved. There are other less-stringent
sufficient conditions, especially for simple ELF images with a small
number of program segments that are to be copied to contiguous
regions.</para>
<para > An implementation shall permit the ELF image to contain other
program segments in addition to those described above, but need not take
any action beyond that defined above as a result of the presence of such
other program segments.</para>
<para > An implementation shall ignore all ELF sections. ELF sections are
intended for binders, not loaders. Note that the CHRP ELF Note Section is
actual an ELF segment of type PT_NOTE and thus the above does not apply
to it.</para>
</section>
</section>
</section>
<section >
<title > Additional Client Interface Requirements</title>
<para > This section describes processor assist callbacks for real and
virtual memory management and a service.</para>
<section >
<title > Client Interface Callbacks</title>
<para > This section describes callbacks for memory management. These
callbacks are provided by the client.</para>
<section xml:id= "dbdoclet.50569368_11616" >
<title > Real-Mode Memory Management Assist Callbacks</title>
<variablelist >
<varlistentry >
<term > claim_mem</term>
<listitem >
<para > IN: [address] min_addr, [address] max_addr, size, align</para>
<para > OUT: throw-code, error, [address] real_addr</para>
<para > Allocate contiguous physical memory between min_addr and max_addr
of size bytes (128KB max for an area in the 0 to 16MB address range),
with align alignment. The alignment boundary is the smallest power of two
greater than or equal to the value of align; an align value of 1
signifies one-byte alignment. A non-zero error code shall be returned if
the mapping cannot be performed. If error code is zero (i.e. allocation
succeeded) the routine returns the real address (real_addr) of the
physical memory block which was allocated for OF.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > release_mem</term>
<listitem >
<para > IN: [address] phys, size</para>
<para > OUT: throw-code</para>
<para > Free size bytes of physical memory starting at real address phys,
making that physical memory available for later use. That memory must
have been previously allocated by claim_mem.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id= "dbdoclet.50569368_11616.1" >
<title > Virtual Address Translation Assist Callbacks</title>
<variablelist >
<varlistentry >
<term > alloc_virt_mem</term>
<listitem >
<para > IN: size</para>
<para > OUT: throw-code, error, [address] virt_addr</para>
<para > Return the virtual address of a virtual memory area of size bytes
aligned to a doubleword (8-byte) boundary. A non-zero error code shall be
returned if the allocation cannot be performed. If error code is zero
(i.e. allocation succeeded) the routine returns the virtual address
(virt_addr) of the memory block which was allocated.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > free_virt_mem</term>
<listitem >
<para > IN: [address] virt_addr, size</para>
<para > OUT: throw-code</para>
<para > Free memory allocated by alloc_virt_mem. The values virt_addr and
size must correspond with memory previously allocated by
alloc_virt_mem.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > claim_virt</term>
<listitem >
<para > IN: size, align</para>
<para > OUT: throw-code, error, [address] virt_addr</para>
<para > Allocate a memory area of size bytes and alignment align. The
alignment boundary is the smallest power of two greater than or equal to
the value of align; an align value of 1 signifies one-byte alignment. A
non-zero error code shall be returned if the allocation cannot be
performed. If error code is zero (i.e. allocation succeeded) the routine
returns the virtual address (virt_addr) of the memory block which was
allocated.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > release_virt</term>
<listitem >
<para > IN: [address] virt, size</para>
<para > OUT: throw-code</para>
<para > Free size bytes of virtual memory starting at virtual address virt,
making that physical memory and the corresponding ranges of virtual
address space available for later use. That memory must have been
previously allocated by claim_virt.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
<section xml:id= "dbdoclet.50569368_25059" >
<title > Client Interface Services</title>
<para > OF shall provide the following
<emphasis > Client Interface Service</emphasis> :</para>
<variablelist >
<varlistentry >
<term > test-method</term>
<listitem >
<para > IN: phandle, [string] method</para>
<para > OUT: missing-flag?</para>
<para > Tests whether the package method named method exists in the package
phandle. missing-flag? is FALSE (0) if the method exists or TRUE (-1) if
the method does not exist.</para>
</listitem>
</varlistentry>
</variablelist>
<para > OF may provide the following Client Interface Service:</para>
<variablelist >
<varlistentry >
<term > ibm,enable-ci64</term>
<listitem >
<para > IN: none</para>
<para > OUT: none</para>
<para > After the successful invocation of this method, all Client
Interface calls will utilize 64 bit cell items in their argument arrays.
This does not affect how the device tree is presented, which will still
assume that a cell is 32 bit in the property values. The method returns
using the cell size in which it was called. This method exists only on
platforms that present the
<emphasis role= "bold" > <literal > “ ibm,enable-ci64-capable” </literal> </emphasis> property in the
<emphasis > root</emphasis> node.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
</section>
<section xml:id= "dbdoclet.50569368_19625" >
<title > Support Packages</title>
<para > This section describes the LoPAR Binding specific requirements of OF
support packages. These support packages are
<emphasis role= "bold" > <literal > disk-label</literal> </emphasis> and
<emphasis role= "bold" > <literal > tape-label</literal> </emphasis> . For “ network” and/or
<emphasis role= "bold" > <literal > obp-tftp</literal> </emphasis> extensions, refer to
<xref linkend= "dbdoclet.50569387_33177" /> . These packages support the
loading and executing of a client program. Another means of executing a
Client Program is provided when an OS ROM is a “ bootable
device” (Refer to
<xref linkend= "dbdoclet.50569368_40198" /> , as an example).</para>
<section >
<title > “ disk-label” Support Package</title>
<para > The process of loading and executing a client program is described
in two stages. The first stage determines what partition and/or file (if
one exists) to read into memory. This is done by locating a partition and
a file within the partition (if the partition supports a file system
structure) from the boot device, usually by means of a name lookup within
a directory contained within a disk “ partition” . The second
stage examines the front portion (header) of the image for
“ well-known” program formats. When the format of the image
has been determined, the loading is completed in a manner determined by
that format.</para>
<para > The name of the partition (and, a file contained within the
partition) can be explicitly specified by the user via the
<emphasis role= "bold" > <literal > load</literal> </emphasis> or
<emphasis role= "bold" > <literal > boot</literal> </emphasis> command, or can be implicitly specified by the
value of the
<emphasis role= "bold" > <literal > “ boot-device” </literal> </emphasis>
property of the
<emphasis role= "bold" > <literal > /options</literal> </emphasis> node. The partition and filename are the
ARGUMENTS portion of the final COMPONENT of the PATH_NAME, as described
in section 4.3.1 of
<xref linkend= "dbdoclet.50569387_45524" /> .</para>
<para > The syntax for explicit partition/filename specification is given
in section
<xref linkend= "dbdoclet.50569368_88157" /> below where partition
identifies the partition to be used and filename is the name of a file
within that partition. If partition is omitted, the default partition (as
determined by the partition format) is used. If filename is omitted, the
default filename (i.e., the filename component of the
<emphasis role= "bold" > <literal > boot-device</literal> </emphasis> path-name) is used.</para>
<section >
<title > Media Layout Format</title>
<para > This section describes the media layout formats of Client Program
Images that the disk-label support package for an LoPAR platform shall
support; an implementation
<emphasis > may</emphasis> support additional mechanisms, in an
implementation-specific manner. The
<emphasis role= "bold" > <literal > disk-label</literal> </emphasis> package for a platform shall
support at least four(4) media layout types:</para>
<itemizedlist >
<listitem >
<para > FAT (FAT12 and FAT16 File System)</para>
</listitem>
<listitem >
<para > FDISK (Partitions 4, 5, 6, 0x41 and 0x96)</para>
</listitem>
<listitem >
<para > ISO-9660 (9660 File System)</para>
</listitem>
<listitem >
<para > UDF</para>
</listitem>
</itemizedlist>
<para > An LoPAR platform may choose to support the following media layout
formats for historic reasons:</para>
<itemizedlist >
<listitem >
<para > Mac OS (MAC Binary Image)</para>
</listitem>
</itemizedlist>
<section >
<title > FDISK Partition Types</title>
<para > The following FDISK partition types shall be supported:</para>
<itemizedlist >
<listitem >
<para > Partition Type 4: FAT 12 or FAT 16 File System</para>
</listitem>
<listitem >
<para > Partition Type 5: Extended Chained Partitions</para>
</listitem>
<listitem >
<para > Partition Type 6: Extended Partitions</para>
</listitem>
<listitem >
<para > Partition Type 0x41: Single program image</para>
</listitem>
<listitem >
<para > Partition Type 0x96: ISO 9660 File System</para>
</listitem>
<listitem >
<para > Partition Type 0x??: UDF File System</para>
</listitem>
</itemizedlist>
<para > FDISK partition type 0 is a free partition. Partition type 0x82 is
reserved and should not be used by this architecture.</para>
</section>
</section>
<section xml:id= "dbdoclet.50569368_88157" >
<title > Open Method Algorithm</title>
<para > The
<emphasis role= "bold" > <literal > open</literal> </emphasis> method of the
<emphasis role= "bold" > <literal > disk-label</literal> </emphasis> support package shall implement a disk
partition recognition algorithm that supports at least the set of disk
formats that are supported by the following algorithm. The following
algorithm is intended to support raw (uninterpreted) disks, raw
partitions of disks beginning with an FDISK partition map, and files on
FAT, UDF and ISO-9660 file systems both within FDISK partitions and by
themselves on disks without a partition map.</para>
<para > That
<emphasis role= "bold" > <literal > open</literal> </emphasis> method shall accept an argument string (as
returned by
<emphasis role= "bold" > <literal > “ my-args” </literal> </emphasis> ) with the following syntax
(according to the algorithm below), where brackets denote an optional
component:</para>
<para > [partition][,[filename]]</para>
<para > If the argument string contains a comma, or if the argument string
begins with a decimal digit, the partition component is deemed to be
present. Note that the arguments above are not the client arguments with
the boot command.</para>
<para > If the partition component is present, it selects the desired
partition, where partition 0 refers to the entire disk, partition 1
refers to the first partition, partition 2 to the second, and so forth.
If the partition component is absent and the disk has an FDISK or Mac
partition map, the first “ bootable” partition is used. If a
“ bootable” partition is not found, then fail in an
implementation specific manner with an error.</para>
<para > If the filename component is present, it selects a particular file
within the file system on the disk or partition thereof.</para>
<para >
<emphasis role= "bold" > Note:</emphasis> For historic reasons, the following algorithm
includes support for the optional MAC OS media layout format.
<programlisting > < ![CDATA[1 OPEN algorithm
2 Set D.SIZE to -1
2 If ARGUMENT$ is not the NULL string and the first character of ARGUMENT$
is in the range '0'--'9' or is equal to ','
3 LEFT-PARSE (ARGUMENT$) -> PARTITION$, FILENAME$
2 Else
3 Set PARTITION$ to the NULL string
3 Set FILENAME$ to ARGUMENT$
2 If PARTITION$ is not the NULL string
3 If PARTITION$ is not a decimal number
4 Return FALSE
3 DECIMAL_STRING_TO_NUMBER (PARTITION$) -> PARTITION
3 If PARTITION is 0
4 GET_DISK_SIZE
3 Else
4 Read the first 512 bytes of the device into a buffer
4 SELECT_EXPLICIT_PARTITION (PARTITION)
4 If SELECT_EXPLICIT_PARTITION returned an error indication
5 Return FALSE
2 Else \ PARTITION$ is NULL
3 Read the first 512 bytes of the device into a buffer
3 SELECT_ACTIVE_PARTITION
3 If SELECT_ACTIVE_PARTITION returned an error indication
4 Return FALSE
2 \ (At this point, D.OFFSET is set to the beginning of the selected
partition and D.SIZE is set to the size of that partition. If the
entire disk was selected, D.OFFSET is 0 and D.SIZE is the size of the disk.)
2 Call parent’
2 Return TRUE
1 CHECK_FOR_BPB procedure
2 If the first four(4) bytes are EBCDIC 'IBMA'(hex character string
C9C2D4C1), then the sector does not contain a BPB.
2 If the 16-bit little-endian quantity beginning at buffer offset 510
is 0xAA55, and the 16-bit little-endian quantity beginning at buffer
offset 11 (which is the BPB “bytes per sector” field) is either 256,
512, or 1024, and the byte at offset 16 (the BPB “number of FATs” field
is either 1 or 2, the sector is deemed to contain a BPB. Otherwise, the
sector does not contain a BPB.
1 CHECK_FOR_ISO_9660 procedure
2 Read 512-byte sector 64 (the beginning of logical 2048-byte sector 16)into
a buffer.
2 If the byte at offset 0 contains the binary number “1”, and the 5 bytes
beginning at offset 1 contains the text string “CD001”, the partition
or raw disk is deemed to contain an ISO 9660 file system. Otherwise,
the partition or raw disk is deemed not to contain an ISO 9660 file system.
1 CHECK_FOR_FDISK procedure
2 If the buffer does not contain an FDisk partition map signature of “AA55”
as a 16-bit little-endian number beginning at buffer offset 510, the buffer
is deemed not to contain an FDISK partition map.
2 If none of the partition type code field (the bytes at buffer offsets 0x1C2,
0x1D2, 0x1E2, and 0x1F2) contains a recognizable partition type code (4,5,
6, 0x41, 0x96, or other types that may be recognized by the implementation),
the buffer is deemed not to contain an FDISK partition map.
2 Otherwise, the buffer is deemed to contain an FDISK partition map.
2 The implementation may, at its option, apply additional validity tests to
the partition map information.
1 CHECK_FOR_MAC_DISK procedure
2 If the first (i.e., at the lowest offset) two bytes in the buffer contains
the 16-bit big-endian signature 0x4552, then the disk is deemed to be a Mac
partitioned disk. Otherwise, the partition or raw disk is deemed not to be
a Mac partitioned disk.]]></programlisting> </para>
<para >
<emphasis role= "bold" > Note:</emphasis> Subsequent 512 byte sectors will contain Mac
partition map entries, each of which begins with the 16-bit big-endian
signature 0x504D. Each such partition map entry contains a field (V)
indicating the total number of partition entries in the map.</para>
<para > <programlisting > < 
3 Else
4 If PARTITION-TYPE is FAT,
5 INTERPOSE (FAT File System package, FILENAME$)
1 SELECT_ACTIVE_PARTITION (PARTITION) procedure
2 CHECK_FOR_BPB
3 If the buffer contains a BPB
4 Set OFFSET to 0
4 Set D.SIZE to the maximum size of the disk in bytes, as indicated by the
information in the BIOS Parameter Block
4 If FILENAME$ is not the NULL string
5 INTERPOSE (FAT File System package, FILENAME$)
4 Return OKAY
2 CHECK_FOR_FDISK
2 If the buffer contains an FDISK partition map
3 Search the FDisk partition map, reading new 512-byte sectors into the
buffer if necessary to “chain” to extended partition entries (i.e. ones
whose type byte at offset 4 contains “5”) for the first (i.e., at the lowest
offset) partition entry whose “bootable” field (at offset 0 in the partition
entry) contains 0x80.
3 If a “bootable” partition was found:
4 Set PARTITION-TYPE to that entry's “type” field (the byte at offset 4)
4 Set D.OFFSET to the byte offset from the beginning of the disk of the
beginning of the partition denoted by that entry.
4 Set D.SIZE to the size of the partition denoted by that entry.
4 INTERPOSE_BY_TYPE
4 Return OKAY
\ (If this point is reached, no partition was marked “bootable”)
3 Search the FDisk partition map beginning in 512-byte sector 0,reading new
512-byte sectors into the buffer if necessary to “chain” to extended
partition entries, for the first partition (i.e., at the lowest offset)
entry whose “type” byte is neither 0 nor 5 (5 is the type code that
indicates a “chained” extended partition entry).
3 If one is found:
4 Set PARTITION-TYPE to that entry's “type” field (the byte at offset 4)
4 Set D.OFFSET to the byte offset from the beginning of the disk of the
beginning of the partition denoted by that entry.
4 Set D.SIZE to the size of the partition in bytes denoted by that entry.
4 INTERPOSE_BY_TYPE
4 Return OKAY
3 Else \ (If this point is reached, the partition map did not contain any
valid partition entries)
4 Return ERROR
2 CHECK_FOR_ISO_9660
2 If it is an ISO 9660 disk
3 GET_DISK_SIZE
3 If FILENAME$ is not the NULL string
4 INTERPOSE (ISO-9660 File System package, FILENAME$)
3 Return OKAY
2 CHECK_FOR_MAC_DISK
2 If this is a Mac partitioned disk
3 Search the Mac partition table for the first “bootable” partition. A
partition is “bootable” when the pmPartStatus flags indicate that this is a
valid, allocated, readable and bootable partition and the pmProcessor field
contains “powerpc” (using case-insensitive matching).
3 If a Mac “bootable” partition is found
4 If FILENAME$ is “%BOOT”
5 If the Nth partition is marked bootable
6 Set D.OFFSET to the byte offset from the beginning of the disk
to the beginning of the boot area, as given by the pmLgBootStart
field.
6 Set D.SIZE to the size of the partition in bytes denoted by
pmBootSize.
6 Return OKAY
4 Else
5 If the FILENAME$ is the NULL string
6 Set D.OFFSET to the byte offset of the “real” partition data
6 Set D.SIZE to the size of the “real” partition data
5 Else
7 INTERPOSE_BY_TYPE
5 Return OKAY
3 Else
4 Return ERROR
3 (If this point is reached, no “bootable” partition was found)
3 Return ERROR
1 GET-DISK-SIZE procedure
2 Set OFFSET to 0
2 If the parent has a “#blocks” method
3 Execute the parent's “#blocks” and “block-size” methods
3 Set D.SIZE to the product of the numbers they returned
2 Else
3 Set D.SIZE to -1
1 SELECT_EXPLICIT_PARTITION procedure
2 CHECK_FOR_BPB
2 If the buffer contains a BPB
3 If PARTITION is 1
4 Set OFFSET to 0
4 Set D.SIZE to the maximum size of the disk in bytes, as indicated by the
information in the BIOS Parameter Block
4 If FILENAME$ is not the NULL string
5 INTERPOSE (FAT File System package, FILENAME$)
4 Return OKAY
3 Else \ Have a BPB, but PARTITION < > 1
4 Return ERROR
2 CHECK_FOR_FDISK
2 If an FDisk partition map is found
3 Search the FDisk partition map beginning in 512-byte sector 0, reading new
512-byte sectors into the buffer if necessary to “chain” to extended
partition entries, for the Nth, where N is the value of PARTITION, partition
entry whose “type” byte is neither 0 nor 5 (5 is the type code that
indicates a “chained” extended partition entry).
3 If the Nth partition is found:
4 Set PARTITION-TYPE to that entry's “type” field (the byte at offset 4)
4 Set D.OFFSET to the byte offset from the beginning of the disk to the
beginning of the partition denoted by that entry.
4 Set D.SIZE to the size of the partition in bytes denoted by that entry.
4 INTERPOSE_BY_TYPE
4 Return OKAY
3 Else \Nth partition does not exist
4 Return ERROR
2 CHECK_FOR_MAC_DISK
2 If this is a Mac partitioned disk
3 Search the Mac partition map for the Nth partition, where N is the value of
PARTITION.
3 If the Nth partition is valid, allocated, and readable
4 If FILENAME$ is %BOOT
5 If the Nth partition is marked bootable
6 Set D.OFFSET to the byte offset from the beginning of the disk
to the beginning of the boot area, as given by the pmLgBootStart
field.
6 Set D.SIZE to the size of the partition in bytes denoted by
pmBootSize.
6 Return OKAY
5 Else \Nth partition not “bootable”
6 Return ERROR
4 Else
5 If FILENAME$ is not the NULL string
6 INTERPOSE_BY_TYPE
5 Return OKAY
3 Else \ (If this point is reached, the partition is invalid)
4 Return ERROR
2 Else \ (If this point is reached, the partition map is not recognized)
3 Return ERROR]]></programlisting> </para>
<para > This algorithm can be used to locate the correct partition and/or
file and/or load image from the specified device. The boot device is
selected as described in 7.4.3.2 of
<xref linkend= "dbdoclet.50569387_45524" /> . A filename can be explicitly
given as the arguments field of the
<emphasis > device-specifier</emphasis> (i.e., the field following the ':'
of the last path component). Other formats
<emphasis > may</emphasis> be recognized in an implementation-specific
manner.</para>
</section>
</section>
<section >
<title > tape-label Support Package</title>
<para > The
<emphasis role= "bold" > <literal > tape-label</literal> </emphasis> Support Package shall
support tape as a standard byte device with the set
of methods specified in
<xref linkend= "dbdoclet.50569387_45524" /> , Section 3.7.3. Presence of
the bootinfo.txt file is optional.</para>
<para > The
<emphasis role= "bold" > <literal > open</literal> </emphasis> method shall accept an argument string, where
brackets denote an optional component:</para>
<para > [file number]</para>
<para > where the first file on the tape media is located at file number
0.</para>
<section >
<title > Tape Format</title>
<para > The LoPAR tape format shall consist of files ending with a file
mark (FM). The first block of data will be identified as file 0. The
bootinfo.txt file, if present, shall be located on the tape as file 0
(the first file). There shall be only one bootinfo.txt file on the tape
media. Refer to
<xref linkend= "dbdoclet.50569368_35854" /> for the LoPAR Tape
format.</para>
<figure pgwide= "1" >
<title > Tape Boot Format</title>
<mediaobject >
<imageobject role= "html" >
<imagedata fileref= "figures/PAPR-62.gif" format= "GIF"
scalefit="1" />
</imageobject>
<imageobject role= "fo" >
<imagedata contentdepth= "100%" fileref= "figures/PAPR-62.gif"
format="GIF" scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</figure>
</section>
<section xml:id= "dbdoclet.50569368_35854" >
<title > Tape bootinfo.txt File</title>
<para > The bootinfo.txt file shall have included for each set
of <emphasis role= "bold" > <literal > < chrp-boot> </literal> </emphasis> tags a set of <emphasis role= "bold" > <literal > < boot-script> </literal> </emphasis> tags that contains
a pointer to the program image to be loaded (Refer to
<xref linkend= "dbdoclet.50569368_26165" /> ). The form for this tape
pointer will be:</para>
<para > device specifier = <emphasis > device</emphasis> :<emphasis > file number</emphasis> </para>
<para > EXAMPLE: device specifier = tape:2 (For the specified set of
<emphasis role= "bold" > <literal > < chrp-boot> </literal> </emphasis> tags, load the tape program image from file 2).</para>
<para > A bootinfo.txt file may contain a multiple set of <emphasis role= "bold" > <literal > < chrp-boot> </literal> </emphasis>
tags where each one can point to a different tape file number. If a
bootinfo.txt file is not present, file 0 should be a bootable file. Only
file 0 will be loaded as a bootable image. No other files will be
searched if a bootinfo.txt file is not present unless the file number to
load is specified by an argument.</para>
</section>
</section>
<section >
<title > network Support Package</title>
<para > The
<emphasis role= "bold" > <literal > network</literal> </emphasis> Support Package shall adhere to the
<xref linkend= "dbdoclet.50569387_33177" /> documentation functions and
conventions.</para>
</section>
<section >
<title > Program-image formats.</title>
<para > OF must recognize a client program that is formatted as ELF, as
defined in
<xref linkend= "dbdoclet.50569387_38836" /> , and PE, as defined in
<xref linkend= "dbdoclet.50569387_18190" /> . Other formats
<emphasis > may</emphasis> be handled in an implementation-specific manner.
<xref linkend= "dbdoclet.50569387_33384" /> defines the FCode and Forth
Program-Image Formats.</para>
<para > After locating the file, OF reads the image into memory at the
location specified by the load-base Configuration Variable. Then, OF must
perform the following procedure to prepare the image for
execution.</para>
<programlisting > < ![CDATA[init-program.
set restart? false
if the image is in ELF format
if the EI_DATA field does not match little-endian?
set little-endian? appropriately.
set restart? true
locate the PowerPC Note Section
if the Note Section’
set Configuration Variables appropriately
set restart? true
if restart?
restart the system, possibly by executing reset-all
else
move and/or relocate the ELF image
set GO’
else if the image is in PE format
if little-endian? is false
set little-endian? to true.
restart the system, possibly by executing reset-all
else
move and/or relocate the PE image.
set GO’
else if the image is FCode Image (hex characters F1,08)
setup system and do subsequent go and perform a byte load of the FCode image
else if the image is Forth Code Source Image (ASCII characters \”<space > ”)
setup system to evaluate Forth Source Image
else if the image is a bootinfo.txt file (i.e., begins with “<CHRP-BOOT > ”)
setup system to parse the bootinfo.txt file
else
FAIL, in an implementation-specific manner.]]></programlisting>
<para > <emphasis role= "bold" > Notes:</emphasis> The following comments apply to the above code:</para>
<orderedlist >
<listitem >
<para > For more information on detecting an ELF format, refer to
<xref linkend= "dbdoclet.50569368_24653" /> .</para>
</listitem>
<listitem >
<para > For more information on relocating an ELF image, refer to
<xref linkend= "dbdoclet.50569368_30006" /> .</para>
</listitem>
</orderedlist>
</section>
</section>
</chapter>
