System BindingLoPAR Boot FlowThis section gives a system boot process overview and defines the
enhancements to the standard OF boot process that are present in the boot
process for an LoPAR platform.Boot OverviewThe platform performs a normal OF boot (see
, as stated in the Core
Practice Document, Section 4.2.3, Start-up script evaluation. LoPAR
platforms provide an additional capability to assist the user in choosing
which of several OSs to boot. A key sequence can be used to interrupt the
normal boot flow and present the user with a
multiboot menu, which can be either graphical or
text-based at the discretion of the platform’s firmware, from which
the user can choose one of the installed or installable OSs. Presenting
the user with this choice can also be made the default mode of operation
at platform boot time, by means of the
auto-boot? and
menu? configuration variables.An overview of a platform boot sequence and the additions of the
multiboot menu are given below:The boot flow described above occurs after all of the devices have
been probed (i.e., by the execution of
probe-all); see
additional requirements for
probe-all method.The boot sequence defaults to a normal boot if the boolean variable
auto-boot? is true and
diagnostic-mode? is false. In this situation, the
system shall then boot from information contained in the configuration
variables
boot-device and
boot-file.From the boot sequence above, entry to the
multiboot menu may occur anywhere after step ‘f’,
banner, if the platform key
sequence (multiboot menu) has been depressed or in step
‘i’ if the boolean variable
menu? is true.Additional Requirements for probe-all MethodBefore probing for plug-in devices, OF shall execute the
probe method, as with
execute-device-method, of any built-in device nodes.
The order of evaluation shall ensure that the
probe method of a parent device node is executed
before the
probe method of any of its children.Note: During this built-in probing, /rom nodes will
locate ROM based OSs. The FCode for these devices can publish their
“bootinfo” properties that are used
during the multiboot scenario as described below.LoPAR MultibootThe boot choices identified to the user are defined by
bootinfo objects hich are located on various system
media. Each
bootinfo object contains information about one OS,
such as its name and description, an icon depicting it, and an OF command
sequence to load and execute it. The locations where
bootinfo objects can be found are specified by OF
device-specifiers that are the values of
configuration variables, the names of which are of the form
“bootinfo-nnnnn”, where
“nnnnn” is OS-specific. These
configuration variables are stored in the System
Partition in NVRAM and are published in the
device tree as properties under the
/options node. The
multiboot menu will use these
configuration variables to locate and parse
bootinfo to obtain the OS icon, description,
etc.In addition to the
bootinfo-nnnnn configuration variables, the
multiboot menu will search the device tree for nodes
containing
“bootinfo” properties, which specify that
the node can supply a
bootinfo object. This is particularly useful for OSs
contained in ROMs.Note: The order prescribed by probe-all guarantees
that these properties be created before the
multiboot menu has been invoked.Different versions of the same OS may each have their own
bootinfo and associated
configuration variables. Although it is possible to
put
bootinfo in any media location that OF can read, this
specification defines standard locations for various types of media, to
allow the firmware to establish the
bootinfo configuration variables automatically in
many cases.Bootinfo Configuration VariablesA
bootinfo configuration variable is any
configuration variable that meets the following
requirements:Its name is of the form
“bootinfo-nnnnn”, where
nnnnn is a string of at most 22 characters from the
set of valid characters for OF configuration variable names. The exact
value of
“nnnnn” for a particular OS may be chosen
by that OS. The naming convention for the OS should be chosen to avoid
possible naming conflicts between OS vendors.Its value is an OF
device-specifier that identifies an object (e.g. disk
file, tape file, disk partition or
/rom child node) whose contents are a
“bootinfo object” as defined
below.Bootinfo PropertiesAny node in the device tree can have a
“bootinfo” property whose value specifies
the arguments to use in opening that device in order to access its
bootinfo object.“bootinfo” Sproperty name locates the node’s
bootinfo objectprop-encoded-array: A string, encoded as with
encode-stringThe presence of this property signifies that the device has an
associated
bootinfo object. The value is a text string such
that when this device’s node
open method is called, the value of text string that
is passed to the device’s node
open method is
“my-args”. When so opened, subsequent
calls to the node’s
“read” method will yield the contents of
the node’s
bootinfo object.Standard Locations for Bootinfo ObjectsThe standard locations for
bootinfo objects on various LoPAR media and
partition types is shown in the table below. An OS must put its
bootinfo object in the standard location in order to
guarantee interoperability with the LoPAR
multiboot menu mechanism.
Standard Pathnames for
bootinfo.txt File
NameDevice/PartitionNotesInstallation Media:Any block device:device:partition,\ppc\bootinfo.txtAny file system formatTape:device:0 (Note 1)Presence of bootinfo.txt is optionalROM:device:bootinfobootinfo is the value of the
“bootinfo” property in a
/rom child nodeNetwork:Could specify bootinfo.txt or some other file from the
Bootp serverSpecifying bootinfo.txt from the Bootp server is
optional
Note 1: If bootinfo.txt file is not present, file 0
should contain a program image file for a bootable tape.Example of installed (
“bootinfo-nnnnn”) block device
(disk):ALIAS EXAMPLE:bootinfo-aix-4.3=disk:2 (The contents of partition 2, which is
probably a “0x41” partition, on the default disk, is the
bootinfo.txt file for a version of the AIX
OS.)bootinfo-nt-4.0=disk:\os\winnt\bootinfo.txtNON-ALIAS EXAMPLE:bootinfo-aix-4.4=/pci@ff500000/pci3,1000@10/sd0,0:3 (The contents
of partition 3, which is probably a “0x41” partition, on the
SCSI disk at target 0 unit 0, is the
bootinfo.txt file for a version of the AIX
OS.)Bootinfo ObjectsThe information used by OF to display information in the
multiboot menu and to
locate and process an OS load image is contained
within a sequence of text that is called a
bootinfo object. The text comprising the bootinfo
object uses SGML syntax, as defined in
, with tags identifying the
subordinate elements.The following outline is a summary of the organization of the
bootinfo object. Elements at the same level do not
have any required order. The tags are illustrated in upper case, but
shall be processed in a case-insensitive manner.
....
....
....
hh hh hh hh . . .
]]>Notes:If ‘SIZE’ is not present, assume default of 64,64.
If ‘COLOR-SPACE’ is not present, assume default of
3,3,2.Another <chrp-boot> tag sequence could define a different
boot selectionLoPAR platforms will recognize only the tags between the
beginning <chrp-boot> tag until the end </chrp-boot> tag. If
a tag is unrecognized, the material will be ignored until the end tag.
Other non-<chrp-boot> tags may be supported in the future. These
additional selections would also be presented to the user as boot
options.Bootinfo EntitiesSGML provides “entities” that provide symbolic names
for text. When the entity names are contained within & and
‘;’, the entity is replaced with text as defined by the
entity; i.e., entities provide a “macro” substitution
capability. The
bootinfo object may use entities to supply pathname
components that depend upon the location of the file. Also, entities have
been defined for the standard SMGL Tags for the presence of the
‘<‘, ‘&’ and ‘>’ characters
in the text as <, & and >. Within the
<BOOT-SCRIPT> element, the following entities are defined with
respect to the fully qualified pathname of the
bootinfo object:devicethe device component.partitionthe partition component.directorythe directory component.filenamethe filename component.full-paththe entire fully qualified pathname.The fully qualified pathname could be represented by the following
text:
Note: Underlined portions illustrate where entities
are positioned within the full pathname.Bootinfo Character SetsThe character set used by the bootinfo.txt file is ISO-8859-1
(Latin-1). Element tags and entity names are not case sensitive; all
other text is case sensitive.Element Tag DescriptionsThe following sections describe each of the element tags and how
they are used.CHRP-BOOT ElementThis element provides the grouping for each OS that is represented
within a single bootinfo.txt file. Multiple CHRP-BOOT sections are
allowed within a single bootinfo.txt file.OS-NAME elementThis element contains the complete name of the OS.BOOT-SCRIPT elementThis element contains an OF script that is executed when the OS
defined by this CHRP-BOOT section is selected to be loaded. Each line of
this element is processed as if it were entered from the input device of
the user interface. Typically, the last line of this script would contain
a
boot command; the pathname of the OS’s load
image can be constructed with the entities described above.ICON elementThis element describes the OS icon that can be displayed by the
multi-boot process. The icon should be designed to be pleasant against a
light background.The SIZE parameter consists of a two decimal numbers, separated by
a comma, that represent the width and height (in pixels) of the icon,
respectively. The default value is “64,64”The COLOR-SPACE parameter consists of three decimal numbers,
separated by commas, that represent the number of bits for the red,
green, and blue components of each pixel. The default value is
“3,3,2”1.Note 1: This version of LoPAR supports only a 3,3,2
icon color-space and 64,64 icon size. Other icon size’s and
color-space’s are reserved for future implementations.If an icon is not stated, the platform will display a generic
system icon that is platform dependent.BITMAP elementThis element specifies the bitmap. It consists of a sequence of hex
digit pairs, each of which defines a pixel; white spaces is allowed
between pixel values. The number of hex digit pairs is defined by the
product of the width and height values of the SIZE parameter.icon string example:<icon size=64,64
color-space=3,3,2><bitmap>hh hh...hh2</bitmap></icon>Note 2: Hex string would be 8192 characters for a
size=64,64 in the above example.For the two examples below, the tags have been indented and
separated by line feeds for each start/end tag pair to make a more
readable script style.AIX Bootinfo Object Example:AIX 4.2.D.0AIX 4.2.D.0boot &device;:2hh ... hh1
]]>AIX Diagnostics Bootinfo Object Example:AIX 4.2.D.0 DiagnosticsAIX 4.2.D.0 Diagnosticsboot &device;:2 diaghh ... hh
]]>Note: 64x64 icon size would have 8192 hex string
characters in the "hh ... hh" field above.Multiboot MenuIf the boot sequence is interrupted by the multiboot key sequence,
then the firmware shall present a
multiboot menu that provides at least the functions
listed below. The form of the menu (e.g. graphical or text- oriented) and
the selection mechanism (e.g. numbered choices, arrow keys, or mouse) are
platform-dependent.Multiboot Required Functions:Locate all bootinfo objects specified by bootinfo configuration
variables and device node
“bootinfo” properties. For each
bootinfo object, present a choice corresponding to
each valid <chrp-boot> section contained therein. For each such
choice, allow the user to either:Execute the contents of that
bootinfo object’s<boot-script>
element.Set the
boot-command configuration variable to the contents
of that
bootinfo object’s<boot-script>
element.Present a choice corresponding to each install device, which,
when invoked, will attempt to locate a bootinfo object at the
device’s standard location (see Table 1).Allow the user to manage configuration variablesAllow the user to invoke the OF user interfaceAdditional options that could be implemented would be to provide a
means to get to diagnostics or specific platform options.There shall be at least one key sequence to enter the multi-boot
platform function for an LoPAR platform.Note: OS have the responsibility to update the NVRAM
System Partition Variable to reflect a change where the
bootinfo.txt file is located; e.g., moving to a
different disk device. Also, the OS is responsible for maintaining the
contents of the
bootinfo.txt file.Reboot-Command Variable DescriptionThe OS can cause OF to execute a specified sequence of commands at
the next boot by setting the value of the
reboot-command configuration variable. LoPAR
firmware implementations shall implement the following configuration
variable.reboot-command(-- addr len) [N]One time or temporary reboot command.The value of this configuration variable is a string consisting of
zero or more lines of text, with lines separated by either
<return>, <linefeed>, or
<return><linefeed>.During firmware start-up, just prior to checking the
auto-boot? configuration variable for automatic
booting, the firmware shall check the value of
reboot-command. If the value is not the empty
string, the firmware shall save the value to a temporary location, set
reboot-command to the empty string, and evaluate the
saved value as though it were a series of user interface command
lines.If the evaluation of
reboot-command returns without executing, the
firmware shall proceed with its normal start-up sequence. In typical
usage, however, the value of
reboot-command will include a
boot command that starts a client program and does
not return.LoPAR ProcessorOF defines a minimum cell size of 32 bits; therefore, only one cell
is necessary to represent addresses up to 4GB (32 bits). Two cells are
necessary to represent addresses above 4GB and within 64 bits. Also, two
cells are necessary to represent sizes greater than 4GB.Processor Endian-ness SupportLoPAR requires the use of PA processors that support Big-Endian
storage format. LoPAR allows for the use of PA processors that support
Little-Endian storage format in addition to Big-Endian storage
format.Multi-Threading SupportThe processors used in some platforms support multiple threads of
execution. This processor model differs from Symmetric Multi-Processors
in that the multiple threads of execution share the processor hardware to
such an extent that operations on one thread can significantly affect the
performance of another tread of the same processor. Therefore, the
processor is represented with a single processor node having multiple
interrupt server numbers. The OS is then free to start and stop
multi-threading as the processing environment dictates. The client
interface call
start-cpu, operates on the full CPU as presented in
the device tree, upon successful completion, the started CPU is running
in single threaded mode, the active thread being the one associated with
the first interrupt server number in the
“ibm,ppc-interrupt-server#s” property.
The client interface calls:
stop-self, idle-self, resume-cpu are all defined to
operate on the full CPU when called in single threaded mode, the behavior
of these calls if called with multiple threads active is implementation
dependent, it is suggested that the implementation deactivate all but one
thread before performing the call’s standard function.OF Platform ExtensionsThis section defines OF properties, methods, device tree structure
and Client Interface Service requirements for LoPAR platforms.The naming conventions for IBM unique OF properties and devices are
as follows:Properties created for use only by IBM compatible implementations
must have the string
“ibm,” as a prefix to the property
name.Property names prefixed with the string
“ibm,fw-” are reserved for and must be
controlled by the Firmware Area.An IBM property name which does not have the firmware or AIX prefix
must be defined in this document unless documented elsewhere.The value of a device
“name” whether reported through the
compatible property or name property for a device implemented by IBM must
contain the string
“IBM,” as a prefix unless it conforms to a
binding which specifies otherwise.Properties for Dynamic ReconfigurationThe following property, when present, replaces the following four properties:
“ibm,drc-indexes”,
“ibm,drc-names”,
“ibm,drc-types” and
“ibm,drc-power-domains”.
This property is defined for all dynamically reconfigurable platform nodes.“ibm,drc-info”property name that defines all required DR information in a new formatprop-encoded-array: The first element of the array is the number of drc-info entries,
encoded with
encode-intThe drc-info entry consists of the following elements:The drc-type encoded with
encode-string.
Examples include “MEM” “PHB” and “CPU”The drc-name-prefix encoded with
encode-string.
Examples include “LMB” “PHB “ “CPU “ and “U8233.E8B.1000C9P-V1-C”The drc-index-start encoded with
encode-int.
The first drc-index of the first entity in the sequence of
entities described by this ibm,drc-info entry.The drc-name-suffix-start encoded with
encode-int.
The integer value that is to be converted to asci and appended to the
drc-name-prefix to create the complete
drc-name of the first entity in the sequence of entities
described by this ibm,drc-info entry.The number-sequential-elements encoded with
encode-int.
The number of sequential entities described by this
ibm,drc-info entry.The sequential-increment encoded with
encode-int.
The number by which to increment the drc-index and the name-suffix
for each sequential entity.The drc-power-domain encoded with
encode-int.The following properties have been replaced by the
“ibm,drc-info” but are documented
here for legacy purposes:“ibm,drc-indexes”property name denotes an integer index to be used to
communicate to the firmware what connector is to be operated upon for the
various RTAS calls used for DR.prop-encoded-array: An integer encoded as with
encode-int, followed by a list of integers also
encoded as with
encode-int.For each DR connector, a unique integer index is provided which
uniquely identifies the DR connector for purposes of the
ibm,configure-connector,
set-indicator, and
get-sensor RTAS calls. The first element of the array
is the number of connectors associated with the node. The second element
of the array is the index which represents the first connector associated
with the node, the third element the second connector, and so on until
all of the node’s DR connectors are specified.“ibm,my-drc-index”property name denotes an integer index (value of the
entry in the
“ibm,drc-indexes” property) for the
connector between the node and the node’s parent.prop-encoded-array: An array of integers encoded as
with
encode-int.“ibm,drc-names”property name describes the external labeling of the
DR connectors.prop-encoded-array: An integer encoded as with
encode-int, followed by a list of strings each
encoded as with
encode-string.For each DR connector, a unique human-readable name for a
connector. The first element of the array is the number of connectors
associated with the node. The second element of the array is the
human-readable name which represents the first connector associated with
the node, the third element the second connector, and so on until all of
the node’s DR connectors are specified.“ibm,drc-power-domains”property name gives the power domain number for each
connector associated with the node, which is the domain number to be used
in the
set-power-level RTAS call, if necessary.prop-encoded-array: An integer encoded as with
encode-int, followed by a list of integers also
encoded as with
encode-int.For each DR connector, the power domain which will be controlled
for DR operations (the power domain in which the DRC resides), and which
will be used, if not -1, in the
set-power-level RTAS call for the connector. The
power domain number of -1 denotes a live-insertion power domain (in which
case, the
set-power-level RTAS call is not used). The first
element of the array is the number of connectors associated with this
node. The second element represents the domain number for the first
connector. The element following this is the domain number for the second
connector, and so on until all of the node’s DR connectors are
specified.“ibm,drc-types”property name, describes the type of each connector
associated with the node, in a human-readable form.prop-encoded-array: An integer encoded as with
encode-int, followed by a list of strings each
encoded as with
encode-string.The first element of the array is the number of connectors
associated with this node. The second element of the array is the
connector type of the first connector associated with the node, the third
element the second connector, and so on until all the node’s DR
connectors are specified, and these elements will be one of the currently
defined connector types specified in
.
Currently Defined DR Connector TypesConnector Type(character
string)Description1A 32-bit, 5 Volt conventional PCI slot which accommodates
cards that operate up to 33 MHz Only.2A 32-bit, 5 Volt conventional PCI slot which accommodates
cards that operate up to 33 MHz.3A 32-bit, 3.3 Volt conventional PCI slot which
accommodates cards that operate up to 33 MHz Only.4A 64-bit, 5 Volt conventional PCI slot which accommodates
cards that operate up to 33 MHz Only.5A 64-bit, 5 Volt conventional PCI slot which accommodates
cards that operate up to 33 MHz.6A 64-bit, 3.3 Volt conventional PCI slot which
accommodates cards that operate up to 33 MHz Only.7A 32-bit, 3.3 Volt conventional PCI slot which
accommodates cards that operate up to 66 MHz. IOAs that operate
up to 66 MHz will only operate at frequencies above 33 MHz if
there are no 33 MHz IOAs on the same bus.8A 64-bit, 3.3 Volt conventional PCI slot which
accommodates cards that operate up to 66 MHz. IOAs that operate
up to 66 MHz will only operate at frequencies above 33 MHz if
there are no 33 MHz IOAs on the same bus.9Reserved10Reserved11A 32-bit PCI-X capable slot which accommodates cards that
operate up to 66 MHz12A 32-bit PCI-X capable slot which accommodates cards that
operate up to 100 MHz13A 32-bit PCI-X capable slot which accommodates cards that
operate up to 133 MHz14A 64-bit PCI-X capable slot which accommodates cards that
operate up to 66 MHz15A 64-bit PCI-X capable slot which accommodates cards that
operate up to 100 MHz16A 64-bit PCI-X capable slot which accommodates cards that
operate up to 133 MHz17A 64-bit PCI-X capable slot which accommodates cards that
operate up to 266 MHz18A 64-bit PCI-X capable slot which accommodates cards that
operate up to 533 MHz19A PCI Express Rev 1 slot with 1x lanes.20A PCI Express Rev 1 slot with 2x lanes.21A PCI Express Rev 1 slot with 4x lanes.22A PCI Express Rev 1 slot with 8x lanes.23A PCI Express Rev 1 slot with 16x lanes.24A PCI Express Rev 1 slot with 32x lanes.25A PCI Express Rev 2 slot with 1x lanes.26A PCI Express Rev 2 slot with 2x lanes.27A PCI Express Rev 2 slot with 4x lanes.28A PCI Express Rev 2 slot with 8x lanes.29A PCI Express Rev 2 slot with 16x lanes.30A PCI Express Rev 2 slot with 32x lanes.CPULogical CPUMEMLogical Memory RegionMEM-n(where n is anon-zero integer)Extended Logical Memory Region(s). Used with the Reserved
Memory option.PHBLogical PCI Host BridgeSLOTLogical I/O slotPORTLogical Port
“ibm,phandle”property name, defines the phandle for the
node.prop-encode-array: An integer encoded with
encode-int.OF Root NodeThis section defines additional properties and methods associated
with LoPAR platforms that OSs expect to find in the root node. Unit
addresses in an LoPAR system are limited to 60 bits in length
corresponding to the maximum real address supported by the POWER
processor architecture. The unit address of all non-system nodes that are
children of the root node shall have the same value each time the
platform is booted; i.e., shall be invariant for each boot
process.Notes:This requirement ensures that the PHB would have a stable unit
address. Violations of this rule may require reinstallation of an
OS.The recommended practice is to generate a virtual unit address
for PHB nodes. This is done by giving a zero length to its first reg
property with an address that is selected such that it remains constant.
In single bridge platforms, the value is chosen based upon historical
precedent of the predecessor product. In multi-enclosure platforms, the
virtual unit address is based upon the manufacturing serial number to
insure uniqueness.Root Node PropertiesThis section defines the additional properties or values which
shall be present in the root node unless otherwise specified.“#address-cells” [S]Standard
property name, encoded as with
encode-int, that specifies the number of cells
required to represent physical addresses on the processor bus. The value
of
“#address-cells” for the processor bus
shall be 1 or 2 depending on whether there is any memory addressable at
or above 4GB’s.“#size-cells” [S]Standard
property name, encoded as with
encode-int, that specifies the size of cells
required to represent physical addresses on the processor bus. The value
of
“#size-cells” for the processor bus shall
be 1 or 2 depending on whether there is any memory addressable at or
above 4GB’s.“clock-frequency” [S]Standard
property name, encoded as with
encode-int, that represents the primary system bus
speed (in hertz).“ibm,extended-clock-frequency”property name: Property that represents the primary
system bus speed in hertz of this node. This property allows the encoding
of multi-giga-hertz quantities.prop-encoded-array: Consisting of two cells
(freq-hi, freq-lo) each encoded as with
encode-int, such that their combined value is
(freq-hi || freq-lo).“system-id” [S]Standard
property name, encoded as with
encode-string, that contains the identification of
the computer system (Reference the
“name” property in
). This string should be unique
across all systems and all manufacturers. An example of an address of
this form is “0nnnnnnmmmmmm” where nnnnnn is a sequence of 6
uppercase hexadecimal digits representing a 24-bit value that identifies
manufacturer and mmmmmm is a sequence of 6 uppercase hexadecimal digits
representing a 24-bit binary number assigned by the manufacturer to
assure uniqueness.Note: For platforms with built-in ethernet or other
IEEE 802-style interfaces, the 6-byte MAC address assigned to that
interface meets the requirements and could be used as the
system-id.“model” [S]Standard
property name that is a printable string identifying
the manufacturer and model number of the platform.prop-encoded-array: Text string, encoded as with
encode-string.The value of this property is a vendor dependent string which
identifies this platform via its manufacturer and model number.“device_type” [S]Standard
property name that is a printable string identifying
the platform as LoPAR Compliant.prop-encoded-array: Text string, encoded as with
encode-string.The value of this property is a string,
“chrp” which identifies the platform is
LoPAR Compliant.“ibm,lpar-capable”property name indicates that the platform is capable
of supporting logical partitioning and is only present on such systems.
This property is, however, present even if the platform is not currently
configured for logical partition operation.prop-encoded-array: <NULL>“ibm,converged-loc-codes”property name indicates that the platform supports
the “Converged Location Code” option. This property shall be
present only on platforms that support the “Converged Location
Code” option.prop-encoded-array: <NULL>“ibm,max-boot-devices”property name indicates the maximum number of
boot-device entries that the OF automatic boot code will process (entries
after this number are ignored). Platforms that do not present this
property default to process a maximum of 5 entries.prop-encoded-array: an integer encoded as with
encode-int.“ibm,aix-diagnostics”property name indicates that the platform is capable
running AIX diagnostics.prop-encoded-array: <NULL>“ibm,diagnostic-lic”property name, presented to partitions authorized to
perform diagnostic operations, that indicates that the platform is
designed to use the specified license internal code package for
diagnostic services.prop-encoded-array: one or more encapsulated package
handles encoded as with
encode-int.“ibm,io-server-lic”property name indicates that the platform is designed
to use the specified license internal code package for I/O
services.prop-encoded-array: one or more encapsulated package
handles encoded as with
encode-int.“ibm,plat-res-int-priorities”property name that designates to the client program
that the platform has reserved one or more interrupt priorities for its
own use.prop-encoded-value: one or more (
interrupt priority, range) pairs, where
interrupt priority is a single cell hexidecimal
number between 0x00 and 0xFF, and
range is an integer encoded as with
encode-int that represents the number of contiguous
interrupt priorities that have been reserved by the platform for its
internal use.“ibm,eeh-default”property name indicates the platform’s default
setting for the EEH option.prop-encoded-array: An integer encoded as with
encode-int that represents the platform’s
default setting for the EEH option. The defined states are:0= The platform boots up with the EEH option disabled.1= The platform boots up with the EEH option enabled.“ibm,model-class”property name to indicate the platform class.prop-encoded-array: string encoded as defined in
.
Example Encoding StringsEncoded StringPlatform ClassC5Blade/EntryD5EntryE5EntryF5Mid-rangeG5High-endH5High-endP5obsolete
“ibm,partition-no” [S]property name to define the partition number of this particular
logical partition as established by the Hardware Management
Console.prop-encoded-array: The logical partition number is a one cell
integer encoded as with
encode-int.“ibm,partition-name” [S]property name to define the partition name of this particular
logical partition as established by the Hardware Management
Console.prop-encoded-array: A NULL terminated string.“ibm,platform-hardware-notification”property name indicating to the OS the presence of
hardware for which the OS may need to take action. This property exists
to notify the OS of hardware elements on the platform which may require
special handling by the OS, such as in response to a hardware
errata.prop-encoded-array: An integer encoded as with
encode-int followed by a list of strings encoded as
with
encode-string.The first element represents the number of strings to follow in the
property. Each string in the array names a hardware element that may
require the OS to take specific action. The intention is that the string
is to name the hardware element being reported. It is not the intention
to define (or even hint at) the action that the OS must take. It is
expected that some source outside this document will contain a cross
reference between these strings and documentation such as hardware errata
notes which define the action the OS must take.If the
“ibm,platform-hardware-notification”
property is provided and a string begins with the <name> field of the
“name” (see
) property in the
CPU nodes followed by an underscore, the characters
following the underscore are a hexadecimal representation of the contents
of a Processor Version Register that the platform may contain.“ibm,fault-behavior”property name to define the behavior of the Error Log
indicator relative to FRU faults.prop-encoded-array: An integer encoded as with
encode-int that represents how the Error Log indicator should be handled
when a FRU fault is detected.Property non-existent -- The OS may set FRU Fault and Error Log
indicators for all errors (those it detected and those that the platform
reports to the OS).Property exists with a value of 1 -- The OS only sets FRU Fault and
Error Log indicators for errors it detects.“ibm,fru-9006-deactivate”property name to define whether or not the OS should
deactivate 9006 indicators that it has activated.prop-encoded-array: An integer encoded as with
encode-int that represents how the OS should behave relative to FRU Fault
indicator deactivation.Property non-existent -- The OS is responsible for deactivating FRU
level 9006 indicators that it has activated.Property exists with a value of 1 -- The OS should not deactivate
FRU level 9006 indicators that it has activated, but is allowed to do so
(firmware does not block). The deactivation of the FRU level 9006
indicators is platform and service procedure dependent.“compatible” [S]Standard
property name that conveys the platform architecture
identifiers.prop-encoded-array: The concatenation, with
encode+, of an arbitrary number of text strings,
each encoded with
encode-string.Specifies a list of platform architectures with which this platform
is compatible. This is used by a client program when it is trying to
determine the appropriate support for this platform. This property shall
include the substring “LoPAR-<LoPAR
version>-<Manufacturer>-<Manufacturer Version>”
where <LoPAR version> is the text (without blanks) after the word
“Version” on the cover page of the LoPAR specification that
the platform adheres to, <Manufacturer> is a unique string
identifying the manufacturer of the platform (see the OF standard
description of the
“name” property for suggestions), and
<Manufacturer_Version> is defined by the manufacturer of the
platform.Note: In order to comply with the OF Standard
description of the
“compatible” property, implementations
should place the “LoPAR-<LoPPR
version>-<Manufacturer>-<Manufacturer Version>”
substring after values that were present in the
“compatible” property prior to the
inclusion of the “LoPAR-<LoPAR
version>-<Manufacturer>-<Manufacturer Version>”
substring.“ibm,max-vios-function-level”property name to define the maximum vios function
level that a client shall permit.prop-encoded-array: An integer encoded as with
encode-int that represents the maximum VIOS level
that the client shall negotiate. See
for the definition of the
values of this property.“ibm,partition-performance-parameters-level”property name to define the level of partition
performance parameter reporting supported by the platform.prop-encoded-array: An integer encoded as with
encode-int that represents the level of partition performance parameter
reporting supported by the platform (See
).
Level of Partition Performance Parameter Reporting
SupportedPartition Performance Parameter
LevelDescription0Base Level1Addition of Processor Virtualization Resource Allocations
to H_GET_PPP and Virtualization Processor idle count to
H_PIC
“ibm,preconfigure-usb-kvm”property name the presence of which indicates that
the platform requires the operating system to force configuration of the
USB keyboard/mouse nodes during its configuration phase.prop-encoded-array: <NULL>This property, when present in the root node, indicates that the
platform requires the operating system to force pre-configuration of USB
keyboard/mouse nodes internally during its configuration phase. This
property is presented only by platforms with a KVM switch that desire to
force configuration by one or more target operating systems that do not
fully support dynamic addition of USB keyboard and mouse unless the USB
keyboard and mouse are actually seen during the operating system
configuration phase, but may be present even if the KVM switch is not
present when the device tree is inspected. Forced pre-configuration is
needed since the operating system may not actually see the USB keyboard
and mouse during its configuration phase due to the KVM switch that the
platform uses only shows USB keyboard and mouse when those devices are
actually switched to the appropriate KVM switch port.“ibm,enable-ci64-capable”property name to define the platform supports the
“ibm,enable-ci64” method in the Client
Interface.prop-encoded-array: None, this is a name only
property.“ibm,migratable-partition”property name indicating that the platform supports
the potential migration of this partition.prop-encoded-array: <NULL>“ibm,extended-address” [S]property name indicates this platform supports
Peripheral Memory Spaces, Peripheral I/O Spaces, and SCA spaces above 4
GB.prop-encoded-array: <none>This property must be present.“ibm,ignore-hp-po-fails-for-dlpar”property name to define that the OS may ignore
failures of Hot Plug power off and isolate operations during a DLPAR
remove operation. See also Note 2 in
.prop-encoded-array: None, this is a name only
property.“ibm,managed-address-types”property name that conveys the platform's supported
types of external addresses that are reprogrammable.prop-encoded-array: The concatenation, with
encode+, of an arbitrary number of text strings as
described in
, each encoded with
encode-string.
Address types supported in
“ibm,managed-address-types”
propertyText StringDescriptionethernet_macEthernet MAC addressethernet_vlanEthernet VLAN ID (for default traffic)san_wwnFibre Channel World Wide Name (covers both Port &
Node names)sas_wwidSAS IOA's WWID value
“ibm,service-indicator-mode”property name indicates in which service indicator
mode the platform is operating.prop-encoded-array: an integer encoded as with
encode-int that represents the mode. Defined values
are:0 = Platform is operating in the Guiding Light mode.1 = Platform is operating in the Lightpath mode.“ibm,guid-partition-table”property name indicates that the partition supports disks
with the GUID Partition Table.prop-encoded-array: <NULL>“ibm,linux-le-capable”property name indicates that the partition is capable of
supporting boot of Little Endian Linux.prop-encoded-array: <NULL>“ibm,partition-uuid”property name specifies a universally unique identifier for this partition.prop-encoded-array: A string of data as described below, encoded as with
encode-stringThe Universally Unique IDentifier (UUID) option provides each partition with a
Universally Unique Identifier that is persisted by the platform across partition
reboots, reconfigurations, OS reinstalls, partition migration, hibernation etc.
The UUID is a 16 byte string of format fields and random bits as defined in
.The random bits are generated in an implementation-dependent manner to
achieve a projected probability of collision of not greater than one in 260.
UUID FormatFieldByte:BitSize (Bits)ValuesVersion0:010: Initial Version1: ReservedRandom Bits0:1 thru 5:747Random BitsGeneration Method6:0-340b0000 Never Used0b0100 Random GeneratedAll other values are reservedRandom Bits6:4 - 7:712Random BitsVariant8:0-120b10 DCE Variant UUIDAll other values are reservedRandom Bits8:2 - 15:762Random Bits
For the GET_PARTNER_UUID subfunction (See ), the data is
represented as 16 bytes as described in .For the ibm,partition-uuid property, the data is represented as a string of
hexadecimal characters, with hyphens added for readability.
Hexadecimal values a through f are lower case. An example of the string
representation of the UUID is 648a9ca6-1fb4-4f7e-9436-14d015f3dd74Implementation Notes:In the absence of this property, the determination of how the OS
is to behave is made by the platform presenting or not presenting FRU
Fault indicators to the OS see chapter
. In the case where there are
no FRUs owned by the partition, the OS will not observe any FRU Fault
indicators assigned, even when the platform is operating in the Lightpath
mode.Presenting this property does not imply any relaxation of the
requirements spe3cified in chapter
.Properties of the Children of Root“ibm,9009-domain”property name that defines the index for a 9009 reset
component indicator, and if it exists, the corresponding 9009 sensor, for
the node in which the property exists. Multiple nodes may have the same
index, indicating that they belong to the same reset domain; including
nodes which are not descendents of the node which contains this property.
Descendents of a node containing this property will be in the same reset
domain.prop-encoded-array: An integer encoded as with
encode-phys that represents the index for the
indicator, and if it exists, for the corresponding sensor.“ibm,associativity”property name to define the associativity domains for this
resource.prop-encoded-array: One or more associativity lists. Each
associativity list consisting of a number of entries integer (N) encoded
as with
encode-int followed by N integers encoded as with
encode-int each representing an associativity domain
number.Root Node MethodsThis section defines methods associated with the platform via
“/” (the
root node).Boot Loader Note: The suggested behavior for boot
loader client programs:Check the “ibm,rpa-client-config”
property to see if
the platform recognized the “ignore-my-settings” bit in the
boot loader image i.e. YABOOT for LINUX.If recognized, check for existence of
“ibm,client-architecture-support”
and invoke that method with the
>ibm,??? compatible (wording???) with the Real Base and Real Size constraints of the
kernel being loaded.If that method did not exist, invoke
“PROCESS-ELF-HEADER” from /packages/elf-loader with a
simulated ELF-header that the Linux kernel is compatible with.ibm,client-architecture-support (ibm,architecture.vec --
err?)This method is called via the call-method
Client Interface Service, prior to starting other
partition processors or threads, to communicate to the platform, via the
ibm,architecture.vec structure, the architecture
options that are supported by the client program. Based upon this
knowledge the platform configures itself and the device tree to represent
the most functional programming environment supported by the combination
of the platform, client program and user specified constraints. If
multiple partition processors or threads are active at the time of the
ibm,client-architecture-support method call, or an
error is detected in the format of the
ibm,architecture.vec structure, the
err? boolean shall be
TRUE; else
FALSE. The
ibm,architecture.vec input parameter is the starting
address of a self defining structure in contiguous memory. Some bits
within the
ibm,architecture.vec structure option vectors
represent policies. When set, and an associated condition is detected,
the
ibm,client-architecture-support method does not
return and processing continues as with a boot failure of the client
program. The LoPAR architecture options that are selected by this method
are communicated in the value of the
“ibm,architecture-vec-5” property of the
/chosen node.To ensure the greatest level of interoperability, the client
program should constrain itself to using the set of instructions and
environment specified for first level interrupt handlers, see Book III of
the
, while not attempting access
to potentially optional SPRs or the MSR prior to invoking the
ibm,client-architecture-support root node
method.Architecture and Implementation Notes:Most of the
IBM,RPA-Client-Config ELF header functionality is
subsumed by the
ibm,client-architecture-support root method. However,
the
ibm,client-architecture-support root method does not
support the functionality specified through the ns.min-load field of the
IBM,RPA-Client-Config ELF header. Supporting firmware
implementations are prepared to move themselves out of the way when
loading client programs.When booting a client program, firmware processes an
IBM,RPA-Client-Config ELF header if present; a
subsequent call of the
ibm,client-architecture-support root method with
conflicting values in the
ibm,architecture.vec structure, overrides the
configuration variables set by the ELF header.Formal definition of ibm,architecture.vec:ibm,architecture.vec = a
PVR-list:
Number-of-option-vectors:
option-vectors[Number-of-option-vectors + 1]PVR-list =
Terminator-list-entry |
Non-terminator-list: Terminator-list-entryNon-terminator-list = Non-terminal-list-entry |
Non-terminal-list-entry : Non-terminator-listList-entry =
4-byte-mask:
4-byte-PVR-valueTerminator-list-entry =
List-entry such that !
4-byte-mask &
4-byte-PVR-value != 0x00000000Non-terminator-list-entry = List-entry such that !
4-byte-mask & 4-byte-PVR-value ==
0x00000000Number-of-option-vectors = The number of option
vectors is n+1 where n is the numeric value of the byte (byte value of
0x00 represents one option vector)option-vector (option-vectors number 1-255): 1 byte
length of the option vector where the number of bytes in the option
vector (including the first byte of length) is n+2 where n is the numeric
value of the byte (byte value of 0x00 represents a two byte option vector
-- one length byte and one bit-vector byte) followed by 1-256 bytes of
bit-vector.option-vector (option-vector number 256): is special
in that it is reserved for expansion. The first byte is again the number
of option vectors in the vector expansion (see definition of
Number-of-option-vectors above). This is followed by
1-255
option-vectors (see definition above) and potentially
a 256th
option-vector which is again an expansion option
vector, and so on.bit-vector: The structure of a bit vector is vector
specific, in general support for most options are indicated by setting a
specific bit to a 1, see
.The
PVR-list of the
ibm,architecture.vec structure is processed for the
PVR value of each processor that the client program may be exposed to
until either a
List-entry allows the process to continue, or the
Terminator-list-entry has been processed. If no
List-entry allows the process to continue, then the
ibm,client-architecture-support method terminates
partition operation as with a boot failure. A
List-entry allows the process to continue if either
of the two following conditions hold.(Processor-PVR-value &
List-entry[4-byte-mask]) == (List-entry[4-byte-PVR-value] &
List-entry[4-byte-mask]) /*The client program explicitly
supports the processor implementation */If (the processor requires no client support for errata)
&&
(Logical-Processor-PVR-value & List-entry[4-byte-mask]) ==
(List-entry[4-byte-PVR-value] & List-entry[4-byte-mask]) /*
Client program specifies support for this level of architecturally
compliant processors */List-entry values of special interest (these are
Terminator-list-entry values):0x00000000 0xFFFFFFFF Single entry list that matches any PVR
value0xFF000000 0x0FFFFFFF Single entry list that matches all
architecturally compliant processors.
ibm,architecture.vec option vectorsOption ArrayOption VectorByte NumberBit NumberDescriptionBase1PowerPC Server Processor Architecture Level 610Ignore1Cessation Policy2Reserved for Expansion (0b0)34567202.0012.0122.0232.0342.0452.0562.0672.07302.081-7Reserved for Expansion (0b0)4-256Reserved for ExpansionBase2Open Firmware10Ignore1Reserved2real-mode3Reserved for Expansion (0b0)45672-30-15Reserved for Expansion (0x0000)4-7real-base0-31OF real starting address or -1 for platform
default8-11real-size0-31Maximum OF size or -1 for platform default12-15virt-base0-31OF starting virtual address or -1 for platform default
(valid for real-mode = 0)16-19virt-size0-31Maximum OF virtual size or -1 for platform default (valid
for real-mode = 0)20-23load-base0-31Starting address of the client program load or -1 for
platform default24-27min-rma-size0-31Minimum size of RMA in MB(total bytes = N*(2**20))28-31min-load0-31Minimum client code to load at load-base or -1 for full
client program at load base32min-rma%0-8RMA size => M% * Partition_memory_size where M is the
value of this 8 bit field33max-pft-size0-8The maximum size of the hash page table as 2**n
17<n<4634-256Reserved for ExpansionBase3IBM PowerPC Server Processor Options10Ignore1Cessation Policy2Reserved for Expansion (0b0)3456720Floating Point1VMX2Decimal Floating Point3Decimal Floating Point Facility (The value of the ibm,dfp
property indicates the architecture level of the
facility.)4Reserved for Expansion (0b0)5673-256Reserved for ExpansionBase4LoPAR Implementation101Cessation Policy2ibm,change-msi busy: If set, the client program supports RTAS
ibm,change-msi returning a -2 (Call again) or 990x (Extended delay)3Reserved for Expansion (0b0)456720-7Minimum VP entitled capacity percentage * 100 (if absent
assume 10%)2-256Reserved for ExpansionBase5LoPAR or OF Options10Ignore1Cessation Policy264 bit PE TCEs : If set, the client program supports ibm,query-pe-dma-window
returning a 64-bit value for PE TCEs3Reserved for Expansion (0b0)456720Logical Partitioning: If set the client program supports
logical partitioning and associated hcall()s; else the client
program shall be run with the hypervisor bit on.1Shared Processor Logical Partitioning: If set the client
program supports the Shared Processor LPAR Option and may be
run with that option enabled; else the Shared Processor LPAR
Option shall be disabled for this partition.2ibm,dynamic-reconfiguration-memory: If set the client
program supports the
“ibm,dynamic-reconfiguration-memory”
property and it may be presented in the device tree; else, the partition
memory shall be represented with individual
memory nodes.3Large Pages: If this bit is set, the client supports
pages larger than 4 KB; else, the platform shall represent all
of memory as mapped via 4 K pages.4Alpha Partition5Tolerate long delays in H_MIGRATE_DMA6Client supports donating dedicated processor
cycles7PCI Express/MSI Support: If set, the client supports PCI
Express implementations utilizing Message Signaled Interrupts
(MSIs).30On input to ibm,client-architecture-support a non-zero
value indicates that the client supports the I/O Super Page
Option (Support of >4K I/O pages) (Includes extensions to
H_MIGRATE_DMA for >4K I/O pages and >256 xlates).
See .In the
ibm,architecture-vec-5 property of the
/chosen node, a non-zero value indicates
that the platform supports the I/O Super Page Option (Support
of >4K I/O pages).1-4On input to ibm,client-architecture-support this field
shall be zero.In the
ibm,architecture-vec-5 property of the
/chosen node, this field represents the
implementation dependent number of xlates entries supported per
migration operation as: 256 * 2**N.
See .5-7On input to ibm,client-architecture-support this field
shall be zero.In the
ibm,architecture-vec-5 property of the
/chosen node, this field represents the
implementation dependent number of simultaneous migration
options supported as: 2**N.
See .Base5LoPAR or OF Options4Cooperative Memory Over-commitment Option Control0The value of 1 enables the Cooperative Memory
Over-commitment Option1The value of 1 enables the Extended Cooperative Memory
Over-commit Option2-7Reserved for Expansion5Associativity Information Option Control0= the “Form value” of the
“ibm,associativity” and
“ibm,associativity-reference-points”
properties. See for further details.1Platform Resource Reassignment Notification (Affinity
Change)2-7Reserved for Expansion6Binary Option Controls0Enable MTT OptionSee
.1Reserved2Enable Active Memory Compression3Reserved for Expansion4Reserved for Expansion5Enable Hotplug Interrupts
See Hot Plug Events in .6Enable Support for Multiple Hotplug Slots per PHB7Reserved for Expansion7Reserved for Expansion8Reserved for Expansion9-12Max Processors Supported
(For legacy support, if this byte is not present the
partition is limited to a maximum of 64 processors)0-3132 bit unsigned integer maximum number of OF device tree
nodes of type “cpu” that may be presented to this
partition.13-140-7 & 0-7Highest Base LoPAR Level Supported as the binary
contents of 13.14
(i.e. level 4.15 would be encoded as 0x040F)15-16Memory Reference Instrumentation0Reference History Array1Access Rate Array2Affinity Domain Access Log3-15Reserved for ExpansionBase5LoPAR or OF Options17-20Platform Facilities Enable – Value of 0b1 indicates
facility is enabled0Random Number Generator1Compression Engine2Encryption Engine3-31Reserved for Expansion -- Value = 0b0210-7Sub-Processor Representation Level --Defined Values:
0: Sub-Processors not supported
1: 1,2,or 4 Sub-Processors supported
2-255 Reserved220If set the client program supports the
“ibm,dynamic-memory-v2”
property in the
“ibm,dynamic-reconfiguration-memory”
node and it may be presented in the device tree;
else, the “ibm,dynamic-memory”
property shall be represented.1If set the client program supports the
“ibm,drc-info”
property definition and it may be presented in the device tree;
else, the “ibm,drc-indexes”,
“ibm,drc-types”,
“ibm,drc-names”, and
“ibm,drc-power-domains” properies shall be presented.2-7Reserved for Expansion23-256Reserved for ExpansionBase6Hints10Reserved for Expansion (0b0)123456720Secondary Page Table Entry Group: If set, the client does
not use secondary page table entry groups; else the client may
use secondary page table entry groups.1Reserved23456730-7OS Name: Represents the name of the client OS. Defined
values include:
0x0: Reserved
0x1: AIX
0x2: Linux
0x3-0xFF: Reserved for Expansion4-256Reserved for Expansion7OS Identification1-256An ASCII character formatted null terminated string that
describes the client operating system. The string shall be
human readable and may be displayed on the console.8-255Reserved for Expansion256Reserved for Expansion to the first Extension Option
ArrayExtensions 1-NReserved for Expansion
Notes:The Ignore Policy bit indicates that the client program assumes
all responsibility for the options represented by the option vector. The
firmware is to configure the platform at the highest level consistent
with its configuration variables and ignore the rest of the specific
option vector. An option vector with the Ignore Policy bit set need be no
longer than two bytes (size=0, data = 0b1ddd dddd where d = don’t
care).The Cessation Policy Bit determines if the partition continues
to run if the platform must operate with an option enabled that is not
explicitly supported by the client program as represented by the option
vector setting. If the Cessation Policy Bit is 1, then processing halts
as with a boot failure. If the Cessation Policy Bit is 0 then client
program processing continues if the unsupported option is initialized to
a benign state and stays in that state unless an aware program activates
the option, and the option does not appear in the device tree. If an
unsupported option cannot be initialized to a benign state, then
processing halts with a boot failure. Following are the detailed
definitions of benign state for selected bit vectors.For option vector numbers 1 “PowerPC Server Processor
Architecture Level” and 3 “IBM PowerPC Server Processor
Extensions” the benign state is defined as unable to generate
exceptions, mask errors, or present covert channel exposures.For option vector number 5 “LoPAR Options” Byte 2
bit 5 “Alpha Partition” The Cessation Policy bit is not
applicable.For option vector number 2 “Open Firmware” the
Cessation Policy Bit is not defined, the platform either accommodates the
values defined in the option vector or proceeds as with boot
failure.The Initial size
of the RMA is set to the greater of the values indicated by bytes 24-27
or 32 of option vector number 2 “Open Firmware” or minimum
RMA size supported by the platform and capped by the maximum memory
defined for the partition and the maximum size of the RMA supported by
the platform. The respective selected values are reported in the length
of the first
memory property.The Alpha flag only applies to the first partition of a non HMC
managed system and activates overrides to the partition's I/O resource
allocation as defined in the partition definition.If the system is HMC managed, the flag is ignored and the client
program gets the resources assigned by its partition definition (no
overrides are activated).If the partition is not the first partition, the flag is ignored
and the client program gets the resources assigned by the partition
definition (no overrides are activated).If the Alpha flag applies, and is set, then the partition gets a
VMC virtual I/O device in its device tree regardless of its partition
definition (Override to include VMC is activated).If the Alpha flag applies, and is not set, then the partition
does not get a VMC virtual I/O device in its device tree regardless of
its partition definition (Override to remove VMC is activated) and it
gets all the physical I/O resources in its device tree regardless of its
partition definition (Override to include all physical I/O is activated).
Note this condition requires that any other platform partitions be
terminated.Given that the Ignore policy bit is off and the partition
continues to run, the options and values presented in by this option
vector and supported/chosen by the platform firmware are reported in the
“ibm,architecture-vec-5” property of the
/chosen node.Option vector number 1 “PowerPC Server Processor
Architecture Level” and the property that reports the chosen value
(i.e.,
“cpu-version”) represent the operational
base architectural level of the processors -- that is without regard to
enabled processor architectural options. Option vector number 3
“IBM PowerPC Server Processor Extensions” and option specific
properties that report the chosen values represent the active processor
architectural options. Some processor implementations may not support all
combinations of these two option vectors. The firmware shall activate the
highest level of processor support, consistent with partition attributes,
that does not exceed the most restrictive of the two option vectors. Note
the Cessation Policy bit may allow operation where the lowest level of
processor support still exceeds the most restrictive case.If a client program does not support logical partitioning no
other client programs may be running simultaneously on the platform. The
platform may impose further restrictions beyond the scope of LoPAR. If
the platform honors the client program restriction of not supporting
logical partitioning, upon return the logical real address equals the
platform real address. If the platform can not honor the restriction, the
processing terminates as with a boot failure. The cessation policy option
vector bit has no effect upon logical partitioning option vector
bit.ROM Node(s)The ROM Node(s), when present to represent optional platform read
only memory containing directly executable platform firmware, shall be a
child or children of the root node.ROM Node PropertiesEach ROM Node shall have the following properties:“name” [S]Standard
property name that denotes a ROM Node.prop-encoded-array: A string, encoded as with
encode-string.The value of this property shall be
“rom”.“reg” [S]Standard
property name to define a unit-address for the
node.prop-encoded-array: One (
phys-addr, size) pair.The
phys-addr of this property shall be the starting
physical address of this ROM and the
size value shall be 0. The
size =0 prevents a conflict with the
“reg” of this node’s
children.“#address-cells” [S]Standard
property name to define the address space
representation of child nodes.prop-encoded-array: an integer, encoded as with
encode-int. Its value shall be identical to that of
this node’s parent’s
“#address-cells” value.“ranges” [S]Standard
property name to define the address range that is
decoded by this
/rom node.prop-encoded-array: One (
child-phys,
parent-phys,
size) triple, where
child-phys equals
parent-phys and the number of cells of each
corresponds to the parent’s
“#address-cells” value.“available” [S]Standard
property name to define available ROM
resources.prop-encoded-array: Arbitrary number of
phys-addr, size pairs.
Phys-
addr is a
phys.hi...phys.lo list of integers, each integer
encoded as with
encode-int.
Size is one or more integers, each encoded as with
encode-int.The value of this property defines resources, managed by this
package, that are currently available for use by a client program.“write-characteristic” [S]Standard
property name defines the ROM Technology.prop-encoded-array: a string, encoded as with
encode-string, where the value could equal
“flash”,
“eeprom”,
“rom” or
“nvram”.“cacheable” [S]OF standard property indicating that the ROM is cacheable.prop-encoded-array: <none>.The presence of this property indicates that the ROM is
cacheable.ROM Node MethodsIf one or more ROM nodes are present, they shall each implement the
following standard methods per
, Section 3.6.1. The
“reg” property is used to determine which
ROM the standard methods apply to for multiple ROM’s.The following methods must be defined by
/rom node.open (-- true) [M]Standard method to prepare the ROM Node for subsequent use.close (--) [M]Standard method to close the previously opened ROM Node.decode-unit
(addr len -- phys.lo...phys.hi) [M]Standard method to convert text unit-string to physical address.encode-unit
(phys.lo...phys.hi -- unit-str unit-len) [M]Standard method to convert physical address to text unit-string.probe (--) [M]OF method used at boot time to probe all ROM’s.The
probe method for ROM Nodes shall probe for FCode
images within the address space defined by its
“reg” property as defined herein. For
each page within its address space, look for a valid FCode image. A valid
FCode image is defined to start with an FCode-header (see section 5.2.2.5
in
) where the first byte is
start1, the format byte is 0x08, the length field
indicates that the FCode program is contained within the address space of
the
/rom node, and where the checksum is correct. (This
probing must take into account the possibility that the ROM image is in
the opposite endian-ness from which OF is currently running.)If such an FCode image is found, a new child node shall be created
by executing
new-device and
set-args, the FCode image copied to memory (taking
into account the endian-ness) and the copy evaluated with
byte-load. (The FCode program can use
my-unit to create its
“reg” property.). The arguments used by
set-args are defined to be 0,0,unit-str, unit-len
where unit-str is a text string representation of the physical address
location for the FCode Image and unit-len is the length of the FCode
Image.ROM Child Node(s)This section describes the properties and methods for a ROM Child
Node.ROM Child Node PropertiesThe following properties must be created by
/rom child nodes.“name” [S]Standard
property name that denotes a ROM child node.prop-encoded-array: A string, encoded as with
encode-string.Some physical ROM implementations may not fully decode their entire
address range. This could lead to multiple images of the ROM to appear at
different addresses, due to the “aliasing” of the ROM image.
To prevent multiple device nodes from appearing in the device tree, the
FCode for such ROMs should look for an already existing peer node that
represents their image. This could be done, for example, by checking that
any of the peer of the child of its parent node has a
“name” property value that is the same as
this node’s FCode would create.If such a node is found, the FCode should “abort” the
evaluation of its FCode (e.g., by executing an
end0) before creating its
“name” property. OF shall remove a node
when the FCode evaluation for the node does not result in a
“name” property being defined.“reg” [S]Standard
property name that defines the child node address
range for a ROM image(s).prop-encoded-array: List of (
phys-addr, size) specifications.Phys-addr is encoded as with
encode-phys, and
size is encoded as with
encode-int. The
phys-addr is a base address of the ROM image and
size is the length of the ROM image.ROM Child Node MethodsThe following methods must be defined by
/rom child nodes.open (-- true) [M]Standard method to prepare this device for subsequent use.The
open method must be prepared to parse
my-args for the case(s) when the node is being opened
in order to access “files”; e.g., when the bootinfo.txt file
is being accessed during the
multiboot menu.close (--) [M]Standard method to close the previously opened device.load (addr -- len) [M]Standard method to load an image. The image must be one that is
recognized by the OF
init-program method. It is strongly recommended that
the ELF format be used, since it has the mechanism to specify
configuration variable requirements of an OS.Run Time Abstraction Services (RTAS) NodeThis system node is a child of
“/” (root). This section defines
properties and methods for the RTAS node. The RTAS Node shall not have
“reg” or
“ranges” properties.RTAS Node PropertiesThis section describes the
rtas node properties.“name” [S]Standard
property name that denotes the RTAS node.prop-encoded-array: A string, encoded as with
encode-string.The value of this property shall be
“rtas”.“rtas-event-scan-rate” [S]property name that is the rate at which an OS should
read indicator/sensor/error dataprop-encoded-array: An integer, encoded as with
encode-intThe value of this property shall be a number indicating the desired
rate for reading sensors and/or error information in calls per minute.
This number is platform dependent.“rtas-indicators” [S]property name that indicates indicators are
implemented.prop-encoded-array: An array of paired integers (
token maxindex), each encoded as with
encode-int.The values for this property is a list of integers that are the
token values (
token) for the defined indicators and the number of
indicators (
maxindex) for that token which are implemented (see
) on the platform.Note: The indicator indices for a given token are
numbered 0... maxindex-1.“rtas-sensors” [S]property name that indicates sensors are
implemented.prop-encoded-array: An array of paired integers (
token maxindex), each encoded as with
encode-int.The values for this property is a list of integers that are the
token values (
token) for the defined sensors and the number of
sensors (
maxindex) for that token which are implemented (see
) on the platform.Note: The sensor indices for a given token are
numbered 0 ... maxindex-1.“rtas-version” [S]property name describes version information for the
RTAS implementation.prop-encoded-array: An integer, encoded as with
encode-int.The value of this property shall denote the version the RTAS
implementation. For this version, the integer shall be as defined in this
architecture.“rtas-size” [S]property name is the size of the RTAS memory
image.prop-encoded-array: An integer, encoded as with
encode-int.The value of this property shall be the amount of contiguous real
system memory required by RTAS, in bytes.“rtas-display-device” [S]property name identifies RTAS Display Deviceprop-encoded-array: An integer, encoded as with
encode-int.The value of this property shall be the
phandle of the device node used by the RTAS
display-character function.“rtas-error-log-max” [S]property name identifies maximum size of an extended
error log entry.prop-encoded-array: An integer, encoded as with
encode-int.The value of this property shall be the maximum size of an extended
error log entry, in bytes.“power-on-max-latency” [S]property name specifies a future power on time
capability.prop-encoded-array: An integer, encoded as with
encode-int.The value of this property specifies the capability of the hardware
to control the delay of system power on in days. If the property is
present, the value shall indicate the maximum delay or latency in days.
If the property is not present, the maximum delay or latency is 28
days.“ibm,preserved-storage”property name specifies that the client program was
loaded with one or more LMBs preserved from a previous client
program.prop-encoded-array: None, this is a name only
property.The client program may wish to save the contents of the preserved
LMBs and deregister the LMBs for preservation.“ibm,scan-log-directory”property name specifies that the platform supports
the scan-log directory option.prop-encoded-array: None, this is a name only
property.“ibm,indicator-<token>”property name to provide a FRU location code for
identifying each indicator.prop-encoded-array: an array of
maxindex + 1 strings, encoded as with
encode-string.“ibm,sensor-<token>”property name to provide a FRU location code for
identifying each physical sensor.prop-encoded-array: an array of
maxindex + 1 strings, encoded as with
encode-string.“ibm,display-line-length”property name to provide the length of a display line
in number of characters.prop-encoded-array: an integer, encoded as with
encode-int.“ibm,display-number-of-lines”property name to provide the number of lines in the
display.prop-encoded-array: an integer, encoded as with
encode-int.“ibm,display-truncation-length”property name, when provided, specifies the length to
which each line to be display is truncated, based on which line of the
physical display on which the line is displayed. When the truncation
length is greater than the length specified in the
“ibm,display-line-length” property, then
the platform provides a platform-dependent method of displaying the line
to the user.prop-encoded-array: An array of integers, each
encoded as with encode-int. The number of integers corresponds to the
number of lines, as defined by the
“ibm,display-number-lines” property. The
first integer refers to the truncation length for the first physical line
of the display, the second to the second physical line, and so on.“ibm,form-feed”property name to provide an indication of the
form-feed capability.prop-encoded-array: a character, NULL (0x00) if
form-feed is not supported and np (0x0C) if form-feed is supported,
encoded as with
encode-int.“ibm,environmental-sensors”property name describes the environmental sensors
which are available to an application.prop-encoded-array: An array of paired integers
(token maxindex), each encoded as with
encode-int.“ibm,flash-block-version”property name in the
/rtas node indicates the block list format to be
used.prop-encoded-array: integer encoded as with
encode-int. Value is 0x01 for the discontiguous
block list. (If a new version of the block list is ever required, other
values could be defined.)“ibm,errinjct-tokens” [S]property name defines the error inject functions implemented on
this platform.prop-encoded-array: List of (errinjct-token-name,
errinjct-token-value) specifications.errinjct-token-name: A string, encoded as with
encode-string.errinjct-token-value: is encoded as with
encode-int.“ibm,lrdr-capacity”property name in the
/rtas node identifies the dynamic reconfiguration
capabilities of the partitionprop-encoded-array: A triple consisting of phys,
size, and one integer encoded as with
encode-intThe phys (of size #address-cells) communicates the maximum address
in bytes and therefore, the most memory that can be allocated to this
partition.The size (of size #size-cells) communicates the increment (quantum
of logical memory dynamic reconfiguration).The first integer communicates the maximum number of processors
(implied quantum of 1).Note: Some implementations depend upon the presence
and value of a second integer. Future extensions to this property should
not define a second integer for new purposes.“ibm,hypertas-functions”property name of the
/rtas node, defines the platform’s implemented
hypervisor RTAS function sets.prop-encoded-array: List of Hypervisor-RTAS-function-set
specifications.Each Hypervisor-RTAS-function-set specification is a byte string
encoded as with
encode-string.“ibm,dma-delay-time”property name to define the time delay need to ensure outstanding
DMA operations targeting migrated pages have completed.prop-encoded-array: A one cell integer encoded as with
encode-int that represents the number of
micro-seconds that the OS should wait prior to reusing migrated DMA read
target pages.“ibm,associativity-reference-points” [S]property name to define the associativity reference points for the
“ibm,associativity”
properties of this platform.prop-encoded-array: A list of one or more integers cell(s) encoded
as with
encode-int.“ibm,max-associativity-domains”property name to define the maximum number associativity domains
for this platform.prop-encoded-array: An associativity list such that all values are
the maximum that the platform supports in that location. The
associativity list consisting of a number of entries integer (N) encoded
as with
encode-int followed by N integers encoded as with
encode-int each representing maximum number
associativity domains the platform supports at that level.“ibm,request-partition-shutdown”property name to specify that the partition was
rebooted in the forced fire hose dump mode.prop-encoded-array: An integer encoded as with
encode-int that represents the platform’s
partition shutdown configuration variable. The defined states are:0 = The platform boots with no request to save appropriate data nor
shutdown the partition.1 = The platform boots with a conditional request to save
appropriate data and shutdown the partition. The client program should
check for an EPOW sensor state of 3 and if present, it should save
appropriate data and shutdown the partition. If the EPOW sensor state of
3 is not present, then the partition should initiate a reboot since the
device tree will be incomplete.2 = The platform boots with a mandatory request to the client
program to save appropriate data and shutdown the partition.“ibm,integrated-stop-self”property name indicating that prior to placing a
processor in the stopped state, the platform flushes and disables any
caches/memory exclusively used by the issuing processor.prop-encoded-array: NULL“ibm,rks-hcalls”property name: indicating the hcalls that are
implemented with a reduced kill set. Absence of this property indicates
that only hcalls that are specified as always having a reduced kill set
provide that semantic.prop-encoded-array: A one to N byte bit vector, bit
positions representing hcall()s (see
) that present a reduced kill
set per their architectural specification.
“ibm,rks-hcalls” bit vector to hcall mapByte NumberBit Numberhcall000b11 for H_CONFER & H_PROD12Set to 1 if H_PURR is implemented with a reduced volatile
kill set of r3 & r4; else set to 0.3Reserved for future expansion (0b0)45671-NReserved for future expansion
“ibm,reset-capabilities”property name indicates what capabilities the
platform supports relative to the ibm,set-slot-reset RTAS call, when that
RTAS call is implemented.prop-encoded-array: An integer encoded as with
encode-int that represents the functions supported in the
ibm,set-slot-reset RTAS call0 = Platform supports Functions 0 and 1 supported.1 = Platform supports Functions 0, 1, and 3.Note: The absence of this property implies the platform supports
Functions 0 and 1 for the
ibm,set-slot-reset RTAS call, when that RTAS call is
implemented.“ibm,configure-kernel-dump-sizes”property name specifies that the Platform Assisted
Kernel Dump option is supported for sections described by this
property.prop-encoded-array: For each dump section type
supported, a 32 bit cell which defines the ID of a supported section
followed by two 32-bit cells which gives the size of the section in bytes
(not including any disk headers.)“ibm,configure-kernel-dump-version”property name specifies that the Platform Assisted
Kernel Dump option is supported for versions described by this
property.prop-encoded-array: Contains a 16-bit cell describing
the minimum kernel dump version supported by the firmware followed by a
16-bit cell describing the maximum kernel dump version supported by the
firmware.“ibm,kernel-dump”property name specifies the presence of a registered
kernel dump in the Platform Assisted Kernel Dump option.prop-encoded-array: Contains the description of the
registered kernel dump in the format described in
.“ibm,read-slot-reset-state-functions”property name specifies the implementation of certain
input or output fields in the
ibm,read-slot-reset-state2 RTAS call. If this
property does not exist, then the
ibm,read-slot-reset-state2 RTAS call implements only
the first 3 inputs and the first 4 outputs (
Number Inputs is required to be 3 and the
Number Outputs is required to be 4), as defined in
.prop-encoded-array: Contains a 32 bit cell, with the
bits defined as follows:Bits 0-29: Reserved (value of 0).Bit 30: When a value of 1, the
ibm,read-slot-reset-state2 RTAS call checks the
Number Outputs and the implements the 5th output (
Number Outputs of 5), as defined by
.Bit 31: When a value of 1, the
ibm,read-slot-reset-state2 RTAS call implements the
first 3 inputs and the first 4 outputs (
Number Inputs of 3 and the
Number Outputs of 4), as defined in
. This bit is always required
to be a value of 1 when this property is implemented.“ibm,change-msix-capable”property name indicating the platform supports the
ibm,change-msi RTAS call with
Number of Outputs equal to 4 and
Functions 3, 4, and 5.prop-encoded-array: <none>/RTAS node DR Sensors and IndicatorsThe following sensors and indicators are defined for the /RTAS node
for the DR option.“9003”sensor token, the existence of this token number
denotes that the platform supports the 9003 “DR entity sense”
sensor.“9001”indicator token, the existence of this token number
denotes that the platform supports the 9001 “isolation state”
indicator.“9002”indicator token, the existence of this token number
denotes that the platform supports the 9002 “dr-indicator”
indicator used to guide operators in the physical add or removal of
hardware.“9003”indicator token, the existence of this token number
denotes that the platform supports the 9003
“allocation-state” indicator.“ibm,extended-os-term”property-name indicating that the platform supports
extended
ibm,os-term behavior as described in
.prop-encoded-array: encode-nullRTAS Function Property NamesThis section defines the property names associated with the various
RTAS functions defined by
.
should be used as the reference
for RTAS Functions currently implemented. Each RTAS function that a
platform implements shall
be represented by its own function property,
who’s value is the
token used to invoke the function on an RTAS
call.The formal property definition for each such property is of the
form:property name specifies the name of the RTAS function
-- such as:“nvram-fetch” [S]prop-encoded-array: The value,
token, is an integer encoded as with
encode-int.If an RTAS function is implemented, there is a property name which
corresponds to its function name. The value of this property is a
token. This
token, when passed to RTAS via its
rtas-call interface (see below), invokes the named
RTAS function. If a RTAS function is not implemented, there will not be a
property corresponding to that function name. See the
for more information about RTAS
functions.“ibm,termno”property name of the
/rtas node defines the virtual terminal numbers
available for use by this partition.prop-encoded-array: A pair of integers encoded as with
encode-int, the first being the value
of the lowest termno in a contiguous range of supported values, the second being the
number of termno values supported.Note: The number of supported termno values is
implementation dependent -- the minimum number is one.“ibm,hypertas_functions”property name of the /RTAS node, defines the
platform’s implemented hypervisor RTAS function sets.prop-encoded-array: List of
Hypervisor-RTAS-function-set specifications.Each
Hypervisor-RTAS-function-set specification is a byte
string encoded as with
encode-string.RTAS Node MethodsThe
instantiate-rtas or
instantiate-rtas-64 method is invoked by the OS to
instantiate the RTAS functionality. This is accomplished via the
call-method
Client Interface Service. If the platform supports
the
ibm,client-architecture-support root node method, and
that method has not been called prior to the call of the
instantiate-rtas or
instantiate-rtas-64 methods, then the platform shall
operate at the least functional level supported by the platform.Note: Platforms should provide a manual override
capability to allow most functional level allowed by the partition
configuration in the event that a client program does not call the
ibm,client-architecture-support root node method
prior to the instantiation of RTAS.instantiate-rtas (rtas-base-address -- rtas-call) [M]Invoking the
instantiate-rtas method binds the RTAS environment to
a given location in System Memory and initializes the RTAS environment.
The in parameter,
rtas-base-address, is the physical address to which
the RTAS environment is to be bound. This call indicates that RTAS is
instantiated in a 32-bit mode. The amount of contiguous real memory that
should be allocated for the RTAS environment is given by the value of the
“rtas-size” property.Upon completion of the
instantiate-rtas method, an entry point address,
rtas-call, is returned. The value of
rtas-call specifies the physical address of the entry
point into RTAS for future RTAS function calls.instantiate-rtas-64 (rtas-base-address -- rtas-call) [M]Invoking the optional
instantiate-rtas-64 method binds the RTAS environment
to a given location in System Memory and initializes the RTAS
environment. The in parameter,
rtas-base-address, is the physical address to which
the RTAS environment is to be bound. This call indicates that RTAS is
instantiated in a 64-bit mode. The amount of contiguous real memory that
should be allocated for the RTAS environment is given by the value of the
“rtas-size” property.Upon completion of the
instantiate-rtas-64 method, an entry point address,
rtas-call, is returned. The value of
rtas-call specifies the physical address of the entry
point into RTAS for future RTAS function calls.Properties of the Node of type cpuWhen the platform implements the LPAR option the following
properties are required of the /cpus nodeibm,pft-sizeproperty name of the children of type
“cpu” of the
/cpus node, defines the size of the processor’s
page frame table.prop-encoded-array: A pair of integers encoded as
with
encode-int, the first being the NUMA CEC Cookie (up
to a maximum of (2
16)-1) the second being the base 2 log of the size
of the page frame table in bytes.Notes:On single CEC platforms, the NUMA CEC Cookie value is
zero.Due to constraints caused by initial memory allocations, and
other running partitions, the firmware may not be able to allocate a
node’s PFT for the full size requested in the PFT_size
configuration variable. The
“ibm,pft-size” property of course
reflects the actual size allocated.The partitions running on multiple NUMA nodes would have
multiple PFTs which did not look alike due to the difference in mapping
local and remote page frames.)To support dynamic addition and removal of processors, the /cpus
node contains either the
ibm,drc-info property or the following set of four properties:
ibm,drc-types (cpu),
ibm,drc-indexes ibm,drc-names and
ibm,drc-power-domains (-1's). These properties have
entries for the maximum number of dynamically reconfigurable processors
that the platform supports for the specific OS image.“ibm,ppc-interrupt-server#s” [S]property name: Defines the single processor server
numbers associated with this processor. Placing the numerical equivalent
of one of these quantities into the server# field of an XIVR directs
associated interrupts to this processor. The first server number is
associated with the “primary processor thread” any subsequent
numbers are associated with the secondary. etc. hardware threads that the
processor may implement.prop-encoded-array: A list of one or more integers
in the range of 0 to
2“ibm,interrupt-server#-size”
encoded as with
encode-int.Note: In order to achieve optimal performance,
processor server numbers should be activated in the order that they are
presented in the
“ibm,ppc-interrupt-server#s” property and
deactivated in the reverse order.“ibm,ppc-interrupt-gserver#s” [S]property name: Defines the multiple processor global
server numbers to which this processor belongs. Placing the numerical
equivalent of one of these quantities into the server# field of an XIVR
directs associated interrupts to one of the processors in that
group.prop-encoded-array: A list of (
server#, gserver#s) specification pairs. the first
integer specifies a single processor
server# as presented in the node’s
“ibm,ppc-interrupt-server#s” property,
followed by an integer with a value less than or equal to 2
“ibm,interrupt-server#-size”
encoded as with
encode-int that specifies the global server queue
that also may present interrupts to the interrupt management area
associated with the
server#.“ibm,sub-processors”property name: the sub-processor configuration that
is running on this processor. In the absence of this property, this
processor may not be divided into sub-processors.prop-encoded-array: a series of three or more
integers each encoded as with encode-int. The value of the first integer
indicates how many integers follow (the value 2 indicates that two
integers follow). The second integer indicates the number of
sub-processors that are running on this processor. If the processor is
not divided into sub-processors the value of the second integer shall be
1, two sub-processors shall be represented by the value 2, four
sub-processors shall be represented by the value 4 and so on. The third
integer indicates the maximum number of sub-processors that could be
configured to run on this processor.Client programs shall ignore subsequent integers beyond those
defined at the time they were written.Extensions for LoPAR I/O Sub-SystemsLoPAR I/O sub-system events may be signaled in a variety of ways
depending upon platform capabilities. In order of increasing
functionality:Events are universally fatal, and are signaled via
checkstop.After being enabled, the effected section enters freeze state
signalling this state with a return of all 1’s to any MMIO load
instruction (If not enabled functionality of the specific section reverts
to #1. Presence of
ibm,set-eeh-option RTAS call denotes platforms that
support this level of functionality.)An extension to #2 above wherein, after being enabled for a
specific section of the I/O sub-system, additional event conditions may
be reported and events are signaled using an external interrupt. The
platform’s capability to support this level of functionality is
reported by the inclusion of the
“ibm,i/o-events-capable” property (see
definition below) in nodes where enabling control may be
exercised.“ibm,i/o-events-capable”property name indicating that I/O sub-system events
detected by the hardware represented by this node in the device tree may
be singled with an I/O event interrupt if enabled.prop-encoded-array: 0 to N interrupt specifiers (per
the definition of interrupt specifiers for the node’s interrupt
parent).When no interrupt specifiers are present, then the interrupt, if
enabled, is signaled via the interrupt specifier given in the
I/O-events child node of the
/events node.To perform certain management functions, it is necessary to quiesce
segments of the platform’s I/O infrastructure, such quiescence
domains are not representable by a strict tree structure. The
“ibm,io-quiesce-domains” property relates
the membership of the various elements of a platform’s I/O
sub-system to such quiescence domains.“ibm,io-quiesce-domains”property name indicating the I/O quiesce domains of
which this device, and all devices under this device (if any), is a
member.prop-encoded-array: List of one or more
domain-id’s to which this device belongs, and to which all devices
under this device (if any) belongs. Domain-id's are encoded as with
encode-int.Virtual I/O that does not take up physical address locations is
represented in a device sub tree for which the
“#size-cells” and
“#address-cells” properties are zero and
one, respectively. However, the ibm dma-window properties, such as
“ibm,dma-window” and
“ibm,my-dma-window”, need to contain
real size and address fields. The number of cells for these real size and
address fields need to be non-zero.“ibm,#dma-size-cells”property name to define the package’s dma
address
size format.prop-encoded-array: number encoded as with
encode-int.The property value specifies the number of cells that are used to
encode the size field of ibm dma-window properties. If the
“ibm,#dma-size-cells” property is
missing, the default value is the
“#size-cells” property for the package.
If both the
“ibm,#dma-size-cells” and
“#size-cells” properties are missing,
refer to the
“#size-cells” property definition in the
for the default value.“ibm,#dma-address-cells”property name to define the package’s dma
address format.prop-encoded-array: number encoded as with
encode-int.The property value specifies the number of cells that are used to
encode the physical address field of ibm dma-window properties. If the
“ibm,#dma-address-cells” property is
missing, the default value is the
“#address-cells” property for the
package. If both the
“ibm,#dma-address-cells” and
“#address-cells” properties are missing,
refer to the
“#address-cells” property definition in
the
for the default value.PCI Host Bridge NodesThis section describes the PCI Host Bridge (PHB) properties which
are added or modified for an LoPAR implementation. Refer to
for the base PCI properties and
methods. For each platform PCI Host Bridge, a
“reg” property shall be present in the
respective PCI Node.Note: Since the standard RTAS PCI configuration
access services do not have separate arguments identifying the PCI host
bridge to which a service applies, platforms with multiple PCI host
bridges must assign them unique bus numbers. An OS must not reassign bus
numbers if it expects to make subsequent use of the any RTAS PCI
configuration access services.To support dynamic addition and removal of PHBs, the / node
contains either the
ibm,drc-info property or the following set of four properties:
ibm,drc-types (phb),
ibm,drc-indexes ibm,drc-names and
ibm,drc-power-domains (-1's). These properties have
entries for the maximum number of dynamically reconfigurable PHBs that
the platform supports for the specific OS image.PCI Host Bridge PropertiesFor each PHB in the platform (called a PCI Bus Controller in the
PCI Bus binding), a PCI Host Bridge Node shall
be defined as a child node of the system bus, in
accordance with
. Each PCI PHB Node shall have
a Unit Address defined in the
“reg” property that is unique and
persistent from each boot-to-boot. One way for the platform to meet this
requirement is to supply a virtual Unit Address based upon a unique
identifier stored in the hardware. In this case, the size field of the
first
“reg” property phys-address, size pair
shall be zero. The following properties are modified or added by this
architecture and shall apply to each of these nodes.Each PHB shall also have the
“used-by-rtas” property, since RTAS is
used for PCI Configuration.“ranges” [S]Standard
property name defines this PHB’s physical
address ranges.prop-encoded-array: Two or more (
child-phys, parent-phys, size)
specifications.This property is mandatory for PCI Host Bridges in LoPAR
implementations. The property value consists of four (
child-phys, parent-phys, size) specifications, as
described in
.The first specification shall specify the configured address and
size of this PHB’s I/O Space. (I/O Space is shown as
“BIOn” to “TIOn” in
"Address Map" section.) The
second specification shall specify the configured address and size of
this PHB’s Memory Space. (Memory Space is shown as
“BPMn” to “TPMn” in the Common Hardware Reference
Platform Architecture.)“model” [S]Standard
property name indicating this PHB’s
manufacturer, part number, and revision level. This property shall be
present if this PHB does not supply the following standard PCI
configuration properties which represent the values of standard PCI
configuration registers:
“vendor-id”,
“device-id”, and
“revision-id”.prop-encoded-array: Text string, encoded as with
encode-string.The value of this property is a vendor dependent string which
uniquely identifies this PHB and is correlated to its manufacturer, part
number, and revision level. (see
for more information.) The
string value is device dependent, but shall supply information sufficient
to identify the part to a level equivalent to the level achievable via
the standard PCI configuration registers:
“vendor-id”,
“device-id”, and
“revision-id”.“64-bit-addressing” [S]property name indicates this PHB’s capability
to address more than 4 GB of memory.prop-encoded-array: <none>This property shall be present indicating that the PHB supports
addressing more than 4 GB of memory (required for all
PHB nodes).“external-control” [S]property name indicates this PHB’s ability to
support the PA external control facility.prop-encoded-int: List of integers, each encoded as
with encode-int.The property value, if present, is a list of Resource ID’s
the version of the PA external control facility supports. This property
shall be present if this PHB supports the PA external control facility,
otherwise the property shall be absent.“ibm,tce-alloc-info”property name indicates the addresses of platform pre
allocated TCE table space.prop-encoded-array: One to N
phys-addr, size pair(s). The first pair represents
the memory area allocated by the platform for the TCE tables associated
with this PHB. Any subsequent pairs represent memory areas that the OS
should avoid using to minimize performance impacts.Phys-addr is encoded as with
encode-phys the number of cells for
phys corresponds to
“#address-cells” value applicable to this
node.size the number of cells for
size corresponds to the
“#cell-size” value applicable to this
node.“ibm,max-completion-latency”property name indicates the maximum DMA Read
completion latency for IOAs under this PHB.prop-encoded-array: Integer, encoded as with
encode-int.This property, when present (for example, see Requirement
), indicates the maximum DMA
Read completion latency for IOAs under this PHB, in microseconds. For
plug-in adapters, the latency value does not include latency of any
additional PCI fabric (for example, PCI Express switches) on the plug-in
adapter.“ibm,extended-address” [S]property name indicates this platform supports
Peripheral Memory Spaces, Peripheral I/O Spaces, and SCA spaces above 4
GB.prop-encoded-array: <none>This property must be present in all PHB nodes.“ibm,pcie-link-width-stats”property name indicates the collection of PCI Express
link-width capabilities and measurements at the PE below the PHB.prop-encoded-array: 2 integers encoded with
encode-intThe first integer represents the maximum PCI Express lane-width at
the Partitionable Endpoint.The second integer represents the actual PCI Express lane-width at
the Partitionable Endpoint.Implementation Note: In some cases, a PCIe device may
train at a different width depending on the speed capabilities of the
link.“ibm,pcie-link-speed-stats”property name indicates the collection of PCI Express
link-speed capabilities and measurements at the PE below the PHB.prop-encoded-array: 2 integers encoded with
encode-int. The value of each integer is
based on which bit is set to reflect link speed according to the Supported Link Speed Vector
segment of the Link Capabilities 2 Register as defined in the PCI Express Capability Structure
chapter of the . In the 3.0 version of that
specification, the supported values are 0x1 (bit 0) = 2.5 GT/s, 0x2 (bit 1) = 5.0 GT/s, and 0x4 (bit 2) = 8.0 GT/s.“ibm,max-rtce-mappings”property name: for platforms that support the hcall-migrate function
set and more than a single Redirected RDMA mapping per virtual TCE, this property indicates
that there are limits to the number if such multiple Redirected RDMA mappings when used
by children of this PHB as indicated by the property value.prop-encoded-array: Maximum number of Redirected RTCE mappings encoded as with
encode-int.Properties for Children of PCI Host BridgesThe following properties are defined for PCI host bridges and their
children.“133mhz-capable” [S]property name: The presence of this property
indicates the device’s capability of operating at 133 megahertz.
Only present if PCI-X Status Register bit 17 is set.prop-encoded-array: None.“266mhz-capable” [S]property name: The presence of this property
indicates the device’s capability of operating at 266 megahertz.
Only present if PCI-X Status Register bit 30 is set.prop-encoded-array: None.“533mhz-capable” [S]property name: The presence of this property
indicates the device’s capability of operating at 533 megahertz.
Only present if PCI-X Status Register bit 31 is set.prop-encoded-array: None.“ibm,msi-ranges”property name: Defines the Message Signaled
Interrupt interrupt source number (as returned by H_XIRR) range(s)
assigned to this unit using the MSI capability structure. (Note this
property is only supplied if the package is assigned one or more message
signaled interrupt numbers at boot time using the MSI capability
structure, those packages assigned level sensitive interrupts include the
standard interrupts property.) The platform firmware assigns the
interrupt source numbers in order to the first N Message Signaled
Interrupt configuration spaces of the adapter, setting the associated
configuration spaces, in accordance with the platform's hardware
configuration, to produce the interrupt source numbers specified.prop-encoded-array: List of one or more (int-number,
range) specifications.Int-number is the first interrupt source number in a
contiguous range of interrupt source numbers encoded as with
encode-int.Range is the one based count of consecutive interrupt
source numbers that compose the specified range of interrupt source
numbers, encoded as with
encode-int.“ibm,msi-x-ranges”property name defines the Message Signaled Interrupt
interrupt source number (as returned by H_XIRR) range(s) assigned to this
IOA function using the MSI-X capability structure. (Note this property is
only supplied if the package is assigned one or more message signaled
interrupt numbers at boot time using MSI-X capability structure, those
packages assigned level sensitive interrupts include the standard
interrupts property.) The platform firmware assigns the interrupt source
numbers in order to the first N MSI-X vectors of the IOA function,
setting the associated configuration spaces and MSI-X vectors, in
accordance with the platform's hardware configuration, to produce the
interrupt source numbers specified.prop-encoded-array: List of one or more (int-number,
range) specifications.Int-number is the first interrupt source number in a
contiguous range of interrupt source numbers encoded as with
encode-int.Range is the one based count of consecutive interrupt
source numbers that compose the specified range of interrupt source
numbers, encoded as with encode-int.“ibm,req#msi”property name: Defines the number of Message
Signaled Interrupts requested by the adapter as communicated in its MSI
capability structure. This number may be greater than the number of
Message Signaled Interrupts actually assigned by the firmware.prop-encoded-array: number of requested interrupts
encoded as with
encode-int.“ibm,req#msi-x”property name: Defines the number of MSI-X Interrupts
requested by the adapter as communicated in the Table Size field of the
MSI-X Capability Structure for the adapter. This number may be greater
than the number of MSI-X interrupts actually assigned by the
firmware.prop-encoded-array: number of requested MSI-X
interrupts encoded as with
encode-int.“ibm,connector-type”property name to identify the connectors associated with a built-in
IOA that supports wrap test. This property must be provided if there is
more than one connector for the same IOA on the platform.prop-encoded-array: the concatenation, with
encode+, of an arbitrary number of text strings,
each encoded as with
encode-string.“ibm,wrap-plug-pn”property name to provide the part number(s) of the wrap plug(s)
required for testing built-in IOAs with the default connector or the
connectors specified in
“ibm,connector-type”. If this property
is provided in the same node with an
“ibm,connector-type” property, there is a
one-to-one correspondence between the strings in each property. If this
property is provided without an
“ibm,connector-type” property, there is
assumed to be only one connector for the device (default connector) and
this property should contain only one string. If multiple wrap plugs may
be used with the same connector, their part numbers shall be represented
in the same string, separated by commas.prop-encoded-array: the concatenation, with
encode+, of an arbitrary number of text strings,
each encoded as with
encode-string.“ibm,pci-config-space-type”property name: Indicates if the platform supports
access to an extended configuration address space from the PHB up to and
including this node.0 = Platform supports only an eight bit register number for
configuration address space accesses.1 = Platform supports a twelve bit register number for
configuration address space accesses.This property may be provided in all
PHB nodes and their children.Note: The absence of this property implies the platform supports
only an eight bit register number for configuration address space
accesses.“ibm,reserved-explanation”property name indicates why this PHB's
“status” property contains the value of
“reserved” or
“reserved-uninitialized”.prop-encoded-array: Text string, encoded as with
encode-string.The property value, when present, can have the values specified in
.
Values
“ibm,reserved-explanation”ValueExplanationstorage-system-ioReserved for storage system product usepcix-over-pciePCIe device is abstracted as a PCIx device in the device
tree for legacy compatibility
“ibm,pe-total-#msi”property name defines the maximum number of Message
Signaled Interrupts (MSI plus MSI-X) that are available to the PE below
this device tree node. This number only indicates the number of available
interrupts, not the number assigned. The number assigned for an IOA may
be obtained by Function 0 (Query only) of the
ibm,change-msi RTAS call.prop-encoded-array: Maximum number of interrupts
encoded as with
encode-int.“ibm,ehci-boot-supported”property name: indicates if this IOA function for
USB 2.0 (EHCI) supports devices beneath it to be used for boot.prop-encoded-array: None.“ibm,pe-reset-is-flr”property name: The presence of this property in the
PCI Express function’s OF Device Tree node indicates that the
platform will use the Function Level Reset (FLR) of the function to reset
the function when the
ibm,set-slot-reset RTAS call is used to reset the PE,
and not the PCI Express Hot Reset.prop-encoded-array: None.“ibm,ddw-applicable”property name: The Dynamic DMA Windows option RTAS
calls may be used against the PE below this node.prop-encoded-array: A list of three integers encoded
as with
encode-int.This property may be provided in all PHB nodes or bridge nodes that
are the PHB’s children. Separate properties must exist for each PE
that can participate in the DDW option (exists in the node above the PE).
The existence of this property in any node, indicates that the platform
supports the Dynamic DMA Windows option for the platform and for the PE
below that node. Lack of this property in the bridge node above a PE
indicates that the DDW option RTAS calls are not applicable to that PE.
The values in the property are defined as follows:The first integer represents the token to be used for the
ibm,query-pe-dma-window RTAS call.The second integer represents the token to be used for the
ibm,create-pe-dma-window RTAS call.The third integer represents the token to be used for the
ibm,remove-pe-dma-window RTAS call.“ibm,ddw-extensions”property name: Extensions to the Dynamic DMA Windows
option RTAS calls may be used against the PE below this node.prop-encoded-array: A list of integers encoded as
with
encode-int.This property may be provided in all PHB nodes or bridge nodes that
are the PHB’s children. Separate properties shall exist for each PE
that can participate in the extensions to the DDW option (exists in the
node above the PE). The existence of this property in any node, indicates
that the platform supports the extensions to the Dynamic DMA Windows
option for the platform and for the PE below that node. Lack of this
property in the bridge node above a PE indicates that the extensions of
the DDW option RTAS calls are not applicable to that PE. This property is
designed to be extended in the future by adding integers to the end of
the list, reading software should be prepared to handle earlier versions
of the property that will have a short list as well as ignore longer
lists from later versions than it was designed to handle. The values in
the property are defined as follows:The first integer represents the number of extensions implemented.
Subsequent integers represent values associated with each extension such
as a token for an additional RTAS call or an architectural level of an
extended interface. The value of one indicates that only a single
extension is implemented as specified by the second integer in the list.
provides the definition of the
subsequent integers as defined for the LoPAR level of the DDW
option.ibm,h-get-dma-xlates-supportedproperty name: to identify those PHBs for which
H_GET_DMA_XLATES is supported on all child LIOBNs.prop-encoded-array: <none>ibm,h-get-dma-xlates-limited-supportedproperty name: to identify those PHBs for which
H_GET_DMA_XLATES_LIMITED is supported on all child LIOBNs.prop-encoded-array: <none>LPAR Option Properties“ibm,dma-window”property name to define the bus address window
children of this bridge may use for dma.prop-encoded-array: One (
logical-bus-number, phys,
size) triple where the logical bus number (LIOBN) is
a one cell cookie representing the unique range of TCE entries assigned
to this bridge encoded as with
encode-int, the number of cells for
phys corresponds to the node’s
“ibm,#dma-address-cells” value while the
number of cells for
size corresponds to the
“ibm,#dma-size-cells” for this
node.Implementation Note: Platforms that support PHB level
granularity of IO assignment to partitions place the
“ibm,dma-window” property in the PHB
node, while platforms that support slot level granularity place the
“ibm,dma-window” property in the bridge
node that creates the per slot bus isolation.Note: The first element of the ibm,dma-window triple
(the LIOBN) is used as a parameter to firmware DMA setup routines to
identify the specific I/O address space (TCE table) to be
referenced.“ibm,is-vf”property name to define that the node represents an
I/O Virtualized instance of an I/O adapter.prop-encoded-array: A one cell value that represents the LoPAR
architectural level of the virtualization:
Memory NodeThis section defines the LoPAR modifications to the OF /
memory node. In LoPAR, the memory allocated to an OS
image may be divided into a number of allocation units called
“regions” or “Logical Memory Blocks (LMB). An OS image
may be dynamically allocated additional regions or may be asked to
release regions. Each LMB is either represented in the device tree by its
own /
memory node or by an entry in
/ibm,dynamic-reconfiguration-memory nodes (see
). The /
memory node that refers to the storage starting at
real address zero (
“reg” property starting at the value
zero) always remains allocated to an OS image. The client program is
initially loaded into this storage, called the RMA, that is represented
by the first value of the
“reg” property of this first /
memory node. Additional storage regions may each be
represented by their own /
memory node that includes dynamic reconfiguration
(DR) properties or by an entry in /ibm,dynamic-reconfiguration-memory nodes.To support dynamic addition and removal of regions, the / node
contains either the
ibm,drc-info property or the following set of four properties:
ibm,drc-types (MEM),
ibm,drc-indexes ibm,drc-names and
ibm,drc-power-domains (-1's). These properties have
entries for the maximum number of dynamically reconfigurable regions that
the platform supports for the specific OS image.Properties of the memory NodeIn addition to the standard properties defined for the
/memory node, the following are required for each
node representing a dynamically allocable memory region. Platforms that
support the dynamic reconfiguration of memory regions represent each such
logical memory block with its own
/memory node. Any new memory granted to an OS image
is done so with a new
/memory node, and OS images may free memory only in
full blocks represented by one of its currently held
/memory nodes.The value of
“#address-cells”
for this node is 1.The value of
“#size-cells”
for this node is 0 because the children of this node do not consume any physical
address space.The
“ibm,my-drc-index” property as defined in
.“ibm,preservable”property name that denotes the platform’s
ability to preserve the contents of the storage represented by this
node.prop-encoded-array: A integer encoded as with
encode-int that represents
the ability of the platform to preserve the contents of the storage.All non-negative values represents the expected length of time, in
minutes, that the platform can sustain the state of the storage. A value
of 0 indicates the storage is not preservable and the client program may
not register this storage for preservation, this is the assumed state if the
“preservable”
property is not present. The largest positive number represents an indefinite
retention time as provided by such technologies as flash storage.Negative values indicate that the storage is preservable as long as
external power is maintained, perhaps by an external battery not directly
integrated into the platform.“ibm,preserved”property name that denotes the preservation state of
the contents of the storage represented by this node.prop-encoded-array: An integer encoded as with
encode-int that represents the preservation state of
the storage. The defined states are:0= The storage was not registered for preservation and thus not
preserved. This is the assumed state if the
“preserved” property is not present. This
is also the state if the platform has lost knowledge of the preservation
registration state of the storage.1= The storage was registered for preservation and is has been
preserved since the client program last modified it.2= The storage was registered for preservation, however, the
contents have not been preserved.“ibm,expected#pages”property name that denotes the number of pages that
the client program is expected to use to virtually map the LMB
represented by this node.prop-encoded-array: An integer encoded as with
encode-int that represents the log base 2 of the
expected number of virtual pages that the client program will use to map
the LMB represented by this node.“ibm,no-h-migrate-dma”property name that designates that the memory in the
memory node in which this property resides cannot
have the H_MIGRATE_DMA hcall() used against it.prop-encoded-value: <none> this is a name only
property.ibm,dynamic-reconfiguration-memoryThis device tree node defines an alternative means to represent a
number of dynamically-reconfigurable logical memory blocks (LMBs). This
node must only be generated by OF when instructed to do so by the client
program in the ELF header. All memory which is not subject to dynamic
reconfiguration (such as the RMA) is represented in
/memory node(s).This node is a child of root. This node does not have a unit
address or
“reg” property.The following properties are defined.“ibm,lmb-size”property name that defines the size of each
dynamically reconfigurable LMB.prop-encoded-array: An integer encoded as with
encode-phys that represents the size in bytes of each
LMB.“ibm,associativity-lookup-arrays”property name that defines a lookup array in which to
find the
ibm,associativity-array property value for the
LMBs.prop-encoded-array: The number M of associativity
lists encoded as with
encode-int, the number N of entries per
associativity list encoded as with
encode-int, followed by M associativity lists each
of length N integers encoded as with
encode-int.This property is used to duplicate the function of the
“ibm,associativity” property in a
/memory node. Each “assigned” LMB
represented has an index valued between 0 and M-1 which is used as in
index into this table to select which associativity list to use for the
LMB. “unassigned” LMBs are place holders for potential DLPAR
additions, for which the associativity list index is meaningless and is
given the reserved value of -1. This static property, need only contain
values relevant for the LMBs presented in the
“ibm,dynamicreconfiguration-memory” node;
for a dynamic LPAR addition of a new LMB, the device tree fragment
reported by the
ibm,configure-connector RTAS function is a /memory
node, with the inclusion of the
“ibm,associativity” device tree property
defined in
.“ibm,dynamic-memory”property name that defines memory subject to dynamic
reconfiguration.prop-encoded-array: The number N of LMB list entries
defined at boot time, encoded as with
encode-int, followed by N LMB list entries.An LMB list entry consists of the following elements. There is one
LMB list entry per LMB represented.Logical address of the start of the LMB, encodes as with
encode-phys. This corresponds to the first words in
the
“reg” property in a
/memory device tree node.DRC index of the LMB, encoded as with
encode-int. This corresponds to the
“ibm,my-drc-index” property in a
/memory device tree node.Four (4) bytes reserved for future expansion of flag.Associativity list index for the LMB, encoded as with
encode-int. This is used as an index into
“ibm,associativity-lookup-arrays”
property defined above to retrieve the associativity list for the LMB. The associativity
list corresponds to the
“ibm,associativity” property in a
/memory device tree node.A flags word, encoded as with
encode-int. This word represents 32 boolean flags.
As of this definition, flag bits are defined to correspond to the
“ibm,preservable” and
“ibm,preserved” properties in a
/memory device tree node. This definition allows for
additional flags to be added in the future.The following bits in the “flags word” above are
defined.
Flag WordNameBit PositionDescriptionpreserved0x00000001If b'0', corresponds to the
“ibm,preserved” property having
a zero value.If b'1', corresponds to the
“ibm,preserved” property having
a non-zero value, and the preserved_state bit below indicates
the state of preservation.preservable0x00000002If b'0', corresponds to the
“ibm,preservable” property
having a zero value.If b'1', corresponds to the
“ibm,preservable” property
having a non-zero value.preserved_state0x00000004If b'0', corresponds to the
“ibm,preserved” property having
a 0x1 value.If b'1', corresponds to the
“ibm,preserved” property having
a 0x2 value (and, in the old binding, the LMB having a status
of “fail”).assigned0x00000008If b'1', this LMB is assigned to the partition as of boot
time. If b'0', this LMB is not assigned to the partition as of
boot time.No H_MIGRATE_DMA0x00000010If b'0', corresponds to non-existence of the
“ibm,no-h-migrate-dma” in the
memory node.If b'1', corresponds to existence of the
“ibm,no-h-migrate-dma” in the
memory node.DRC invalid0x00000020If b'0', the DRC field of
“ibm,dynamic-memory” property
is valid or the DRC values for the set of
“ibm,dynamic-memory-v2”
property are valid.If b'1', the DRC field of
“ibm,dynamic-memory” property
is invalid or the DRC values for the set of
“ibm,dynamic-memory-v2”
property are invalid.Associativity Index0x00000040If b'0', the Associativity List Index field of
“ibm,dynamic-memory” property
or “ibm,dynamic-memory-v2” is valid.If b'1', the Associativity List Index field of
“ibm,dynamic-memory” property
or “ibm,dynamic-memory-v2” is invalid.Reserved Memory0x00000080If b'0', corresponds to the
“status” property having a
value of “okay”.If b'1', corresponds to the
“status” property having a
value of “reserved”.Hot-removable Memory0x00000100If b'1', this LMB can be “hot-removed”.If b'0', this LMB may fail to be “hot-removed”.
“ibm,dynamic-memory-v2”property name that defines memory subject to dynamic
reconfiguration with data in version 2 format.prop-encoded-array: The number N of LMB set entries, encoded with
encode-int,
followed by N LMB set entries.The number-of-sequential-lmbs encoded with
encode-int.
The number of LMBs in the set.The starting-logical-address encoded with
encode-phys.
The logical address of the first LMB in the set.The starting-drc-index encoded with
encode-int.
The drc-index of the first LMB in the set.The associativity-index encoded with
encode-int.
All LMBs within the set share the same associativity.The flags word encoded with
encode-int.
All LMBs within the set share the same flag value. The bits in the flags word are defined in
.“ibm,memory-flags-mask”property name that defined which flags in the
“flags word” above are defined in this version of this
architecture.prop-encoded-array: An integer encoded as with
encode-int with all flag bits recognized by this
version of this architecture having a b'1' value. For this version, the
value will be 0x000000FF.“ibm,memory-preservation-time”property name that defined the time value that would
appear in the
“ibm,preservable” property in the old
bindings for a preservable LMB.prop-encoded-array: An integer value encoded as with
encode-int that represents the expected length of
time, in minutes, that the platform can sustain the state of power for a
preservable LMB. The largest positive number represents an indefinite
retention time as provided by such technologies as flash storage. A value
zero indicates that no memory will be marked as preservable.Memory Controller NodesThis section describes
memory-controller nodes and their properties. NUMA
configurations, have multiple
memory-controller nodes in the device tree one for
each Central Electronics Complex (CEC). In dynamic reconfiguration NUMA
environments, these
/memory-controller nodes are subject to standard
LoPAR dynamic reconfiguration operations and contain standard LoPAR
dynamic reconfiguration properties.Memory Controller Node PropertiesNo nodes of type
memory-controller shall be defined anywhere in the
device tree when the platform fully abstracts the memory controller and
the OS has no access to the memory controller (typically when running in
a partition). Otherwise, one or more nodes of type
memory-controller shall be defined as a child of
“/” (the root) and shall not have a
“ranges” property. The following
properties shall apply to each of these nodes. If the platform does not
abstract the functions of a platform's multiple memory controllers via
firmware (such as RTAS) then the platform shall
include a node of type
memory-controller for each Memory Controller in the
platform.A Memory Controller can also have the
“used-by-rtas” property (see
), if it has functions
abstracted by RTAS.“device_type” [S]Standard property name that denotes a Memory Controller
node.prop-encoded-array: A string, encoded as with
encode-string.The value of this property shall be
“memory-controller”.“reg” [S]Standard
property name defines the base physical address and
size of this Memory Controller’s addressable register space.prop-encoded-array: One (
phys-address, size) pair where
phys-address is encoded as with
encode-phys, and
size is encoded as with
encode-int.The property value shall be the base physical address and size of
this Memory Controller’s register space.“model” [S]Standard property name indicating this Memory
Controller’s manufacturer, part number and revision level.prop-encoded-array: Text string, encoded as with
encode-string.The value of this property is a vendor dependent string which
uniquely identifies this Memory Controller and shall be correlated to its
manufacturer, part number, and revision level. (see Core document for
more information.)“external-control” [S]property name indicates this Memory
Controller’s ability to support the PA external control
facility.prop-encoded-int: List of integers, each encoded as
with encode-int.The property value, if present, is a list of Resource ID’s
the version of the PA external control facility supports. This property
shall be present if this Memory Controller supports the PA external
control facility, otherwise the property shall be absent.“error-checking” [S]Standard property name defines the error checking capability
of the node.prop-encoded-array: a string, encoded as with
encode-string, where the value could equal
“none”, “ecc”, or “parity”.The value of
“#address-cells”
for this node is 1.The value of
“#size-cells” for this node is 0 because
the children of this node do not consume any physical address
space.IBM,memory-module NodesMemory packaged on DIMMs or DIMM like modules are represented in
the device tree with
IBM,memory-module nodes. These nodes represent
physical packages, these packages do not necessarily map directly to a
memory address range.No nodes of type
IBM,memory-module shall be defined anywhere in the
device tree when the platform supports dynamic VPD via the RTAS
ibm,get-vpd service. Instead the VPD that would
normally be reported via the
“ibm,vpd” property in these nodes shall
be reported by
ibm,get-vpd.Properties for Memory ModulesMemory modules appear as children of the
memory node or, for platforms supporting memory DR
operations (either logical or physical), the
memory-controller node of the device tree. This
section defines properties for the
IBM,memory-module nodes and additional properties for
the
memory and
memory-controller nodes.IBM,memory-module Node PropertiesAn
IBM,memory-module node is a child of the
memory node or, for platforms supporting memory DR
operations (either logical or physical), the
memory-controller node.The
“name”
of the node is “IBM,memory-module”The
“device_type”
of the node is “IBM,memory-module”The
“reg”
standard property for an
IBM,memory-module node is its memory module number
which is an arbitrary OF selected enumeration.The
“ibm,size”
property for an
IBM,memory-module node is an integer which is less
than 4GB and which by itself indicates the size of the memory module, in
bytes, if the memory module is smaller than 4GB and if
“status” is
“okay” or
“fail”.If the memory module is larger than or equal to 4GB in size, then
the
“ibm,size-upper”
property for an
IBM,memory-module node is present in addition to the
“ibm,size” property. This property is an
integer which is multiplied times 4GB and then added to the value of the
“ibm,size” property to get the size of
the module, in bytes. The property
“ibm,size-upper” is not required if the
memory module size is less than 4GB.The
“status”
standard property for an
IBM,memory-module node may have one of the following
string values:“okay” for a good memory module“fail” for a bad memory module“fail-no-matched-pair” for a missing
memory module if one of a pair is missing“fail-unsupport” for an unsupported
memory module“fail-partial” for a bad memory module
where part of the memory on the module is bad and has not been configured
and part of the memory is good and has been configured.“fail-excess-memory” for
“okay” memory modules that are not
configured because they exceed the system memory addressability of the
platform.“disabled” for a memory module that has
been manually deconfigured.“ibm,mem-banks”property name defines the number of memory banks
contained within the memory module.prop-encoded-array: an integer, encoded as with
encode-int, which describes whether this is a 1, 2,
or 4-bank module, with a corresponding value of 1, 2 or 4 and so on to
match the number of banks in the physical device.“ibm,mem-type”property name defines the memory module type.prop-encoded-array: a string, encoded as with
encode-string, that describes the type of module,
with values of
“FP” (Fast Page),
“EDO” (Extended Data Out), or
“SDRAM” (Synchronous DRAM).“ibm,mem-err-det”property name defines the type of error detection
mechanism supported by the moduleprop-encoded-array: a string, encoded as with
encode-string, with values of
“none”,
“parity”, or
“ECC”.“ibm,mem-speed”property name defines the access or clock speed
supported by the module, in picosecondsprop-encoded-array: an integer, encoded as with
encode-int, which describes the access or clock
speed supported by the module, in picoseconds.Interrupt Controller NodesThis section describes the properties for the LoPAR interrupt
controller node. If an interrupt controller node includes the
“used-by-rtas” property, then the
platform includes firmware code for accessing the interrupt
controller.For LSIs, the platform shall adhere to the
interrupt structure OF
representation.PowerPC External Interrupt Controller NodesThis section describes the properties for the PowerPC External
Interrupt Controller nodes. PowerPC interrupt controllers are normally
packaged inside other system chips, however, they are logically
represented in the device tree by two or more independent interrupt
controller nodes. Each node reports either the interrupt source layer
resources that are housed in a single Bus Unit Controller (BUC) e.g. host
bridge, or logical equivalent, or a subset of the resources associated
with the platform’s interrupt presentation layer. The node per BUC
and presentation layer subset divisions provides a foundation for dynamic
reconfiguration.At a dynamic reconfiguration event, such as adding an IO drawer, or
removing a processor, the interrupt controller nodes associated with the
added or removed hardware will also be added or removed. Therefore.
platforms should report, in individual nodes, each interrupt controller
that occupies a separate physical package. And OSs should expect a fine
granularity of interrupt controller reporting.“ibm,interrupt-domain”property name that denotes a PowerPC External
Interrupt Domainprop-encoded-array: An integer encoded as with
encode-int.PowerPC External Interrupt Presentation Controller Node
PropertiesThe following properties apply to this node.“name” [S]Standard
property name that denotes a PowerPC External
Interrupt Controller.prop-encoded-array: A string, encoded as with
encode-string.The value of this string shall be
“interrupt-controller”.“device_type” [S]Standard
property name that indicates an Interrupt
Controller.prop-encoded-array: A string, encoded as with
encode-string.The value of this property shall be
“PowerPC-External-Interrupt-Presentation”.“reg” [S]Standard
property name defines the base physical address(s)
and size(s) of this PowerPC External Interrupt Presentation layer’s
registers.prop-encoded-array: List of (
phys-addr, size) specifications.Phys-addr is encoded as with
encode-phys, and
size is encoded as with
encode-int.The entries shall represent the base address of a single set of
PowerPC External Interrupt Presentation Layer Registers of the Interrupt
Management Area. There shall be one entry for each interrupt server queue
supported by this unit. The order of the entries shall correspond to the
entries in the
“ibm,interrupt-server-ranges” property
described below.“compatible” [S]Standard
property name to define alternate
“name” property values.prop-encoded-array: The concatenation, with
encode+, of an arbitrary number of text strings,
each encoded as with
encode-string.The property value shall include
“IBM,ppc-xicp”.“ibm,interrupt-buid-size”property name: Defines the number of bits
implemented in the concatenation of the BUID fields.prop-encoded-value: An integer in the range of 9 to
20 encoded as with
encode-int.As platforms grow in size so as to require use of larger BUIDs
(values of the
“ibm,interrupt-buid-size”
property greater than 9) the platform engineers need to interlock with their OS
providers to ensure support.“ibm,interrupt-server-ranges”Property name that defines the interrupt server
number(s) and range(s) handled by this unit.prop-encoded-array: List of (server#, range) specifications.Server# is encoded as with
encode-int in the range of 0 - 2
the largest value of the
“ibm,interrupt-server#-size” property contained in the device
tree.Range is encoded as with
encode-int.The first entry in this list shall contain the
server# associated with the first
“reg” property entry. The
server# corresponds to a value of a processor’s
“ibm,ppc-interrupt-server#s” property.
The range shall be the number of contiguous
server# s supported by the unit (this also
corresponds to the number of
“reg” entries).“interrupt-controller” [S]Standard
property name to indicate an interrupt (sub-)tree
root.prop-encoded-array: <none> The presence of
this property indicates that this node represents an interrupt
controller.“model” [S]Standard
property name indicating this unit’s
manufacturer, part number, and revision level.prop-encoded-array: Text string, encoded as with
encode-string.The value of this property shall be a string which uniquely
identifies the interrupt controller and shall be correlated to the
manufacturer, part number, and revision level. This value is device
dependent (see the Core document for more information).PowerPC External Interrupt Source Controller Node
PropertiesInterrupt source controller resources as represented by
“interrupt-ranges”,
“#interrupt-cells”, and
“ibm,interrupt-server#-size” properties
may be reported in stand-alone interrupt source controller nodes or in
other logical equivalent nodes which contain the
“interrupt-controller” property. The
following properties apply to these nodes.“name” [S]Standard
property name that denotes a PowerPC External
Interrupt Controller.prop-encoded-array: A string, encoded as with
encode-string.The value of this string shall be
“interrupt-controller”.“device_type” [S]Standard
property name that indicates the specific flavor of
Interrupt Source Controller.prop-encoded-array: A string, encoded as with
encode-string.The value of this property shall be one of the following:“PowerPC-LSI-Source”
For Level Sensitive Interrupt source controllers.“PowerPC-MSI-Source”
For Message Sensitive Interrupt source controllers such as used
with PCI MSI.“reg” [S]Standard
property name defines the base physical address(s)
and size(s) of this PowerPC External Interrupt Source if any.prop-encoded-array: List of (
phys-addr, size) specifications.Phys-addr is encoded as with
encode-phys, and
size is encoded as with
encode-int.If the
“device-type” of the interrupt source
controller is
“PowerPC-MSI-Source”, then the last
“reg” entry shall correspond to the
interrupt controller’s 4 byte Message Interrupt Input Port.“compatible” [S]Standard
property name to define alternate
“name” property values.prop-encoded-array: The concatenation, with
encode+, of an arbitrary number of text strings,
each encoded as with
encode-string.The property value shall include
“ibm,ppc-xics”.“interrupt-ranges” [S]Standard
property name that defines the interrupt number(s)
and range(s) handled by this unit.prop-encoded-array: List of (
int-number, range) specifications.Int-number is encoded as with
encode-int.Range is encoded as with
encode-int.The first entry in this list shall contain the
int-number associated with the first
“reg” property entry. The
int-number is the value representing the interrupt
source as would appear in the PowerPC External Interrupt Architecture
XISR. The range shall be the number of sequential interrupt numbers which
this unit can generate.“interrupt-controller” [S]Standard
property name to indicate an interrupt (sub-)tree
root.prop-encoded-array: <none> The presence of
this property indicates that this node represents an interrupt
controller.“model” [S]Standard
property name indicating this unit’s
manufacturer, part number, and revision level.prop-encoded-array: Text string, encoded as with
encode-string.The value of this property shall be a string which uniquely
identifies the interrupt controller and shall be correlated to the
manufacturer, part number, and revision level. This value is device
dependent (see the Core document for more information).“#interrupt-cells” [S]Standard property name to define the number of cells in an
interrupt-specifier within an interrupt
domain.prop-encoded-array: An integer, encoded as with
encode-int, that denotes the number of cells
required to represent an interrupt specifier in its child nodes.The value of this property for the PowerPC External Interrupt
option shall be 2. Thus all interrupt specifiers (as used in the standard
“interrupts” property) shall consist of
two cells, each containing an integer encoded as with
encode-int. The first integer represents the
interrupt number the second integer is the trigger code: 0 for edge
triggered, 1 for level triggered.“ibm,interrupt-server#-size”property name: Defines the number of bits
implemented in the concatenation of the server#extension and server#
fields.prop-encoded-value: An integer in the range of 8 to
24 encoded as with
encode-int.As platforms grow in size so as to require use of the
server#extension field (values of the
“ibm,interrupt-server#-size”
property greater than 8) the platform engineers need to interlock with their OS
providers to ensure support.Additional Node PropertiesAdditional properties and methods are defined in this section for
LoPAR binding adapters and/or devices.Interrupt PropertiesThe properties in this section shall be implemented for any device
that can present an interrupt for an LoPAR platform implementation. The
platform shall adhere to the
definition for the interrupt
structure.Miscellaneous Node PropertiesThis section defines properties which support devices, adapter and
buses with geographical information. These properties shall be present
for an LoPAR platform.“built-in” [S]Standard property name: Any device that connects to an
industry standard I/O expansion bus attached through a non-standard
connector.prop-encoded-string: <none>.Note: This property will also include platform
‘riser’ cards.“used-by-rtas” [S]Standard property name: Indicates the device can be in use by
an RTAS Function Call.prop-encoded-int: Presence of property indicates a
device may have an I/O or resource conflict with a RTAS Function
Call.The use of the
“slot-names” property defined below is
deprecated in favor of the
“ibm,loc-code” property.“slot-names” [S]property name: Describes external labeling of
adapter/device connectors.prop-encoded-array: An integer, encoded as with
encode-int, followed by a list of strings, each
encoded as with
encode-string.The integer portion of the property value is a bitmask of available
connectors; for each connector associated with the adapter/device, the
bit corresponding to that connector’s ID number is set from
least-significant to most-significant ID number. The number of following
strings is the same as the number of connectors; the first string gives
the platform nomenclature or label for the connector with the smallest ID
number, and so on.Note: Each device that has a connector should
identify the order and contents of the list of strings in a
binding.“ibm,loc-code” [S]property name to provide location code(s) for the
Field Replacable Unit.prop-encoded-array: an arbitrary number of strings,
encoded as with
encode-string.“ibm,vpd”property name to provide Vital Product Data (VPD)
information as defined in
.prop-encoded-array: the concatenation, with
encode+, of one or more pairs of elements, the first
element of each pair being an integer (representing the length of the
second element) encoded as with
encode-int, and the second element of each pair
being a series of bytes (the VPD data) encoded as with
encode-bytes.“ibm,loc-code-map”prop-name to identify that the interface may have
child nodes, which may or may not be present in the device tree, that
have a physical location code based on their unit-address.prop-encoded-array: A list of pairs (unit-address,
location-code). The unit-address is the child device node's
“reg” property string-encoded according
to the parent node's architecture and encoded as with encode-string. The
location-code is the child device node's
“ibm,loc-code” property encoded as with
encode-string.If a child device under this node has a matching unit-address, the
location code corresponds to the physical location of that child
device./aliases NodeA device alias, or simply
alias, is a shorthand representation of a
device-path.
Aliases are properties of the
aliases node, encoded as with
encode-string. Aliases are typically used by a user
to facilitate not specifying a long path name at the User Interface
‘ok’ prompt.An implementation of OF for an LoPAR platform shall provide the
following aliases as properties of the
aliases node, if the corresponding device
exists:“disk” [S]property name indicating the device path of the
factory default disk that is the preferred boot diskImplementation Note: The preferred
boot disk should be the disk
that results in the fastest boot time. Implementations might
automatically spin up a disk at system power on and provide mechanisms
for firmware to report that disk in this property.for the platform.“tape” [S]property name indicating the device path of the
factory default tape.“cdrom” [S]property name indicating the device path of the
factory default CDROM.“keyboard” [S]property name indicating the device path to the
keyboard to be used for the User Interface.“mouse” [S]property name indicating the device path to the mouse
to be used for the User Interface.“screen” [S]property name indicating the device path to the
screen to be used for the User Interface.“pc-keyboard” [S]property name indicating the device path of the
factory default PC-style keyboard.“pc-mouse” [S]property name indicating the device path of the
factory default PC-style mouse.“adb-keyboard” [S]property name indicating the device path of the
factory default ADB-style keyboard.“adb-mouse” [S]property name indicating the device path of the
factory default ADB-style mouse.“scsi” [S]property name indicating the device path of the
factory default built-in SCSI device.“com1” [S]property name indicating the device path of the
factory default 16550-style serial port known as
“com1.”“com2” [S]property name indicating the device path of the
factory default 16550-style serial port known as “com2.”“scca” [S]property name indicating the device path of the
factory default SCC-style serial port known as “SCCA.”“sccb” [S]property name indicating the device path of the
factory default SCC-style serial port known as “SCCB.”“floppy” [S]property name indicating the device path of the
factory default floppy drive.“net” [S]property name indicating the device path of the
factory default built-in network interface controller.“rtc” [S]property name indicating the device path of the
factory default real-time-clock chip.“nvram” [S]property name indicating the device path of the
factory default NVRAM./event-sources NodeThe
/event-sources node describes the possible RTAS Error
and Event Classes for interrupts. The
/event-sources node shall be defined to be a child of
the root device tree node if the platform supports any event interrupts.
The following properties shall be defined for this node:“name” [S]Standard
property name that denotes the Event Sources.prop-encoded-array: A string, encoded as with
encode-string.The value of this string shall be
“event-sources”.When events are reported as virtual interrupts there shall be a
node of
device_type
“PowerPC-External-Interrupt-Presentation” from
which the virtual interrupt source BUID size can be obtained. Also the
event-sources node represents the interrupt source
node for virtual event interrupts and thus the following properties shall
be defined for this node:“interrupt-controller” [S]Standard property name: to indicate the events interrupt tree
root.prop-encoded-array: <none> The presence of
this property indicates that this node represents a source of virtual
interrupts. Encoded with
encode-null.“#interrupt-cells” [S]Refer to the definition of the
“#interrupt-cells” property for nodes of
device_type “PowerPC-LSI-Source” for
information about the definition of this property for virtual event
interrupts.“interrupt-ranges” [S]Refer to the definition of the
“interrupt-ranges” property for nodes of
device_type
“PowerPC-LSI-Source” for information
about the definition of this property for virtual event
interrupts.Children of
/event-sources present the interrupt specifiers
associated with the reporting of platform events. LoPAR platforms have
historically implied the default value of
“#interrupt-cells” of 1 to report the
associated interrupt specifiers without the interrupt trigger specifier.
However, all new designs shall present interrupt specifiers with explicit
trigger level values.Child nodes of the Event Sources NodeThe following specify standard child nodes of the
/event-sources node. These nodes could be present in
an LoPAR platform.Children of the
/event-sources node specify the interrupt specifiers
associated with the reporting of platform events. Interrupt designs shall
use the 1275 standard
“interrupts” property as configured to
report the interrupt specifier for the platforms PowerPC interrupt
controller. The interrupt specifiers if the
“interrupts” property indicates one or
more interrupt source numbers that are used to report event
conditions.internal-errorsThe presence of the node indicates that all or some of the function
has been implemented and will be reported using an interrupt.“name” [S]Standard
property name that denotes the internal error’s
events.prop-encoded-array: A string, encoded as with
encode-string.The value of this string shall be
“internal-error”.epow-eventsThe presence of the node indicates that all or some of the function
has been implemented and will be reported using an interrupt.“name” [S]Standard
property name that denotes the EPOW events.prop-encoded-array: A string, encoded as with
encode-string.The value of this string shall be
“epow-events”.ibm,io-eventsThe presence of the node indicates that all or some of the function
has been implemented and will be reported using an interrupt.“name” [S]Standard
property name that denotes the I/O sub-system
events.prop-encoded-array: A string, encoded as with
encode-string.The value of this string shall be
“ibm,io-events”.hot-plug-eventsThe presence of the node indicates that all or some of the function
has been implemented and will be reported using an interrupt. “name”Standard
property name that denotes the hot-plug
events.prop-encoded-array: A string, encoded as with
encode-string.The value of this string shall be
“hot-plug-events”./reserved NodeThis section defines a reserved node which shall have a
“reg” property which allocates addresses
(on the bus of which it is a child) which is intended to be a place to
identify hardware registers that do not otherwise belong to a recognized
device.“name” [S]Standard
property name that denotes reserved addresses that do
not belong to a recognized device.prop-encoded-array: A string, encoded as with
encode-string.The value of this string shall be
“reserved”.“device_type” [S]Standard
property name that indicates the device type.prop-encoded-array: Text string, encoded as with
encode-string.The value of this property shall be
“reserved”.“reg” [S]Standard
property name defines a hardware register address and
range of addresses not intended for OS (OS) use.prop-encoded-array: List of (
phys-addr, size) specifications.Phys-addr is a (phys.lo ... phys.hi) sequence equal
to #address-cells, encoded as with
encode-phys.size is a sequence equal to
#size-cells encoded as with
encode-size.The first entry in this list shall be a hardware register address (
phys-addr) and a range of hardware addresses (
size) that is not intended for OS usage. Successive
entries in this list shall be additional hardware addresses not intended
for OS usage./chosen NodeThis section lists additional properties as required under the
/chosen node with the following text in a manner that
is consistent with
, Section 3.5.“nvram” [S]Standard property name that defines the package
Ihandle for CHRP NVRAM.prop-encoded-array: an integer, as encoded with
encode-int, that is the package
Ihandle the CHRP NVRAM.Note: The nvram Node identified in the /chosen Node
shall support a size method as specified in
, Section 7.2. The size method
will return a value that is the total platform NVRAM size.“ibm,rpa-client-config”property name that defines the processed fields of
the client program’s IBM,RPA-Client-Config ELF note section.prop-encoded-array: an array of integers encoded as
with
encode-int, that consist of the fields of the note
section that the firmware processed prior to loading the client
program.“ibm,architecture-vec-5”property name: that presents the values of the
option vector #5 negotiated by the
ibm,client architecture-support method. Presence of
this property signifies that the client program load module invoked the
ibm,client architecture-support method.prop-encoded-array: An array of bytes having the
format of the fifth option vector from
representing the value chosen
by the ibm,client architecture-support method.“ibm,client-architecture-support-reboot”property name: that indicates that one or more
reboots have occurred in this boot sequence in order to adjust the
platform settings to match the specification in the
“ibm,client-architecture-support” open
firmware method or the IBM,RPA-Client-Config ELF header note. Note this
property is not included for the first boot in a sequence.prop-encoded-array: encoded as with
encode-int that specifies the number of reboots that
have occurred in this boot sequence in order to adjust the platform
settings to match the specification in the
“ibm,client-architecture-support” open
firmware method or the IBM,RPA-Client-Config ELF header note./vdevice NodeThe node of type vdevice is a child of the root node. It is only
present in trees that also include the
“ibm,hypertas_functions” property. It,
and its children represent the virtualized devices that are implemented
by the platform firmware. Virtualized devices do not surface to a client
program a direct hardware interface. They do not appear to take up space
in the client program’s address map. Standard property names
associated with the
/vdevice node have special values as specified
below.“#address-cells” [S]Standard
property name encoded as with
encode-int that specifies the number of cells
required to represent a child bus address. Shall have the value of 1.“#size-cells” [S]Standard
property name encoded as with
encode-int that specifies the number of cells
required to encode the size field of a child’s reg property. Shall
have the value of 0 indicating that no child node may actually take
physical address space.“name” [S]Standard
property name string encoded as with
encode-string that defines the name of node. The
value shall be the string “vdevice”.“device_type” [S]Standard
property name string encoded as with
encode-string that defines the device type of the
node. The value shall be the string “vdevice”.“ibm,max-virtual-dma-size”Vendor unique
property name indicating the maximum size virtual dma
transfer size supported by the platformprop-encoded-array: a single integer encoded as with
encode-int.“ibm,migration-control”property name that indicates when platform firmware
supports the ability for an I/O server partition to delay the migration
of a partition to a different server in order to let any in progress I/O
to be completed. Specifically, this property indicates that the
DISABLE_MIGRATION and ENABLE_MIGRATION subfunctions of the H_VIOCTL
hypervisor call are supported.prop-encoded-array: None, this is a name only
property.“ibm,reserved-virtual-addresses”Vendor unique
property name indicating ranges of the client program
virtual address space that are reserved for platform use.prop-encoded-array: one or more pairs of
abbreviated-virtual-address, virtual-address-length specifications
representing the origin and length respectively of a reserved virtual
address range.abbreviated-virtual-address: Consists of two integers
encoded as with
encode-int representing the high order and low order
32 bits respectively of the 64 bit abbreviated virtual address. The full
virtual address is the abbreviated-virtual-address concatenated with 3
low order bytes of 0x00.virtual-address-length: Consists of a single integer
encoded as with
encode-int representing the number of consecutive 4K
pages contained within the range.Children of the /vdevice NodeThe children of the
/vdevice node represent the individual virtual
devices.Children of the
/vdevice node that support dma operations contain a
the
“ibm,my-dma-window” property as defined
below:“ibm,my-dma-window”property name that defines the bus address window(s)
that this IOA may use for its dma.prop-encoded-array: One or more (
logical-I/O-bus-number, phys,
size) triple(s) where the logical bus number is a
one cell cookie representing the unique range of TCE entries assigned to
this IOA encoded as with
encode-int, the number of cells for
phys corresponds to the node’s
“ibm,#dma-address-cells” value while the
number of cells for
size corresponds to the
“ibm,#dma-size-cells” for this node. The
first triple represents the TCE range available for mapping local memory,
while the second triple, if it exists, is where remote memory mapped by
remote partitions appears. The size field of the second triple shall be
equal to the size field of the corresponding remote partition’s
first triple.The
“ibm,my-dma-window” property is the per
device equivalent of the
“ibm,dma-window” property found in nodes
representing bus bridges.Children of the
/vdevice node share the ability to display unique
capabilities as represented by the following properties.“ibm,async-dma-required”property name indicates that the virtual device
requires the use of asynchronous virtual DMA interfaces (see
for definition of asynchronous
virtual DMA interfaces).prop-encoded-array: None, this is a name only
property.Children of the
/vdevice node which act a a server to other virtual
client devices, display the following property.“ibm,vserver”property name indicates that the virtual device is a
server to virtual devices.prop-encoded-array: None, this is a name only
property.“ibm,mac-address-filters”property name specifies the number of non-broadcast
multicast MAC filters supported by the implementation.prop-encoded-array: an integer in the range of 0-255
encoded as with
encode-int.“ibm,trunk-adapter”property name that indicates that the virtual device
is a trunk adapter server to the logical LAN.prop-encoded-array: None, this is a name only
property.“ibm,illan-options”property name: The existence of this property is
required when any of the ILLAN sub-options are implemented and indicates
that the H_ILLAN_ATTRIBUTES hcall() is implemented, and that hcall() is
then used to determine which ILLAN options are implemented.prop-encoded-array: None, this is a name only
property.“ibm,vf-loc-code”Vendor unique property name indicating the physical device
virtual function upon which the vnic-server runs. The value is that of the
“ibm,loc-code”
property of the physical device virtual function.prop-encoded-array: an arbitrary number of strings, encoded as with
encode-string.“ibm,vnic-mode”Vendor unique property name that represents the operational
mode in which the vnic-server runs.prop-encoded-array: a single byte, encoded as with
encode-bytes.Defined values:0: backing device is dedicated to one VNIC client1: backing device is shared by multiple VNIC clients2-255: reserved“ibm,vnic-client-mac”Vendor unique property name that represents the MAC
address of a given vNIC server's client.prop-encoded-array: 6 bytes, encoded as with
encode-bytes.Virtual Teletype DeviceThe virtual teletype device allows communication through the
platform’s attached Hardware System Console. There is one such
virtual device node for each virtual terminal enumerated by the
“ibm,termno” property. The unit addresses
of the virtual teletype devices shall correspond to the enumeration
presented in the
“ibm,termno” property. Such virtual
terminals, as represented by the
“ibm,termno” property, are intended for
the use of the client program and shall not be marked
“used-by-rtas”. Similarly they may be
“chosen” as the default input and output device.“name” [S]Standard
property name encoded as with
encode-string that defines the device name. The value
shall be the string
“vty”.“reg” [S]Standard property name to define a unit address for the node.
One (
phys-addr, size) pair. The
phys-addr is the unit address of the device
(corresponding to one of the virtual terminals enumerated by the
“ibm,termno” property), and the
size shall have a length of zero.“device_type” [S]Standard property name encoded as with
encode-string to specify the device type. The value
shall be the string
“serial” indicating that the device
emulates a serial terminal.“compatible” [S]Standard
property name encoded as with
encode-string to specify the device driver
compatibility. The value shall be one of the strings specified in
.
Virtual tty compatibility stringsCompatible property String
ValueComments“hvterm1”Standard client virtual tty protocol“hvterm2”Standard server virtual tty protocol“hvterm-protocol”Client virtual tty protocol extended for control of
modems etc.
See
for further detail on this
virtual device.Children of
/vdevice node defined in other documentsLike children of the pci bus node, children of
/vdevice may be defined by their own binding
documents or via binding sections/tables in their device specifications.
For example, the binding information for the LoPAR Interpartition
Logical LAN, Virtual SCSI, and Virtual Terminal can be found in the
appropriate sections of this document. The virtualization of traditional
physical devices repositions their associated device tree nodes to be
children of
/vdevice. Examples include NVRAM and Real Time Clock
(RTC) devices which are defined by
.Barrier Synchronization FacilityThis section describes the OF node that represents the optional
Barrier Synchronization Register (BSR) facility. If the platform provides
a BSR facility it provides the
ibm,bsr node as a child of
/ (root). If the platform provides a client program
with multiple independent facilities, it represents each such facility
with a separate node. A given facility may have multiple representations
through parallel windows. Each window of a given facility is represented
by a separate
“reg” property value. The following
properties are the minimum required, optional support such as dynamic
reconfiguration will add properties per requirements called out in the
.“name” [S]Standard
property name encoded as with
encode-string that defines the device name. The value
shall be the string
“ibm,bsr” for legacy implementations and
“ibm,bsr2” for POWER8 implementations and
beyond.“reg” [S]Standard
property name to define the addresses for the
facility window(s).prop-encoded-array: One or more (
phys-addr, size) pair(s). The
phys-addr, encoded as with
encode-phys, is the starting address (4 K aligned) of
the window. The
size, encoded in the number of cells specified by
“#size-cells” of the parent, is the
length of the corresponding window.“device_type” [S]Standard
property name encoded as with
encode-string to specify the device type. The value
shall be the string
“ibm,bsr”.“compatible” [S]Standard
property name encoded as with
encode-string to specify the device driver
compatibility. The value shall be the string
“ibm,bsr”.“ibm,#lock-bytes”property name: Indicates the number of lock bytes
per line of the BSR facility.prop-encoded-array: One or more integers encoded as
with encode-int. When the facility has multiple windows,
as represented by multiple values of the
“reg” property, then there is a
corresponding number of integers, each integer representing the number of
lock bytes per line of the corresponding window.“ibm,lock-stride”property name: Indicates the number of bytes between
the beginning of lock lines in the BSR facility.prop-encoded-array: One or more integers encoded as
with encode-int. When the facility
has multiple windows, as represented by multiple values of the
“reg” property, then there is a
corresponding number of integers, each integer representing the number of
bytes to the beginning of the next lock line in the corresponding
window.Nodes of device_type “block” and
“byte”This section describes the OF nodes that provide access to storage
devices in block or byte commands. This applies to such nodes with and
without a
“reg” property.“ibm,write-supported”property name: Indicates the driver supports write
functionality and has been verified by IBM. The use of the write function
without this property is discouraged.prop-encoded-array: None, this is a name only
property.“ibm,16byte-cdb-supported”property name: Indicates the driver supports using
the 16 byte Command Descriptor Block format, which is needed to access
above 2 TB on 512 byte block-sized media.prop-encoded-array: None, this is a name only
property./ibm,platform-facilitiesThe node of type
ibm,platform-facilities is a child of the root node.
It and its children represent the non-CPU platform computational
facilities that are available. Platform facilities do not take up space
in the client program’s address map. Standard property names
associated with the
/ibm,platformfacilities node have special values as
specified below.“#address-cells” [S]Standard
property name encoded as with
encode-int that specifies the number of cells
required to represent a child bus address. Shall have the value of
1.“#size-cells” [S]Standard
property name encoded as with
encode-int that specifies the number of cells
required to encode the size field of a child’s reg property. Shall
have the value of 0 indicating that no child node may actually take
physical address space.“name” [S]Standard
property name string encoded as with
encode-string that defines the name of node. The
value shall be the string
“ibm,platform-facilities”.“device_type” [S]Standard
property name string encoded as with
encode-string that defines the device type of the
node. The value shall be the string
“ibm,platform-facilities”.Some platform facilities configurations allow multiple facilities
to share a common pool of interrupt server numbers. Individual operations
specify which interrupt server number from the pool shall be used to
signal completion of the operation. To represent such a configuration,
the
/ibm,platformfacilities node may either represent an
interrupt source controller for its children or the interrupt source
controller associated with the shared pool may be represented by a
PowerPC External Interrupt Source Controller Node as an additional child
node of the
/ibm,platform-facilities node
(). Additionally, the node
representing the platform facilities Interrupt Source Controller shall
contain the
“ibm,interrupt-pool” property, and all
platform facilities that share the common pool of interrupts shall
contain the
“ibm,shared-interrupt-pool” property.“ibm,interrupt-pool”property name: that indicates this interrupt
controller provides a shared pool of interrupt source numbers.property encoded array: single cell encoded as with
encode-int that represents the type of shared
interrupt pool being represented: Defined values are: 0 with all other
values reserved.“ibm,max-async-ops-per-processor”property name: that indicates for the partition the
allowed maximum number of outstanding operations for the platform
facility based upon the number of processors currently allocated to the
partition. The total allowable number of such operations outstanding
across all partition processors is the product of the value of
“ibm,max-async-ops-per-processor” and the
number of nodes of type cpu in the current partition device tree.property encoded array: single cell encoded as with
encode-intChildren of the /ibm,platform-facilities NodeThe children of the
/ibm,platform-facilities node represent the
individual platform facilities. Standard property names associated with
the children of the
/ibm,platform-facilities node have special values as
specified below. Note the children of the
/ibm,platform-facilities node shall contain the
following standard properties with their standard definitions:“compatible”“name” The defined Values for the
“name” property of children of
/ibm,platform-facilities are (were # is the version
number of the interface):ibm,random-v# Random number generatoribm,compression-v# Compression/Decompression
engineibm,sym-encryption-v# Symmetric encryption/decryption
engineibm,asym-encryption-v# Asymmetric
encryption/decryption engineibm,memory-utilization-instrumentation-v# Memory
usage information“status”Optionally the children of the
/ibm,platform-facilities node may contain as
appropriate the following standard properties with their standard
definitions:“interrupts”Additionally the children of the
/ibm,platform-facilities node may contain as
appropriate the following unique properties:“ibm,resource-id”property name: that indicates the platform facility
resource identification handle.property encoded array: single cell encoded as with
encode-int“ibm,max-sync-cop”property name: that indicates the maximum
characteristics of the parameters for a synchronous call of the platform
facility. These characteristics are represented as a series of integers
encoded as with
encode-int that
may grow over time as platform
facilities evolve. The absence of this property indicates that
synchronous operations are not allowed for the given child.property encoded array: a series of zero or more or
more cells each encoded as with
encode-int. The interpretation of the series of
integers is unique per the value of the
“name” property:For the Random number generator: NULL value indicating that all
calls are synchronousFor the compression/decompression engine: Two series of cells the
first series of cells represents the maximums that can be synchronously
compressed. The second series of cells represents the maximums that can
be synchronously decompressed.The first cell in each series contains the count of the number of
data length, scatter/gather elements pairs that follow – each being
of the formOne cell data byte lengthOne cell total number of scatter/gather elementsFor the symmetric encryption/decryption engine: the series of
cells report for each function code (FC) and mode combination the maximum
amount of data and scatter/gather list elements that can be processed
with a given key length. Thus the array consists of 1-N sub sequences
each of the form:First cell contains the FC fieldSecond cell contains the mode fieldThird cell contains the count of the number of key length, data
length, scatter/gather elements triples that follow – each being of
the form:One cell key bit lengthOne cell data byte lengthOne cell total number of scatter/gather elements“ibm,max-sg-len”property name: that indicates the maximum byte length
of a scatter/gather list for the platform facility.property encoded array: single cell encoded as with
encode-int“ibm,shared-interrupt-pool”property name: that provides an indirect pointer to
the node representing the shared interrupt pool used by this
facility.property encoded array: the phandle of the node
representing the PowerPC External Interrupt Source Controller that
sources the interrupts of the shared interrupt pool used by this
facility.For the memory utilization instrumentation facility node the following properties are defined:“ibm,mui-associativity-mapping”property name to define the mapping between Memory Usage
Instrumentation Affinity Log Array entries and their associated associativity strings.property encoded array: An integer (L) encoded as with
encode-int followed by L sets ALA map entries.Each ALA map entry consisting of:An integer (ALAentry) encoded as with
encode-int
as would be found in the affinity_log record for the return buffer
from the H_RETURN_PAGEINFO hcall() followed by;An integer (M) encoded as with
encode-int
that represents the type of source of the reference
(defined values are presented below). Sources of a general
type are grouped together, so that if the
client program does not recognize a given specific type,
it can still categorize via the more general
type of source:0-100,000,000 CPU100,000,001 – 200,000,000 I/O Bridge200,000,001 – 300,000,000 Platform Service DeviceAll other values reserved (may be grouped together as an unknown source type).Followed by:An integer (N) encoded as with
encode-int
followed by N associativity lists.Each associativity list consisting of a number of entries integer (P) encoded as with
encode-int
followed by P integers encoded as with
encode-int
each representing an associativity
domain number.“ibm,mui-ranges”property name to define the implementation specific
ranges of memory utilization instrumentationmeasures.property encoded array: An integer (N) encoded as with
encode-int
which communicates the number of pairs of range values, each being an integer encoded as with
encode-int
which represent the implementation limits of a given measure. See
for details. The reader is to ignore values pairs beyond those it was designed to use.
If the value of N is zero the MUI measures are not available.
“ibm,mui-associativity-mapping” range limitsPair #1MIN/MAXThe minimum and maximum supported value of the HUC field
which is the power of 2 multiplier of microseconds that defines the
History Bit Array update period.20/MAXThe number of bits implemented in the HBA.30/MAXAccess rate in accesses per millisecond.40/MAXPage Age; the MAX value is the number of Page Age Granules
which saturates the page age counter.50/MAXRemote Reference; the MAX value is the number of implemented ALA entries.
Symmetric Multi-Processors (SMP)LoPAR platforms can have Symmetric Multi-Processor (SMP)
Configurations. In addition to the processor node properties defined in
, a SMP Configuration will
utilize the
/cpus node as explained in
SMP Platform Device Tree StructureOF requires that multiple instances of any device that appears more
than once in the device tree must be unique and distinguishable by means
of their
“reg” properties. For LoPAR platforms,
processors shall not be directly attached to the main physical bus (root
node (“
/ ”)). Instead, cpu devices shall be children
of the
/cpus node.The
/cpus node shall have one child node of device type
cpu for each processor. The
ihandle of the “executing” processor
shall
be published in the
“cpu” property of the
/chosen node.Note: The properties of a cpu device are already
defined in
. The only change for symmetric
multiprocessor (SMP) systems is that there will be a cpu device node
under the
/cpus node for each individual processor. Other
properties of the cpu devices shall
conform with the requirements stated in
.SMP PropertiesThe following properties are for a PA SMP environment. These SMP
properties will be under the
/cpus Node.“slot-names” [S]property name that describes platform labeling of
plug-in cpu/processor card slots.prop-encoded-array: An integer, encoded as with
encode-int, followed by a list of strings, each
encoded as with
encode-string.The integer portion of the property value is a bitmask of possible
processors; for each add-in slot on the bus, the bit corresponding to
that slot’s ID number is set from least-significant to
most-significant ID number. The number of following strings is the same
as the number of slots; the first string gives the platform nomenclature
for the slot with the smallest ID number, and so on. The CPU’s
“slot-names-index” property can be used
as an index into the bitmask integer of this property. The absence of
this property indicates that no slots are present.“smp-enabled” [S]property name that indicates a platform can be SMP
enabled.prop-encoded-array: <NULL>The presence of this property signifies that the platform is SMP
enabled, even if it only has one processor.Processor NodeThe following properties are for a PA SMP environment. This SMP
property will be under each
/cpu Node.“slot-names-index” [S]property name: Identifies each cpu with a unique
number.prop-encoded-array: An integer, encoded as with
encode-int.The value of this integer is a platform unique number with a range
from 0 to
n-1 for each CPU where
n is the number of slots. This number is used to
index into the
“slot-names” property to identify the
value of the string associated with the slot name.Device Power Management Properties/MethodsThis section defines standard platform node properties, device node
properties, and methods related to power management. The properties and
methods of this section shall be implemented on any platform which supports
power management except where noted. However, it is still being enhanced.
OS providers who want to ensure that the data needed for their power
management policies is included should contact the authors of this
document.System Node PropertiesThe following defines properties are to be associated with the rtas
and the power-management-events nodes of the device tree.Properties assigned to the RTAS nodePower domains are a feature of platforms which support power
management. Within the OF device tree, power domains are represented by a
power domain identifier which is defined to be an integer in the range 0
... n-1, where n is the number of power domains on the platform.“power-domains-tree” [S]Standard
property name which defines the power domain
hierarchy for this platform.prop-encoded-array: An array of integers, each
encoded as with
encode-int, that is a flattened representation of
the power domain dependency tree.The array consists of a number of tuples, one for each power domain
defined on the platform. Each tuple consists of the power domain
identifier domain#, followed by the number of power levels #levels
supported by the domain, followed by an array of tuples, one for each
level. These tuples consist of a level identifier level, followed by the
number of power sources from which the domain draws power, followed by an
array of tuples (power-source-id, power). The power domain tuple is
terminated by the number of children #children followed by a list of the
domain identifiers of each child. The power values are expressed in
milliamperes and include only the power consumed by support logic not
represented as devices in the device tree including any RTAS abstracted
devices within the particular power domain.“power-domains-controllers” [S]Standard
property name which defines the power domain
controllers present on this platform.prop-encoded-array: an array of integers, each
encoded as with
encode-int.Each integer is the
phandle of the device tree node that functions as the
power domain controller for a domain. A single controller may serve as
the control point for multiple domains (the architecture calls them power
domain control points). Each device which serves as a controller encodes
the
“controls-power-domain” property.“power-domains-names” [S]Standard
property name used to define the user readable names
for the power domains.prop-encoded-array: an array of strings, each
encoded as with
encode-string, that are the user readable names for
the domains.The number of strings matches the number of domains and there is a
one-to-one correspondence between the entries in the
“power-domain-controllers” property and
the entries in this array.“platform-power-sources” [S]Standard
property name defining the platform power
sources.prop-encoded-array: an array of integers, each
encoded as with
encode-int.The array is structured as a number of tuples. Each of these tuples
consists of the values source-voltage, (given in millivolts), peak-power,
continuous-use-power (both expressed in milliamperes supplied at the
stated voltage), and conversion-efficiency (expressed in percent).“power-sources-names” [S]Standard
property name defining the platform power source
names.prop-encoded-array: an array of strings, each
encoded as with
encode-string, that are the user readable names for
the power sources.The number of strings match the number of power sources and is in
one-to-one correspondence to the entries in the
“platform-power-sources” property.“platform-battery-sources” [S]Standard
property name defining the batteries utilized by a
platform.prop-encoded-array: an array of integers, each
encoded as with
encode-int.Each value in this array is the manufacturer’s rated capacity
of the battery expressed in milliwatt-hours.“battery-sources-names” [S]Standard
property name defining the human-readable identifier
of the batteries utilized by a platform.prop-encoded-array: an array of strings, each
encoded as with
encode-string.Each entry in this array corresponds one-for-one with the batteries
defined in the
“platform-battery-sources” property.Properties of the power-management-events node“power-type” [S]Standard
property name defining the power management event
types implemented on a specific platform.prop-encoded-array: an array of integers, each
encoded as with
encode-int.Device Properties“power-domains” [S]Standard
property name, indicating the power domains of which
this device is a member.prop-encoded-array: List of one or more
domain-id’s to which this device belongs.
Domain-id’s is encoded as with
encode-int.The
“power-domains” property should only list
the
domain-id’s of the lowest power domain tree
nodes in which this device has membership. If the device is a member of
the default power domain 0 alone, this property does not need to be
provided.“device-power-states” [S]Standard
property name which describes the power states this
device supports.prop-encoded-array: An array of integers, each
encoded as with
encode-int that defines the supported power states
for this device.This property shall be provided for each physical device which has
multiple power states, if platform firmware provides device power state
information.The array consists of an integer representing the initial device
power state after reset, followed by the number of power sources from
which the device draws power, followed by an arbitrary number of tuples,
one for each supported power state of the device. Each tuple consists of
the state, followed by an array of tuples (power-source-id, power) giving
the average power consumption from each power source during active use.
This is followed by another array of tuples (power-source-id, power)
giving the idle power consumption for each power source. Each power state
tuple is terminated by the maximum expected power usage lifetime in
seconds for the device if it were to remain in that state. The value
power is stated in the millamperes consumed at the voltage supplied by
the power source.The value state shall be further constrained to have the following
semantics:
Semantics of device state valuesValueSemantics100This is the device’s most responsive state.20-99The device is functional. The range represents a range of
performance.11-19Reserved10Device is not operational, but retains its internal
functional parameters.1-9Reserved0Device not functional, may lose internal functional
parameters.
The semantics of device power states may be further defined by
device type specific bindings.The interaction of the defined semantics of device power state and
domain power level is defined in
. Those combinations not marked
are disallowed.
Combinations of Device Power State/Domain Power
LevelDevice Power StateDomain Power LevelFull OnAllowedAllowedAllowedAllowedReducedAllowedAllowedAllowedFreezeAllowedAllowedOffAllowed
“device-state-transitions” [S]Standard
property name that describes the legal power state
transitions supported by the device.prop-encoded-array: an array of integers, each
encoded as with
encode-int that defines the legal power state
transitions for this device.The array is structured as a number of tuples, one for each
possible transition. Each tuple consists of the starting state, followed
by the destination state, followed by an array of tuples
(power-source-id, power), one for each power source, followed by the time
required to make the transition in microseconds, followed by the maximum
count allowed for this transition. The starting state and destination
state are values defined in the
“device-power-states” property. The value
power is stated in the millamperes consumed. This property shall be
provided if platform firmware provides device power state
information.“power-sources” [S]Standard
property name which designates this device as a
consumer of power sourced from a defined power source.prop-encoded-array: an array of integers, each
encoded as with
encode-int that gives the list of power sources to
which this device is connected.The values are indices into the platform-power-sources data
structure. This property shall be provided if platform firmware provides
device power state information.“power-management-mapping” [S]Standard
property name that defines device power states and
commands.prop-encoded-array: an array of integers as encoded
with
encode-int.This optional property provides a device dependent mapping between
device power state and commands which the device driver sends to its
device. Also provides information concerning which device power states
are supported for each of the four domain power levels. See the device
type binding for a definition of the property value.Properties for Power Domain Control PointsThe following are specific to devices which can act as power domain
control points.“controls-power-domains” [S]Standard
property name which designates the domains over which
this device exercises control.prop-encoded-array: an array of integers, each
encoded as with
encode-int that defines the domains for which this
device can act a power domain control point.A single device may serve as multiple logical control
points.Power Management Related MethodsThis section defines methods associated with device tree nodes
which serve as power domain controllers (the architecture calls them
control points).set-power-level (domain# level -- actual-level) [M]This method is only present for power domain controllers. The
domain# is the power domain whose power level is altered, and level is
the desired level. actual-level reports the level to which the domain was
actually set.get-power-level (domain# -- level) [M]This method is only present for power domain controllers. The
domain# is the power domain that is being queried. level is the current
level at which the domain is now operating.system-off (--) [M]Method to turn the system off. This method is attached to the root
node of the device tree and is only present in a platform with software
control over system power.Configuration of Platform ResourcesAny computer platform is composed of standard components which are
invariant (platform ‘built-in’ standard I/O and power
management), optional components which are detectable (a second processor,
for example), and configurable components which are self-identifying
(system memory, for example). Most computer platforms also provide one or
more industry standard I/O buses which allow the insertion of specialized
functional adapter cards. These buses generally support a method for
automatic identification, interrogation, and option selection of installed
adapter cards.A Platform shall
also have the capability of configuring power
management resources, if power management is implemented by the platform,
as defined in
.Power Management Resource ConfigurationFor a platform which supports device power management, all platform
power management related information shall be resident in the OF device
tree prior to the transfer phase of software operation (see the
definition of transfer phase in
). Dummy devices shall be
placed in the device tree for all standard I/O bus connectors which are
not in use to provide a node to assign the slot-names, power-domains, and
power-sources properties.Ultimately, the goal is that pluggable devices would not only
identify themselves to platform firmware but would also provide all
applicable power management related information. As an interim solution,
a utility shall be provided either in the platform firmware ROM or
supplied as a loadable OF utility on external media. This utility
interacts with a person to obtain power management information concerning
plug-in adapters and peripherals.Power Management Information UtilityAny platform capable of being expanded via the addition of
power-managed devices shall provide a device power management information
utility. The purpose of the utility is to allow a person (end-user or
system developer) to enter power management related device properties of
plug-in adapters and peripherals which have no mechanism to automatically
report this information to firmware or system software. The need for this
utility will disappear as standard protocols are developed for
interrogating pluggable adapters and devices to provide power management
related information.In the most general case, the devices to be added to a node
representing a standard bus or I/O port are in the form of multilevel
subtrees. The root of this subtree specifies the path to the node in the
device tree where the subtree is to be grafted.The utility determines the path to the node at which to graft the
new devices by interacting with a person to receive the information. The
utility uses the
“slot-names” property to identify the
location of the device for which it needs information. For example, the
utility might prompt the user with, “Enter the name of the first
device attached to the external scsi connector labeled
‘SCSI1’.”A data structure describing the subtree is stored in NVRAM. The
root node of this subtree contains an
“in-graft-node” property which specifies
the path to the parent node where the subtree is to be grafted into the
OF device tree.As adapters and devices are enhanced to support the automatic
reporting of power management information the parent node would supply a
method query-power-management-attributes which can be used by firmware to
obtain this information without the need for this utility. Any
information obtained by direct device interrogation may update that
supplied via the PM NVRAM partition.PM Configuration ProcessWhen the platform is booted after a configuration change and the
newly inserted adapter does not support the automatic reporting of power
management information, firmware should prompt the user asking if he
wishes to supply this information or potentially forfeit some or all of
the power management capabilities of the device.The utility records the information it obtains in the NVRAM Power
Management Configuration Partition (NVRAM Signature of 0x71 and name
pm-config). On a subsequent reboot, platform
firmware uses the information saved in NVRAM to fill out the device tree
adding new nodes and their properties, as well as adding properties and
updating the values of properties of existing device tree nodes.PM Configuration FormatThe NVRAM power management configuration partition is designed to
be accessed primarily by firmware, but the partition is designated global
and the format is specified to allow a third party to write a power
management information utility which runs on the booted OS.The data field of the power management NVRAM partition shall be
defined as follows:The data field is composed of a header, followed by a number of
fixed length data blocks, and finally a variable length property list
area. The length of the header and each data block is 8 bytes. The data
blocks use 16-bit integer offsets into the partition as pointers to the
data blocks and into the property list area. The base of this offset is
the beginning of the partition. This effectively limits the size of the
PM configuration area to 64 KB. If more space is required, additional PM
configuration partitions may be provided. Each pointer into the property
list area locates the start of a NULL-terminated string which represents
a list of property name/value pairs.The following table specifies the format of the header:
Power Management Configuration Data HeaderFieldSizeDescriptionVersion1 byteDesignates the version of the PM Partition data area
formatSubtree_ptr2 bytesPointer to the first data block which describes a device
subtreeProperty_ptr2 bytesPointer to first data block which describes a property
list to be added to the base platform device treeReserved3 bytesReserved
The PM Partition data area format value shall be 1.The following table specifies the format of the data blocks:
Data Block FormatFieldSizeDescriptionBlock_type1 byteDesignates the data block typeData Block Data7 bytesRemainder of data block, format specific to data block
type
Two data blocks are defined: one defining a device node and a
second defining properties to be added to the base platform device
tree.The data block type field shall have the value 1 for a data block
which describes a device node. The data block type field shall have a
value 2 for a data block which describes a property.
Node Data Block FormatFieldSizeDescriptionBlock_type1 byteThis field shall contain the value 0x01Prop_list_ptr2 bytesPointer to a NULL terminated string containing the
property list for this nodeChild_ptr2 bytesPointer to a data block defining a child node of this
node. This pointer will be equal to 0x0000 if this node has no
children.Sibling_ptr2 bytesPointer to a data block defining a sibling node of this
node. This pointer will be equal to 0x0000 if this node has no
siblings.Reserved1 byteReserved
Property Data Block FormatFieldSizeDescriptionBlock_type1 byteThis field shall contain the value 0x02Node_path2 bytesPointer to a NULL terminated string giving the path name
of the node to which the designated property list
belongs.Property_list_ptr2 bytesPointer to a NULL terminated string containing the
property list to be assigned to the designated node.Reserved3 byteReserved
The first node of a subtree shall have a
“name” property equal to “/”
and shall specify the
“in-graft-node” property. The child_ptr
of this data block points to the first in a list of data blocks which
describe the nodes which make up the subtree to be grafted onto the
system tree.The final area of the partition is a set of NULL terminated strings
which represent property name/value pair lists. The last string in this
area will be terminated by at least two NULL bytes. The property list for
each node shall provide all the required PM properties and their values.
These include
“power-domains”,
“device-power-states”,
“device-state-transitions”,
“power-sources”,
“power-management-mapping”, and
“controls-power-domains”.Client Program RequirementsFor LoPAR platforms, the client program requirements are defined in
, with the following
modifications. OF Client Programs for an LoPAR platform shall execute in
32-bit mode with an OF cell size of 1.Load AddressThe 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, within the first LMB, 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.Note: The load-base address represents the area into
which the client program will be read by load and does not correspond to
the address at which the program will be executed.Initial Register ValuesThe “Initial Register Values” specified in the PA
Binding (see
) are modified as
follows:r3 -- shall be 0 on client program entryr4 -- shall be 0 on client program entryI/O Devices StateWith the exception of the stdin and stdout devices, OF shall close
all devices with the following conditions true:All Devices - no DMA and not interruptingNormal I/O Devices - not responding to access PCI
Adapter/DevicesHOST Bridges - responding to config cycles and passing through
config cycles to childrenRTAS Devices - contract with OF to leave in state to perform
intended functionClient Program FormatThe data format of a client program compliant with this
specification shall be either ELF (Executable and Linkage Format) as
defined by
, and extended by
, or PE (Portable Executable)
as defined by
. The standard ELF format
contains explicit indication as to the program's execution modes (e.g.,
32- or 64-bit, Big- or Little-Endian). LoPAR only supports the 32-bit
version (i.e., ELFCLASS32) for 32 and 64 bit platforms.Note: Other client program formats may be supported,
in an implementation specific manner, by an OF implementation.A standard client program shall be statically linked, requiring no
relocation of the image. The program's entry point (e_entry) shall
contain the address of the first PA instruction of the client program. It
is the responsibility of the client program to establish the appropriate
value of the TOC (r2), if necessary.Note: The entry point is the address of the first
instruction of the client program, not that of a procedure
descriptor.ELF-FormatThis section defines how OF recognizes and prepares to execute an
ELF-Format Program.ELF Note SectionPart of the process of loading a client program involves verifying
its environmental requirements (e.g., endian-ness and address translation
mode) against the current firmware configuration. The client’s
endian-ness can be directly determined by examining the ELF EI-DATA
value; ELFDATA2LSB (1) implies Little-Endian while ELFDATA2MSB (2)
implies Big-Endian. However, the other client requirements (e.g., address
translation mode) are defined by means of an ELF Note Section (PT_NOTE),
pointed to by the program header. The following describes the format of
the Note Section for a client program file.As defined by
, an ELF file can be
“annotated” by means of Note Sections within the executable
file. A Note Section contains a “header” followed by a
(possibly NULL) “descriptor”, as follows:Note: The endian format of the values corresponds to
the endian-ness specified by the EI-DATA field of the file.The format of a Note Section header can be described by an OF
struct as:1275 PowerPC Note DefinitionThe ns.name field of the PowerPC OF Note Section shall be
“PowerPC”; the ns.type field n shall be
0x1275.Following the Note Section header is a descriptor (desc); the
length (in bytes) of the descriptor is specified by a word in the Note
Section’s header (descsz). The interpretation of the descriptor
depends upon the kind of Note Section in which it is contained. For the
PowerPC OF note, the format of the Note Section’s descriptor can be
described by an OF struct, as follows:
/L field ns.real-mode
/L field ns.real-base
/L field ns.real-size
/L field ns.virt-base
/L field ns.virt-size
/L field ns.load-base]]>If the
ns.load-base value is not -1, then that value is
compared against the current value of the
load-base configuration variable. If they are equal
no further action is taken. If they are not equal then the
load-base configuration variable is set to the value
of
ns.load-base and the system is rebooted.Note: DATA field of the file.1275 IBM,RPA-Client-Config Note DefinitionThe ns.name field of the LoPAR Client Program Configuration Note
Section shall be
“IBM,RPA-Client-Config”; the ns.type
field shall be 0x12759999.The format and requirements associated with this ELF Note Section
are designed to allow for expandability of the section definition (by
adding fields to the end of the section) while retaining forward and
backward compatibility for both the 1275 firmware and Client Program.
When the 1275 firmware code recognizes the
“IBM,RPA-Client-Config” note, it creates
a property named
“ibm,rpa-client-config” within the
/chosen node reads into this property and interprets
the lesser of the descriptor size or the maximum size of the descriptor
that was defined when the firmware was built. Should the note contain a
smaller descriptor than was defined when the firmware was built, the
firmware assumes default values for the missing descriptor fields. In
this way, new fields may be defined, and the four cases of
firmware/client program work as follows:New Firmware/New Client Program:Client Program Header Note contains old plus new fields.Firmware reads all the new header and places it in
“ibm,rpa-client-config” property.Client Program gets feed back that new fields were interpreted by
reading property in
/chosen.Old Firmware/Old Client Program:Client Program Header Note contains old fields.Firmware reads all the old definition header and places it in
“ibm,rpa-client-config” property.Client Program gets feed back that the expected fields were
interpreted by reading property in
/chosen.New Firmware/Old Client Program:Client Program Header Note contains only old fields.Firmware reads only the descriptor length defined in the note
header, and places it in
“ibm,rpa-client-config” property.Client Program gets feed back on the fields that were interpreted
by reading property in
/chosen.Firmware uses default values for any missing fields.Old Firmware/New Client Program:Client Program Header Note contains old plus new fields.Firmware reads only the length that it was defined when it was
built, and places it in
“ibm,rpa-client-config” property.Client Program gets feed back that new fields were interpreted by
reading property in
/chosen, those missing fields indicate function not
implemented by the platform.Following the Note Section header is a descriptor (desc); the
length (in bytes) of the descriptor is specified by a word in the Note
Section’s header (descsz). The interpretation of the descriptor
depends upon the kind of Note Section in which it is contained. For the
ELF header note named IBM,RPA-Client-Config of type 1275, the format of
the Note Section’s descriptor can be described by an OF struct, as
follows:Note: The size of the /L field is based off of
e_ident (EI_CLASS) i.e. is 4 for ELFCLASS32.The
ns.lparaffinity field is a binary flag whose valid
values are 0 or 1. If the field is not one of these valid values the
value is assumed to be 0. If the character value is 1, the client program
requests that the platform provide all available affinity
information.The
ns.min-rmo field specifies the minimum amount of real
mode addressable storage (in bytes times 2
20) that the client program needs to operate. The
ns.min-rmo-percent field specifies the minimum
percentage (valid values 0-100) of storage that must be real mode
addressable for the client program to operate. The platform shall start
the client program with a quantity of real mode accessible storage
(starting at location 0) of at least the ceiling of these two
values.The
ns.max-pft-size field value specifies the largest
hardware Page Frame Table (in bytes times2
ns.max-pft-size) that the client program can
support. The firmware shall not start a client program with a PFT larger
than this amount The minimum value is 18, the platform ignores the field
if the value is less than 18 and uses the platform defined default
value.The
ns.splpar field is a binary flag whose valid values
are 0 or 1. If the field is not one of these valid values the value is
assumed to be 0. If the field’s value is 1, the client program
supports running in shared processor logical partitioning mode. If the
character value is not 1 and the partition is running in shared processor
mode, platform firmware reports a platform-specific error code and halts
the boot. However, if the client-program does not contain an
IBM,RPA-Client-Config
note, firmware assumes the OS supports shared
processor logical partition mode. This exception only applies to the
ns.slpar field.The
ns.min-load field specifies the minimum amount of the
client program load module that must be loaded at
load-base. If this value is a -1 then the entire
load module must be loaded starting at
load-base else the client program load fails. The
default value is assumed to be -1. If the value of is greater than the
platform can support client program load fails. Given that the platform
can load the minimum amount of the client program load module at
load-base, it loads the amount up to the boundary
specified by
ns.min-load starting at
load-base, then it loads the rest of the load module
into contiguous storage at a location selected by platform firmware
(default, if possible, is that the residual is loaded immediately
following the first segment resulting in a single segment load).The
ns.new-mem-def field is a flag which indicates if the
ibm,dynamic-reconfiguration-memory representation of reconfigurable
memory may be used. The default value 0x00000000 indicates the new
definition may not be used. The value 0x00000001 indicates the new
definition may be used. The value 0x00000001 indicates the original version of the new definition may be used.
The value 0x00000002 indicates the version 2 of the new definition may be used.
All other values are reserved for future use.The
ns.large-page-ready field is a flag which indicates
if the partition OS is prepared to support large pages. The default value
0x00000000 indicates that the OS is not prepared for large pages. The
value 0x00000001 indicates that the OS is prepared for large pages. All
other values are reserved for future use.If this variable indicates that the OS is not prepared for large
pages and large pages are present in the partition configuration,
platform firmware reports a platform-specific error code which indicates
this mismatch between the partition configuration and the OS
capabilities, removes all large pages from the device tree, and continues
the OS boot.If the value of the
ns.ignore-my-client-config variable is 0x00000001,
platform firmware must not examine the value of
ns.large-page-ready until the client program calls
the PROCESS-ELF-HEADER method. The decision to continue boot should then
be made based on the value of the
ns.large-page-ready flag in the updated ELF head
passed by this method.The
ns.force_alpha_mode field is a flag which indicates
that a non-HMC managed I/O services partition with partition management
support (VMC) configuration is being requested. The default value of
0x00000000 indicates that the client expects to run in a configuration
which is not an I/O services partition configuration. If the partition
configuration is not compatible with this setting, the system will be
rebooted as a single partition which owns all of the system resources. On
reboot, the original partition configuration will be reinstated. The
value 0x0000001 indicates that the client is expecting to be executed in
a non-HMC managed I/O services partition with partition management
support (VMC). If the partition is not in this mode, the system will be
rebooted in this mode. In the case that the ns.force_alpha_mode flag is
compatible with the partition configuration, the boot process will
continue. This flag will be ignored when the system is HMC
managed.Recognizing ELF-Format ProgramsThe
init-program shall recognize client program images
that conform to all the requirements listed below as
“ELF-format” programs.In the description below, field names refer to fields within the
ELF “file header” structure, which is assumed to begin at
load-base, and offsets are relative to the beginning of that structure.
Multi-byte numerical fields are interpreted according to the endianess
specified by the “data” field at offset 5.The “e_ident” field (at offset 0) contains the
string “\7fELF”, where '\7f'’ is a byte whose value is
(hex) 7f. This indicates the beginning of an ELF file header.The “EI_CLASS” field (at offset 4) contains the
value 1. This indicates the 32-bit variant of the ELF format.The “e-type” field (at offset 16) contains the
value 2. This indicates that the ELF image is executable.The “e_machine” field (at offset 18) contains the
value 20. This indicates that the ELF image is for the PA instruction
set.The “e_version” field (at offset 20) contains the
value 1.The “e_flags” field (at offset 36) contains the
value 0.Preparing ELF-Format Programs for ExecutionUpon recognition of the client program image at load-base as an
ELF-format program, init-program shall prepare the program for execution
by performing the following sequence of steps.In the description below, the fields mentioned by name are within
ELF “program header” structures, unless specified
otherwise.Search for an ELF “note” section of type
“1275” as defined in the section “ELF Note
Section”. If one is found, and the values specified by its
descriptor do not match the firmware's current operating mode, set the
appropriate configuration variables to the values specified in the note
section descriptor, and restart the firmware so that it will re-execute
the
boot command that resulted in the execution of
init-program.Set the p_paddr field for each PT_LOAD segment equal to its
p_vaddr field value if
real-mode? is false and p_paddr is -1. This
effectively maps these segments v=r.Allocate and map, if required, sufficient physical memory for
all program segments of type PT_LOAD (i.e. whose “p_type”
field contains the value 1) listed in the ELF image's program headers.
Note that all PT_LOAD program segments that have a p_paddr value that
matches their location in physical memory need not be moved, but the
memory that they occupy must be claimed. This special case is added to
allow large program images to be loaded without the 2x memory required to
move the segments.Copy the program headers to a “safe” location to
guard against the possibility of them being overwritten by the following
steps.For each program segment of type “PT_LOAD”:Copy, if required, the initialized portion of the program
segment from its current location in the loaded image to the location
given by the section's “p_paddr” field.Fill the rest of the segment with zero bytes (i.e., fill
“p_memsz - p_filez” bytes beginning at the address
“p_paddr + p_filesz”).If real-mode? is false, then map the program segment to
the virtual address specified by p_vaddr.Set the saved program state so that subsequent execution of
“go” will begin execution at the address
given by the “e_entry” field in the ELF file header. The
e_entry field is a physical address if
real-mode? is
TRUE and is a virtual address if
real-mode? is
false.The implementation need not take precautions to ensure that the
process of copying and zeroing program segments does not overwrite the
portions of the load image that have not yet been copied. In order to
guarantee correct copying, the value of the
load-base configuration variable and the destination
addresses of the various sections must be such that such overwriting does
not occur. One sufficient condition is that the region of memory
beginning at
load-base, of size equal to the size of the loaded
image, be disjoint from the regions of memory to which the program
segments are copied and zero-filled. Another sufficient condition is to
specify a
load-base in the Notes Section (PT_NOTE) that ensures
that the PT_LOAD segments are loaded at the address required by their
program headers and thus are not moved. There are other less-stringent
sufficient conditions, especially for simple ELF images with a small
number of program segments that are to be copied to contiguous
regions.An implementation shall permit the ELF image to contain other
program segments in addition to those described above, but need not take
any action beyond that defined above as a result of the presence of such
other program segments.An implementation shall ignore all ELF sections. ELF sections are
intended for binders, not loaders. Note that the CHRP ELF Note Section is
actual an ELF segment of type PT_NOTE and thus the above does not apply
to it.Additional Client Interface RequirementsThis section describes processor assist callbacks for real and
virtual memory management and a service.Client Interface CallbacksThis section describes callbacks for memory management. These
callbacks are provided by the client.Real-Mode Memory Management Assist Callbacksclaim_memIN: [address] min_addr, [address] max_addr, size, alignOUT: throw-code, error, [address] real_addrAllocate contiguous physical memory between min_addr and max_addr
of size bytes (128KB max for an area in the 0 to 16MB address range),
with align alignment. The alignment boundary is the smallest power of two
greater than or equal to the value of align; an align value of 1
signifies one-byte alignment. A non-zero error code shall be returned if
the mapping cannot be performed. If error code is zero (i.e. allocation
succeeded) the routine returns the real address (real_addr) of the
physical memory block which was allocated for OF.release_memIN: [address] phys, sizeOUT: throw-codeFree size bytes of physical memory starting at real address phys,
making that physical memory available for later use. That memory must
have been previously allocated by claim_mem.Virtual Address Translation Assist Callbacksalloc_virt_memIN: sizeOUT: throw-code, error, [address] virt_addrReturn the virtual address of a virtual memory area of size bytes
aligned to a doubleword (8-byte) boundary. A non-zero error code shall be
returned if the allocation cannot be performed. If error code is zero
(i.e. allocation succeeded) the routine returns the virtual address
(virt_addr) of the memory block which was allocated.free_virt_memIN: [address] virt_addr, sizeOUT: throw-codeFree memory allocated by alloc_virt_mem. The values virt_addr and
size must correspond with memory previously allocated by
alloc_virt_mem.claim_virtIN: size, alignOUT: throw-code, error, [address] virt_addrAllocate a memory area of size bytes and alignment align. The
alignment boundary is the smallest power of two greater than or equal to
the value of align; an align value of 1 signifies one-byte alignment. A
non-zero error code shall be returned if the allocation cannot be
performed. If error code is zero (i.e. allocation succeeded) the routine
returns the virtual address (virt_addr) of the memory block which was
allocated.release_virtIN: [address] virt, sizeOUT: throw-codeFree size bytes of virtual memory starting at virtual address virt,
making that physical memory and the corresponding ranges of virtual
address space available for later use. That memory must have been
previously allocated by claim_virt.Client Interface ServicesOF shall provide the following
Client Interface Service:test-methodIN: phandle, [string] methodOUT: missing-flag?Tests whether the package method named method exists in the package
phandle. missing-flag? is FALSE (0) if the method exists or TRUE (-1) if
the method does not exist.OF may provide the following Client Interface Service:ibm,enable-ci64IN: noneOUT: noneAfter the successful invocation of this method, all Client
Interface calls will utilize 64 bit cell items in their argument arrays.
This does not affect how the device tree is presented, which will still
assume that a cell is 32 bit in the property values. The method returns
using the cell size in which it was called. This method exists only on
platforms that present the
“ibm,enable-ci64-capable” property in the
root node.Support PackagesThis section describes the LoPAR Binding specific requirements of OF
support packages. These support packages are
disk-label and
tape-label. For “network” and/or
obp-tftp extensions, refer to
. These packages support the
loading and executing of a client program. Another means of executing a
Client Program is provided when an OS ROM is a “bootable
device” (Refer to
, as an example).“disk-label” Support PackageThe process of loading and executing a client program is described
in two stages. The first stage determines what partition and/or file (if
one exists) to read into memory. This is done by locating a partition and
a file within the partition (if the partition supports a file system
structure) from the boot device, usually by means of a name lookup within
a directory contained within a disk “partition”. The second
stage examines the front portion (header) of the image for
“well-known” program formats. When the format of the image
has been determined, the loading is completed in a manner determined by
that format.The name of the partition (and, a file contained within the
partition) can be explicitly specified by the user via the
load or
boot command, or can be implicitly specified by the
value of the
“boot-device”
property of the
/options node. The partition and filename are the
ARGUMENTS portion of the final COMPONENT of the PATH_NAME, as described
in section 4.3.1 of
.The syntax for explicit partition/filename specification is given
in section
below where partition
identifies the partition to be used and filename is the name of a file
within that partition. If partition is omitted, the default partition (as
determined by the partition format) is used. If filename is omitted, the
default filename (i.e., the filename component of the
boot-device path-name) is used.Media Layout FormatThis section describes the media layout formats of Client Program
Images that the disk-label support package for an LoPAR platform shall
support; an implementation
may support additional mechanisms, in an
implementation-specific manner. The
disk-label package for a platform shall
support at least four(4) media layout types:FAT (FAT12 and FAT16 File System)FDISK (Partitions 4, 5, 6, 0x41 and 0x96)ISO-9660 (9660 File System)UDFAn LoPAR platform may choose to support the following media layout
formats for historic reasons:Mac OS (MAC Binary Image)FDISK Partition TypesThe following FDISK partition types shall be supported:Partition Type 4: FAT 12 or FAT 16 File SystemPartition Type 5: Extended Chained PartitionsPartition Type 6: Extended PartitionsPartition Type 0x41: Single program imagePartition Type 0x96: ISO 9660 File SystemPartition Type 0x??: UDF File SystemFDISK partition type 0 is a free partition. Partition type 0x82 is
reserved and should not be used by this architecture.Open Method AlgorithmThe
open method of the
disk-label support package shall implement a disk
partition recognition algorithm that supports at least the set of disk
formats that are supported by the following algorithm. The following
algorithm is intended to support raw (uninterpreted) disks, raw
partitions of disks beginning with an FDISK partition map, and files on
FAT, UDF and ISO-9660 file systems both within FDISK partitions and by
themselves on disks without a partition map.That
open method shall accept an argument string (as
returned by
“my-args”) with the following syntax
(according to the algorithm below), where brackets denote an optional
component:[partition][,[filename]]If the argument string contains a comma, or if the argument string
begins with a decimal digit, the partition component is deemed to be
present. Note that the arguments above are not the client arguments with
the boot command.If the partition component is present, it selects the desired
partition, where partition 0 refers to the entire disk, partition 1
refers to the first partition, partition 2 to the second, and so forth.
If the partition component is absent and the disk has an FDISK or Mac
partition map, the first “bootable” partition is used. If a
“bootable” partition is not found, then fail in an
implementation specific manner with an error.If the filename component is present, it selects a particular file
within the file system on the disk or partition thereof.Note: For historic reasons, the following algorithm
includes support for the optional MAC OS media layout format.
PARTITION$, FILENAME$
2 Else
3 Set PARTITION$ to the NULL string
3 Set FILENAME$ to ARGUMENT$
2 If PARTITION$ is not the NULL string
3 If PARTITION$ is not a decimal number
4 Return FALSE
3 DECIMAL_STRING_TO_NUMBER (PARTITION$) -> PARTITION
3 If PARTITION is 0
4 GET_DISK_SIZE
3 Else
4 Read the first 512 bytes of the device into a buffer
4 SELECT_EXPLICIT_PARTITION (PARTITION)
4 If SELECT_EXPLICIT_PARTITION returned an error indication
5 Return FALSE
2 Else \ PARTITION$ is NULL
3 Read the first 512 bytes of the device into a buffer
3 SELECT_ACTIVE_PARTITION
3 If SELECT_ACTIVE_PARTITION returned an error indication
4 Return FALSE
2 \ (At this point, D.OFFSET is set to the beginning of the selected
partition and D.SIZE is set to the size of that partition. If the
entire disk was selected, D.OFFSET is 0 and D.SIZE is the size of the disk.)
2 Call parent’s “seek” method with an argument of 0,0.
2 Return TRUE
1 CHECK_FOR_BPB procedure
2 If the first four(4) bytes are EBCDIC 'IBMA'(hex character string
C9C2D4C1), then the sector does not contain a BPB.
2 If the 16-bit little-endian quantity beginning at buffer offset 510
is 0xAA55, and the 16-bit little-endian quantity beginning at buffer
offset 11 (which is the BPB “bytes per sector” field) is either 256,
512, or 1024, and the byte at offset 16 (the BPB “number of FATs” field
is either 1 or 2, the sector is deemed to contain a BPB. Otherwise, the
sector does not contain a BPB.
1 CHECK_FOR_ISO_9660 procedure
2 Read 512-byte sector 64 (the beginning of logical 2048-byte sector 16)into
a buffer.
2 If the byte at offset 0 contains the binary number “1”, and the 5 bytes
beginning at offset 1 contains the text string “CD001”, the partition
or raw disk is deemed to contain an ISO 9660 file system. Otherwise,
the partition or raw disk is deemed not to contain an ISO 9660 file system.
1 CHECK_FOR_FDISK procedure
2 If the buffer does not contain an FDisk partition map signature of “AA55”
as a 16-bit little-endian number beginning at buffer offset 510, the buffer
is deemed not to contain an FDISK partition map.
2 If none of the partition type code field (the bytes at buffer offsets 0x1C2,
0x1D2, 0x1E2, and 0x1F2) contains a recognizable partition type code (4,5,
6, 0x41, 0x96, or other types that may be recognized by the implementation),
the buffer is deemed not to contain an FDISK partition map.
2 Otherwise, the buffer is deemed to contain an FDISK partition map.
2 The implementation may, at its option, apply additional validity tests to
the partition map information.
1 CHECK_FOR_MAC_DISK procedure
2 If the first (i.e., at the lowest offset) two bytes in the buffer contains
the 16-bit big-endian signature 0x4552, then the disk is deemed to be a Mac
partitioned disk. Otherwise, the partition or raw disk is deemed not to be
a Mac partitioned disk.]]>Note: Subsequent 512 byte sectors will contain Mac
partition map entries, each of which begins with the 16-bit big-endian
signature 0x504D. Each such partition map entry contains a field (V)
indicating the total number of partition entries in the map. 1
4 Return ERROR
2 CHECK_FOR_FDISK
2 If an FDisk partition map is found
3 Search the FDisk partition map beginning in 512-byte sector 0, reading new
512-byte sectors into the buffer if necessary to “chain” to extended
partition entries, for the Nth, where N is the value of PARTITION, partition
entry whose “type” byte is neither 0 nor 5 (5 is the type code that
indicates a “chained” extended partition entry).
3 If the Nth partition is found:
4 Set PARTITION-TYPE to that entry's “type” field (the byte at offset 4)
4 Set D.OFFSET to the byte offset from the beginning of the disk to the
beginning of the partition denoted by that entry.
4 Set D.SIZE to the size of the partition in bytes denoted by that entry.
4 INTERPOSE_BY_TYPE
4 Return OKAY
3 Else \Nth partition does not exist
4 Return ERROR
2 CHECK_FOR_MAC_DISK
2 If this is a Mac partitioned disk
3 Search the Mac partition map for the Nth partition, where N is the value of
PARTITION.
3 If the Nth partition is valid, allocated, and readable
4 If FILENAME$ is %BOOT
5 If the Nth partition is marked bootable
6 Set D.OFFSET to the byte offset from the beginning of the disk
to the beginning of the boot area, as given by the pmLgBootStart
field.
6 Set D.SIZE to the size of the partition in bytes denoted by
pmBootSize.
6 Return OKAY
5 Else \Nth partition not “bootable”
6 Return ERROR
4 Else
5 If FILENAME$ is not the NULL string
6 INTERPOSE_BY_TYPE
5 Return OKAY
3 Else \ (If this point is reached, the partition is invalid)
4 Return ERROR
2 Else \ (If this point is reached, the partition map is not recognized)
3 Return ERROR]]>This algorithm can be used to locate the correct partition and/or
file and/or load image from the specified device. The boot device is
selected as described in 7.4.3.2 of
. A filename can be explicitly
given as the arguments field of the
device-specifier (i.e., the field following the ':'
of the last path component). Other formats
may be recognized in an implementation-specific
manner.tape-label Support PackageThe
tape-label Support Package shall
support tape as a standard byte device with the set
of methods specified in
, Section 3.7.3. Presence of
the bootinfo.txt file is optional.The
open method shall accept an argument string, where
brackets denote an optional component:[file number]where the first file on the tape media is located at file number
0.Tape FormatThe LoPAR tape format shall consist of files ending with a file
mark (FM). The first block of data will be identified as file 0. The
bootinfo.txt file, if present, shall be located on the tape as file 0
(the first file). There shall be only one bootinfo.txt file on the tape
media. Refer to
for the LoPAR Tape
format.Tape bootinfo.txt FileThe bootinfo.txt file shall have included for each set
of <chrp-boot> tags a set of <boot-script> tags that contains
a pointer to the program image to be loaded (Refer to
). The form for this tape
pointer will be:device specifier = device:file numberEXAMPLE: device specifier = tape:2 (For the specified set of
<chrp-boot> tags, load the tape program image from file 2).A bootinfo.txt file may contain a multiple set of <chrp-boot>
tags where each one can point to a different tape file number. If a
bootinfo.txt file is not present, file 0 should be a bootable file. Only
file 0 will be loaded as a bootable image. No other files will be
searched if a bootinfo.txt file is not present unless the file number to
load is specified by an argument.network Support PackageThe
network Support Package shall adhere to the
documentation functions and
conventions.Program-image formats.OF must recognize a client program that is formatted as ELF, as
defined in
, and PE, as defined in
. Other formats
may be handled in an implementation-specific manner.
defines the FCode and Forth
Program-Image Formats.After locating the file, OF reads the image into memory at the
location specified by the load-base Configuration Variable. Then, OF must
perform the following procedure to prepare the image for
execution.”)
setup system to evaluate Forth Source Image
else if the image is a bootinfo.txt file (i.e., begins with “”)
setup system to parse the bootinfo.txt file
else
FAIL, in an implementation-specific manner.]]>Notes: The following comments apply to the above code:For more information on detecting an ELF format, refer to
.For more information on relocating an ELF image, refer to
.