Version 1.8 Date : 05/05/2009 Revision History : 1.0 Approved by FWARC/2006/700. 1.1 Added memory segment nodes and updates to component node. Added section numbers to the entire document 1.2 Added 'core' as an acceptable value to the component type property. Added 'pm-version' property to the components node. Added properties to the component node to describe Power Management characteristics. 1.3 Added 'topo-skip' and 'topo-hc-name' properties to the components node Extended 'id', 'nac', 'serial_number', 'part_number', 'rev_number', and 'dash_number' to be required for component types that are FRUs Added 'cfg-handle' property to node components where "topo-hc-name=pciexrc" Added section on IO Device node 1.4 Change to suggested topologies for use with FMA PI. 1.5 Added 'pri-version' property to the root node (FWARC/2008/768) 1.6 Added root-port node and minor typo corrections (FWARC/2008/761) 1.7 Added 'path' property as a requirement to node components where "topo-hc-name=pciexrc" Deprecated 'cfg-handle' property to node components where "topo-hc-name=pciexrc" Corrected a few minor typos. 1.8 Added additional constraints on the 'id' property in the root complex component node, clarified the definition of root complex vs. root port component nodes, and removed incorrect wording in the description of the 'cfg-handle' and 'path' properties in the 'iodevice' node. Physical Resource Inventory (PRI) Specification =============================================== 1.0 Introduction This is the specification for the Physical Resource Inventory (PRI). The PRI is intended to contain physical information about a system. Much of this information had previously been contained in the Machine Description (MD) provided to the guest. With the advent of Logical Domains (LDoms), it becomes essential to have a clean separation between the physical and virtual views of a system. To achieve this, much of the physical information is no longer part of the MD within a guest domain. This provides a strictly virtual view of the system within an LDom. However, besides the System Controller (SC), other management entities (e.g. FMA, the LDom Manager) still require a physical view of the system. This is now provided by the PRI. The PRI includes the physical information which is no longer available in the MD (needed by FMA to perform diagnosis). It also includes additional information necessary for the LDom Manager to configure and manage individual logical domains, including acting as a template for the LDom Manager to construct MDs for the various logical domains it is managing. The PRI is provided by the System Controller (SC) to the domain. The PRI contains physical information about system resources in a format identical to that used by the guest MD. The names for the nodes and properties used to access that information are defined to be platform independent, as are many of the values. Some of the values may be platform-dependent and may require additional documentation to parse them. The PRI may be updated at anytime on the SC depending on the state of its resources. Protocols and transports may be agreed upon with the domain for delivering the PRI to it so that it may use the information for activities such as configuring LDOM guest domains or diagnosing error data. One of the primary consumers of the PRI on the domain is the LDOM Manager. It uses the PRI to generate guest MDs by extracting information from it that serves as a template for new domains. The PRI may contain any of the nodes and properties that may be found in a guest MD on a system. For this reason, this case imports all past and future cases that specify new nodes or properties for the guest MD that may be used on a system. Since future cases cannot be explicitly imported, any new cases that arise should specify that they apply to both the guest MD and the PRI. In addition to containing the information needed by the LDOM Manager for creating guest MDs, the PRI also supplies the information it needs to generate the hypervisor data needed to boot a set of configured guest domains. This hypervisor data may include information about either the SC or other firmware components that it needs to know about. Some items in this specification in this category include the LDC endpoints and host prom information. Another of the primary consumers of the PRI are FMA modules such as diagnosis engines. There is a requirement to provide additional information in the PRI so that FMA may make diagnoses and act on them through fault, repair or logging actions. To enable this, the PRI contains system-wide information that may not be available in the guest MD in the domain on which FMA modules are running. As an example, FMA modules running in the control domain (the single domain running the LDOM Manager) may handle ereports generated for resources owned by other guest domains in the system. It may access the PRI to get information it needs to diagnose and act on data in the ereports. For more background, see the FWARC case 2006/141 FMA Domain Services. In addition to the requirements spelled out in the FMA Domain Services case, there is a requirement to add additional information to the PRI so that FMA may generate reports with more specific details about components that have been diagnosed faulty. Some of this information is available in a FRUID present on the component or on another component that is proxying the information. It is the responsibility of the SC to derive this information for components present on a system and to populate the relevant property values in the PRI. The PRI also represents how components are contained within other components in a hierarchical fashion in the system. Each component can be identified as a FRU or not based on a property. The parent component that contains each component can also be found by following an arc property back to it. Based on this, for any component in a system, its closest parent component that is a FRU can be found so that it may be replaced if faulty. There should be only one parent component for each component, but a component may have multiple children components if they are all physically contained by it. The idea of a component physically containing another component is meant to indicate how they may be removed or replaced and is determined on a platform-specific basis. FMA also uses the hierarchy of the components node to build the FM topology in Solaris. The hierarchy encoded into the PRI directly translates to the resulting topology in Solaris. In addition to hierarchy, new properties have been added to guide how topology is enumerated in the OS. 1.1 Root Node Name Category Required subordinates ---- -------- --------------------- root core components Description ----------- This node is the top-most node of the PRI. 1.1.1 PRI version property Name Tag Required ---- --- -------- pri-version PROP_STR yes Description ----------- Version string for the PRI. Format of string is ".", where denotes the decimal major version number and denotes the decimal minor version number. In this context, "major" and "minor" version numbers connote incompatible and compatible changes respectively, as defined in the API versioning interface specified by FWARC/2005/499 and documented in the API versioning chapter of the Hypervisor API Specification. Currently defined version is "1.0". 1.2 Components Node Name Category Required subordinates ---- -------- --------------------- components core component Description ----------- This node is the parent of all component nodes and has a back arc to the root node. 1.2.1 Power Management (PM) versioning property Name Tag Required ---- --- -------- pm-version PROP_STR yes Description ----------- Version string for the content of the Power Management related information in the PRI. Currently defined version is "1.0". 1.3 Component Node Name Category Required subordinates Optional subordinates ---- -------- --------------------- --------------------- component resource component required Description ----------- Represents physical entities in the system in order to provide component information and system topology to the domain. 1.3.1 type Property Name Tag Required ---- --- -------- type PROP_STR yes Description ----------- This property contains the type of the component. Only types that have been submitted with an ARC case should be present. Current acceptable values for the type property include: systemboard A system board. dimm A single memory dimm. processor A physical processor that is logically a single agent on the system interconnect fabric. It may contain several processor cores or strands. strand A physical strand in the processor. mem-board A physical memory board. cpu-board A physical memory board. io An io device such as a switch, bridge, slot or leaf device. core A physical processor core. 1.3.1.1 Type-specific property requirements The following requirements hold for component nodes of these types: For processors that have multiple cores, the fwd property of the processor type node should link to a core type node. For core type nodes, the fwd property should link to a strand type node. If there are multiple component nodes for multiple processors in the system, this can be used to determine which processor a core is on, and which core a strand is on. Any type of node may have an id property. The id property must be unique within a set of nodes with the same topo-hc-name value as well as immutable across system reset events. In addition, for root complex IO nodes (i.e. nodes whose topo-hc-name value is "hostbridge"), the id property is further constrained to have whatever platform-specific binding is required for this value to denote a unique and persistent root complex ID. This property is required for nodes that do *not* set the topo-skip property. Grandfather clause: 'id' is *always* required for strand, mem-board, and cpu-board nodes. Any type of node may have a nac property. nac is required for component nodes that are FRUs (fru property = 0x1) An io type node may have a path property, as described below. Any type of node may set the topo-hc-name property. This property is required for nodes that do *not* set the topo-skip property. Any type of node may set the topo-skip property. Nodes representing a root complex must use a topo-hc-name of "hostbridge" and set the path property. Previous requirements for setting the cfg-handle property for a node representing a root complex is now deprecated. Nodes representing a root port must use a topo-hc-name of "pciexrc". This apparent misnomer is intentional, as it follows the convention established on the x64 platforms. Any type node that is a FRU (fru = 0x1) are required to include the serial_number, part_number, rev_number, and dash_number properties. The components node *must* provide a topo-hc-name hierarchy of hostbridge/ pciexrc. No intervening nodes are allowed. Failure to comply will result in a Solaris-side FM topology that does not support PCIE fabric diagnosis in ON. Node hierarchy above hostbridge is arbitrary per platform. For platforms wishing to employ the sun4v platform independent SPARC cpu diagnosis engine, *one* of the following nodes must be present: processor, core, or strand. One, some or all can be used. The most logical hierarchy is processor/core/strand. For platforms wishing to employ the sun4v platform independent SPARC memory diagnosis engine, the following topo-hc-name hierarchy *must* be provided in the components node: chip/memory-buffer *OR* memory-controller/memory-buffer. No intervening nodes are allowed. Node hierarchy above or below is arbitrary per platform. 1.3.2 nac Property Name Tag Required ---- --- -------- nac PROP_STR yes Description ----------- This property contains the NAC for the component, as described in the system nomenclature document for the system. It may appear in any type of component node. It is only required for nodes that are FRUs (fru = 0x1). 1.3.3 fru Property Name Tag Required ---- --- -------- fru PROP_VAL no Description ----------- This property is present and has a value of 1 if the component is a FRU. 1.3.4 serial_number Property Name Tag Required ---- --- -------- serial_number PROP_STR yes Description ----------- This property contains the component serial number contained in the FRUID. It is only required for nodes that are FRUs (fru = 0x1). 1.3.5 part_number Property Name Tag Required ---- --- -------- part_number PROP_STR yes Description ----------- This property contains the component part number contained in the FRUID. It is only required for nodes that are FRUs (fru = 0x1). 1.3.6 rev_number Property Name Tag Required ---- --- -------- rev_number PROP_STR yes Description ----------- This property contains the component rev number contained in the FRUID. It is only required for nodes that are FRUs (fru = 0x1). 1.3.7 dash_number Property Name Tag Required ---- --- -------- dash_number PROP_STR yes Description ----------- This property contains the component dash number contained in the FRUID. It is only required for nodes that are FRUs (fru = 0x1). 1.3.8 id Property Name Tag Required ---- --- -------- id PROP_VAL yes Description ----------- This property contains the physical id (physical with respect to the system) of a resource in the system. It is required for all nodes, *except* those that set topo-skip to a non-zero value. The id must be unique within a set of nodes with the same topo-hc-name value (i.e. no two nodes where 'topo-hc-name="dimm"' can have the same id, but a node with 'topo-hc-name="dimm"' and a node with 'topo-hc-name="cpu"' can have the same id). 1.3.9 path Property Name Tag Required ---- --- -------- path PROP_STR yes Description ----------- This property contains the canonical path of an io device, composed of its full device path with device names removed. It is required on nodes where the topo-hc-name property is set to "hostbridge" or "pciexrc". It is possible to find the FRU parent of an io device by doing a search beginning with its parent and continuing through its ancestry until reaching a component node with a fru property with value of 1. 1.3.10 label Property Name Tag Required ---- --- -------- label PROP_STR no Description ----------- This property is currently only defined to appear in dimm type component nodes. It will contain the J number that is silk-screened on the board next to the dimm slot. 1.3.11 name Property Name Tag Required ---- --- -------- name PROP_STR no Description ----------- This property is a human readable string describing the component. Examples are "CPU Chip 0", "CPU Chip 0 Core 0", and "Strand 1". 1.3.12 pm_resource Property Name Tag Required ---- --- -------- pm_resource PROP_STR no Description ----------- This property indicates the type of resource that will stop carrying load if the resource has been transitioned to a state that yields zero performance. Possible values are : "MEMORY", "CPU", "IO", etc. It is consumed by the PM Engine. 1.3.13 pm_states Property Name Tag Required ---- --- -------- pm_states PROP_DATA no Description ----------- This property encodes multiple string tuples. Within each tuple are two elements; the first element describes the performance value at the power state which is described by the second element. Performance values are in units of 0.1%. Examples are, For "strand" type node, pm_states = { "0 Parked", "1000 Unparked" }; For "core" type node, pm_states = { "0 Disabled", "1000 Enabled" }; For "processor" type node, pm_states = { "125 One-Eighth_Speed", "250 One-Fourth_Speed", "375 Three-Eighths_Speed", "500 Half_Speed", "625 Five-Eighths_Speed", "750 Three-Fourths_Speed", "875 Seven-Eighths_Speed", "1000 Full_Speed" }; 1.3.14 pm_cookie Property Name Tag Required ---- --- -------- pm_cookie PROP_STR no Description ----------- This property encodes a string. The string is a resource identifier that is consumed by the PM Engine. Each string consists of a space-delineated set of tokens, which taken together describe an instance of a particular resource type. For pm-version 1.0, each string is a tuple describing a resource type and a type-specific identifier. Examples are "F 0", "C 3", and "S 12". 1.3.15 pm_dependency Property Name Tag Required ---- --- -------- pm_dependency PROP_STR no Description ----------- This property describes the power dependencies between the component and it's children. It is consumed by the PM Engine. Example is "StrictParental Performance". 1.3.16 pm_coordination Property Name Tag Required ---- --- -------- pm_coordination PROP_STR no Description ----------- This property describes the power dependencies between the component and it's peers. It is consumed by the PM Engine. Example is "NeedOne Defragment". 1.3.17 pm_mapping Property Name Tag Required ---- --- -------- pm_mapping PROP_STR no Description ----------- This property describes the mapping from the component to the identity in the LDom manager's namespace of the resource upon which a reconfiguration operation may be required prior to transitioning the component to zero performance state, or after transitioning the component out of zero performance state. Example is "cpu 7", which means : 1. cpu known to the LDom manager as (physical) cpu 7 2. when the PM Engine sets the component into or out of the zero performance state, reconfiguration can be effected by asking the LDom manager to reconfigure "cpu 7" prior to or after the power state transition. 1.3.18 topo-hc-name Property Name Tag Required ---- --- -------- topo-hc-name PROP_STR yes Description ----------- This property contains the FM libtopo hc canonical name string for a node. It is used by Solaris enumerators when instantiating a topology. It is required for all nodes *except* if those that set topo-skip to a non-zero value. The value of topo-hc-name must be an approved name per FMA's hc scheme. 1.3.19 topo-skip Name Tag Required ---- --- -------- topo-skip PROP_VAL no Description ----------- When this property is present and has a non-zero integer value, the sun4v platform independent enumerator will *not* create FM topology nodes for this node or any of it's children. This property can be used on any type of node. 1.4 Firmware Node Name Category Required subordinates Optional subordinates ---- -------- --------------------- --------------------- firmware core read_only_memory Description ----------- This node contains information describing firmware constraints needed by the LDOM Manager for configuring guest domains. 1.4.1 max_guests Property Name Tag Required ---- --- -------- max_guests PROP_VAL yes Description ----------- This property describes the maximum number of guests that the firmware supports. 1.4.2 max_hv_ldcs Property Name Tag Required ---- --- -------- max_hv_ldcs PROP_VAL yes Description ----------- This property describes the maximum number of hypervisor LDC endpoints that the hypervisor supports. 1.4.3 max_guest_ldcs Property Name Tag Required ---- --- -------- max_guest_ldcs PROP_VAL yes Description ----------- This property describes the maximum number of guest LDC endpoints that the hypervisor supports. 1.5 Read_Only_Memory Node Name Category Required subordinates Optional subordinates ---- -------- --------------------- --------------------- read_only_memory core rom_img Description ----------- This node contains information about the contents of read-only memory on the system, such as the host or system PROM. 1.5.1 name Property Name Tag Required ---- --- -------- name PROP_STR yes Description ----------- This property contains a human readable string for identifying the read-only memory that this node represents. For example, "System PROM" may be used to indicate that this is the PROM for the system firmware. 1.5.2 base Property Name Tag Required ---- --- -------- base PROP_VAL yes Description ----------- This property contains the base address of the read-only memory in the system address space. 1.5.3 size Property Name Tag Required ---- --- -------- size PROP_VAL yes Description ----------- This property contains the size of the read-only memory in bytes. 1.6 Rom_Img Node Name Category Required subordinates Optional subordinates ---- -------- --------------------- --------------------- rom_img core Description ----------- This node contains information about a firmware component in read-only memory. =============================================================================== Name Tag Required ---- --- -------- name PROP_STR yes Description ----------- This property contains a human readable string for identifying this firmware image in the read-only memory. For example, "Openboot" may be used to indicate that this image is the Openboot image used to boot the guest. 1.6.1 offset Property Name Tag Required ---- --- -------- offset PROP_VAL yes Description ----------- This property contains the offset into read-only memory of this firmware image. 1.6.2 size Property Name Tag Required ---- --- -------- size PROP_VAL yes Description ----------- This property contains the size of the firmware image in bytes. 1.6.3 alignment Property Name Tag Required ---- --- -------- alignment PROP_VAL no Description ----------- This property contains any memory alignment requirements of the firmware image, for placing that image in memory so that it runs and boots successfully. 1.6.4 min_allocation Property Name Tag Required ---- --- -------- min_allocation PROP_VAL no Description ----------- This property contains any minimum memory allocation requirements of the firmware image. 1.6.5 guest_use Property Name Tag Required ---- --- -------- guest_use PROP_VAL no Description ----------- This property indicates that this firmware image is suitable for use as the startup image for a guest. 1.7 Ldc_Endpoints Node Name Category Required subordinates Optional subordinates ---- -------- --------------------- --------------------- ldc_endpoints core ldc_endpoint Description ----------- This node aggregates fwd arc links to all the ldc_endpoint nodes needed by the LDOM Manager for generating the information hypervisor needs to configure its internal data structures to route packets between LDC channel endpoints. 1.8 Ldc_Endpoint Node Name Category Required subordinates Optional subordinates ---- -------- --------------------- --------------------- ldc_endpoint core Description ----------- This node contains the information hypervisor needs to configure its internal data structures to route packets between LDC channel endpoints. 1.8.1 resource_id Property Name Tag Required ---- --- -------- resource_id PROP_VAL yes Description ----------- This property contains a unique id for each ldc_endpoint node. 1.8.2 target_type Property Name Tag Required ---- --- -------- target_type PROP_VAL yes Description ----------- This property contains a value indicating one of several types of targets that is on the other end of a pair of LDC endpoints. Acceptable values are 0 The target endpoint is in the guest 1 The target endpoint is in the hypervisor 2 The target endpoint is in the SC 1.8.3 channel Property Name Tag Required ---- --- -------- channel PROP_VAL yes Description ----------- This property contains the endpoint id for the channel endpoint this node represents. The channel endpoint may be owned by a guest, hypervisor or the SP. 1.8.4 target_channel Property Name Tag Required ---- --- -------- target_channel PROP_VAL yes Description ----------- This property contains the endpoint id for the target endpoint on the other end of this channel. The target channel endpoint may be owned by a guest, hypervisor or the SP. 1.8.5 tx-ino and rx-ino Properties Name Tag Required ---- --- -------- tx-ino PROP_VAL yes rx-ino PROP_VAL yes Description ----------- These properties contains the same values as the corresponding tx-ino and rx-ino properties in the channel-endpoint node in the guest MD. The channel-endpoint node has an id property value matching this ldc_endpoint node channel property value. This enables hypervisor to target interrupts to the guest LDC endpoint. 1.9 Memory Segments and related nodes Memory-Segments Node Name Category Required subordinates Optional subordinates ---- -------- --------------------- --------------------- memory-segments resource memory-segment required Description ----------- Child of the root node with fwd arcs to the memory-segment nodes. 1.10 Memory-Segment Node Name Category Required subordinates Optional subordinates ---- -------- --------------------- --------------------- memory-segment resource memory-bank required Description ----------- Describes a contiguous memory address range. Its properties define that address range and they link to child nodes that specify criteria for locating a physical address in the memory segment to a set of one or more dimms that constitute a memory-bank. A memory-segment node has the following properties. 1.10.1 base Property Name Tag Required ---- --- -------- base PROP_VAL yes Description ----------- The base physical address of the range represented by this memory segment. 1.10.2 size Property Name Tag Required ---- --- -------- size PROP_VAL yes Description ----------- The size of the address range represented by this memory segment. 1.11 Memory-Bank Node Name Category Required subordinates Optional subordinates ---- -------- --------------------- --------------------- memory-bank resource component required Description ----------- Contains properties that describe the constraints for determining if a physical address is located on the set of one or more dimms that comprise this memory bank. The memory-bank node has fwd arcs to component nodes with dimm type properties. The dimm type component nodes contain nac properties used to identify the dimm. If an address belongs to this memory bank, it is located on one of the dimm type component nodes that are linked to by this node. 1.11.1 size Property Name Tag Required ---- --- -------- size PROP_VAL yes Description ----------- The size of this memory bank. 1.11.2 mask Property Name Tag Required ---- --- -------- mask PROP_VAL yes Description ----------- The value of the mask register is logically and'd with a physical address and the result is compared with the value in the match register to determine if the physical address is in this memory-bank. 1.11.3 match Property Name Tag Required ---- --- -------- match PROP_VAL yes Description ----------- After the value of the mask property is and'd with a physical address, if the resultant value is equal to the value of the match property, the address is on one of the dimms in this memory bank. 1.12 IO Device node NOTE: The IO Device node is described in the context of an MD in FWARC/2007/070. All of the information in section 4.1.1 of that case's 1-pager apply to the PRI. That material is copied here for ease of reference. Properties extended by this specification are noted with "*". Name Category Required subordinates Optional subordinates ---- -------- --------------------- --------------------- iodevice optional - iodevice, interrupt-map-entry Name Tag Required ---- --- -------- device-type PROP_STR Yes Description ----------- A string type for this node. The remaining properties in the MD node for this device will vary depending on the value of this string. For each specific device-type allowed, the remaining properties are shown below. Current allowed device-type values are: - pciex This value indicates a sun4v root nexus pci express device (Fire ports A and B, N2 PIU, etc.) - pcie-root-port This value indicates the node is a pci express root port. - pcie-switch-upstream This value indicates the node is an upstream port of a pci express switch - pcie-switch-downstream This value indicates the node is a downstream port of a pci express switch - pcie-pcix-bridge This value indicates the node is a of pci express to pci-x bridge. - pcix-pcix-bridge This value indicates the node is a of pci-x to pci-x bridge. - pci-network This value indicates the node is a pci-express or pci-x network device - pci-scsi This value indicates the node is a pci-express or PCI-x SCSI adapter - pci-generic This value indicates the node is a pci-express or pci-x device 1.12.1 Sun4v to PCI Express root nexus device Name Tag Required ---- --- -------- name PROP_STR Yes Description ----------- A string with the value 'pci'. this value is converted to the OpenBoot device tree 'name' property. Name Tag Required ---- --- -------- compatible PROP_STR Yes Description ----------- A string with the value 'SUNW,sun4v-pci'. this value is converted to the OpenBoot device tree 'compatible' property. Name Tag Required ---- --- -------- cfg-handle PROP_VAL Yes Description ----------- A 64 bit value that is unique to this device on the sun4v bus. Name Tag Required ---- --- -------- path PROP_STR Yes Description ----------- A string which contains the address of, and is unique to, this device on the sun4v bus. Name Tag Required ---- --- -------- address-ranges PROP_DATA Yes Description ----------- An array of 64 bit value pairs which specifies the address ranges available to this device. Each pair contains a base and range value. The first pair of the array specifies the PCI IO space addresses, the second pair specifies the PCI 32 bit memory address ranges, and the final pair specifies the 64 bit prefetchable memory address ranges. Name Tag Required ---- --- -------- virtual-dma PROP_DATA Yes Description ----------- A pair of 64 bit values which specific the virtual DMA region for this device. This property is converted to the OpenBoot device node 'virtual-dma' property. Name Tag Required ---- --- -------- msi-address-range PROP_DATA Yes Description ----------- An MSI property as specified in [7] Name Tag Required ---- --- -------- #msi PROP_VAL Yes Description ----------- An MSI property as specified in [7] Name Tag Required ---- --- -------- msi-data-mask PROP_VAL Yes Description ----------- An MSI property as specified in [7] Name Tag Required ---- --- -------- msi-ranges PROP_DATA Yes Description ----------- An MSI property as specified in [7] Name Tag Required ---- --- -------- msi-eq-size PROP_VAL Yes Description ----------- An MSI property as specified in [7] Name Tag Required ---- --- -------- msix-data-width PROP_VAL Yes Description ----------- An MSI property as specified in [7] Name Tag Required ---- --- -------- #msi-eqs PROP_VAL Yes Description ----------- An MSI property as specified in [7] Name Tag Required ---- --- -------- msi-eq-to-devino PROP_DATA Yes Description ----------- An MSI property as specified in [7] Name Tag Required ---- --- -------- bus-ranges PROP_DATA Yes Description ----------- An MSI property as specified in [7] 1.12.2 Generic PCI device properties The following properties are allowed for device-types that have the values: - pcie-switch-upstream - pcie-switch-downstream - pcie-pcix-bridge - pcix-pcix-bridge - pci-network - pci-scsi - pci-generic Name Tag Required ---- --- -------- device-number PROP_VAL Yes Description ----------- The PCI device number for this PCI device Name Tag Required ---- --- -------- function-number PROP_VAL Yes Description ----------- The PCI function number for this PCI device Name Tag Required ---- --- -------- devalias PROP_STR No Description ----------- The OpenBoot devalias for this PCI device, if one exists 1.12.3 PCI bridge type device properties The following properties are allowed for device-types that have the values: - pcie-switch-upstream - pcie-switch-downstream - pcie-pcix-bridge - pcix-pcix-bridge Name Tag Required ---- --- -------- #interrupt-cells PROP_VAL No Description ----------- This value will be converted into the '#interrupt-cells' property. The value is the number of 32 bit integers required for the representation of a single interrupt specifier for this node. A more complete description of this property can be found in [6] Name Tag Required ---- --- -------- interrupt-map-mask PROP_DATA No Description ----------- This array of integers will specify the interrupt-map-mask property that OpenBoot needs to create in this PCI device node. A more complete description of this property can be found in [6] Name Tag Required ---- --- -------- chassis-location-name PROP_STR no * Description ----------- This property, when present, contains a NAC name string matching a node in the "components" portion of the PRI graph. This property will exist in the device nodes where a FRU boundary has been crossed in the PCIE fabric. It will exist in the first device node entry pertaining to the FRU. This property is only applicable to pcie-switch-upstream and pcie-switch-downstream device types. It is *only* for locations within a chassis. It does not apply for slot adapters or any sub-frus external to the chassis itself. 1.12.4 PCI slot device properties The following properties are allowed for device-types that have the values: - pcie-switch-downstream - pcie-pcix-bridge - pcix-pcix-bridge Name Tag Required ---- --- -------- slot-present PROP_STR yes * Description ----------- The presence of this property means that a PCI slot is present at this device/function number. Name Tag Required ---- --- -------- slot-names PROP_STR yes * Description ----------- The 'slot-names' property as described by the IEEE 1275 PCI device binding. 1.12.5 PCI network device properties The following properties are allowed for device-types that have the values: - pci-network Name Tag Required ---- --- -------- phy-type PROP_STR No Description ----------- This property will contain a string that specifies the type of external physical layer transceiver is connected to the network device. The following are the allowed values Value: "xgc" for 10Gb copper "xgf" for 10Gb fiber "mif" for 1G/100M/10M copper "pcs" for 1Gb fiber Name Tag Required ---- --- -------- mac-addresses PROP_DATA No Description ----------- An array of MAC addresses allocated to this network device. 1.12.5 PCI scsi adapter device properties The following properties are allowed for device-types that have the values: - pci-scsi Name Tag Required ---- --- -------- sas-wwid PROP_VAL No Description ----------- An array of 8 byte SAS WWIDs for this SCSI adaper. 1.13 Interrupt mapping node NOTE: The Interrupt Mapping node is described in the context of an MD in FWARC/2007/070. All of the information in section 4.1.1 of that case's 1-pager apply to the PRI. That material is copied here for ease of reference. Name Category Required subordinates Optional subordinates ---- -------- --------------------- --------------------- interrupt-map-entry optional - - Name Tag Required ---- --- -------- parent-interrupt PROP_DATA Yes Description ----------- n array of integers that describes the interrupt number in the parent interrupt domain. Name Tag Required ---- --- -------- child-interrupt PROP_DATA Yes Description ----------- An array of integers that describes the interrupt number in the child interrupt domain. Name Tag Required ---- --- -------- child-unit-address PROP_DATA Yes Description ----------- The unit address of the device that generates the interrupt in the child interrupt domain. There number of integers in this array will be equal to the '#address-cells' for the child device. Name Tag Required ---- --- -------- parent-device-path PROP_STR Yes Description ----------- The textual device path of the device tree node that serves as the parent domain of the interrupt mapping. If the parent device that is specified by the 'parent-device-path' property is not present in the device tree, OpenBoot will eliminate the child device node from the device tree. 2. References [1] FWARC 2007/070 Machine Description IO Device Node Definitons http://sac.eng/Archives/CaseLog/arc/FWARC/2007/070/ [6] Open Firmware Recommended Practice: Interrupt Mapping (v0.9) http://playground.sun.com/1275/practice/imap/imap0_9d.pdf [7] MSI properties list http://sac.sfbay/FWARC/2005/030/materials/msi-props.txt