You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
4404 lines
205 KiB
XML
4404 lines
205 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!--
|
|
Copyright (c) 2016, 2020 OpenPOWER Foundation
|
|
|
|
Licensed under the Apache License, Version 2.0 (the "License");
|
|
you may not use this file except in compliance with the License.
|
|
You may obtain a copy of the License at
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
Unless required by applicable law or agreed to in writing, software
|
|
distributed under the License is distributed on an "AS IS" BASIS,
|
|
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
See the License for the specific language governing permissions and
|
|
limitations under the License.
|
|
|
|
-->
|
|
<appendix xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
xmlns:xl="http://www.w3.org/1999/xlink"
|
|
version="5.0"
|
|
xml:id="dbdoclet.50569374_59715"
|
|
xml:lang="en">
|
|
<title>PA Processor Binding</title>
|
|
|
|
<section>
|
|
<title>Purpose of this Binding</title>
|
|
|
|
<para>This appendix specifies the application of OF to a PA Processor (which covers
|
|
all PowerPC processors and their suc- cessors), including requirements and
|
|
practices to support unique firmware specific to a PA Processor. The core
|
|
requirements and practices specified by OF must be augmented by processor-specific
|
|
requirements to form a complete specification for the firmware implementation
|
|
for a PA processor. This appendix establishes such additional requirements
|
|
pertaining to the processor and the support required by OF.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Overview</title>
|
|
|
|
<para>This appendix specifies the application of
|
|
<emphasis><xref linkend="dbdoclet.50569387_45524" /></emphasis>
|
|
to computer systems that use the PA instruction set, including
|
|
instruction-set-specific requirements and practices for debugging, client
|
|
program interface and data formats. An implementation of OF for PA shall
|
|
implement the core requirements as defined in
|
|
<xref linkend="dbdoclet.50569387_45524" /> and the PA-specific extensions
|
|
described in this binding.</para>
|
|
|
|
<para>This appendix addresses
|
|
<xref linkend="dbdoclet.50569387_99718" />. The descriptions that follow,
|
|
and the relevant sections describing translation features for this binding,
|
|
assume that the system’s PA processor(s) implement the entire PA
|
|
(that is, all books of
|
|
<xref linkend="dbdoclet.50569387_99718" />). Some processors may implement
|
|
different Book II-III features; such processors may need a variant of this
|
|
binding describing the differences to the mapping functions, etc.</para>
|
|
|
|
</section>
|
|
|
|
<xi:include href="sec_pa_processor_binding_terms.xml"/>
|
|
|
|
<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 valign="middle" >
|
|
<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="dbdoclet.50569332_71049" />.</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 valign="middle" >
|
|
<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 valign="middle" >
|
|
<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 valign="middle" >
|
|
<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 valign="middle" >
|
|
<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 valign="middle" >
|
|
<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 valign="middle" >
|
|
<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 valign="middle" >
|
|
<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 valign="middle" >
|
|
<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 valign="middle" >
|
|
<row>
|
|
<entry morerows="8">
|
|
<para>msr</para>
|
|
</entry>
|
|
<entry>
|
|
<para>EE = 0, interrupts disabled</para>
|
|
</entry>
|
|
<entry>
|
|
<para>1</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>PR = 0, supervisor state</para>
|
|
</entry>
|
|
<entry>
|
|
<para> </para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>FP = 1, floating point enabled</para>
|
|
</entry>
|
|
<entry>
|
|
<para> </para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>ME = 1, machine checks enabled</para>
|
|
</entry>
|
|
<entry>
|
|
<para> </para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>FE0, FE1 = 0, floating point exceptions disabled</para>
|
|
</entry>
|
|
<entry>
|
|
<para> </para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>IP, see
|
|
<xref linkend="dbdoclet.50569374_27751" /></para>
|
|
</entry>
|
|
<entry>
|
|
<para> </para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>IR,DR, see
|
|
<xref linkend="dbdoclet.50569374_25139" /></para>
|
|
</entry>
|
|
<entry>
|
|
<para> </para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>SF=0, 32-bit mode</para>
|
|
</entry>
|
|
<entry>
|
|
<para> </para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<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>
|
|
|
|
</appendix>
|