<?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:id="dbdoclet.50569374_59715"
xml:lang="en">
<title>Processor Architecture Binding</title>
<section>
<title>Data Formats and Representations</title>
<para>The cell size shall be 32 bits. Number ranges for
<emphasis>n</emphasis>,
<emphasis>u</emphasis>, and other cell-sized items are consistent with
32-bit, two's-complement number representation.</para>
<para>The required alignment for items accessed with
<emphasis>a-addr</emphasis> addresses shall be four-byte aligned (i.e., a
multiple of 4).</para>
<para>Each operation involving a
<emphasis>qaddr</emphasis> address shall be performed with a single 32-bit
access to the addressed location; similarly, each
<emphasis>waddr</emphasis> access shall be performed with a single 16-bit
access. This implies four-byte alignment for
<emphasis>qaddrs</emphasis> and two-byte alignment for
<emphasis>waddrs</emphasis>.</para>
</section>
<section>
<title>Memory Management</title>
<section>
<title>PA Address Translation Model</title>
<para>This section describes the model that is used for co-existence of
OF and client programs (i.e., OSs) with respect to address
translation.</para>
<para>The following overview of translation is provided so that the
issues relevant to OF for the PA can be discussed. Details that are not
relevant to OF issues (e.g., protection) are not described in detail;
<xref linkend="dbdoclet.50569387_99718" />, particularly Book III, should
be consulted for the details. For the scope of this section, terms will
be used as defined in
<xref linkend="dbdoclet.50569387_99718" />.</para>
<section>
<title>Translation requirements</title>
<para>The default access mode of storage for load and stores (i.e., with
translation disabled -- referred to as
<emphasis>Real-Mode</emphasis>) within the PA assumes that caches are
enabled (in copy-back mode). In order to perform access to I/O device
registers, the access mode must be set to Cache-Inhibited, Guarded by
establishing a translation with this mode and enabling translation. Thus,
even though most of a client program and/or OF can run with translation
disabled, it must be enabled when performing I/O.</para>
</section>
<section xml:id="dbdoclet.50569374_41703">
<title>Segmented Address Translation</title>
<para>
<emphasis role="bold">Note:</emphasis> The use of the term Virtual Address in this
section refers to the PA definition, while the rest of the document uses
the IEEE 1275 definition of virtual address.</para>
<para>
<emphasis role="bold">Note:</emphasis> The following description of PA address
translation is only one of several translation modes available and is
given for reference only. See
<xref linkend="dbdoclet.50569387_99718" />for complete details.</para>
<para>An Effective Address (EA) of a PA processor is 64(32) bits wide.
Each EA is translated into an 80(52)-bit Virtual Address (VA) by
prepending a 52(24)-bit Virtual Segment Id (VSID) to the 28 LSbs of the
effective address. On 32-bit implementations, the VSID is obtained by
indexing into a set of 16 Segment Registers (SRs) using the 4 MSbs of the
EA. On 64-bit implementations, the VSID is looked up in a Segment Table
using the 36 MSbs of the EA. Finally, the virtual address is translated
into a Real Address (RA). This is done by mapping the Virtual Page-Number
(VPN) (bits 0-67(39) of the VA) into a Real Page Number (RPN) and
concatenating this RPN with the byte offset (12 LSbs of the VA). The
mapping of VPN to RPN involves a hashing algorithm within a Hashed Page
Table (HTAB) to locate a Page Table Entry (PTE) that matches the VPN and
using that entry’s RPN component. If a valid entry is not found, a
Data Storage Interrupt (DSI) or Instruction Storage Interrupt (ISI) is
signalled, depending upon the source of the access.</para>
<para>This process is not performed for every translation! Processors
will typically have a Translation Look-aside Buffer (TLB) that caches the
most recent translations, thus exploiting the natural spatial locality of
programs to reduce the overhead of address translation. 64-bit
implementations may also implement a Segment Lookaside Buffer (SLB) for
the same reasons. On most PA processors, the TLB updates are performed in
hardware. However, the architecture allows an implementation to use a
software-assisted mechanism to perform the TLB updates. Such schemes must
not affect the architected state of the processor unless the translation
fails; i.e., the HTAB does not contain a valid PTE for the VA and a
DSI/ISI is signalled.</para>
<para>
<emphasis role="bold">Note:</emphasis> One unusual feature of this translation
mechanism is that valid translations might not be found in the HTAB; the
HTAB might be too small to contain all of the currently valid
translations. This introduces a level of complexity in the use of address
translation by OF, as discussed below.</para>
</section>
<section>
<title>Block Address Translation</title>
<para>To further reduce the translation overhead for contiguous regions
of virtual and real address spaces (e.g., a frame buffer, or all of real
memory), the Block Address Translation (BAT) mechanism is also supported
by the PA. The Block Address Translation involves the use of BAT entries
that contain a Block Effective Page Index (BEPI), a Block Length (BL)
specifier and a Block Real Page Number (BRPN); the architecture defines 4
BAT entries for data (DBAT entries) and 4 BAT entries for instruction
(IBAT entries)<footnote xml:id="pgfId-550376">
<para>The 601 has a single set of BAT entries that are shared by both
instruction and data accesses.</para>
</footnote>. BAT areas are restricted to a finite set of allowable
lengths, all of which are powers of 2. The smallest BAT area defined is
128 KB (217 bytes). The largest BAT area defined is 256 MB (228 bytes).
The starting address of a BAT area in both EA space and RA space must be
a multiple of the area's length.</para>
<para>Block Address Translation is done my matching a number of upper
bits of the EA (specified by the BL value) against each of the BAT
entries. If a match is found, the corresponding BRPN bits replace the
matched bits in the EA to produce the RA.</para>
<para>Block Address Translation takes precedence over Segmented Address
Translation; i.e., if a mapping for a storage location is present in both
a BAT entry and a Page Table Entry or HTAB, the Block Address Translation
will be used.</para>
<para>
<emphasis role="bold">Note:</emphasis> Block Address Translation is a deprecated
translation mode of the PA. This description is retained here for
historical reference. See
<xref linkend="dbdoclet.50569387_99718" />for details on all supported
addressing mechanisms.</para>
</section>
</section>
<section>
<title>Open Firmware’s use of memory</title>
<para>OF shall use the memory resources within the space indicated by the
<emphasis role="bold"><literal>real-base</literal></emphasis>,
<emphasis role="bold"><literal>real-size</literal></emphasis>,
<emphasis role="bold"><literal>virt-base</literal></emphasis>, and
<emphasis role="bold"><literal>virt-size</literal></emphasis> Configuration Variables defined for the PA.
As described in the applicable platform binding, a mechanism is defined
to enable OF to determine if its current configuration is consistent with
the requirements of the client.</para>
<para>If the client program has specific requirements for physical memory
or address space usage, it may establish requirements for OF's physical
and/or virtual address space usage by means of its program header. When
OF loads the client program, it inspects the program header, and if its
current usage of physical memory or virtual address space conflicts with
that specified in the program header, OF shall set the
<emphasis role="bold"><literal>real-base</literal></emphasis>,
<emphasis role="bold"><literal>real-size</literal></emphasis>,
<emphasis role="bold"><literal>virt-base</literal></emphasis>, and
<emphasis role="bold"><literal>virt-size</literal></emphasis> to the configuration variables as specified
in the header and restart itself.
<emphasis role="bold"><literal>Real-base</literal></emphasis>,
<emphasis role="bold"><literal>real-size</literal></emphasis>,
<emphasis role="bold"><literal>virt-base</literal></emphasis>, and
<emphasis role="bold"><literal>virt-size</literal></emphasis> may be specified as -1, in which case the
firmware is permitted to choose appropriate values for the variables
specified as -1.</para>
<para>If the values of the
<emphasis role="bold"><literal>real-size</literal></emphasis> and/or
<emphasis role="bold"><literal>virt-size</literal></emphasis> configuration variables do not provide
sufficient memory and/or virtual address space for the firmware's own
use, then the firmware shall not attempt to load a client program and the
condition should be reported to the user. The possibility of not being
able to comply with limitations on firmware's size should be tested as
the firmware is coming up in order to handle the possibility that a user
established an unworkable limitation on the size. Clients can minimize
this exposure by setting size to -1 and allowing OF to choose the
size.</para>
<para>A PA OF binding shall support two different addressing models,
depending upon the setting of the
<emphasis role="bold"><literal>real-mode?</literal></emphasis> Configuration Variable. This variable
indicates the OF addressing mode that a client program expects;
<emphasis role="bold"><literal>false</literal></emphasis> (0) indicates Virtual-Mode,
<emphasis role="bold"><literal>true</literal></emphasis> (-1) indicates Real-Mode; the default value of
<emphasis role="bold"><literal>real-mode?</literal></emphasis> is implementation dependent.</para>
<para>The management of
<emphasis role="bold"><literal>real-mode?</literal></emphasis> is analogous to
<emphasis role="bold"><literal>little-endian?</literal></emphasis>. OF determines its addressing mode
using the value of
<emphasis role="bold"><literal>real-mode?</literal></emphasis>. If the current state of
<emphasis role="bold"><literal>real-mode?</literal></emphasis> (and hence, the current state of OF) is
incorrect, it shall set
<emphasis role="bold"><literal>real-mode?</literal></emphasis> appropriately and reset itself, possibly
by executing
<emphasis>reset-all</emphasis>.</para>
<para>Memory that cannot be allocated for general purpose use, for
example physical memory on LoPAR systems used for interrupt vectors and
implementation specific areas, shall not appear in the “
<emphasis>available</emphasis> ” property of the
<emphasis>memory</emphasis> node. A Client Program that needs to use such
memory for its architected purpose must not claim that area prior to
use.</para>
<para>In the following two sections, some of conventions in Real-Mode and
Virtual-Mode address translations are described. Remaining sections
describe the assumptions that OF makes about the state and control of the
system in regard to OF’s use of system resources for three OF
interfaces (e.g. Device, User and Client interfaces).</para>
<section xml:id="dbdoclet.50569374_25139">
<title>Real-Mode</title>
<para>In Real-Mode (when
<emphasis role="bold"><literal>real-mode?</literal></emphasis> is
<emphasis role="bold"><literal>true</literal></emphasis>), the use of address translations by OF and its
client are independent. Either they do not use translation, or their
translations are private; they do not share any translations. All
interfaces between the two must pass the real address of the data. Any
data structure shared by OF and its client that refers to
<emphasis>virt</emphasis> addresses in
<xref linkend="dbdoclet.50569387_45524" />, or this binding, must be real
addresses.</para>
<para>
<emphasis role="bold">Note:</emphasis> In particular, that the address of the Client
interface handler, that is passed to the client, has to be a real
address.</para>
<para>The Configuration Variables
<emphasis role="bold"><literal>real-base</literal></emphasis> and
<emphasis role="bold"><literal>real-size</literal></emphasis> should indicate the physical memory base
and size in which OF must locate itself. In Real-Mode, the Configuration
Variables
<emphasis role="bold"><literal>virt-base</literal></emphasis> and
<emphasis role="bold"><literal>virt-size</literal></emphasis> do not have meaning and should be set to
-1.</para>
</section>
<section>
<title>Virtual-Mode</title>
<para>When
<emphasis role="bold"><literal>real-mode?</literal></emphasis> is
<emphasis role="bold"><literal>false</literal></emphasis>, OF shall configure itself to run in
<emphasis>Virtual-Mode</emphasis>. In Virtual-Mode, OF and its client
will share a single virtual address space. This binding provides
interfaces to allow OF and its client to ensure that this single virtual
address model can be maintained.</para>
<para>The Configuration Variables
<emphasis role="bold"><literal>virt-base</literal></emphasis> and
<emphasis role="bold"><literal>virt-size</literal></emphasis> should indicate the virtual address space
base address and size that OF should use. The Configuration Variables
<emphasis role="bold"><literal>real-base</literal></emphasis> and
<emphasis role="bold"><literal>real-size</literal></emphasis> should indicate the physical memory base
and size in which OF must locate itself.</para>
</section>
<section>
<title>Device Interface (Real-Mode)</title>
<para>While OF is performing system initialization and probing functions,
it establishes and maintains its own translations. In particular, it
maintains its own Page Tables (and/or BAT entries) and handles any
DSI/ISI interrupts itself.</para>
<para>
<emphasis role="bold">Note:</emphasis> In Real-Mode, all translations will be
<emphasis>virt=real</emphasis>; the primary reason for translation is to
allow appropriate I/O accesses.</para>
</section>
<section>
<title>Device Interface (Virtual-Mode)</title>
<para>OF will establish its own translation environment, handling DSI/ISI
interrupts as in the Real-Mode case. However, this environment will, in
general, contain translations in which virtual addresses do not equal
real addresses. The virtual address space used by OF must be compatible
with its client.</para>
<para>
<emphasis role="bold">Note:</emphasis> Since these virtual addresses will be used by
the Client and/or User Interfaces (e.g., for pointers to its code,
device-tree, etc.), their translations must be preserved until the client
OS decides that it no longer requires the services of OF.</para>
</section>
<section>
<title>Client Interface (Real-Mode)</title>
<para>In Real-Mode, addresses of client data are real.; the client must
ensure that all data areas referred to across the Client Interface are
valid real addresses. This may require moving data to meet any
requirements for contiguous storage areas (e.g., for
<emphasis role="bold"><literal>read/write</literal></emphasis> calls). Translation shall be disabled
before the client interface call is made.</para>
<para>OF will typically have to maintain its translations in order to
perform I/O. Since the client may be running with translation enabled
(except for the Client interface call), OF shall save the state of all
relevant translation resources (e.g., SDR1, BATs) and restore them before
returning to the client. Likewise, it
<emphasis>may</emphasis> take over interrupts for its own use (e.g., for
doing “lazy” allocation of BATs); it shall preserve the state
of any interrupt vectors for its client.</para>
<para>Since the state of the address translation system is not
predictable to any interrupts, the client shall ensure that interrupts
are disabled before calling the Client Interface handler and call the
handler from only one CPU at a time. The client shall also ensure that
other processors do not generate translation exceptions for the duration
of the call.</para>
<para>Client programs are not required to assume responsibility for
physical memory management. The client program must use the OF claim
client interface service to allocate physical memory while physical
memory is managed by OF. Physical memory shall remain managed by OF until
the client program defines the real-mode physical memory management
assist callbacks. Physical memory must be managed by the client program
once the client program defines the real-mode physical memory management
assist callbacks. OF shall use the client program's real-mode physical
memory management assist callbacks to allocate physical memory after the
client program has assumed physical memory management.</para>
<para>In Real-Mode,
<emphasis role="bold"><literal>claim</literal></emphasis> methods shall not allocate more pages than are
necessary to satisfy the request.</para>
</section>
<section xml:id="dbdoclet.50569374_96317">
<title>Client Interface (Virtual-Mode)</title>
<para>Client interface calls are essentially “subroutine”
calls to OF. Hence, the client interface executes in the environment of
its client, including any translations that the OS has established. E.g.,
addresses passed in to the client interface are assumed to be valid
virtual addresses within the scope of the OS. Any DSI/ISI interrupts are
either invalid addresses or caused by HTAB “spills”. In
either case, the OS has the responsibility for the handling of such
exceptions.</para>
<para>
<emphasis role="bold">Note:</emphasis> Addresses that the OF internal use will be
those that were established by the Device interface (or, by subsequent
actions of the Client or User interface). Thus, the client must preserve
these OF translations if it takes over the virtual memory management
function.</para>
<para>In addition to using existing translations, the Client Interface
might require the establishment of new translations (e.g., due to
<emphasis role="bold"><literal>map-in</literal></emphasis> calls during
<emphasis role="bold"><literal>open</literal></emphasis> time), or the removal of old translations (e.g.,
during
<emphasis role="bold"><literal>map-out</literal></emphasis> calls during
<emphasis role="bold"><literal>close</literal></emphasis> time). Since this requires altering the
Client’s translation resources (e.g., Page Tables), possibly
handling spill conditions, OF cannot know how to perform these
updates.</para>
<para>Hence, there shall be
<emphasis role="bold"><literal>callback</literal></emphasis> services provided by the client for use by
OF for such actions; see
<xref linkend="dbdoclet.50569374_11616" />.</para>
<para>In order to let clients (i.e., target OSs) know where OF lives in
the address space, the following rules shall be followed by an OF
implementation for the PA and by client programs.</para>
<para>OF:</para>
<itemizedlist>
<listitem>
<para>OF shall maintain its “translations”
“mmu”-node property (see
<xref linkend="dbdoclet.50569374_34579" />)</para>
</listitem>
<listitem>
<para>OF’s
<emphasis role="bold"><literal>claim</literal></emphasis> methods shall not allocate more pages
than are necessary to satisfy the request.</para>
</listitem>
<listitem>
<para>When a client executes
<emphasis role="bold"><literal>set-callback</literal></emphasis>, OF shall attempt to invoke the
“translate” callback. If the translate callback is
implemented, OF shall cease use of address translation hardware, instead
using the client callbacks for changes to address translation.</para>
</listitem>
</itemizedlist>
<para>The
<emphasis role="bold"><literal>exit</literal></emphasis> service must continue to work after a
<emphasis role="bold"><literal>set-callback</literal></emphasis> that takes over address translation.
This implies that OF takes responsibility for address translation
hardware upon
<emphasis role="bold"><literal>exit</literal></emphasis> and must maintain internal information about
translations that it requests of the client.</para>
<para>Client Programs:</para>
<itemizedlist>
<listitem>
<para>Client programs that take control of the management of address
translation hardware and expect to be able to subsequently invoke OF
client services must provide callbacks to assist OF in address
translation (see
<xref linkend="dbdoclet.50569374_11616" />).</para>
</listitem>
<listitem>
<para>A client program shall not directly manipulate any address
translation hardware before it either a) ceases to invoke OF client
services or b) issues a
<emphasis role="bold"><literal>set-callback</literal></emphasis> to install the “translate”
callback.</para>
</listitem>
</itemizedlist>
<para>
<emphasis role="bold">Note:</emphasis> The intended sequence is that a client program
will first issue a set-callback and then take control of address
translation hardware. Address translation hardware includes BAT entries,
page table, segment registers, Machine State Register and the interrupt
vectors relating to translation faults.</para>
</section>
<section>
<title>User Interface (Real-Mode)</title>
<para>In Real-Mode, OF regains total control of the system. As with the
Client interface in Real-Mode, it should save the state of the
translation resources (including interrupt vectors) upon entry and should
restore them upon exit.</para>
</section>
<section>
<title>User Interface (Virtual-Mode)</title>
<para>When the User interface is invoked, OF is responsible for managing
the machine. Therefore, it will take over control of any relevant
interrupt vectors for its own handling. In particular, it will take over
DSI/ISI handling in order to report errors to the user for bad addresses,
protection violations, etc. However, as described above, one source of
DSI/ISI may simply be HTAB spills. As with the case of
<emphasis role="bold"><literal>map-in</literal></emphasis> and
<emphasis role="bold"><literal>map-out</literal></emphasis> calls, the User interface cannot know how to
handle such spill conditions, itself, or even if this is, in fact, a
spill versus a bad address.</para>
<para>Hence, this binding defines
<emphasis role="bold"><literal>callback</literal></emphasis> services that the client provides for use by
OF; see
<xref linkend="dbdoclet.50569374_11616" />.</para>
</section>
</section>
</section>
<section>
<title>Properties</title>
<para>This section describes the standard properties of a PA OF
implementation.</para>
<section xml:id="dbdoclet.50569374_58081">
<title>CPU properties</title>
<para />
<section xml:id="dbdoclet.50569374_37877">
<title>The Device Tree</title>
<para>OF requires that the multiple instances of any device that appears
more than once in the device tree must be distinguishable by means of
their
<emphasis role="bold"><literal>“reg”</literal></emphasis> properties. The
<emphasis role="bold"><literal>“reg”</literal></emphasis> property must express the address
of each node relative to its parent bus. Furthermore, the core
specification says that the root node of the device tree usually
represents the main physical bus of the system. Thus, if processors are
not directly addressable on the main physical bus, as is expected to be
the case on many/most PA-based systems, the CPU nodes on such systems may
not be children of the root node but must instead be children of a
pseudo-device node. In this case, the name of the pseudo-device node,
which will usually be a child of the root node, shall be
“cpus”.</para>
<para>The “cpus” node shall have one child node of
device_type “cpu” for each processor.</para>
</section>
<section xml:id="dbdoclet.50569374_18332">
<title>Physical Address Formats and Representations for CPU
Nodes</title>
<para />
<section>
<title>Numerical Representation</title>
<para>The numerical representation of a processor’s
“address” in a LoPAR system shall consist of one cell,
encoded as follows (Bit# 0 refers to the least significant bit)
<emphasis role="bold">:</emphasis></para>
<table frame="all" pgwide="1">
<title>Numerical Representation of a Processor’s
“address”</title>
<?dbhtml table-width="75%" ?>
<?dbfo table-width="75%" ?>
<tgroup cols="5">
<colspec colname="c1" colwidth="20*" align="center" />
<colspec colname="c2" colwidth="20*" align="center" />
<colspec colname="c3" colwidth="20*" align="center" />
<colspec colname="c4" colwidth="20*" align="center" />
<colspec colname="c5" colwidth="20*" align="center" />
<thead>
<row>
<entry valign="middle">
<para>
<emphasis role="bold">Bit#</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">33222222<?linebreak?>10987654</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">22221111<?linebreak?>32109876</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">11111100<?linebreak?>54321098</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">00000000<?linebreak?>76543210</emphasis>
</para>
</entry>
</row>
</thead>
<tbody>
<row>
<entry>
<para>phys.lo cell:</para>
</entry>
<entry>
<para>00000000</para>
</entry>
<entry>
<para>00000000</para>
</entry>
<entry>
<para>00000000</para>
</entry>
<entry>
<para>pppppppp</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
<para>where:
<emphasis>pppppppp</emphasis> is an 8-bit integer representing the
interprocessor interrupt identifier used by the platform.</para>
</section>
<section>
<title>Text Representation</title>
<para>The text representation of a processor’s
“address” shall be an ASCII hexadecimal number in the range
<emphasis>0...FF</emphasis>.</para>
<para>Conversion of the hexadecimal number from text representation to
numeric representation shall be case insensitive, and leading zeros shall
be permitted but not required.</para>
<para>Conversion from numeric representation to text representation shall
use the lower case forms of the hexadecimal digits in the range
<emphasis>a..f</emphasis>, suppressing leading zeros.</para>
</section>
<section>
<title>Unit Address Representation</title>
<para>A processor’s “unit-number” (i.e. the first
component of its
<emphasis role="bold"><literal>“reg”</literal></emphasis> value) is the interprocessor
interrupt destination identifier used by the platform. For a
uni-processor platform, the “unit-number” shall be
zero.</para>
</section>
</section>
<section xml:id="dbdoclet.50569374_25612">
<title>CPUS Node Properties</title>
<para>The following properties shall be created within the
“cpus” node.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold"><literal>“#address-cells”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis> to define the number of cells required
to represent the physical addresses for the “
<emphasis>cpu</emphasis> ” nodes (i.e., the children of the “
<emphasis>cpus</emphasis> ” node).</para>
<para><emphasis>prop-encoded-array</emphasis>: Integer constant 1, encoded as
with <emphasis role="bold"><literal>encode-int</literal></emphasis>.</para>
<para>The value of
<emphasis role="bold"><literal>“#address-cells”</literal></emphasis> for the
“cpus” node shall be
<emphasis>1</emphasis>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“#size-cells”</literal></emphasis></term>
<listitem>
<para>Standard
<emphasis>property name</emphasis> to define the number of cells necessary
to represent the length of a physical address range.</para>
<para><emphasis>prop-encoded-array</emphasis>: Integer constant 0, encoded as
with <emphasis role="bold"><literal>encode-int</literal></emphasis>.</para>
<para>The value of “
<emphasis role="bold"><literal>#size-cells</literal></emphasis> ” for the “cpus”
pseudo-device node is 0 because the processors that are represented by
the cpu nodes do not consume any physical address space.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="dbdoclet.50569374_89868">
<title>CPU Node Properties</title>
<para>For each CPU in the system, a cpu-node shall be defined as a child
of
<emphasis role="bold"><literal>“cpus”</literal></emphasis>. The following properties apply to
each of these nodes. The
<emphasis>cpus</emphasis> node shall not have “
<emphasis>reg</emphasis> ” or “
<emphasis>ranges</emphasis> ” properties. In general, properties in
a cpu-node that affect the software interface (for example properties
that convey the presence of instructions, presence of registers, or
location of resources) to the processor are preserved by the device tree
once presented upon boot. For a list of properties that may change before
a reboot, see
<xref linkend="LoPAR.RTAS" />.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold"><literal>“name”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>. The value of this property
shall be of the form: “PowerPC,<name>”, where <name>
is the name of the processor chip which may be displayed to the user.
<name>
<emphasis>shall not</emphasis> contain underscores.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“device_type”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>. The value of this
property for CPU nodes shall be
<literal>“cpu”</literal>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“reg”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>proper name</emphasis> to define a cpu node’s
unit-address.</para>
<para><emphasis>prop-encoded-array</emphasis>: an integer encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>.</para>
<para>For a cpu node, the first and only value of the
<emphasis role="bold"><literal>“reg”</literal></emphasis> property shall be the number of the
per-processor interrupt line assigned to the processor represented by the
node. For a uni-processor platform, the value of the
<emphasis role="bold"><literal>“reg”</literal></emphasis> property shall be zero.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“status”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>. The value of the is
property shall be one of the following string values:</para>
<itemizedlist>
<listitem>
<para><literal>“okay”</literal> for a good processor.</para>
</listitem>
<listitem>
<para><literal>“fail”</literal> for a processor that fails during power-on testing.</para>
</listitem>
<listitem>
<para><literal>“fail-offline”</literal>
for a processor that has been automatically deconfigured because of previous
failures.</para>
</listitem>
<listitem>
<para><literal>“disabled”</literal>
for a processor that has been manually deconfigured.</para>
</listitem>
</itemizedlist>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“cpu-version”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis>: Represents the processor type.</para>
<para><emphasis>prop-encoded-value</emphasis>: The value, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>,
shall be either the value obtained by
reading the Processor Version Register of the processor described by this
node, or the logical processor version as given in
<xref linkend="dbdoclet.50569374_97612" />. The first byte of the logical
processor version value shall be 0x0F. The values of the “Logical
Processor Version” column of
<xref linkend="dbdoclet.50569374_97612" />indicate that the processor
provides the base support described by that version of the architecture.
The presence and value of all optional and implementation dependent
features and facilities are described by their corresponding
properties.</para>
<table frame="all" pgwide="1" xml:id="dbdoclet.50569374_97612">
<title>Logical Processor Version 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">Logical Processor Version</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Property Value</emphasis>
</para>
</entry>
</row>
</thead>
<tbody>
<row>
<entry>
<para>2.04</para>
</entry>
<entry>
<para>0x0F000001</para>
</entry>
</row>
<row>
<entry>
<para>2.05</para>
</entry>
<entry>
<para>0x0F000002</para>
</entry>
</row>
<row>
<entry>
<para>2.06</para>
</entry>
<entry>
<para>0x0F000003</para>
</entry>
</row>
<row>
<entry>
<para>2.06 plus:</para>
<para>URG field in DSCR (Bits 55-57)</para>
</entry>
<entry>
<para>0x0F100003</para>
</entry>
</row>
<row>
<entry>
<para>2.07</para>
</entry>
<entry>
<para>0x0F000004</para>
</entry>
</row>
<row>
<entry>
<para>2.08</para>
</entry>
<entry>
<para>0x0F000005</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“clock-frequency”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents
the internal processor speed (in hertz) of this node.</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 internal
processor 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 the low order 32
bits 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 (the low order 32 bits of freq-hi || the low order
32 bits of freq-lo).</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“timebase-frequency”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>,
that represents the rate (in hertz) at
which the PA TimeBase and Decrementer registers are updated.</para>
<para><emphasis role="bold">Note:</emphasis> The 601 PowerPC
processor does not have a timebase frequency,
therefore on a 601 PowerPC processor the value reported in this property
shall be 1 billion (1 x 109) which represents the logical rate of the
real time clock.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“ibm,extended-timebase-frequency”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis>: Property that represents the rate in
hertz at which the PA TimeBase and Decrementer registers are updated.
This property allows the encoding of multi-giga-hertz quantities.</para>
<para><emphasis>prop-encoded-array</emphasis>: Consisting of the low order 32
bits 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 (the low order 32 bits of freq-hi || the low order 32 bits of freq-lo).</para>
<para><emphasis role="bold">Note:</emphasis> The
<emphasis role="bold"><literal>“ibm,extended-timebase-frequency”</literal></emphasis>
property will be deprecated from the architecture due to the emergence of the
<emphasis role="bold"><literal>“ibm,nominal-tbf”</literal></emphasis> property and the lack
of a need for a two cell version of the
<emphasis role="bold"><literal>“timebase-frequency”</literal></emphasis> property.
Implementations should not provide the
<emphasis role="bold"><literal>“ibm,extended-timebase-frequency”</literal></emphasis> property.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“ibm,nominal-tbf”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis>: Property, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>,
that represents the design nominal
timebase frequency (in hertz).</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“ibm,tbu40-offset”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis>: that provides the value that, when
added (ignoring overflow) to the processor TimeBase, yields a value
consistent with other platform partitions that utilize their respective
values of the property. If the property is missing, the default value is
zero.</para>
<para><emphasis>prop-encoded-array</emphasis>: An eight byte, big endian,
unsigned, binary value.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“64-bit”</literal></emphasis></term>
<listitem>
<para><emphasis>prop-encoded-array</emphasis>: <none></para>
<para>This property, if present, indicates that the PA processor defined
by this CPU node is a 64-bit implementation of the PA. The absence of
this property indicates that the microprocessor defined by this CPU node
is a 32 bit implementation of the PA</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“64-bit-virtual-address”</literal></emphasis></term>
<listitem>
<para><emphasis>prop-encoded-array</emphasis>: <none></para>
<para>This property, if present, indicates that the PA processor defined
by this CPU node supports the 64-bit virtual address subset of the 80-bit
virtual address as defined by the PA. The absence of this property
indicates that the PA processor defined by this CPU node supports the
full 80-bit virtual address defined by the PA. This property is only
valid for 64-bit implementations.</para>
<para><emphasis role="bold">Note:</emphasis> The
<emphasis role="bold"><literal>“64-bit-virtual-address”</literal></emphasis>
will be
deprecated from the architecture. Implementations should not provide this
property.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“603-translation”</literal></emphasis></term>
<listitem>
<para><emphasis>prop-encoded-array</emphasis>: <none></para>
<para>This property, if present, indicates that the PA processor defined
by this CPU node uses the PowerPC 603 processor defined mechanism to
update its Translation Lookaside Buffers (TLBs). The absence of this
property indicates that the PA processor defined by this CPU node does
not use the PowerPC 603 processor defined mechanism to update its
TLBs.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“603-power-management”</literal></emphasis></term>
<listitem>
<para><emphasis>prop-encoded-array</emphasis>: <none></para>
<para>This property, if present, indicates that the PA processor defined
by this CPU node implements the PowerPC 603 processor defined power
management states. The absence of this property indicates that the PA
processor defined by this CPU node does not support the PowerPC 603
processor defined power management states.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“bus-frequency”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>,
that represents the speed (in hertz) of
this processor’s bus.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“ibm,extended-bus-frequency”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis>: Property that represents the rate in
hertz of this processor’s bus. This property allows the encoding of
multi-giga-hertz quantities.</para>
<para><emphasis>prop-encoded-array</emphasis>: Consisting of the low order 32
bits 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 (the
low order 32 bits of freq-hi || the low order 32 bits of freq-lo).</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“32-64-bridge”</literal></emphasis></term>
<listitem>
<para><emphasis>prop-encoded-array</emphasis>: <none></para>
<para>This property, if present, indicates that the PA processor defined
by this CPU node implements the “Bridge Facilities and Instructions
for 64-bit Implementations” as described in an appendix of Book III
of
<xref linkend="dbdoclet.50569387_99718" />. The absence of this property
indicates that the PA processor defined by this CPU node does not support
these facilities and instructions.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“external-control”</literal></emphasis></term>
<listitem>
<para><emphasis>prop-encoded-array</emphasis>: <none></para>
<para>This property, if present, indicates that the PA processor defined
by this CPU node implements the External Control Facility as described in
the “Optional Facilities and Instructions” appendix of Book
II of
<xref linkend="dbdoclet.50569387_99718" />. The absence of his property
indicates that the PA processor defined by this CPU node does not support
the External Control Facility.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“general-purpose”</literal></emphasis></term>
<listitem>
<para><emphasis>prop-encoded-array</emphasis>: <none></para>
<para>This property, if present, indicates that the PA processor defined
by this CPU node implements the floating point instructions
<emphasis>fsqrt</emphasis>,
<emphasis>fsqrts</emphasis> and
<emphasis>stfiwx</emphasis>. The absence of this property indicates that
the PA processor defined by this CPU node does not support the floating
point instructions
<emphasis>fsqrt</emphasis>,
<emphasis>fsqrts</emphasis> and
<emphasis>stfiwx</emphasis>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“reservation-granule-size”</literal></emphasis></term>
<listitem>
<para>Standard property, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>,
that represents the reservation granule
size (i.e., the minimum size of lock variables) supported by this
processor, in bytes.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“graphics”</literal></emphasis></term>
<listitem>
<para><emphasis>prop-encoded-array</emphasis>: <none></para>
<para>This property, if present, indicates that the PA processor defined
by this CPU node implements floating point instructions
<emphasis>fres, frsqrte,</emphasis> and
<emphasis>fsel</emphasis>. The absence of this property indicates that
the PA processor defined by this CPU node does not support the floating
point instructions
<emphasis>fres, frsqrte,</emphasis> and
<emphasis>fsel.</emphasis></para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“performance-monitor”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis>: Indicates that the processor described
by this node implements a performance monitor.</para>
<para><emphasis>prop-encoded-array</emphasis>: Consists of a pair of values,
each encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>.
The first value of the pair shall be 0
indicating that the performance monitor functionality is implementation
specific. The second value of the pair represents the documentation
describing the performance monitor functionality implemented by the
processor described by this node. The documentation represented by the
second value is specified in
<xref linkend="dbdoclet.50569374_84889" />.</para>
<table frame="all" pgwide="1" xml:id="dbdoclet.50569374_84889">
<title>Documentation for Implementation Specific Performance
Monitors</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">Second Value</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Documentation</emphasis>
</para>
</entry>
</row>
</thead>
<tbody>
<row>
<entry>
<para>0</para>
</entry>
<entry>
<para>
<emphasis>Power 5+ Performance Monitor Programmer’s
Guide</emphasis>
</para>
</entry>
</row>
<row>
<entry>
<para>1</para>
</entry>
<entry>
<para>
<emphasis>Power 7 Performance Monitor Programmer’s
Guide</emphasis>
</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“ibm,vmx”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis> that indicates that the processor
supports the POWER VMX architecture.</para>
<para><emphasis>prop-encoded-array</emphasis>: an integer encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>,
that represents the level of the VMX
architecture supported. The first level supported is the value 1. The
value of 1 represents the level of support described by the
<emphasis>A Vector/SIMD Multimedia eXtension to the PowerPC Architecture,
Specification Revision 1.2.3, 7/18/97</emphasis> specification. The value
of 2 represents the level of support provided by the VSX option of
<xref linkend="dbdoclet.50569387_99718" />level 2.06.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“ibm,segment-page-sizes”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis>: that indicates the segment base page
sizes and related encodings supported by the processor.</para>
<para><emphasis>prop-encoded-array</emphasis>: one or more
segment-page-size-descriptor(s).</para>
<para><emphasis>segment-page-size-descriptor</emphasis>: a
segment-page-size-header followed by a pte-lp-descriptor.</para>
<para><emphasis>segment-page-size-header</emphasis>: Consists of three cells
(X,Y,Z) encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>.
The first cell represents the base page
size of the segment (the page size which determines the hash value used
to locate the segment's page table entries) as 2
<emphasis>X</emphasis>. The second cell contains the SLB encoding that,
ORed with the RS register value for use by a slbmte instruction, selects
this segment's base page size. Note, the low order bits of the cell Y are
aligned with the low order bits of RS and the RS's L and LP bits are zero
prior to the logical OR operation. The third cell contains the number of
pte-lp-encodings in the pte-lp-descriptor.</para>
<para><emphasis>pte-lp-descriptor</emphasis>: Consists of Z (from the
segment-page-size-header) pte-lp-encoding(s), one for each of the page
sizes supported for this base segment page size.</para>
<para><emphasis>pte-lp-encoding</emphasis>: Each pte-lp-encoding consists of
two cells (P,Q) encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>.
The first cell represents the page size
of the encoding as 2
<emphasis>P</emphasis> (thus implying the number of low order RPN bits
that are available to page size encoding). The second cell, left shifted
12 bit positions, is the encoding to be entered into the available low
order RPN bits to represent this page size for this segment base page
size.</para>
<para><emphasis role="bold">Note:</emphasis> A
<emphasis>segment-page-size-descriptor</emphasis> applies to a segment
only if the size of the segment is greater than or equal to all of the
page sizes within the
<emphasis>pte-lp-encoding</emphasis> (s) contained within the
<emphasis>segment-page-size-descriptor</emphasis>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“ibm,processor-page-sizes”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis>: Relates the number and sizes of the virtual memory
page sizes supported by the processor describe by this node.</para>
<para><emphasis>prop-encoded-array</emphasis>: One to N cells in ascending
value order, each encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, each cell represents the size of a
supported virtual memory page where the value of the cell is the power of
2 of the cell size. i.e. a 4 K page size is represented by the value 12
(4 K= 2
<superscript>12</superscript>) etc.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“ibm,processor-radix-AP-encodings”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis>: Relates the AP (Actual Page size) encodings
for the supported page sizes used by the TLB management instructions when the processor
is in Radix address translation mode.</para>
<para><emphasis>prop-encoded-array</emphasis>: One to N cells in ascending order of
Radix mode supported page size, each encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>. The top 3 bits of the low order byte
contain the tlbie AP field associated with the corresponding Radix mode supported page size.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“ibm,processor-segment-sizes”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis>: Relates the number and sizes of the
virtual memory segment sizes supported by the processor described by this
node.</para>
<para><emphasis>prop-encoded-array</emphasis>: One to N cells in ascending
value order of the segment selector (SLBE B field), each encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, each positive value cell represents the
size of a supported virtual memory segment where the value of the cell is
the power of 2 of the segment size. That is, a 256Meg segment size is
represented by the value 28 (256Meg = 2
<superscript>28</superscript>) etc. (negative valued cells represent
unsupported encodings).</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“ibm,processor-storage-keys”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis> indicating the number of virtual
storage keys supported by the processor described by this node.</para>
<para><emphasis>prop-encoded-array</emphasis>: Consists of two cells encoded as
with <emphasis role="bold"><literal>encode-int</literal></emphasis>.
The first cell represents the number of
virtual storage keys supported for data accesses while the second cell
represents the number of virtual storage keys supported for instruction
accesses. The cell value of zero indicates that no storage keys are
supported for the access type.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“ibm,processor-vadd-size”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis> indicating the number of virtual
address bits that are supported by the processor described by this
node.</para>
<para><emphasis>prop-encode-array</emphasis>: An integer, encoded as with
<emphasis>encode-int,</emphasis> that represents the number of supported
virtual address bits.</para>
<para><emphasis role="bold">Note:</emphasis> A processor
described by this node implements
the least significant
<emphasis role="bold"><literal>“ibm,processor-vadd-size”</literal></emphasis>
bits of the architected virtual address.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“ibm,vrma-page-sizes”</literal></emphasis></term>
<listitem>
<para><emphasis>property-name</emphasis>: Maps the VRMASD field values
implemented by the processor described by this node to their page
sizes.</para>
<para><emphasis>prop-encoded-array</emphasis>: Array of one or more
<emphasis>VRMA page-size-descriptor</emphasis> (s) starting with the value
selected by the firmware when booting the partition, followed by the
other values supported by the platform.</para>
<para><emphasis>VRMA page-size-descriptor</emphasis>: A pair of cells encoded
as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>; The first cell is the log base 2 of the
page size. The second cell contains, in its low order bits, the VRMASD
field value to achieve that supported size. The high order bits of the
second cell are zero.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“ibm,estimate-precision”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis>: Relates PA estimate instruction
mnemonics to precisions supported by the processor described by this
node.</para>
<para><emphasis>prop-encoded-array</emphasis>: One or more
<emphasis>instruction-precision descriptor</emphasis> (s).</para>
<para>
<emphasis>instruction-precision descriptor</emphasis>: An
<emphasis>instruction descriptor</emphasis> followed by a
<emphasis>precision descriptor</emphasis>. An
<emphasis>instruction-precision</emphasis> descriptor relates one estimate
instruction mnemonic to the precision supported by the processor
described by this node for that estimate instruction mnemonic.</para>
<para><emphasis>instruction descriptor</emphasis>: Consists of one PA
instruction mnemonic encoded as with
<emphasis role="bold"><literal>encode-string</literal></emphasis>.</para>
<para><emphasis>precision descriptor</emphasis>: Consists of an integer, encoded
as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>,
specifying the number of bits of
precision the processor described by this node supports for an
instruction mnemonic.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“ibm,dfp”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis>: Indicates that the processor described
by this node supports the Decimal Floating Point (DFP)
architecture.</para>
<para><emphasis>prop-encoded-value</emphasis>: an integer, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>,
that represents the level of DFP support
of the CPU described by this node. The absolute value of the integer
represents the level of the DFP architecture supported. The sign of the
integer indicates how the architecture level is supported. A positive
integer indicates native support while a negative integer indicates
emulation assisted support. The absolute values supported are as
follows:</para>
<para>1: Represents the level of support defined by Version 2.05 of the
<xref linkend="dbdoclet.50569387_99718" />.</para>
<para>2: Represents the level of support defined by Version 2.06 of the
<xref linkend="dbdoclet.50569387_99718" />.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“ibm,purr”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis>: Indicates that the processor
described by this node implements a Processor Utilization of Resources
Register (PURR).</para>
<para><emphasis>prop-encoded-value</emphasis>: an integer, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>,
that represents the level of PURR
architecture supported. The first level supported is the value 1 and is
defined by Section 6.5 “Processor Utilization of Resources
Register” of Book III of version 2.02 of the PA.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“ibm,spurr”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis>: Indicates that the processor
described by this node implements a Scaled Processor Utilization of
Resources Register (SPURR).</para>
<para><emphasis>prop-encoded-value</emphasis>: an integer, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>,
that represents the level of SPURR
architecture supported. The value of 1 represents the level of support
defined by Version 2.05 of the
<xref linkend="dbdoclet.50569387_99718" />.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“ibm,pa-features”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis>: Indicates level of support of several
extended features of the Processor Architecture.</para>
<para><emphasis>prop-encoded-array</emphasis>: One or more
<emphasis>attribute-descriptor</emphasis> (s).</para>
<para><emphasis>attribute-descriptor</emphasis>: Consists of an
<emphasis>attribute-header</emphasis> immediately followed by an
<emphasis>attribute-specifier.</emphasis></para>
<para><emphasis>attribute-header</emphasis>: Consists of two bytes. The first
byte is an unsigned integer representing a value from 1 to 254. The first
byte specifies the number of bytes implemented by the platform of the
<emphasis>attribute-specifier</emphasis>. The second byte is an unsigned
integer specifying the
<emphasis>attribute-specifier-type</emphasis>.</para>
<para><emphasis>attribute-specifier</emphasis>: The
<emphasis>attribute-specifier</emphasis> is defined by the
<emphasis>attribute-specifier-type</emphasis> of the
<emphasis>attribute-header.</emphasis> The
<emphasis>attribute-specifier</emphasis> for the
<emphasis>attribute-specifier-type</emphasis> value of 0 is defined by
<xref linkend="dbdoclet.50569374_18997" />.</para>
<table frame="all" pgwide="1" xml:id="dbdoclet.50569374_18997">
<title>Definition for
<emphasis>attribute-specifier</emphasis>
<emphasis>attribute-specifier-type</emphasis> value 0</title>
<tgroup cols="4">
<colspec colname="c1" colwidth="20*" align="center" />
<colspec colname="c2" colwidth="10*" align="center" />
<colspec colname="c3" colwidth="20*" align="center" />
<colspec colname="c4" colwidth="50*" 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">Attribute Name</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Description</emphasis>
</para>
</entry>
</row>
</thead>
<tbody>
<row>
<entry morerows="7">
<para>0</para>
</entry>
<entry>
<para>0</para>
</entry>
<entry>
<para>Memory Management Unit (MMU)</para>
</entry>
<entry>
<para>The value of 1 indicates MMU support; else not
supported.</para>
</entry>
</row>
<row>
<entry>
<para>1</para>
</entry>
<entry>
<para>Floating Point Unit (FPU)</para>
</entry>
<entry>
<para>The value of 1 indicates FPU support; else not
supported.</para>
</entry>
</row>
<row>
<entry>
<para>2</para>
</entry>
<entry>
<para>Segment Lookaside Buffer (SLB).</para>
</entry>
<entry>
<para>The value of 1 indicates SLB support; else not
supported.</para>
</entry>
</row>
<row>
<entry>
<para>3</para>
</entry>
<entry>
<para>RUN field</para>
</entry>
<entry>
<para>The value of 1 indicates support for the RUN field of the
Control Register (CTRL, SPR #152); else not supported.</para>
</entry>
</row>
<row>
<entry>
<para>4</para>
</entry>
<entry>
<para>Reserved</para>
</entry>
<entry>
<para>Reserved bits within defined bytes
<emphasis>shall</emphasis> be zero.</para>
</entry>
</row>
<row>
<entry>
<para>5</para>
</entry>
<entry>
<para>Data Address Breakpoint Register (DABR)</para>
</entry>
<entry>
<para>The value of 1 indicates DABR support; else not
supported.</para>
</entry>
</row>
<row>
<entry>
<para>6</para>
</entry>
<entry>
<para>No Execute (N) bit in Page Table Entries.</para>
</entry>
<entry>
<para>The value of 1 indicates No Execute (N) bit in Page Table
Entry support; else not supported.</para>
</entry>
</row>
<row>
<entry>
<para>7</para>
</entry>
<entry>
<para>Write Through Required (W) bit</para>
</entry>
<entry>
<para>The value of 1 indicates setting the W bit to 1 (write
through always) is supported; else attempting to set the W bit
to 1 has no effect</para>
</entry>
</row>
<row>
<entry morerows="7">
<para>1</para>
</entry>
<entry>
<para>0</para>
</entry>
<entry>
<para>Memory Coherence Required (M) bit</para>
</entry>
<entry>
<para>The value of 1 indicates that setting the M bit to 0
(main storage not always coherent) is supported; else
attempting to set the M bit to 0 has no effect.</para>
</entry>
</row>
<row>
<entry>
<para>1</para>
</entry>
<entry>
<para>Data Storage Interrupt Status Register (DSISR) set on an
alignment interrupt.</para>
</entry>
<entry>
<para>The value of 1 indicates that the DSISR is set on an
alignment interrupt as described by version 2.01 of PA; else
the DSISR is not set on alignment interrupt as described by
version 2.01 of PA.</para>
</entry>
</row>
<row>
<entry>
<para>2</para>
</entry>
<entry>
<para>I=1 (cache inhibited) Large Pages</para>
</entry>
<entry>
<para>The value of 1 indicates support for I=1 (cache
inhibited) large pages; else not supported.</para>
</entry>
</row>
<row>
<entry>
<para>3</para>
</entry>
<entry>
<para>Round to Integer (from floating point) group of
instructions.</para>
</entry>
<entry>
<para>The value of 1 indicates support for the
<emphasis>frin, friz, frip,</emphasis> and
<emphasis>frim</emphasis> instructions; else these instructions
are not supported.</para>
</entry>
</row>
<row>
<entry>
<para>4</para>
</entry>
<entry>
<para>Data Address Breakpoint Register Extension (DABRX)</para>
</entry>
<entry>
<para>The value of 1 indicates support for the DABRX
architecture as defined by version 2.02 of PA; else not
supported.</para>
</entry>
</row>
<row>
<entry>
<para>5</para>
</entry>
<entry>
<para>User Accessible SPRG3</para>
</entry>
<entry>
<para>The value of 1 indicates support for accessing SPRG3 in
Problem State; else SPRG3 is not accessible in Problem
State.</para>
</entry>
</row>
<row>
<entry>
<para>6</para>
</entry>
<entry>
<para>Reading an invalid SLB entry returns zeros.</para>
</entry>
<entry>
<para>The value of 1 indicates that reading an invalid SLB
entry always returns zeros; else non-zero values may be
returned.</para>
</entry>
</row>
<row>
<entry>
<para>7</para>
</entry>
<entry>
<para>Support for “110” value of the Page
Protection (PP) bits.</para>
</entry>
<entry>
<para>The value of 1 indicates support for “110”
value of the Page Protection (PP) bits as described by version
2.04 of PA; else “110” is not supported.as
described by 2.04 of PA.</para>
</entry>
</row>
<row>
<entry morerows="7">
<para>2</para>
</entry>
<entry>
<para>0</para>
</entry>
<entry>
<para>Virtualized Partition Memory (VPM)</para>
</entry>
<entry>
<para>The value of 1 indicates support for Virtualized
Partition Memory (VPM) as described by version 2.04 of PA; else
not supported.</para>
</entry>
</row>
<row>
<entry>
<para>1</para>
</entry>
<entry>
<para>2.05 Data Stream Support</para>
</entry>
<entry>
<para>The value of 1 indicates that data streams as described
by version 2.05 of PA are supported; else not supported.</para>
</entry>
</row>
<row>
<entry>
<para>2</para>
</entry>
<entry>
<para>Reserved</para>
</entry>
<entry>
<para>Reserved bits within defined bytes
<emphasis>shall</emphasis> be zero.</para>
</entry>
</row>
<row>
<entry>
<para>3</para>
</entry>
<entry>
<para>Data Address Register (DAR) set on an alignment
interrupt.</para>
</entry>
<entry>
<para>The value of 1 indicates that the DAR is set on an
alignment interrupt as described by version 2.01 of PA; else
the DAR is not set on alignment interrupt as described by
version 2.01 of PA.</para>
</entry>
</row>
<row>
<entry>
<para>4</para>
</entry>
<entry>
<para>Reserved</para>
</entry>
<entry>
<para>Reserved bits within defined bytes
<emphasis>shall</emphasis> be zero.</para>
</entry>
</row>
<row>
<entry>
<para>5</para>
</entry>
<entry>
<para>Program Priority Register (PPR)</para>
</entry>
<entry>
<para>The value of 1 indicates that the PPR is implemented as
described by version 2.03 of PA; else the PPR is not
implemented as described by version 2.03 of PA.</para>
</entry>
</row>
<row>
<entry>
<para>6</para>
</entry>
<entry>
<para>2.02 Data Stream Support</para>
</entry>
<entry>
<para>The value of 1 indicates that data streams as described
by version 2.02 of PA are supported; else not supported.</para>
</entry>
</row>
<row>
<entry>
<para>7</para>
</entry>
<entry>
<para>2.06 Data Stream Support</para>
</entry>
<entry>
<para>The value of 1 indicates that data streams as described
by version 2.06 of PA are supported; else the 2.06 version data
streams are not supported.</para>
</entry>
</row>
<row>
<entry morerows="2">
<para>3</para>
</entry>
<entry>
<para>0</para>
</entry>
<entry>
<para>LSD in DSCR(Bit 58)</para>
</entry>
<entry>
<para>The value of 1indicates that “Load Stream
Disable” bit of the Data Stream Control Register is
implemented</para>
</entry>
</row>
<row>
<entry>
<para>1</para>
</entry>
<entry>
<para>URG in DSCR (Bits 55::57)</para>
</entry>
<entry>
<para>The value of 1 indicates that the “Depth Attainment
Urgency” field of the Data Stream Control Register is
implemented.</para>
</entry>
</row>
<row>
<entry>
<para>2-7</para>
</entry>
<entry>
<para>Reserved</para>
</entry>
<entry>
<para>Reserved bits within defined bytes
<emphasis>shall</emphasis> be zero.</para>
</entry>
</row>
<row>
<entry morerows="2">
<para>4</para>
</entry>
<entry nameend="c3" namest="c2">
<para>Storage Order Options</para>
</entry>
<entry>
<para>Byte bits define the availability of specific
options</para>
</entry>
</row>
<row>
<entry>
<para>0</para>
</entry>
<entry>
<para>2.06 Strong Storage Order</para>
</entry>
<entry>
<para>The value of 1 indicates that Strong Storage Order as
defined by version 2.06 of PA is supported; else not.</para>
</entry>
</row>
<row>
<entry>
<para>1-7</para>
</entry>
<entry>
<para>Reserved for future storage order options</para>
</entry>
<entry>
<para>Reserved bits within defined bytes
<emphasis>shall</emphasis> be zero.</para>
</entry>
</row>
<row>
<entry morerows="4">
<para>5</para>
</entry>
<entry>
<para>0</para>
</entry>
<entry>
<para>Little Endian</para>
</entry>
<entry>
<para>The value of 1indicates support for Little Endian as
described by version 2.03 of PA; else not supported.</para>
</entry>
</row>
<row>
<entry>
<para>1</para>
</entry>
<entry>
<para>Come From Address Register (CFAR)</para>
</entry>
<entry>
<para>The value of 1 indicates that the CFAR is implemented as
described by version 2.05 of PA; else the CFAR is not
implemented as described by version 2.05 of PA.</para>
</entry>
</row>
<row>
<entry>
<para>2</para>
</entry>
<entry>
<para>Elemental Barriers</para>
</entry>
<entry>
<para>The value of 1 indicates that elemental barriers are
supported; else elemental barriers are not supported.</para>
</entry>
</row>
<row>
<entry>
<para>3</para>
</entry>
<entry>
<para>2.07 load/store quadword</para>
</entry>
<entry>
<para>The value of 1 indicates that the load/store quadword
category as described by version 2.07 of POWER ISA is
supported; else the 2.07 version load/store quadword category
is not supported.</para>
</entry>
</row>
<row>
<entry>
<para>4-7</para>
</entry>
<entry>
<para>Reserved</para>
</entry>
<entry>
<para>Reserved bits within defined bytes
<emphasis>shall</emphasis> be zero.</para>
</entry>
</row>
<row>
<entry morerows="2">
<para>6-7</para>
</entry>
<entry nameend="c4" namest="c2">
<para>Data Streaming Specifications</para>
</entry>
</row>
<row>
<entry>
<para>0</para>
</entry>
<entry>
<para>2.07 Data Streaming Support</para>
</entry>
<entry>
<para>The value of 1 indicates that data streams as described
by version 2.07 of POWER ISA are supported; else the 2.07
version data streams are not supported.</para>
</entry>
</row>
<row>
<entry>
<para>1-7</para>
</entry>
<entry>
<para>Reserved</para>
</entry>
<entry>
<para>Reserved bits within defined bytes
<emphasis>shall</emphasis> be zero.</para>
</entry>
</row>
<row>
<entry>
<para>8-15</para>
</entry>
<entry>
<para>0-7</para>
</entry>
<entry>
<para>Reserved Co-Processor Option</para>
</entry>
<entry>
<para>Individual non-zero bits indicate available coprocessor
types per their architected ACOP bit locations. (the value
0x0000000000000000 indicates that moving to/from the ACOP SPR
or the ICSWX instruction should not be attempted)</para>
</entry>
</row>
<row>
<entry morerows="2">
<para>16-17</para>
</entry>
<entry nameend="c4" namest="c2">
<para>Level of Vector Category Support</para>
</entry>
</row>
<row>
<entry>
<para>0</para>
</entry>
<entry>
<para>2.07 Vector Support</para>
</entry>
<entry>
<para>The value of 1 indicates that the vector category as
described by version 2.07 of POWER ISA is supported; else the
2.07 version vector category is not supported.</para>
</entry>
</row>
<row>
<entry>
<para>1-7</para>
</entry>
<entry>
<para>Reserved</para>
</entry>
<entry>
<para>Reserved bits within defined bytes
<emphasis>shall</emphasis> be zero.</para>
</entry>
</row>
<row>
<entry morerows="2">
<para>18-19</para>
</entry>
<entry nameend="c4" namest="c2">
<para>Level of Vector Scalar Category Support</para>
</entry>
</row>
<row>
<entry>
<para>0</para>
</entry>
<entry>
<para>2.07 Vector Scalar Support</para>
</entry>
<entry>
<para>The value of 1 indicates that the vector scalar category
as described by version 2.07 of POWER ISA is supported; else
the 2.07 version vector scalar category is not
supported.</para>
</entry>
</row>
<row>
<entry>
<para>1-7</para>
</entry>
<entry>
<para>Reserved</para>
</entry>
<entry>
<para>Reserved bits within defined bytes
<emphasis>shall</emphasis> be zero.</para>
</entry>
</row>
<row>
<entry morerows="2">
<para>20-21</para>
</entry>
<entry nameend="c4" namest="c2">
<para>Level of Vector.XOR Category Support</para>
</entry>
</row>
<row>
<entry>
<para>0</para>
</entry>
<entry>
<para>2.07 Vector.CRYPTO Support</para>
</entry>
<entry>
<para>The value of 1 indicates that the vector.crypto category as
described by version 2.07 of POWER ISA is supported; else the
2.07 version vector.crypto category is not supported.</para>
</entry>
</row>
<row>
<entry>
<para>1-7</para>
</entry>
<entry>
<para>Reserved</para>
</entry>
<entry>
<para>Reserved bits within defined bytes
<emphasis>shall</emphasis> be zero.</para>
</entry>
</row>
<row>
<entry morerows="2">
<para>22-23</para>
</entry>
<entry nameend="c4" namest="c2">
<para>Level of Transactional Memory Category Support</para>
</entry>
</row>
<row>
<entry>
<para>0</para>
</entry>
<entry>
<para>2.07 Transactional Memory Support</para>
</entry>
<entry>
<para>The value of 1 indicates that the Transactional Memory
Category as described by version 2.07 of POWER ISA is
supported; else the 2.07 version Transactional Memory Category
is not supported.</para>
</entry>
</row>
<row>
<entry>
<para>1-7</para>
</entry>
<entry>
<para>Reserved</para>
</entry>
<entry>
<para>Reserved bits within defined bytes
<emphasis>shall</emphasis> be zero.</para>
</entry>
</row>
<row>
<entry>
<para>24-255</para>
</entry>
<entry>
<para>0-7</para>
</entry>
<entry>
<para>Undefined</para>
</entry>
<entry>
<para>Readers
<emphasis>shall</emphasis> ignore undefined bytes if
present.</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“ibm,pi-features”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis>: Indicates level of support of
processor implementation specific options not described by the Processor
Architecture.</para>
<para><emphasis>prop-encoded-array</emphasis>: One or more
<emphasis>pi-attribute-descriptor</emphasis> (s).</para>
<para><emphasis>pi-attribute-descriptor</emphasis>: Consists of a
<emphasis>pi-attribute-header</emphasis> immediately followed by a
<emphasis>pi-attribute-specifier.</emphasis></para>
<para><emphasis>pi-attribute-header</emphasis>: Consists of two bytes. The first
byte is an unsigned integer representing a value from 1 to 254. The first
byte specifies the number of bytes implemented by the platform of the
<emphasis>pi-attribute-specifier</emphasis>. The second byte is an
unsigned integer specifying the
<emphasis>pi-attribute-specifier-type</emphasis>.</para>
<para><emphasis>pi-attribute-specifier</emphasis>: The
<emphasis>pi-attribute-specifier</emphasis> is defined by the
<emphasis>pi-attribute-specifier-type</emphasis> of the
<emphasis>pi-attribute-header.</emphasis> The
<emphasis>pi-attribute-specifier</emphasis> for the
<emphasis>pi-attribute-specifier-type</emphasis> value of 0 is defined by
<xref linkend="dbdoclet.50569374_22443" />.</para>
<table frame="all" pgwide="1" xml:id="dbdoclet.50569374_22443">
<title>Definition for
<emphasis>‘</emphasis>
<emphasis>pi-attribute-specifier-type</emphasis> value 0</title>
<tgroup cols="4">
<colspec colname="c1" colwidth="20*" align="center" />
<colspec colname="c2" colwidth="10*" align="center" />
<colspec colname="c3" colwidth="20*" align="center" />
<colspec colname="c4" colwidth="50*" 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">Attribute Name</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Description</emphasis>
</para>
</entry>
</row>
</thead>
<tbody>
<row>
<entry morerows="3">
<para>0</para>
</entry>
<entry>
<para>0</para>
</entry>
<entry>
<para>P4 Data Address Register (DAR) setting on alignment
interrupt.</para>
</entry>
<entry>
<para>The value of 1 indicates that the DAR is set on an
alignment interrupt as described by version 2.01 of PA except
for the case where the interrupt is caused by an unsupported
access to cache inhibited space. In this case, the DAR will be
set to the effective address of the first access into the cache
inhibited space. The value of 0 indicates that the processor
does not adhere to this behavior.</para>
</entry>
</row>
<row>
<entry>
<para>1</para>
</entry>
<entry>
<para>Reserved</para>
</entry>
<entry>
<para>Reserved bits within defined bytes
<emphasis>shall</emphasis> be zero.</para>
</entry>
</row>
<row>
<entry>
<para>2</para>
</entry>
<entry>
<para>Ordered Thread Activation/Deactivation</para>
</entry>
<entry>
<para>The value of 1 indicates that the
<emphasis role="bold"><literal>“ibm,ppc-interrupt-server-#s”</literal></emphasis> property
conveys the order that threads need to be activated and
deactivated in to achieve optimal performance; else no need to
activate and deactivate threads in order.</para>
</entry>
</row>
<row>
<entry>
<para>3-7</para>
</entry>
<entry>
<para>Reserved</para>
</entry>
<entry>
<para>Reserved bits within defined bytes
<emphasis>shall</emphasis> be zero.</para>
</entry>
</row>
<row>
<entry>
<para>1-255</para>
</entry>
<entry>
<para>0-7</para>
</entry>
<entry>
<para>Reserved</para>
</entry>
<entry>
<para>Reserved bits within defined bytes
<emphasis>shall</emphasis> be zero.</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“ibm,negotiated-pa-features”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis>: Indicates level
of support negotiated via the
<emphasis role="bold"><literal>ibm,client-architecture-support</literal></emphasis>
method (See
<xref linkend="dbdoclet.50569368_91814" />) of several extended features
of the Processor Architecture.</para>
<para><emphasis>prop-encoded-array</emphasis>: One or more
<emphasis>negotiated-pa-attribute-descriptor</emphasis> (s).</para>
<para><emphasis>negotiated-pa-attribute-descriptor</emphasis>: Consists of a
<emphasis>negotiated-pa-attribute-header</emphasis> immediately followed
by a
<emphasis>negotiated-pa-attribute-specifier.</emphasis></para>
<para><emphasis>negotiated-pa-attribute-header</emphasis>: Consists of two
bytes. The first byte is an unsigned integer representing a value from 1
to 254. The first byte specifies the number of bytes implemented by the
platform of the
<emphasis>negotiated-pa-attribute-specifier</emphasis>. The second byte
is an unsigned integer specifying the
<emphasis>negotiated-pa-attribute-specifier-type</emphasis>.</para>
<para><emphasis>negotiated-pa-attribute-specifier</emphasis>: The
<emphasis>negotiated-pa-attribute-specifier</emphasis> is defined by the
<emphasis>negotiated-pa-attribute-specifier-type</emphasis> of the
<emphasis>negotiated-pa-attribute-header.</emphasis> The
<emphasis>negotiated-pa-attribute-specifier</emphasis> for the
<emphasis>negotiated-pa-attribute-specifier-type</emphasis> value of 0 is
defined by
<xref linkend="dbdoclet.50569374_79508" />.</para>
<table frame="all" pgwide="1" xml:id="dbdoclet.50569374_79508">
<title>Definition for
<emphasis>negotiated-pa-attribute-specifier</emphasis>
<emphasis>negotiated-pa-attribute-specifier-type</emphasis> value
0</title>
<tgroup cols="4">
<colspec colname="c1" colwidth="20*" align="center" />
<colspec colname="c2" colwidth="10*" align="center" />
<colspec colname="c3" colwidth="20*" align="center" />
<colspec colname="c4" colwidth="50*" 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">Attribute Name</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Description</emphasis>
</para>
</entry>
</row>
</thead>
<tbody>
<row>
<entry morerows="1">
<para>0</para>
</entry>
<entry>
<para>0</para>
</entry>
<entry>
<para>TC Set</para>
</entry>
<entry>
<para>The value of 1 indicates that the TC bit is implemented
as described by version 2.05 of PA and set to a value of 1;
else the TC bit is not implemented as described by version 2.05
of PA or not set to a value of 1.</para>
</entry>
</row>
<row>
<entry>
<para>1-7</para>
</entry>
<entry>
<para>Reserved</para>
</entry>
<entry>
<para>Reserved bits within defined bytes
<emphasis>shall</emphasis> be zero.</para>
</entry>
</row>
<row>
<entry>
<para>1-255</para>
</entry>
<entry>
<para>0-7</para>
</entry>
<entry>
<para>Reserved</para>
</entry>
<entry>
<para>Reserved bits within defined bytes
<emphasis>shall</emphasis> be zero.</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“ibm,raw-pi-features”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis>: Indicates level of support of
processor implementation specific options not described by the Processor
Architecture and not supported on partitions that contain the
<emphasis role="bold"><literal>“ibm,migratable-partition”</literal></emphasis> property.</para>
<para><emphasis>prop-encoded-array</emphasis>: One or more
<emphasis>raw-pi-attribute-descriptor</emphasis> (s).</para>
<para><emphasis>raw-pi-attribute-descriptor</emphasis>: Consists of a
<emphasis>raw-pi-attribute-header</emphasis> immediately followed by a
<emphasis>raw-pi-attribute-specifier.</emphasis></para>
<para><emphasis>raw-pi-attribute-header</emphasis>: Consists of two bytes. The
first byte is an unsigned integer representing a value from 1 to 254. The
first byte specifies the number of bytes implemented by the platform of
the
<emphasis>raw-pi-attribute-specifier</emphasis>. The second byte is an
unsigned integer specifying the
<emphasis>raw-pi-attribute-specifier-type</emphasis>.</para>
<para><emphasis>raw-pi-attribute-specifier</emphasis>: The
<emphasis>raw-pi-attribute-specifier</emphasis> is defined by the
<emphasis>raw-pi-attribute-specifier-type</emphasis> of the
<emphasis>raw-pi-attribute-header.</emphasis> The
<emphasis>raw-pi-attribute-specifier</emphasis> for the
<emphasis>raw-pi-attribute-specifier-type</emphasis> value of 0 is defined
by
<xref linkend="dbdoclet.50569374_66103" />.</para>
<table frame="all" pgwide="1" xml:id="dbdoclet.50569374_66103">
<title>Definition for
<emphasis>raw-pi-attribute-specifier</emphasis>
<emphasis>raw-pi-attribute-specifier-type</emphasis> value 0</title>
<tgroup cols="4">
<colspec colname="c1" colwidth="20*" align="center" />
<colspec colname="c2" colwidth="10*" align="center" />
<colspec colname="c3" colwidth="20*" align="center" />
<colspec colname="c4" colwidth="50*" 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">Attribute Name</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Description</emphasis>
</para>
</entry>
</row>
</thead>
<tbody>
<row>
<entry morerows="1">
<para>0</para>
</entry>
<entry>
<para>0</para>
</entry>
<entry>
<para>FPR GPR Move Instructions</para>
</entry>
<entry>
<para>The value of 1 indicates that the PA processor defined by
this CPU node implements the
<emphasis>mftgpr</emphasis> and
<emphasis>mffgpr</emphasis> instructions as described by IBM
<emphasis>POWER6® CEC Book IV Implementation
Features</emphasis>; else not supported.</para>
</entry>
</row>
<row>
<entry>
<para>1-7</para>
</entry>
<entry>
<para>Reserved</para>
</entry>
<entry>
<para>Reserved bits within defined bytes
<emphasis>shall</emphasis> be zero.</para>
</entry>
</row>
<row>
<entry>
<para>1-255</para>
</entry>
<entry>
<para>0-7</para>
</entry>
<entry>
<para>Reserved</para>
</entry>
<entry>
<para>Reserved bits within defined bytes
<emphasis>shall</emphasis> be zero.</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“ibm,pa-optimizations”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis>: Indicates the level of support of
performance variabilities described by the Processor Architecture.</para>
<para><emphasis>prop-encoded-array</emphasis>: One or more
<emphasis>pa-optimization-attribute-descriptor</emphasis> (s).</para>
<para><emphasis>pa-optimization-attribute-descriptor</emphasis>: Consists of a
<emphasis>pa-optimization-attribute-header</emphasis> immediately followed
by a
<emphasis>pa-optimization-attribute-specifier.</emphasis></para>
<para><emphasis>pa-optimization-attribute-header</emphasis>: Consists of two
bytes. The first byte is an unsigned integer representing a value from 1
to 254. The first byte specifies the number of bytes implemented by the
platform of the
<emphasis>pa-optimization-attribute-specifier</emphasis>. The second byte
is an unsigned integer specifying the
<emphasis>pa-optimization-attribute-specifier-type</emphasis>.</para>
<para><emphasis>pa-optimization-attribute-specifier</emphasis>: The
<emphasis>pa-optimization-attribute-specifier</emphasis> is defined by the
<emphasis>pa-optimization-attribute-specifier-type</emphasis> of the
<emphasis>pa-optimization-attribute-header.</emphasis> The
<emphasis>pa-optimization-attribute-specifier</emphasis> for the
<emphasis>pa-optimization-attribute-specifier-type</emphasis> value of 0
is defined by
<xref linkend="dbdoclet.50569374_95694" />.</para>
<table frame="all" pgwide="1" xml:id="dbdoclet.50569374_95694">
<title>Definition for
<emphasis>pa-optimization-attribute-specifier</emphasis>
<emphasis>pa-optimization-attribute-specifier-type</emphasis> value
0</title>
<tgroup cols="4">
<colspec colname="c1" colwidth="20*" align="center" />
<colspec colname="c2" colwidth="10*" align="center" />
<colspec colname="c3" colwidth="20*" align="center" />
<colspec colname="c4" colwidth="50*" 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">Attribute Name</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Description</emphasis>
</para>
</entry>
</row>
</thead>
<tbody>
<row>
<entry>
<para>0</para>
</entry>
<entry>
<para>0-7</para>
</entry>
<entry>
<para>Stream IDs</para>
</entry>
<entry>
<para>The value is an unsigned quantity indicating the number
of data stream IDs supported. The value of this byte
<emphasis>shall</emphasis> be zero for processors that do not
support data streams.</para>
</entry>
</row>
<row>
<entry>
<para>1</para>
</entry>
<entry>
<para>0-7</para>
</entry>
<entry>
<para>Default Prefetch Depth</para>
</entry>
<entry>
<para>The value in the Default Prefetch Depth (DPFD) field of
the Logical Partitioning Control Register (LPCR) as described
by version 2.05 of PA. Unimplemented high order bits
<emphasis>shall</emphasis> be zero. This byte is valid only if
the “2.05 Data Stream Support” bit of
<emphasis role="bold"><literal>“ibm,pa-features”</literal></emphasis> is set to
one; else this byte is undefined.</para>
</entry>
</row>
<row>
<entry>
<para>2-255</para>
</entry>
<entry>
<para>0-7</para>
</entry>
<entry>
<para>Reserved</para>
</entry>
<entry>
<para>Reserved bits within defined bytes
<emphasis>shall</emphasis> be zero.</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="dbdoclet.50569374_58783">
<title>TLB properties</title>
<para>Since the PA defines the MMU as being part of the processor, the
properties defined by Section 3.6.5 of
<xref linkend="dbdoclet.50569387_45524" />and the following MMU-related
properties shall be presented under “cpu” nodes.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold"><literal>“tlb-size”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents
the total number of TLB entries.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“tlb-sets”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents
the number of associativity sets of the TLB. A value of 1 indicates that the TLB is
fully-associative.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“tlb-split”</literal></emphasis></term>
<listitem>
<para>This property, if present, shall indicate that the TLB has a split
organization. The absence of this property shall indicate that the TLB
has a unified organization.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“d-tlb-size”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents
the total number of d-TLB entries.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“d-tlb-sets”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents
the number of associativity sets of the d-TLB. A value of 1 indicates that the
d-TLB is fully-associative.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“i-tlb-size”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that
represents the total number of i-TLB entries.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“i-tlb-sets”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents
the number of associativity sets of the i-TLB. A value of 1 indicates that the
i-TLB is fully-associative.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“tlbia”</literal></emphasis></term>
<listitem>
<para><emphasis>prop-encoded-array</emphasis>: <none></para>
<para>This property, if present, indicates that the PA processor defined
by this CPU node implements the<emphasis>tlbia</emphasis> instruction. The absence
of this property indicates that the PA processor defined by this CPU node does
not support the <emphasis>tlbia</emphasis> instruction.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section>
<title>Internal (L1) cache properties</title>
<para>The PA defines a Harvard-style cache architecture; however, unified
caches are an implementation option. All of the PA cache instructions act
upon a cache “block”. The coherence block size, if different
from the cache block size, is reported via the
<emphasis role="bold"><literal>“i-cache-line-size”</literal></emphasis> and
<emphasis role="bold"><literal>“d-cache-line-size”</literal></emphasis> properties. The
internal (also referred to as “L1”) caches of PA processors
are represented in the OF device tree by the following properties
contained under
<emphasis role="bold"><literal>“cpu”</literal></emphasis> nodes.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold"><literal>“cache-unified”</literal></emphasis></term>
<listitem>
<para>This property, if present, indicates that the internal cache has a
physically unified organization. Absence of this property indicates that
the internal caches are implemented as separate instruction and data
caches. Unless otherwise noted, separate instruction and data caches
require the architected instruction sequence for instruction modification
so that data cache stores appear in the instruction cache.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“i-cache-size”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents
the total size (in bytes) of the internal instruction cache.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“i-cache-sets”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents
number of associativity sets of the internal instruction cache. A value of 1
signifies that the instruction cache is fully associative.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“i-cache-block-size”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents
the internal instruction cache's block size, in bytes.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“d-cache-size”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents
the total size (in bytes) of the internal data cache.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“d-cache-sets”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents
number of associativity sets of the internal data cache. A value of 1 signifies
that the data cache is fully associative.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“d-cache-block-size”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents
the internal (L1) data cache's block size, in bytes.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“l2-cache”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents
the next level of cache in the memory hierarchy.</para>
<para>Absence of this property indicates that no further levels of cache
are present. If present, its value is the
<emphasis>phandle</emphasis> of the device node that represents the next
level of cache.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“i-cache-line-size”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents
the internal instruction cache's coherency block size (line size), in bytes,
if different than its cache block size.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“d-cache-line-size”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents
the internal data cache's coherency block size (line size), in bytes, if different
than its cache block size.</para>
<para><emphasis role="bold">Note:</emphasis> If this is a unified cache, the
corresponding i- and d- sizes must be equal.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="dbdoclet.50569374_34579">
<title>Memory Management Unit properties</title>
<para>To aid a client in “taking over” the translation
mechanism and still interact with OF (via the client interface), the
client needs to know what translations have been established by OF. The
following standard property shall exist within the package to which the
“mmu” property of the /chosen package refers.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold"><literal>“translations”</literal></emphasis></term>
<listitem>
<para>This property, consisting of sets of translations, defines the
currently active translations that have been established by OF (e.g.,
using map). Each set has the following format:</para>
<programlisting><![CDATA[(virt size phys mode)]]></programlisting>
<para>Each value is encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section>
<title>SLB properties</title>
<para>Since the PA defines the MMU as being part of the processor, the
properties defined by Section 3.6.5 of
<xref linkend="dbdoclet.50569387_45524" />and the following MMU-related
properties as appropriate to the specific processor implementation shall
be presented under “cpu” nodes.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold"><literal>“slb-size”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that
represents the total number of SLB entries.</para>
<para><emphasis role="bold">Note:</emphasis>
<xref linkend="dbdoclet.50569387_99718" />requires that the SLB be
fully-associative, and appear to be a unified organization. Therefore,
properties to report SLB sets, split, and sizes and sets of i and d SLBs
are not defined.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
<section>
<title>Ancillary (L2,L3...) cache node properties</title>
<para>Some systems might include secondary (L2) or tertiary (L3), etc.
cache(s). As with the L1 caches, they can be implemented as either
Harvard-style or unified. Unlike the L1 properties, that are contained
within the
<emphasis role="bold"><literal>“cpu”</literal></emphasis> nodes, the properties of ancillary
caches are contained within other device tree nodes.</para>
<para>The following properties define the characteristics of such
ancillary caches. These properties shall be contained within a child node
of one of the CPU nodes or, for platforms that support dynamic
reconfiguration of cpus, the CPUS node; this is to allow path-name access
to the node. These properties shall always be contained within a child
node of the CPUS node. All
<emphasis role="bold"><literal>“cpu”</literal></emphasis> nodes that share the same ancillary
cache (including the cpu node under which the ancillary cache node is
contained) shall contain an
<emphasis role="bold"><literal>“l2-cache”</literal></emphasis> property whose value is the
<emphasis>phandle</emphasis> of that ancillary cache node.</para>
<para>
<emphasis role="bold">Note:</emphasis> The
<emphasis role="bold"><literal>“l2-cache”</literal></emphasis> property shall be used in one
level of the cache hierarchy to represent the next level. The device node
for a subsequent level shall appear as a child of one of the caches in
the hierarchy to allow path-name traversal. The preceding sentence does
not apply to platforms that support dynamic reconfiguration of cpus or
platforms designed after 07/2005.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold"><literal>“device_type”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>; the device_type of ancillary cache
nodes shall be
<emphasis role="bold"><literal>“cache”</literal></emphasis>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“cache-unified”</literal></emphasis></term>
<listitem>
<para>This property, if present, indicates that the cache at this node
has a physically unified organization. Absence of this property indicates
that the caches at this node are implemented as separate instruction and
data caches. Unless otherwise noted, separate instruction and data caches
require the architected instruction sequence for instruction modification
so that data cache stores appear in the instruction cache.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“i-cache-size”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents the total size (in
bytes) of the instruction cache at this node.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“i-cache-sets”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents number of associativity
sets of the instruction cache at this node. A value of 1 signifies that
the instruction cache is fully associative.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“d-cache-size”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents the total size (in
bytes) of the data cache at this node.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“d-cache-sets”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents number of associativity
sets of the instruction cache at this node. A value of 1 signifies that
the instruction cache is fully associative.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“l2-cache”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents the next level of cache
in the memory hierarchy.</para>
<para>Absence of this property indicates that no further levels of cache
are present. If present, its value is the
<emphasis>phandle</emphasis> of the device node that represents the cache
at the next level.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“i-cache-line-size”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents the internal instruction
cache's line size, in bytes, if different than its block size.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“d-cache-line-size”</literal></emphasis></term>
<listitem>
<para>Standard <emphasis>property name</emphasis>, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, that represents the internal data
cache's line size, in bytes, if different than its block size.</para>
<para>
<emphasis role="bold">Note:</emphasis> If this is a unified cache, the corresponding
i- and d- sizes must be equal.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
<section xml:id="dbdoclet.50569374_77797">
<title>Methods</title>
<para>This section describes the additional standard methods required of a
PA OF implementation.</para>
<section>
<title>MMU related methods</title>
<para>The MMU methods defined by section 3.6.5. of
<xref linkend="dbdoclet.50569387_45524" />shall be implemented by CPU
nodes. The value of the
<emphasis role="bold"><literal>mode</literal></emphasis> parameter for the relevant methods (e.g.,
<emphasis role="bold"><literal>map</literal></emphasis>) shall be the value that is contained within
PTEs that control Write-through, Cache-Inhibit, Memory-coherent, Guarded
and the 2 protection bits; thus, its format is:
<emphasis role="bold"><literal>WIMGxPP</literal></emphasis>, where x is a reserved bit that shall be 0.
In order for I/O accesses to be properly performed in a LoPAR system,
address ranges that are mapped by
<emphasis role="bold"><literal>map-in</literal></emphasis> shall be marked as Cache-Inhibited,
Guarded.</para>
<para>The default mode (i.e., the mode specified when the value of the
<emphasis role="bold"><literal>mode</literal></emphasis> argument is -1) for the
<emphasis role="bold"><literal>map-in</literal></emphasis> and
<emphasis>modify</emphasis> MMU methods of CPU nodes is defined as
follows:</para>
<para>If the beginning of the physical address range affected by the
operation refers to system memory, the values for
<emphasis role="bold"><literal>WIMGxPP</literal></emphasis> shall be W=0, I=0, M=0, G=1, PP=10.</para>
<para>If the beginning of the physical address range affected by the
operation refers to an I/O address, the values for WIMGxPP shall be W=1,
I=1, M=0, G=1, PP=10.</para>
</section>
</section>
<section>
<title>Client Interface Requirements</title>
<para>A PA OF implementation shall implement a client interface (as defined
in chapter 6 of
<xref linkend="dbdoclet.50569387_45524" />) according to the specifications
contained within this section.</para>
<section>
<title>Calling Conventions</title>
<para>To invoke a client interface service, a
<emphasis>client program</emphasis> constructs a client interface
<emphasis>argument array</emphasis> as specified in the core OF document,
places its address in
<emphasis role="bold"><literal>r3</literal></emphasis> and transfers to the
<emphasis>client interface handler</emphasis>, with the return address in
<emphasis role="bold"><literal>lr</literal></emphasis>. (A typical way of accomplishing this is to copy
the
<emphasis>client interface handler</emphasis>'s address into
<emphasis role="bold"><literal>ctr</literal></emphasis> and executing a
<emphasis role="bold"><literal>bctrl</literal></emphasis>.)</para>
<para>The term “preserved” below shall mean that the register
has the same value when returning as it did when the call was
made.</para>
<table frame="all" pgwide="1">
<title>Register usage conventions</title>
<tgroup cols="6">
<colspec colname="c1" colwidth="16*" align="center" />
<colspec colname="c2" colwidth="16*" />
<colspec colname="c3" colwidth="16*" />
<colspec colname="c4" colwidth="16*" />
<colspec colname="c5" colwidth="16*" />
<colspec colname="c6" colwidth="16*" align="center" />
<thead>
<row>
<entry>
<para>
<emphasis role="bold">Register(s)</emphasis>
</para>
</entry>
<entry nameend="c3" namest="c2" align="center">
<para>
<emphasis role="bold">Value -- real-mode</emphasis>
</para>
</entry>
<entry nameend="c5" namest="c4" align="center">
<para>
<emphasis role="bold">Value -- virt-mode</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Notes</emphasis>
</para>
</entry>
</row>
</thead>
<tbody>
<row>
<entry>
<para> </para>
</entry>
<entry>
<para>If either the FWNMI, or LPAR option is implemented</para>
</entry>
<entry>
<para>If neither the FWNMI or LPAR option is implemented</para>
</entry>
<entry>
<para>If either the FWNMI, or LPAR option is implemented</para>
</entry>
<entry>
<para>If neither the FWNMI or LPAR option is implemented</para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para>msr</para>
</entry>
<entry>
<para>client interface shall preserve</para>
</entry>
<entry>
<para>client interface shall preserve</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para>client interface shall not modify</para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para>cr</para>
</entry>
<entry>
<para>client interface shall preserve</para>
</entry>
<entry>
<para>client interface shall preserve</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para>1</para>
</entry>
</row>
<row>
<entry>
<para>r1-r2</para>
</entry>
<entry>
<para>client interface shall preserve</para>
</entry>
<entry>
<para>client interface shall preserve</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para>r3</para>
</entry>
<entry>
<para>argument array address on client interface entry</para>
</entry>
<entry>
<para>argument array address on client interface entry</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para>2</para>
</entry>
</row>
<row>
<entry>
<para> </para>
</entry>
<entry>
<para>result value (true or false) on client interface
return</para>
</entry>
<entry>
<para>result value (true or false) on client interface
return</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para>2</para>
</entry>
</row>
<row>
<entry>
<para>r13-r31</para>
</entry>
<entry>
<para>client interface shall preserve</para>
</entry>
<entry>
<para>client interface shall preserve</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para>sprg0, sprg1, and sprg3</para>
</entry>
<entry>
<para>client interface shall preserve</para>
</entry>
<entry>
<para>client interface shall not modify</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para>fpscr</para>
</entry>
<entry>
<para>client interface shall preserve</para>
</entry>
<entry>
<para>client interface shall preserve</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para>f0-f31</para>
</entry>
<entry>
<para>client interface shall preserve</para>
</entry>
<entry>
<para>client interface shall preserve</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para>lr,</para>
<para>ctr,</para>
<para>xer</para>
</entry>
<entry>
<para>undefined</para>
</entry>
<entry>
<para>undefined</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para>sr0-sr15</para>
</entry>
<entry>
<para>client interface shall preserve</para>
</entry>
<entry>
<para>client interface shall preserve</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para>client interface shall not modify</para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para>vr0-vr31</para>
</entry>
<entry>
<para>client interface shall preserve</para>
</entry>
<entry>
<para>client interface shall preserve</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para>same as real mode</para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para>dec</para>
</entry>
<entry>
<para>client interface shall preserve</para>
</entry>
<entry>
<para>client interface shall not modify</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para>same as real mode</para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para>Other SPRs</para>
</entry>
<entry>
<para>client interface shall preserve</para>
</entry>
<entry>
<para>client interface shall preserve</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para>same as real-mode</para>
</entry>
<entry>
<para>3</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
<para><emphasis role="bold">Notes:</emphasis></para>
<orderedlist>
<listitem>
<para>Only the non-volatile fields (
<emphasis>cr2-cr4</emphasis>) need to be preserved.</para>
</listitem>
<listitem>
<para>As defined by section 6.3.1. of
<xref linkend="dbdoclet.50569387_45524" />.</para>
</listitem>
<listitem>
<para>Other special purpose registers</para>
</listitem>
</orderedlist>
<para>The
<emphasis>client interface handler</emphasis> shall perform the service
specified by the contents of the argument array that begins at the
address in
<emphasis role="bold"><literal>r3</literal></emphasis>, place the return value (indicating success or
failure of the attempt to invoke the client interface service) back into
<emphasis role="bold"><literal>r3</literal></emphasis>, and return to the
<emphasis>client program</emphasis>. This is typically done by a Branch
to Link Register (
<emphasis role="bold"><literal>blr</literal></emphasis>).</para>
<para>The
<emphasis>client interface handler</emphasis> shall preserve the contents
of the Stack Pointer (r1), TOC Pointer (r2), Condition Register (
<emphasis role="bold"><literal>cr</literal></emphasis>) all non-volatile registers (r13-r31) and all
special purpose registers except lr, ctr and xer.</para>
<para>The preservation of r2 allows TOC-based client programs to function
correctly. OF shall
<emphasis>not</emphasis> depend upon whether its client is TOC-based or
not. If the client interface handler, itself, is TOC-based, it must
provide for the appropriate initialization of its
<emphasis role="bold"><literal>r2</literal></emphasis>.</para>
</section>
</section>
<section>
<title>Client Program Requirements</title>
<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 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>
</section>
<section>
<title>Initial Program State</title>
<para>This section defines the “initial program state”, the
execution environment that exists when the first machine instruction of a
<emphasis>client program</emphasis> of the format specified above begins
execution. Many aspects of the “initial program state” are
established by
<emphasis role="bold"><literal>init-program</literal></emphasis>, which sets the
<emphasis>saved program state</emphasis> so that subsequent execution of
<emphasis role="bold"><literal>go</literal></emphasis> will begin execution of the
<emphasis>client program</emphasis> with the specified environment.</para>
<section>
<title>Initial Register Values</title>
<para>Upon entry to the client program, the following registers shall
contain the following values:</para>
<table frame="all" pgwide="1" xml:id="dbdoclet.50569374_45461">
<title>Initial Register Values</title>
<?dbhtml table-width="80%" ?>
<?dbfo table-width="80%" ?>
<tgroup cols="3">
<colspec colname="c1" colwidth="30*" align="center" />
<colspec colname="c2" colwidth="60*" />
<colspec colname="c3" colwidth="10*" align="center" />
<thead>
<row>
<entry>
<para>
<emphasis role="bold">Register(s)</emphasis>
</para>
</entry>
<entry align="center">
<para>
<emphasis role="bold">Value</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Notes</emphasis>
</para>
</entry>
</row>
</thead>
<tbody>
<row>
<entry>
<para>msr</para>
</entry>
<entry>
<para>EE = 0, interrupts disabled</para>
</entry>
<entry>
<para>1</para>
</entry>
</row>
<row>
<entry>
<para> </para>
</entry>
<entry>
<para>PR = 0, supervisor state</para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para> </para>
</entry>
<entry>
<para>FP = 1, floating point enabled</para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para> </para>
</entry>
<entry>
<para>ME = 1, machine checks enabled</para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para> </para>
</entry>
<entry>
<para>FE0, FE1 = 0, floating point exceptions disabled</para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para> </para>
</entry>
<entry>
<para>IP, see
<xref linkend="dbdoclet.50569374_27751" /></para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para> </para>
</entry>
<entry>
<para>IR,DR, see
<xref linkend="dbdoclet.50569374_25139" /></para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para> </para>
</entry>
<entry>
<para>SF=0, 32-bit mode</para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para> </para>
</entry>
<entry>
<para>ILE,LE, little endian support</para>
</entry>
<entry>
<para>2</para>
</entry>
</row>
<row>
<entry>
<para>r1</para>
</entry>
<entry>
<para>See
<xref linkend="dbdoclet.50569374_27292" /></para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para>r2</para>
</entry>
<entry>
<para>0</para>
</entry>
<entry>
<para>3</para>
</entry>
</row>
<row>
<entry>
<para>r3</para>
</entry>
<entry>
<para>reserved for platform binding</para>
</entry>
<entry>
<para>4</para>
</entry>
</row>
<row>
<entry>
<para>r4</para>
</entry>
<entry>
<para>reserved for platform binding</para>
</entry>
<entry>
<para>4</para>
</entry>
</row>
<row>
<entry>
<para>r5</para>
</entry>
<entry>
<para>See
<xref linkend="dbdoclet.50569374_31886" /></para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para>r6, r7</para>
</entry>
<entry>
<para>See
<xref linkend="dbdoclet.50569374_13831" /></para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para>Other user mode registers</para>
</entry>
<entry>
<para>0</para>
</entry>
<entry>
<para> </para>
</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
<emphasis role="bold">Notes:</emphasis>
</para>
<orderedlist>
<listitem>
<para>OF will typically require the use of external interrupts for its
<emphasis>user interface</emphasis>. However, when a
<emphasis>client program</emphasis> is invoked, external interrupts shall
be disabled. If a
<emphasis>client program</emphasis> causes the invocation of the user
interface, external interrupts
<emphasis>may</emphasis> be re-enabled.</para>
</listitem>
<listitem>
<para>The 601 processor uses a different mechanism for controlling the
endian-mode of the processor. On the 601, the LE bit is contained in the
HID0 register; this bit controls the endian-mode of both program and
privileged states.</para>
</listitem>
<listitem>
<para>OF does not make any assumptions about whether a client program
is TOC-based or not. It is the responsibility of the client program to
set
<emphasis>r2</emphasis> to its TOC, if necessary.</para>
</listitem>
<listitem>
<para>As defined in the relevant section of the platform
binding.</para>
</listitem>
</orderedlist>
</section>
<section xml:id="dbdoclet.50569374_27292">
<title>Initial Stack</title>
<para>Client programs shall be invoked with a valid stack pointer (
<emphasis>r1</emphasis>) with at least 32 KB of memory available for
stack growth. The stack pointer shall be 16-byte aligned, reserving
sufficient room for a linkage area (32 bytes above the address in r1). If
the system is executing in Real-Mode, the value in r1 is a real address;
if in Virtual-Mode, the address in r1 is a mapped virtual address.</para>
</section>
<section xml:id="dbdoclet.50569374_31886">
<title>Client Interface Handler Address</title>
<para>When client programs are invoked,
<emphasis>r5</emphasis> shall contain the address of the entry point of
the
<emphasis>client interface handler</emphasis>. If the system is executing
in Real-Mode, the value in r5 is a real address; if in Virtual-Mode, the
address in r5 is a mapped virtual address.</para>
<para>
<emphasis role="bold">Note:</emphasis> This address points to the first instruction of
the
<emphasis>client interface handler</emphasis>, not to a procedure
descriptor.</para>
</section>
<section xml:id="dbdoclet.50569374_13831">
<title>Client Program Arguments</title>
<para>The calling program
<emphasis>may</emphasis> pass to the client an array of bytes of arbitrary
content; if this array is present, its address and length shall be passed
in registers
<emphasis>r6</emphasis> and
<emphasis>r7</emphasis>, respectively. For programs booted directly by
OF, the length of this array is zero. Secondary boot programs may use
this argument array to pass information to the programs that they
boot.</para>
<para>
<emphasis role="bold">Note:</emphasis> The OF standard makes no provision for
specifying such an array or its contents. Therefore, in the absence of
implementation-dependent extensions, a client program executed directly
from an OF implementation will not be passed such an array. However,
intermediate boot programs that simulate or propagate the OF client
interface to the programs that they load can provide such an array for
their clients.</para>
<para>
<emphasis role="bold">Note:</emphasis>
<emphasis>boot</emphasis> command line arguments, typically consisting of
the name of a file to be loaded by a secondary boot program followed by
flags selecting various secondary boot and OS options, are provided to
client programs via the
<emphasis role="bold"><literal>“bootargs”</literal></emphasis> and
<emphasis role="bold"><literal>“bootpath”</literal></emphasis> properties of the
<emphasis role="bold"><literal>/chosen</literal></emphasis> node.</para>
</section>
</section>
<section>
<title>Caching</title>
<para>The caches of the processor shall be enabled when the client
program is called. The I-cache shall be consistent with the D-cache for
all memory areas occupied by the client program. Memory areas allocated
on behalf of the client program shall be marked as cacheable. Accesses to
“I/O” devices (especially, to devices across
“bridges”) shall be made with the register access words
(e.g.,
<emphasis role="bold"><literal>%rl@</literal></emphasis>). All processors in a SMP system shall have the
same consistent view of all memory areas (for data references). No more
than one processor shall have a modified copy of the same data area in
its cache when the client program is called.</para>
<para>
<emphasis role="bold">Note:</emphasis> If firmware makes cacheable M=0 data references
from different processors on a SMP system, it may have to perform
additional cache management to meet this requirement.</para>
</section>
<section xml:id="dbdoclet.50569374_27751">
<title>Interrupts</title>
<para>OF requires that interrupts be “vectored” to its
handlers when it is in control of the processor; this will occur when the
User Interface is running. Client Interface calls are considered to
execute in the environment of the client, and hence, OF does not assume
ownership of interrupts.</para>
<para>
<emphasis role="bold">Note:</emphasis> There used to be a paragraph here that said an
area of memory was to be reserved by the client program for the exclusive
use of OF. This requirement has been removed, since the sharing of
interrupt vectors on these platforms has not been found to be
practical.</para>
<para>OF shall save and restore the first location of each interrupt that
it wants to “take over”. I.e., whenever OF needs the use of
an interrupt, it shall save the current contents of the corresponding
entry point and replace that location with a branch to its entry point.
When OF returns control, it shall restore the RAM location to its
original contents.</para>
</section>
<section>
<title>Client callbacks</title>
<para>This section defines the callback mechanism that allows OF to
access services exported to it by the client program. As described in
section 6.3.2 and the glossary entries for
<emphasis role="bold"><literal>callback</literal></emphasis> and
<emphasis role="bold"><literal>$callback</literal></emphasis> in
<xref linkend="dbdoclet.50569387_45524" />, the callback mechanism
follows the same rules as those of Client interface calls. I.e., an
<emphasis>argument array</emphasis> is constructed by OF and the address
of that array is passed (via
<emphasis role="bold"><literal>r3</literal></emphasis>) to the client’s callback routine; the
address of the callback routine is supplied to OF by means of the
<emphasis role="bold"><literal>set-callback</literal></emphasis> client call.</para>
<para>If the system is running in Real-Mode, the address of the client
callback routine shall be a real address; if it is running in
Virtual-Mode, the client callback routine address shall be a mapped
virtual address.</para>
<section xml:id="dbdoclet.50569374_11616">
<title>Real-Mode physical memory management assist
callback</title>
<para>Once the control of physical memory is transferred to the client
program, OF which is running in real-mode shall use the callback service
provided by the client program to allocate physical memory. Client
programs which expect OF to operate in read-mode must implement the
following physical memory management client callback routines for
OF:</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold"><literal>alloc-real-mem</literal></emphasis></term>
<listitem>
<para>IN: [address] min_addr, [address] max_addr, size, mode</para>
<para>OUT: error, [address] real_addr</para>
<para>This routine allocates a contiguous physical memory of
<emphasis>size</emphasis> bytes within the address range between
<emphasis>min_addr</emphasis> and
<emphasis>max_addr</emphasis>. The
<emphasis role="bold"><literal>mode</literal></emphasis> parameter contains the WIMGxPP bits as defined
in
<xref linkend="dbdoclet.50569374_77797" />A non-zero error code shall be
returned if the mapping cannot be performed. If error code is zero (i.e.
allocation is succeeded) the routine returns the base address of the
physical memory allocated for OF.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section>
<title>Virtual address translation assist callbacks</title>
<para>As mentioned in
<xref linkend="dbdoclet.50569374_96317" />, when OF is in Virtual-Mode,
client programs that take over control of the system’s memory
management must provide a set of callbacks that implement MMU functions.
This section defines the input arguments and return values for these
callbacks. The notation follows the style used in chapter 6 of the OF
specification
<xref linkend="dbdoclet.50569387_45524" />.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold"><literal>map</literal></emphasis></term>
<listitem>
<para>IN: [address] phys, [address] virt, size, mode</para>
<para>OUT: throw-code, error</para>
<para>This routine creates system-specific translation information; this
will typically include the addition of PTEs to the HTAB. If the mapping
is successfully performed, a value of zero shall be placed in the
<emphasis>error</emphasis> cell of the argument array; a non-zero error
code shall be returned in
<emphasis>error</emphasis> if the mapping cannot be performed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>unmap</literal></emphasis></term>
<listitem>
<para>IN: [address] virt, size</para>
<para>OUT: throw-code</para>
<para>The system removes any data structures (e.g., PTEs) for the virtual
address range.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">translate</emphasis></term>
<listitem>
<para>IN: [address] virt</para>
<para>OUT: throw-code, error, [address] real, mode</para>
<para>The system attempts to compute the real address (
<emphasis>real</emphasis>) to which the virtual address (
<emphasis>virt</emphasis>) is mapped. If the translation is successful, a
PTE shall be placed into the HTAB for this translation, the number of
return cells shall be four with the resulting real address returned in
<emphasis>real</emphasis> and
<emphasis>error</emphasis> shall be set to
<emphasis role="bold"><literal>false</literal></emphasis> (0). If the translation is not successful, the
number of return cells shall be two and
<emphasis>error</emphasis> shall be set to a non-zero error code.</para>
<para>This call shall be made when OF handles a DSI/ISI within the User
interface. A successful result of the translate call indicates that OF
can complete the interrupted access; a failure indicates that an access
was made to an invalid address.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
</section>
<section>
<title>User Interface Requirements</title>
<para>An implementation of OF for the PA shall conform to the core
requirements as specified in
<xref linkend="dbdoclet.50569387_45524" />and the following PA-specific
extensions.</para>
<section>
<title>Machine Register Access</title>
<para>The following
<emphasis>user interface</emphasis> commands represent PA registers within
the
<emphasis>saved program state</emphasis>. Executing the command returns
the saved value of the corresponding register. The saved value may be set
by preceding the command with
<emphasis>to</emphasis>; the actual registers are restored to the saved
values when
<emphasis role="bold"><literal>go</literal></emphasis> is executed.</para>
<para>The following command displays the PA processor's
<emphasis>saved program state</emphasis>.</para>
<para>
<emphasis role="bold"><literal>.registers</literal></emphasis>
</para>
<section>
<title>Branch Unit Registers</title>
<variablelist>
<varlistentry>
<term><emphasis role="bold"><literal>%cr</literal></emphasis></term>
<listitem>
<para>Access saved copy of Condition Register.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>%ctr</literal></emphasis></term>
<listitem>
<para>Access saved copy of Count Register.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>%lr</literal></emphasis></term>
<listitem>
<para>Access saved copy of Link Register.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>%msr</literal></emphasis></term>
<listitem>
<para>Access saved copy of the low order 16 bits of SRR1 register.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>%srr0</literal></emphasis> and
<emphasis role="bold"><literal>%srr1</literal></emphasis></term>
<listitem>
<para>Access saved copy of Save/Restore Registers.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>%pc</literal></emphasis></term>
<listitem>
<para>An alias of “
<emphasis role="bold"><literal>%srr0</literal></emphasis> ”</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section>
<title>Fixed-Point Registers</title>
<variablelist>
<varlistentry>
<term><emphasis role="bold"><literal>%r0</literal></emphasis> through
<emphasis role="bold"><literal>%r31</literal></emphasis></term>
<listitem>
<para>Access saved copies of fixed-point registers.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>%xer</literal></emphasis></term>
<listitem>
<para>Access saved copy of XER register.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>%sprg0</literal></emphasis> through
<emphasis role="bold"><literal>%sprg3</literal></emphasis></term>
<listitem>
<para>Access saved copies of SPRG registers.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section>
<title>Floating-Point Registers</title>
<para>Unlike the other registers, the floating point unit registers are
not normally saved, since they are not used by OF. The following access
words, therefore, access the registers directly.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold"><literal>%f0</literal></emphasis> through
<emphasis role="bold"><literal>%f31</literal></emphasis></term>
<listitem>
<para>Access floating point registers.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>%fpscr</literal></emphasis></term>
<listitem>
<para>Access Floating Point Status and Control Register.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
</section>
<section xml:id="dbdoclet.50569374_72253">
<title>Configuration Variables</title>
<para>In addition to the standard Configuration Variables defined by the
core OF document
<xref linkend="dbdoclet.50569387_45524" />, the following Configuration
Variables shall be implemented for the PA:</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold"><literal>“little-endian?”</literal></emphasis></term>
<listitem>
<para>This boolean variable controls the endian-mode of OF. If
<emphasis role="bold"><literal>true</literal></emphasis> (-1), the endian-mode is Little-Endian; if
<emphasis role="bold"><literal>false</literal></emphasis> (0), the endian-mode is Big-Endian. The default
value is implementation dependent.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“real-mode?”</literal></emphasis></term>
<listitem>
<para>This boolean variable controls the address translation mode of OF. If
<emphasis role="bold"><literal>true</literal></emphasis> (-1), the addressing mode is Real-Mode; if
<emphasis role="bold"><literal>false</literal></emphasis> (0), the addressing mode is Virtual-Mode. The
default value is implementation dependent.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“real-base”</literal></emphasis></term>
<listitem>
<para>This integer variable defines the starting physical address to be
used by OF.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“real-size”</literal></emphasis></term>
<listitem>
<para>This integer variable defines the size of the physical address space
which can be used by OF.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“virt-base”</literal></emphasis></term>
<listitem>
<para>This integer variable defines the starting virtual memory address
which can be used by OF.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“virt-size”</literal></emphasis></term>
<listitem>
<para>This integer variable defines the size of the virtual address space
which can be used by OF.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>“load-base”</literal></emphasis></term>
<listitem>
<para>This integer variable defines the default load address for
<emphasis>client programs</emphasis> when using the
<emphasis role="bold"><literal>load</literal></emphasis> method. The default value is implementation
dependent.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section>
<title>MP Extensions</title>
<para>This section specifies the application of OF to PA multiprocessor
(MP) systems. An OF implementation for an MP PA system shall implement the
extensions described in this section as well as the requirements described
in previous sections of this binding.</para>
<section>
<title>The Device Tree</title>
<para>This section defines an additional property under the
<emphasis role="bold"><literal>/chosen</literal></emphasis> node for a MP extension. Refer to
<xref linkend="dbdoclet.50569374_37877" />for more details about the
device tree structure for a MP Configuration.</para>
<section>
<title>Additional Properties</title>
<para>
<emphasis role="bold"><literal>/chosen</literal></emphasis> Node Properties</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold"><literal>“cpu”</literal></emphasis></term>
<listitem>
<para><emphasis>property name</emphasis>, identifies the running CPU.</para>
<para><emphasis>prop-encode-array</emphasis>: An integer, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>, which contains the i-handle of the CPU
node that is associated with the “running” CPU.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
<section>
<title>Initialization</title>
<para>OF shall select one processor, using an algorithm of its choice, to
be the “master” processor, which performs the role of the
single processor on a uniprocessor system, either booting the client or
providing the user interface. OF shall place all the remaining processors
into stopped state, a state in which the processor does not perform OF or
client functions and does not interfere with the operation of the master
processor. A processor in stopped state remains in that state unless and
until an executing client starts it using the
<emphasis role="bold"><literal>start-cpu</literal></emphasis> client service defined below.</para>
<para>Client programs shall use the OF
<emphasis role="bold"><literal>start-cpu</literal></emphasis> client interface service to start all
processors before it reclaims the OF memory</para>
<para>On machines in which a machine check on one processor is broadcast
to all processors, the processors which are either in the idle or stopped
state shall not change their states due to a machine check on another
processor: OF shall not depend on the contents of the low vector (IP=0)
in the event of a machine check.</para>
<para>
<xref linkend="dbdoclet.50569374_85573" />depicts the relationship of the
Running, Stopped and Idle States to each other. The
<emphasis>Client Interface Service</emphasis> calls are shown as how to
move between the states.</para>
<figure pgwide="1" xml:id="dbdoclet.50569374_85573">
<title>Stopped, Running, and Idle State Diagram</title>
<mediaobject>
<imageobject role="html">
<imagedata fileref="figures/PAPR-64.gif" format="GIF"
scalefit="1" />
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%" fileref="figures/PAPR-64.gif"
format="GIF" scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</figure>
<para><emphasis role="bold">Note:</emphasis> OF's memory cannot be reclaimed by a client if
a CPU is in the “stopped” or “idle” state.</para>
</section>
<section>
<title>Client Interface Services</title>
<para>The following client interface services are added for MP support on
PA systems. These interfaces make the client program responsible for any
Inter-CPU communication needed for these interfaces. The rationale for
this is to architecturally separate the Inter-CPU communication mechanism
of the firmware from the client program and vice versa.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold"><literal>start-cpu</literal></emphasis></term>
<listitem>
<para>IN: nodeid, pc, arg</para>
<para>OUT: none</para>
<para>This client interface service starts the CPU. The
<emphasis>nodeid</emphasis> is the phandle of a node whose device_type is
“cpu”.</para>
<para><emphasis role="bold"><literal>Start-cpu</literal></emphasis> arranges for the CPU identified by phandle
in <emphasis>nodeid</emphasis> to begin executing client code at the real
address given by the
<emphasis>pc</emphasis> input with an argument,
<emphasis>arg,</emphasis> passed in register r3. When it begins execution,
the started processor shall be in the endian mode of the client program,
and in real (not translated) addressing mode. The contents of registers
other than r3 are indeterminate.</para>
<para>A client should not call
<emphasis role="bold"><literal>start-cpu</literal></emphasis> for the processor on which it is running,
effectively restarting with a new pc and abandoning the only client
thread. A jump or branch instruction shall be used instead to achieve the
objective.</para>
<para><emphasis role="bold"><literal>start-cpu</literal></emphasis> permits more than one processor to run at
the same time, enabling multi-threaded client execution. In general, an
OF client shall avoid multi-threaded operation within OF. Usually, this
means that client threads running on different CPUs must use mutual
exclusion to prevent more than one processor from making client service
requests at any one time. The exceptions are that a client thread may
invoke either the
<emphasis role="bold"><literal>stop-self</literal></emphasis> or
<emphasis role="bold"><literal>idle-self</literal></emphasis> client services defined below at any
time.</para>
<para><emphasis role="bold">Note:</emphasis> The results are undefined if the CPU identified
by *phandle* has already been started (e.g. it is already running and has
not exited) or *phandle* is not a valid package handle of a CPU device
node.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>stop-self</literal></emphasis></term>
<listitem>
<para>IN: none</para>
<para>OUT: none</para>
<para>OF places the processor on which the caller was running into the
“stopped” state. The client program is not-resumable.</para>
<para><emphasis role="bold">Note:</emphasis> When an MP client program exits, one CPU
invokes the
<emphasis role="bold"><literal>exit</literal></emphasis> client interface service, the others invoke the
<emphasis role="bold"><literal>stop-self</literal></emphasis> service.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>idle-self</literal></emphasis></term>
<listitem>
<para>IN: none</para>
<para>OUT: none</para>
<para>OF places the CPU on which this service was invoked into an 'idle'
state, saving the *current state* of the client program, so that the
client program may be resumed.</para>
<para>A processor in idle state can be resumed using
<emphasis role="bold"><literal>resume-cpu</literal></emphasis> service defined below or restarted using
<emphasis role="bold"><literal>start-cpu</literal></emphasis>. If the processor is resumed, it executes
a normal return to the client, as if its call to
<emphasis role="bold"><literal>idle-self</literal></emphasis> had just completed.</para>
<para>
<emphasis role="bold">Note:</emphasis> When a client program wants to enter the
firmware user interface, one CPU invokes the
<emphasis>enter</emphasis> client interface service, the others invoke the
<emphasis role="bold"><literal>idle-self</literal></emphasis> service. The rational is that the user
interface may affect the machine state in any way that it desires,
therefore the client shall not depend on it.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"><literal>resume-cpu</literal></emphasis></term>
<listitem>
<para>IN: nodeid</para>
<para>OUT: none</para>
<para>This client interface service is used to resume an *idled* CPU. The
<emphasis>nodeid</emphasis> is the phandle of a CPU node in idle
state.</para>
<para><emphasis role="bold"><literal>resume-cpu</literal></emphasis> arranges for that CPU to restore the
CPU’s state as saved by
<emphasis role="bold"><literal>idle-self</literal></emphasis> and begin return to the client, completing
the idle-self client service call that placed the CPU into idle state.
The results are undefined if the CPU identified by *phandle* is not in an
*idle* state by a previous call to the
<emphasis role="bold"><literal>idle-self</literal></emphasis> client interface service.</para>
<para><emphasis role="bold">Note:</emphasis> When the client program is resumed via the GO
(or similar) user interface command, the client program is resumed on the
CPU which called the
<emphasis>enter</emphasis> service; the client program is responsible for
calling the
<emphasis role="bold"><literal>resume-cpu</literal></emphasis> service to resume other idled CPU's, if
that is the desired client program behavior.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section>
<title>Breakpoints</title>
<para>If the breakpoint is taken by the firmware, without the client
program's assistance, the other CPUs will continue to run in the client
program. The client program may field the breakpoint 'trap' or 'vector'
and idle the other CPUs before entering the PROM. The platform binding
document has to specify how this is done to avoid loss of state at
breakpoint time.</para>
</section>
<section>
<title>Serialization</title>
<para>The firmware is a single threaded program, from the client
program's point of view. Only the
<emphasis role="bold"><literal>idle-self</literal></emphasis>,
<emphasis role="bold"><literal>stop-self</literal></emphasis>,
<emphasis>enter</emphasis> and
<emphasis role="bold"><literal>exit</literal></emphasis> client interfaces may be invoked simultaneously
on different CPUs. Furthermore, only a single CPU may invoke the
<emphasis>enter</emphasis> or
<emphasis role="bold"><literal>exit</literal></emphasis> client interface at any one time. The other CPUs
must use the
<emphasis role="bold"><literal>idle-self</literal></emphasis> or
<emphasis role="bold"><literal>stop-self</literal></emphasis> client interface service.</para>
<para>
<emphasis role="bold">Note:</emphasis> The results are undefined if the client program
invokes client interface services including breakpoint traps (other than
the
<emphasis role="bold"><literal>enter/exit stop-self/idle-self</literal></emphasis> case listed above)
simultaneously on more than a single CPU.</para>
<para>
<emphasis role="bold">Note:</emphasis> Since locking mechanisms are subject to client
program policy, the client program is responsible for implementing any
necessary mechanism to insure that it adheres to this policy. Further,
the client program should disable any preemption mechanism before calling
a client interface service to avoid rescheduling a thread of execution in
the firmware on a different CPU if such a mechanism exists in the client
program.</para>
</section>
</section>
</chapter>