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.

This appendix specifies the application of 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 and the PA-specific extensions described in this binding. This appendix addresses . 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 ). 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.

The cell size shall be 32 bits. Number ranges for n, u, and other cell-sized items are consistent with 32-bit, two's-complement number representation. The required alignment for items accessed with a-addr addresses shall be four-byte aligned (i.e., a multiple of 4). Each operation involving a qaddr address shall be performed with a single 32-bit access to the addressed location; similarly, each waddr access shall be performed with a single 16-bit access. This implies four-byte alignment for qaddrs and two-byte alignment for waddrs.

This section describes the model that is used for co-existence of OF and client programs (i.e., OSs) with respect to address translation. 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; , particularly Book III, should be consulted for the details. For the scope of this section, terms will be used as defined in .

The default access mode of storage for load and stores (i.e., with translation disabled -- referred to as Real-Mode) 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.

Note: 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. Note: The following description of PA address translation is only one of several translation modes available and is given for reference only. See for complete details. 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. 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. Note: 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.

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) The 601 has a single set of BAT entries that are shared by both instruction and data accesses. . 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. 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. 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. Note: Block Address Translation is a deprecated translation mode of the PA. This description is retained here for historical reference. See for details on all supported addressing mechanisms.

OF shall use the memory resources within the space indicated by the real-base, real-size, virt-base, and virt-size 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. 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 real-base, real-size, virt-base, and virt-size to the configuration variables as specified in the header and restart itself. Real-base, real-size, virt-base, and virt-size may be specified as -1, in which case the firmware is permitted to choose appropriate values for the variables specified as -1. If the values of the real-size and/or virt-size 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. A PA OF binding shall support two different addressing models, depending upon the setting of the real-mode? Configuration Variable. This variable indicates the OF addressing mode that a client program expects; false (0) indicates Virtual-Mode, true (-1) indicates Real-Mode; the default value of real-mode? is implementation dependent. The management of real-mode? is analogous to little-endian?. OF determines its addressing mode using the value of real-mode?. If the current state of real-mode? (and hence, the current state of OF) is incorrect, it shall set real-mode? appropriately and reset itself, possibly by executing reset-all. 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 “ available ” property of the memory node. A Client Program that needs to use such memory for its architected purpose must not claim that area prior to use. 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).

In Real-Mode (when real-mode? is true), 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 virt addresses in , or this binding, must be real addresses. Note: In particular, that the address of the Client interface handler, that is passed to the client, has to be a real address. The Configuration Variables real-base and real-size should indicate the physical memory base and size in which OF must locate itself. In Real-Mode, the Configuration Variables virt-base and virt-size do not have meaning and should be set to -1.

When real-mode? is false, OF shall configure itself to run in Virtual-Mode. 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. The Configuration Variables virt-base and virt-size should indicate the virtual address space base address and size that OF should use. The Configuration Variables real-base and real-size should indicate the physical memory base and size in which OF must locate itself.

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. Note: In Real-Mode, all translations will be virt=real; the primary reason for translation is to allow appropriate I/O accesses.

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. Note: 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.

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 read/write calls). Translation shall be disabled before the client interface call is made. 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 may 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. 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. 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. In Real-Mode, claim methods shall not allocate more pages than are necessary to satisfy the request.

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. Note: 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. In addition to using existing translations, the Client Interface might require the establishment of new translations (e.g., due to map-in calls during open time), or the removal of old translations (e.g., during map-out calls during close 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. Hence, there shall be callback services provided by the client for use by OF for such actions; see . 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. OF: OF shall maintain its “translations” “mmu”-node property (see ) OF’s claim methods shall not allocate more pages than are necessary to satisfy the request. When a client executes set-callback, 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. The exit service must continue to work after a set-callback that takes over address translation. This implies that OF takes responsibility for address translation hardware upon exit and must maintain internal information about translations that it requests of the client. Client Programs: 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 ). 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 set-callback to install the “translate” callback. Note: 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.

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.

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 map-in and map-out 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. Hence, this binding defines callback services that the client provides for use by OF; see .

This section describes the standard properties of a PA OF implementation.

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 “reg” properties. The “reg” 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”. The “cpus” node shall have one child node of device_type “cpu” for each processor.

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) : Bit# 3322222210987654 2222111132109876 1111110054321098 0000000076543210 phys.lo cell: 00000000 00000000 00000000 pppppppp where: pppppppp is an 8-bit integer representing the interprocessor interrupt identifier used by the platform.

The text representation of a processor’s “address” shall be an ASCII hexadecimal number in the range 0...FF. Conversion of the hexadecimal number from text representation to numeric representation shall be case insensitive, and leading zeros shall be permitted but not required. Conversion from numeric representation to text representation shall use the lower case forms of the hexadecimal digits in the range a..f, suppressing leading zeros.

A processor’s “unit-number” (i.e. the first component of its “reg” value) is the interprocessor interrupt destination identifier used by the platform. For a uni-processor platform, the “unit-number” shall be zero.

The following properties shall be created within the “cpus” node. “#address-cells” Standard property name to define the number of cells required to represent the physical addresses for the “ cpu ” nodes (i.e., the children of the “ cpus ” node). prop-encoded-array: Integer constant 1, encoded as with encode-int. The value of “#address-cells” for the “cpus” node shall be 1. “#size-cells” Standard property name to define the number of cells necessary to represent the length of a physical address range. prop-encoded-array: Integer constant 0, encoded as with encode-int. The value of “ #size-cells ” 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.

For each CPU in the system, a cpu-node shall be defined as a child of “cpus”. The following properties apply to each of these nodes. The cpus node shall not have “ reg ” or “ ranges ” 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 . “name” Standard property name. 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> shall not contain underscores. “device_type” Standard property name. The value of this property for CPU nodes shall be “cpu”. “reg” Standard proper name to define a cpu node’s unit-address. prop-encoded-array: an integer encoded as with encode-int. For a cpu node, the first and only value of the “reg” 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 “reg” property shall be zero. “status” Standard property name. The value of the is property shall be one of the following string values: “okay” for a good processor. “fail” for a processor that fails during power-on testing. “fail-offline” for a processor that has been automatically deconfigured because of previous failures. “disabled” for a processor that has been manually deconfigured. “cpu-version” property name: Represents the processor type. prop-encoded-value: The value, encoded as with encode-int, 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 . The first byte of the logical processor version value shall be 0x0F. The values of the “Logical Processor Version” column of 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. Logical Processor Version Property Value 2.04 0x0F000001 2.05 0x0F000002 2.06 0x0F000003 2.06 plus: URG field in DSCR (Bits 55-57) 0x0F100003 2.07 0x0F000004 2.08 0x0F000005 “clock-frequency” Standard property name, encoded as with encode-int, that represents the internal processor speed (in hertz) of this node. “ibm,extended-clock-frequency” property name: Property that represents the internal processor speed in hertz of this node. This property allows the encoding of multi-giga-hertz quantities. prop-encoded-array: Consisting of the low order 32 bits of two cells (freq-hi, freq-lo) each encoded as with encode-int, such that their combined value is (the low order 32 bits of freq-hi || the low order 32 bits of freq-lo). “timebase-frequency” Standard property name, encoded as with encode-int, that represents the rate (in hertz) at which the PA TimeBase and Decrementer registers are updated. Note: 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. “ibm,extended-timebase-frequency” property name: 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. prop-encoded-array: Consisting of the low order 32 bits of two cells (freq-hi, freq-lo) each encoded as with encode-int, such that their combined value is (the low order 32 bits of freq-hi || the low order 32 bits of freq-lo). Note: The “ibm,extended-timebase-frequency” property will be deprecated from the architecture due to the emergence of the “ibm,nominal-tbf” property and the lack of a need for a two cell version of the “timebase-frequency” property. Implementations should not provide the “ibm,extended-timebase-frequency” property. “ibm,nominal-tbf” property name: Property, encoded as with encode-int, that represents the design nominal timebase frequency (in hertz). “ibm,tbu40-offset” property name: 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. prop-encoded-array: An eight byte, big endian, unsigned, binary value. “64-bit” prop-encoded-array: <none> 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 “64-bit-virtual-address” prop-encoded-array: <none> 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. Note: The “64-bit-virtual-address” will be deprecated from the architecture. Implementations should not provide this property. “603-translation” prop-encoded-array: <none> 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. “603-power-management” prop-encoded-array: <none> 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. “bus-frequency” Standard property name, encoded as with encode-int, that represents the speed (in hertz) of this processor’s bus. “ibm,extended-bus-frequency” property name: Property that represents the rate in hertz of this processor’s bus. This property allows the encoding of multi-giga-hertz quantities. prop-encoded-array: Consisting of the low order 32 bits of two cells (freq-hi, freq-lo) each encoded as with encode-int, such that their combined value is (the low order 32 bits of freq-hi || the low order 32 bits of freq-lo). “32-64-bridge” prop-encoded-array: <none> 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 . The absence of this property indicates that the PA processor defined by this CPU node does not support these facilities and instructions. “external-control” prop-encoded-array: <none> 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 . The absence of his property indicates that the PA processor defined by this CPU node does not support the External Control Facility. “general-purpose” prop-encoded-array: <none> This property, if present, indicates that the PA processor defined by this CPU node implements the floating point instructions fsqrt, fsqrts and stfiwx. The absence of this property indicates that the PA processor defined by this CPU node does not support the floating point instructions fsqrt, fsqrts and stfiwx. “reservation-granule-size” Standard property, encoded as with encode-int, that represents the reservation granule size (i.e., the minimum size of lock variables) supported by this processor, in bytes. “graphics” prop-encoded-array: <none> This property, if present, indicates that the PA processor defined by this CPU node implements floating point instructions fres, frsqrte, and fsel. The absence of this property indicates that the PA processor defined by this CPU node does not support the floating point instructions fres, frsqrte, and fsel. “performance-monitor” property name: Indicates that the processor described by this node implements a performance monitor. prop-encoded-array: Consists of a pair of values, each encoded as with encode-int. 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 . Second Value Documentation 0 Power 5+ Performance Monitor Programmer’s Guide 1 Power 7 Performance Monitor Programmer’s Guide “ibm,vmx” property name that indicates that the processor supports the POWER VMX architecture. prop-encoded-array: an integer encoded as with encode-int, 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 A Vector/SIMD Multimedia eXtension to the PowerPC Architecture, Specification Revision 1.2.3, 7/18/97 specification. The value of 2 represents the level of support provided by the VSX option of level 2.06. “ibm,segment-page-sizes” property name: that indicates the segment base page sizes and related encodings supported by the processor. prop-encoded-array: one or more segment-page-size-descriptor(s). segment-page-size-descriptor: a segment-page-size-header followed by a pte-lp-descriptor. segment-page-size-header: Consists of three cells (X,Y,Z) encoded as with encode-int. 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 X. 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. pte-lp-descriptor: 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. pte-lp-encoding: Each pte-lp-encoding consists of two cells (P,Q) encoded as with encode-int. The first cell represents the page size of the encoding as 2 P (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. Note: A segment-page-size-descriptor applies to a segment only if the size of the segment is greater than or equal to all of the page sizes within the pte-lp-encoding (s) contained within the segment-page-size-descriptor. “ibm,processor-page-sizes” property name: Relates the number and sizes of the virtual memory page sizes supported by the processor describe by this node. prop-encoded-array: One to N cells in ascending value order, each encoded as with encode-int, 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 12) etc. “ibm,processor-radix-AP-encodings” property name: 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. prop-encoded-array: One to N cells in ascending order of Radix mode supported page size, each encoded as with encode-int. The top 3 bits of the low order byte contain the tlbie AP field associated with the corresponding Radix mode supported page size. “ibm,processor-segment-sizes” property name: Relates the number and sizes of the virtual memory segment sizes supported by the processor described by this node. prop-encoded-array: One to N cells in ascending value order of the segment selector (SLBE B field), each encoded as with encode-int, 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 28) etc. (negative valued cells represent unsupported encodings). “ibm,processor-storage-keys” property name indicating the number of virtual storage keys supported by the processor described by this node. prop-encoded-array: Consists of two cells encoded as with encode-int. 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. “ibm,processor-vadd-size” property name indicating the number of virtual address bits that are supported by the processor described by this node. prop-encode-array: An integer, encoded as with encode-int, that represents the number of supported virtual address bits. Note: A processor described by this node implements the least significant “ibm,processor-vadd-size” bits of the architected virtual address. “ibm,vrma-page-sizes” property-name: Maps the VRMASD field values implemented by the processor described by this node to their page sizes. prop-encoded-array: Array of one or more VRMA page-size-descriptor (s) starting with the value selected by the firmware when booting the partition, followed by the other values supported by the platform. VRMA page-size-descriptor: A pair of cells encoded as with encode-int; 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. “ibm,estimate-precision” property name: Relates PA estimate instruction mnemonics to precisions supported by the processor described by this node. prop-encoded-array: One or more instruction-precision descriptor (s). instruction-precision descriptor: An instruction descriptor followed by a precision descriptor. An instruction-precision descriptor relates one estimate instruction mnemonic to the precision supported by the processor described by this node for that estimate instruction mnemonic. instruction descriptor: Consists of one PA instruction mnemonic encoded as with encode-string. precision descriptor: Consists of an integer, encoded as with encode-int, specifying the number of bits of precision the processor described by this node supports for an instruction mnemonic. “ibm,dfp” property name: Indicates that the processor described by this node supports the Decimal Floating Point (DFP) architecture. prop-encoded-value: an integer, encoded as with encode-int, 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: 1: Represents the level of support defined by Version 2.05 of the . 2: Represents the level of support defined by Version 2.06 of the . “ibm,purr” property name: Indicates that the processor described by this node implements a Processor Utilization of Resources Register (PURR). prop-encoded-value: an integer, encoded as with encode-int, 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. “ibm,spurr” property name: Indicates that the processor described by this node implements a Scaled Processor Utilization of Resources Register (SPURR). prop-encoded-value: an integer, encoded as with encode-int, that represents the level of SPURR architecture supported. The value of 1 represents the level of support defined by Version 2.05 of the . “ibm,pa-features” property name: Indicates level of support of several extended features of the Processor Architecture. prop-encoded-array: One or more attribute-descriptor (s). attribute-descriptor: Consists of an attribute-header immediately followed by an attribute-specifier. attribute-header: 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 attribute-specifier. The second byte is an unsigned integer specifying the attribute-specifier-type. attribute-specifier: The attribute-specifier is defined by the attribute-specifier-type of the attribute-header. The attribute-specifier for the attribute-specifier-type value of 0 is defined by . Byte Number Bit Number Attribute Name Description 0 0 Memory Management Unit (MMU) The value of 1 indicates MMU support; else not supported. 1 Floating Point Unit (FPU) The value of 1 indicates FPU support; else not supported. 2 Segment Lookaside Buffer (SLB). The value of 1 indicates SLB support; else not supported. 3 RUN field The value of 1 indicates support for the RUN field of the Control Register (CTRL, SPR #152); else not supported. 4 Reserved Reserved bits within defined bytes shall be zero. 5 Data Address Breakpoint Register (DABR) The value of 1 indicates DABR support; else not supported. 6 No Execute (N) bit in Page Table Entries. The value of 1 indicates No Execute (N) bit in Page Table Entry support; else not supported. 7 Write Through Required (W) bit 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 1 0 Memory Coherence Required (M) bit 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. 1 Data Storage Interrupt Status Register (DSISR) set on an alignment interrupt. 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. 2 I=1 (cache inhibited) Large Pages The value of 1 indicates support for I=1 (cache inhibited) large pages; else not supported. 3 Round to Integer (from floating point) group of instructions. The value of 1 indicates support for the frin, friz, frip, and frim instructions; else these instructions are not supported. 4 Data Address Breakpoint Register Extension (DABRX) The value of 1 indicates support for the DABRX architecture as defined by version 2.02 of PA; else not supported. 5 User Accessible SPRG3 The value of 1 indicates support for accessing SPRG3 in Problem State; else SPRG3 is not accessible in Problem State. 6 Reading an invalid SLB entry returns zeros. The value of 1 indicates that reading an invalid SLB entry always returns zeros; else non-zero values may be returned. 7 Support for “110” value of the Page Protection (PP) bits. 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. 2 0 Virtualized Partition Memory (VPM) The value of 1 indicates support for Virtualized Partition Memory (VPM) as described by version 2.04 of PA; else not supported. 1 2.05 Data Stream Support The value of 1 indicates that data streams as described by version 2.05 of PA are supported; else not supported. 2 Reserved Reserved bits within defined bytes shall be zero. 3 Data Address Register (DAR) set on an alignment interrupt. 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. 4 Reserved Reserved bits within defined bytes shall be zero. 5 Program Priority Register (PPR) 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. 6 2.02 Data Stream Support The value of 1 indicates that data streams as described by version 2.02 of PA are supported; else not supported. 7 2.06 Data Stream Support 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. 3 0 LSD in DSCR(Bit 58) The value of 1indicates that “Load Stream Disable” bit of the Data Stream Control Register is implemented 1 URG in DSCR (Bits 55::57) The value of 1 indicates that the “Depth Attainment Urgency” field of the Data Stream Control Register is implemented. 2-7 Reserved Reserved bits within defined bytes shall be zero. 4 Storage Order Options Byte bits define the availability of specific options 0 2.06 Strong Storage Order The value of 1 indicates that Strong Storage Order as defined by version 2.06 of PA is supported; else not. 1-7 Reserved for future storage order options Reserved bits within defined bytes shall be zero. 5 0 Little Endian The value of 1indicates support for Little Endian as described by version 2.03 of PA; else not supported. 1 Come From Address Register (CFAR) 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. 2 Elemental Barriers The value of 1 indicates that elemental barriers are supported; else elemental barriers are not supported. 3 2.07 load/store quadword 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. 4-7 Reserved Reserved bits within defined bytes shall be zero. 6-7 Data Streaming Specifications 0 2.07 Data Streaming Support 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. 1-7 Reserved Reserved bits within defined bytes shall be zero. 8-15 0-7 Reserved Co-Processor Option 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) 16-17 Level of Vector Category Support 0 2.07 Vector Support 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. 1-7 Reserved Reserved bits within defined bytes shall be zero. 18-19 Level of Vector Scalar Category Support 0 2.07 Vector Scalar Support 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. 1-7 Reserved Reserved bits within defined bytes shall be zero. 20-21 Level of Vector.XOR Category Support 0 2.07 Vector.CRYPTO Support 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. 1-7 Reserved Reserved bits within defined bytes shall be zero. 22-23 Level of Transactional Memory Category Support 0 2.07 Transactional Memory Support 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. 1-7 Reserved Reserved bits within defined bytes shall be zero. 24-255 0-7 Undefined Readers shall ignore undefined bytes if present. “ibm,pi-features” property name: Indicates level of support of processor implementation specific options not described by the Processor Architecture. prop-encoded-array: One or more pi-attribute-descriptor (s). pi-attribute-descriptor: Consists of a pi-attribute-header immediately followed by a pi-attribute-specifier. pi-attribute-header: 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 pi-attribute-specifier. The second byte is an unsigned integer specifying the pi-attribute-specifier-type. pi-attribute-specifier: The pi-attribute-specifier is defined by the pi-attribute-specifier-type of the pi-attribute-header. The pi-attribute-specifier for the pi-attribute-specifier-type value of 0 is defined by . Byte Number Bit Number Attribute Name Description 0 0 P4 Data Address Register (DAR) setting on alignment interrupt. 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. 1 Reserved Reserved bits within defined bytes shall be zero. 2 Ordered Thread Activation/Deactivation The value of 1 indicates that the “ibm,ppc-interrupt-server-#s” 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. 3-7 Reserved Reserved bits within defined bytes shall be zero. 1-255 0-7 Reserved Reserved bits within defined bytes shall be zero. “ibm,negotiated-pa-features” property name: Indicates level of support negotiated via the ibm,client-architecture-support method (See ) of several extended features of the Processor Architecture. prop-encoded-array: One or more negotiated-pa-attribute-descriptor (s). negotiated-pa-attribute-descriptor: Consists of a negotiated-pa-attribute-header immediately followed by a negotiated-pa-attribute-specifier. negotiated-pa-attribute-header: 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 negotiated-pa-attribute-specifier. The second byte is an unsigned integer specifying the negotiated-pa-attribute-specifier-type. negotiated-pa-attribute-specifier: The negotiated-pa-attribute-specifier is defined by the negotiated-pa-attribute-specifier-type of the negotiated-pa-attribute-header. The negotiated-pa-attribute-specifier for the negotiated-pa-attribute-specifier-type value of 0 is defined by . Byte Number Bit Number Attribute Name Description 0 0 TC Set 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. 1-7 Reserved Reserved bits within defined bytes shall be zero. 1-255 0-7 Reserved Reserved bits within defined bytes shall be zero. “ibm,raw-pi-features” property name: Indicates level of support of processor implementation specific options not described by the Processor Architecture and not supported on partitions that contain the “ibm,migratable-partition” property. prop-encoded-array: One or more raw-pi-attribute-descriptor (s). raw-pi-attribute-descriptor: Consists of a raw-pi-attribute-header immediately followed by a raw-pi-attribute-specifier. raw-pi-attribute-header: 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 raw-pi-attribute-specifier. The second byte is an unsigned integer specifying the raw-pi-attribute-specifier-type. raw-pi-attribute-specifier: The raw-pi-attribute-specifier is defined by the raw-pi-attribute-specifier-type of the raw-pi-attribute-header. The raw-pi-attribute-specifier for the raw-pi-attribute-specifier-type value of 0 is defined by . Byte Number Bit Number Attribute Name Description 0 0 FPR GPR Move Instructions The value of 1 indicates that the PA processor defined by this CPU node implements the mftgpr and mffgpr instructions as described by IBM POWER6® CEC Book IV Implementation Features; else not supported. 1-7 Reserved Reserved bits within defined bytes shall be zero. 1-255 0-7 Reserved Reserved bits within defined bytes shall be zero. “ibm,pa-optimizations” property name: Indicates the level of support of performance variabilities described by the Processor Architecture. prop-encoded-array: One or more pa-optimization-attribute-descriptor (s). pa-optimization-attribute-descriptor: Consists of a pa-optimization-attribute-header immediately followed by a pa-optimization-attribute-specifier. pa-optimization-attribute-header: 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 pa-optimization-attribute-specifier. The second byte is an unsigned integer specifying the pa-optimization-attribute-specifier-type. pa-optimization-attribute-specifier: The pa-optimization-attribute-specifier is defined by the pa-optimization-attribute-specifier-type of the pa-optimization-attribute-header. The pa-optimization-attribute-specifier for the pa-optimization-attribute-specifier-type value of 0 is defined by . Byte Number Bit Number Attribute Name Description 0 0-7 Stream IDs The value is an unsigned quantity indicating the number of data stream IDs supported. The value of this byte shall be zero for processors that do not support data streams. 1 0-7 Default Prefetch Depth 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 shall be zero. This byte is valid only if the “2.05 Data Stream Support” bit of “ibm,pa-features” is set to one; else this byte is undefined. 2-255 0-7 Reserved Reserved bits within defined bytes shall be zero.

Since the PA defines the MMU as being part of the processor, the properties defined by Section 3.6.5 of and the following MMU-related properties shall be presented under “cpu” nodes. “tlb-size” Standard property name, encoded as with encode-int, that represents the total number of TLB entries. “tlb-sets” Standard property name, encoded as with encode-int, that represents the number of associativity sets of the TLB. A value of 1 indicates that the TLB is fully-associative. “tlb-split” 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. “d-tlb-size” Standard property name, encoded as with encode-int, that represents the total number of d-TLB entries. “d-tlb-sets” Standard property name, encoded as with encode-int, that represents the number of associativity sets of the d-TLB. A value of 1 indicates that the d-TLB is fully-associative. “i-tlb-size” Standard property name, encoded as with encode-int, that represents the total number of i-TLB entries. “i-tlb-sets” Standard property name, encoded as with encode-int, that represents the number of associativity sets of the i-TLB. A value of 1 indicates that the i-TLB is fully-associative. “tlbia” prop-encoded-array: <none> This property, if present, indicates that the PA processor defined by this CPU node implements thetlbia instruction. The absence of this property indicates that the PA processor defined by this CPU node does not support the tlbia instruction.

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 “i-cache-line-size” and “d-cache-line-size” 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 “cpu” nodes. “cache-unified” 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. “i-cache-size” Standard property name, encoded as with encode-int, that represents the total size (in bytes) of the internal instruction cache. “i-cache-sets” Standard property name, encoded as with encode-int, that represents number of associativity sets of the internal instruction cache. A value of 1 signifies that the instruction cache is fully associative. “i-cache-block-size” Standard property name, encoded as with encode-int, that represents the internal instruction cache's block size, in bytes. “d-cache-size” Standard property name, encoded as with encode-int, that represents the total size (in bytes) of the internal data cache. “d-cache-sets” Standard property name, encoded as with encode-int, that represents number of associativity sets of the internal data cache. A value of 1 signifies that the data cache is fully associative. “d-cache-block-size” Standard property name, encoded as with encode-int, that represents the internal (L1) data cache's block size, in bytes. “l2-cache” Standard property name, encoded as with encode-int, that represents the next level of cache in the memory hierarchy. Absence of this property indicates that no further levels of cache are present. If present, its value is the phandle of the device node that represents the next level of cache. “i-cache-line-size” Standard property name, encoded as with encode-int, that represents the internal instruction cache's coherency block size (line size), in bytes, if different than its cache block size. “d-cache-line-size” Standard property name, encoded as with encode-int, that represents the internal data cache's coherency block size (line size), in bytes, if different than its cache block size. Note: If this is a unified cache, the corresponding i- and d- sizes must be equal.

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. “translations” 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: Each value is encoded as with encode-int.

Since the PA defines the MMU as being part of the processor, the properties defined by Section 3.6.5 of and the following MMU-related properties as appropriate to the specific processor implementation shall be presented under “cpu” nodes. “slb-size” Standard property name, encoded as with encode-int, that represents the total number of SLB entries. Note: 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.

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 “cpu” nodes, the properties of ancillary caches are contained within other device tree nodes. 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 “cpu” nodes that share the same ancillary cache (including the cpu node under which the ancillary cache node is contained) shall contain an “l2-cache” property whose value is the phandle of that ancillary cache node. Note: The “l2-cache” 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. “device_type” Standard property name; the device_type of ancillary cache nodes shall be “cache”. “cache-unified” 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. “i-cache-size” Standard property name, encoded as with encode-int, that represents the total size (in bytes) of the instruction cache at this node. “i-cache-sets” Standard property name, encoded as with encode-int, 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. “d-cache-size” Standard property name, encoded as with encode-int, that represents the total size (in bytes) of the data cache at this node. “d-cache-sets” Standard property name, encoded as with encode-int, 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. “l2-cache” Standard property name, encoded as with encode-int, that represents the next level of cache in the memory hierarchy. Absence of this property indicates that no further levels of cache are present. If present, its value is the phandle of the device node that represents the cache at the next level. “i-cache-line-size” Standard property name, encoded as with encode-int, that represents the internal instruction cache's line size, in bytes, if different than its block size. “d-cache-line-size” Standard property name, encoded as with encode-int, that represents the internal data cache's line size, in bytes, if different than its block size. Note: If this is a unified cache, the corresponding i- and d- sizes must be equal.

This section describes the additional standard methods required of a PA OF implementation.

The MMU methods defined by section 3.6.5. of shall be implemented by CPU nodes. The value of the mode parameter for the relevant methods (e.g., map) 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: WIMGxPP, 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 map-in shall be marked as Cache-Inhibited, Guarded. The default mode (i.e., the mode specified when the value of the mode argument is -1) for the map-in and modify MMU methods of CPU nodes is defined as follows: If the beginning of the physical address range affected by the operation refers to system memory, the values for WIMGxPP shall be W=0, I=0, M=0, G=1, PP=10. 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.

A PA OF implementation shall implement a client interface (as defined in chapter 6 of ) according to the specifications contained within this section.

To invoke a client interface service, a client program constructs a client interface argument array as specified in the core OF document, places its address in r3 and transfers to the client interface handler, with the return address in lr. (A typical way of accomplishing this is to copy the client interface handler's address into ctr and executing a bctrl.) The term “preserved” below shall mean that the register has the same value when returning as it did when the call was made. Register(s) Value -- real-mode Value -- virt-mode Notes   If either the FWNMI, or LPAR option is implemented If neither the FWNMI or LPAR option is implemented If either the FWNMI, or LPAR option is implemented If neither the FWNMI or LPAR option is implemented   msr client interface shall preserve client interface shall preserve same as real-mode client interface shall not modify   cr client interface shall preserve client interface shall preserve same as real-mode same as real-mode 1 r1-r2 client interface shall preserve client interface shall preserve same as real-mode same as real-mode   r3 argument array address on client interface entry argument array address on client interface entry same as real-mode same as real-mode 2   result value (true or false) on client interface return result value (true or false) on client interface return same as real-mode same as real-mode 2 r13-r31 client interface shall preserve client interface shall preserve same as real-mode same as real-mode   sprg0, sprg1, and sprg3 client interface shall preserve client interface shall not modify same as real-mode same as real-mode   fpscr client interface shall preserve client interface shall preserve same as real-mode same as real-mode   f0-f31 client interface shall preserve client interface shall preserve same as real-mode same as real-mode   lr, ctr, xer undefined undefined same as real-mode same as real-mode   sr0-sr15 client interface shall preserve client interface shall preserve same as real-mode client interface shall not modify   vr0-vr31 client interface shall preserve client interface shall preserve same as real-mode same as real mode   dec client interface shall preserve client interface shall not modify same as real-mode same as real mode   Other SPRs client interface shall preserve client interface shall preserve same as real-mode same as real-mode 3 Notes: Only the non-volatile fields ( cr2-cr4) need to be preserved. As defined by section 6.3.1. of . Other special purpose registers The client interface handler shall perform the service specified by the contents of the argument array that begins at the address in r3, place the return value (indicating success or failure of the attempt to invoke the client interface service) back into r3, and return to the client program. This is typically done by a Branch to Link Register ( blr). The client interface handler shall preserve the contents of the Stack Pointer (r1), TOC Pointer (r2), Condition Register ( cr) all non-volatile registers (r13-r31) and all special purpose registers except lr, ctr and xer. The preservation of r2 allows TOC-based client programs to function correctly. OF shall not 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 r2.

The client’s load address is specified by the value of the load-base Configuration Variable. The value of load-base defines the default load address for client programs when using the load method. Load-base 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 load; it does not correspond to the addresses at which the program will be executed. All of physical memory from load-base 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.

This section defines the “initial program state”, the execution environment that exists when the first machine instruction of a client program of the format specified above begins execution. Many aspects of the “initial program state” are established by init-program, which sets the saved program state so that subsequent execution of go will begin execution of the client program with the specified environment.

Upon entry to the client program, the following registers shall contain the following values: Register(s) Value Notes msr EE = 0, interrupts disabled 1   PR = 0, supervisor state     FP = 1, floating point enabled     ME = 1, machine checks enabled     FE0, FE1 = 0, floating point exceptions disabled     IP, see     IR,DR, see     SF=0, 32-bit mode     ILE,LE, little endian support 2 r1 See   r2 0 3 r3 reserved for platform binding 4 r4 reserved for platform binding 4 r5 See   r6, r7 See   Other user mode registers 0   Notes: OF will typically require the use of external interrupts for its user interface. However, when a client program is invoked, external interrupts shall be disabled. If a client program causes the invocation of the user interface, external interrupts may be re-enabled. 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. 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 r2 to its TOC, if necessary. As defined in the relevant section of the platform binding.

Client programs shall be invoked with a valid stack pointer ( r1) 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.

When client programs are invoked, r5 shall contain the address of the entry point of the client interface handler. 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. Note: This address points to the first instruction of the client interface handler, not to a procedure descriptor.

The calling program may 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 r6 and r7, 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. Note: 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. Note: boot 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 “bootargs” and “bootpath” properties of the /chosen node.

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., %rl@). 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. Note: 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.

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. Note: 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. 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.

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 callback and $callback in , the callback mechanism follows the same rules as those of Client interface calls. I.e., an argument array is constructed by OF and the address of that array is passed (via r3) to the client’s callback routine; the address of the callback routine is supplied to OF by means of the set-callback client call. 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.

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: alloc-real-mem IN: [address] min_addr, [address] max_addr, size, mode OUT: error, [address] real_addr This routine allocates a contiguous physical memory of size bytes within the address range between min_addr and max_addr. The mode parameter contains the WIMGxPP bits as defined in 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.

As mentioned in , 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 . map IN: [address] phys, [address] virt, size, mode OUT: throw-code, error 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 error cell of the argument array; a non-zero error code shall be returned in error if the mapping cannot be performed. unmap IN: [address] virt, size OUT: throw-code The system removes any data structures (e.g., PTEs) for the virtual address range. translate IN: [address] virt OUT: throw-code, error, [address] real, mode The system attempts to compute the real address ( real) to which the virtual address ( virt) 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 real and error shall be set to false (0). If the translation is not successful, the number of return cells shall be two and error shall be set to a non-zero error code. 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.

An implementation of OF for the PA shall conform to the core requirements as specified in and the following PA-specific extensions.

The following user interface commands represent PA registers within the saved program state. Executing the command returns the saved value of the corresponding register. The saved value may be set by preceding the command with to; the actual registers are restored to the saved values when go is executed. The following command displays the PA processor's saved program state. .registers

%cr Access saved copy of Condition Register. %ctr Access saved copy of Count Register. %lr Access saved copy of Link Register. %msr Access saved copy of the low order 16 bits of SRR1 register. %srr0 and %srr1 Access saved copy of Save/Restore Registers. %pc An alias of “ %srr0 ”

%r0 through %r31 Access saved copies of fixed-point registers. %xer Access saved copy of XER register. %sprg0 through %sprg3 Access saved copies of SPRG registers.

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. %f0 through %f31 Access floating point registers. %fpscr Access Floating Point Status and Control Register.

In addition to the standard Configuration Variables defined by the core OF document , the following Configuration Variables shall be implemented for the PA: “little-endian?” This boolean variable controls the endian-mode of OF. If true (-1), the endian-mode is Little-Endian; if false (0), the endian-mode is Big-Endian. The default value is implementation dependent. “real-mode?” This boolean variable controls the address translation mode of OF. If true (-1), the addressing mode is Real-Mode; if false (0), the addressing mode is Virtual-Mode. The default value is implementation dependent. “real-base” This integer variable defines the starting physical address to be used by OF. “real-size” This integer variable defines the size of the physical address space which can be used by OF. “virt-base” This integer variable defines the starting virtual memory address which can be used by OF. “virt-size” This integer variable defines the size of the virtual address space which can be used by OF. “load-base” This integer variable defines the default load address for client programs when using the load method. The default value is implementation dependent.

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.

This section defines an additional property under the /chosen node for a MP extension. Refer to for more details about the device tree structure for a MP Configuration.

/chosen Node Properties “cpu” property name, identifies the running CPU. prop-encode-array: An integer, encoded as with encode-int, which contains the i-handle of the CPU node that is associated with the “running” CPU.

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 start-cpu client service defined below. Client programs shall use the OF start-cpu client interface service to start all processors before it reclaims the OF memory 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. depicts the relationship of the Running, Stopped and Idle States to each other. The Client Interface Service calls are shown as how to move between the states.

Note: OF's memory cannot be reclaimed by a client if a CPU is in the “stopped” or “idle” state.

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. start-cpu IN: nodeid, pc, arg OUT: none This client interface service starts the CPU. The nodeid is the phandle of a node whose device_type is “cpu”. Start-cpu arranges for the CPU identified by phandle in nodeid to begin executing client code at the real address given by the pc input with an argument, arg, 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. A client should not call start-cpu 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. start-cpu 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 stop-self or idle-self client services defined below at any time. Note: 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. stop-self IN: none OUT: none OF places the processor on which the caller was running into the “stopped” state. The client program is not-resumable. Note: When an MP client program exits, one CPU invokes the exit client interface service, the others invoke the stop-self service. idle-self IN: none OUT: none 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. A processor in idle state can be resumed using resume-cpu service defined below or restarted using start-cpu. If the processor is resumed, it executes a normal return to the client, as if its call to idle-self had just completed. Note: When a client program wants to enter the firmware user interface, one CPU invokes the enter client interface service, the others invoke the idle-self 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. resume-cpu IN: nodeid OUT: none This client interface service is used to resume an *idled* CPU. The nodeid is the phandle of a CPU node in idle state. resume-cpu arranges for that CPU to restore the CPU’s state as saved by idle-self 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 idle-self client interface service. Note: 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 enter service; the client program is responsible for calling the resume-cpu service to resume other idled CPU's, if that is the desired client program behavior.

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.

The firmware is a single threaded program, from the client program's point of view. Only the idle-self, stop-self, enter and exit client interfaces may be invoked simultaneously on different CPUs. Furthermore, only a single CPU may invoke the enter or exit client interface at any one time. The other CPUs must use the idle-self or stop-self client interface service. Note: The results are undefined if the client program invokes client interface services including breakpoint traps (other than the enter/exit stop-self/idle-self case listed above) simultaneously on more than a single CPU. Note: 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.