A set of OF properties is defined to facilitate asset protection and RAS capabilities in LoPAR systems. The following properties are defined in ): “ibm,vpd” “ibm,loc-code” R1--1. Each instance of a hardware entity (FRU) has a platform unique location code and any node in the OF device tree that describes a part of a hardware entity must include the “ibm,loc-code” property with a value that represents the location code for that hardware entity. R1--2. OF nodes that do not represent an instance of a hardware entity (FRU) do not have a location code and thus these nodes, except for the OF root node, do not include the “ibm,loc-code” property. Architecture Note: In general, an OF node that has a unit address corresponds to an instance of a hardware entity and a node that does not have a unit address does not correspond to an instance of a hardware entity. The nodes for caches are one exception to this statement. Note that the OF openprom node is a system node and thus should have neither the “ibm,loc-code” property nor the “ibm,vpd” property. R1--3. If a hardware entity contains unique VPD information and the entity corresponds to a node in the OF device tree, then that device tree node must include the “ibm,vpd” property. R1--4. An instance of a hardware entity (FRU) must have one and only one “ibm,vpd” property element that defines the VPD keywords specified in Requirement . Platform Implementation Note: In general, an instance of a hardware entity has a single “ibm,vpd” property element that is in one of the nodes that also contains an “ibm,loc-code” property element for that entity. R1--5. An OF device tree node that includes the “ibm,vpd” property must also include an “ibm,loc-code” property, where each property has the same number of elements and the matching elements of both properties define the same instance of a hardware entity (FRU), where matching elements are defined as the nth string of the “ibm,loc-code” property and the nth set of tags in the “ibm,vpd” property for all values of n. R1--6. VPD data that is not associated with an instance of a hardware entity (FRU) that is described by a single OF device tree node must be reported in an appropriate OF node using the “ibm,loc-code” and “ibm,vpd” properties. Architecture Notes: The root node is the appropriate OF node (for Requirement ) for any instance of a hardware entity that cannot be dynamically reconfigured. Any one and only one of the OF nodes that describe the dynamically reconfigurable entity can contain the properties for the dynamically reconfigurable entity case. A dynamically reconfigurable entity may consist of more than one FRU. In this case, the first element of both the “ibm,vpd” property and the “ibm,loc-code” property for the dynamically reconfigurable entity must define the VPD and location code for the OF device tree node that includes those properties. A FRU can be considered dynamically reconfigurable if the hardware is enabled for dynamic reconfiguration and full platform support might be implemented at a later date. Platform Implementation Note: If a location does not return VPD, the property would contain a null entry for the VPD.

provides properties in the “OF Root Node” section called “system-id” and“model”. R1--1. (Requirement Number Reserved For Compatibility) R1--2. Each system enclosure (generally, a drawer), must have the VPD SE and TM keywords (see ). R1--3. The SE and TM keywords for a master enclosure must be contained in the “ibm,vpd” property for the master enclosure which may also contain other keywords. A master enclosure must also have the YK keyword if another enclosure shares the same combined SE and TM keyword values. The YK keyword (see ) for a secondary enclosure must be contained in the “ibm,vpd” property for the secondary enclosure, which may also contain other keywords. Each master enclosure with a YK keyword must have a unique YK value that is the same as the value of the YK keyword for each of the secondary enclosures that share the same combined SE and TM keyword values. An enclosure is not a FRU and thus its VPD must not contain the FN, PN, SN, EC, RM or RL keywords. R1--4. The enclosure must also be represented in the corresponding element of the “ibm,loc-code” property with the location code of the enclosure for a multi-enclosure platform. Implementation Note: The location code will be for the full enclosure. The drawer position is the u-units counting from the bottom of the rack. Specific numbering is platform dependent. R1--5. If the system contains multiple processor enclosures, firmware must use the VPD SE field from the first or ‘marked’ processor enclosure (see ) to construct “system-id”. Implementation Note: What is meant by ‘marked’ above is that, in a system, the ‘first’ processor enclosure could become ambiguous. In such a case, a specific processor enclosure could be marked by the firmware or HMC as being the processor enclosure to use for identification purposes. R1--6. One or more of the MI, RM, and RL keywords must be present for any firmware specific VPD. (with a value of “UNKNOWN” for unknown values), and must be present based on all of the following: The RL keyword must be provided if the platform does not support the ibm,update-flash-64-and-reboot RTAS call. The RM keyword must be provided if the platform supports only a single flash image updated via the ibm,update-flash-64-and-reboot service and does not support the ibm,manage-flash-image and ibm,validate-flash-image RTAS calls. The MI keyword must be provided if the platform supports dual flash images via the ibm,update-flash-64-and-reboot, the ibm,manage-flash-image, and the ibm,validate-flash-image RTAS calls. The ML keyword must be provided if the platform supports dual flash images via the ibm,update-flash64-and-reboot, the ibm,manage-flash-image, and the ibm,validate-flash-image RTAS calls. R1--7. System firmware and service processor firmware must have VPD that is separate from the VPD of the FRU that contains the system firmware and service processor firmware and this VPD must have a location code that is made by adding “/Yn” to the end of the location code for the FRU that contains the firmware where n is a platform dependent instance of the firmware. R1--8. The description (large resource type of 0x82) for the system firmware VPD in the “ibm,vpd” property must be “System Firmware or Platform Firmware”. R1--9. System firmware VPD must be found in the root node if the system supports only static VPD, otherwise system firmware VPD must be provided via the ibm,get-vpd RTAS call. R1--10. The description (large resource type of 0x82) for the service processor firmware VPD in the “ibm,vpd” property must be “Service Processor Firmware”, if the service processor firmware is a separate FRU from the system firmware. R1--11. Service processor firmware VPD must be found in the root node if the service processor firmware is a separate FRU from the system firmware. R1--12. The VPD SE field (see ) must be electronically stored in a manner that is not modifiable in a user environment. R1--13. There must be a property, “model”, under the root node in the format, “<vendor>,xxxx-yyy”, where <vendor> is replaced by one to five letters representing the stock symbol of the company (for example, for IBM: “IBM,xxxx-yyy”), and where xxxx-yyy is derived from the VPD TM field (see ) of the first or ‘marked’ processor enclosure. R1--14. The values of the type/model (TM) and system serial number (SE) (see ) must remain the same even with service or reconfiguration of the system. Implementation Note: A change in either TM or SE would indicate a system replacement as opposed to a reconfiguration. This definition of the“system-id” property provides extensibility and ensures that uniqueness can be maintained. The 2 byte Field Type will serve to identify the format of the System Identifier Field which follows. Hardware Implementation Note: It is recommended that the VPD SE field be held in an area of the machine that is least susceptible to hardware failure. This is to minimize the effect on software licensing when a FRU must be changed. Another useful technique is to socket the part containing the SE field, allowing service personnel to move the old SE to the new FRU.

Hardware location codes are used to provide a mapping of logical functions in a platform (or expansion sites for logical functions, such as connectors or ports) to their specific locations within the physical structure of the platform. The description in the following section is intended to define a standard architecture for these location codes, which would be used in three places: These location codes would be included as a property, “ibm,loc-code”, under device nodes in the OF device tree, to provide identification of where those device functions are physically located in the platform. To make service and parts replacement easier, hardware location codes of failing components would be appended to the standard 40-byte Extended Error Log templates returned by the RTAS event-scan and check-exception services. Software Note: Since the OF device tree currently only defines the core platform devices and IOAs, OS applications such as diagnostics may need to extend these location codes with logical addresses to point to devices such as SCSI (Small Computer System Interface) drives or asynchronous tty (teletypewriter) terminals. Location Codes are globally unique within a system and are persistent between system reboots and power cycles. R1--1. All platforms must implement the Converged Location Codes option. R1--2. Location codes must be globally unique within a system, including across multiple CECs of a clustered system, and must be persistent across multiple system reboots and power cycles. Converged location codesThe term “converged” is historic, based on merging (converging) several previous versions of location codes. are strings composed of one or more location labels separated by dashes (“-”). Location labels are strings that begin with a location prefix followed by a distinguishing value. For example, the location code for a PCI (Peripheral Component Interconnect) card in a CEC (Central Electronic Complex) might be something like this: U7879.001.1012345-P2-C3 Valid location codes consist of uppercase characters ('A' - 'Z'), digits (0 - 9), periods ('.'), and dashes ('-'). Characters other than these valid characters will be replaced by pound signs ('#') to protect display and formatting routines and give a consistent indication of a problem in the data. Periods may be used to improve readability of the location code. The existence of the “ibm,converged-loc-codes” property in the root node of the device tree indicates that the platform implements the Converged Location Codes option. R1--3. For the Converged Location Codes option: The platform must implement the “ibm,converged-loc-codes” property in the root node of the device tree. R1--4. For the Converged Location Codes option: The location code contained in each instance of the property “ibm,loc-code” must match the format as described in the sections under and . R1--5. For the Converged Location Codes option: Extended error logs reported to the OS by event-scan orcheck-exception must have the characters “IBM<NULL>” in bytes 12-15, and include the location codes for the failing elements in the format as described in the sections under and .

This section describes the types of location code labels. See also for the rules for building a location code.

The prefix of a converged location code is as defined in this section. R1--1. For the Converged Location Codes option: The location code prefixes specified in must be used in constructing location codes. Prefix Meaning A Air handler (for example: blower, fan, motor scroll assembly, motor drive assembly). . C Card Connector (for example, connector for: IOA, Processor Card, Riser Card, Daughter Card, DIMM, Regulator Card, MCM, L3 Cache, Jumper Card, Passthru Interposer (for Processor Fabric when an MCM is not installed), Pluggable Module Chips). . D Device (for example: Diskette, DASD, Operator Panel, SES (Storage Enclosure Services) Device). . E Electrical (for example: Battery, Power Supply, Charger). . F Frame. See . L Logical Path (for example: SCSI Target, IDE Address, ATAPI Address, Fibre Channel LUN, etc.). . M Mechanical (Plumbing, Valves, Latches). See . N Horizontal placement for an empty rack location. See . P Planar (for example: Backplane, Board). . R Resource (identifies a resource that is not a FRU, but needs identification in the error log). See . S SR-IOV adapter virtual function. See . T Port (for example: Port, Connector, Cable Connector, Jack, Interposer). . U Unit (for example: System, CEC, Card Cage, Drawer, Chassis (Unpopulated drawer)). . V Virtual Planar. See . W Worldwide unique ID (for example: Fibre Channel). . X EIA value for empty rack location. See . Y Firmware FRU. See .

The unit location label consists of the prefix “U” followed by uppercase alphabetic characters, digits, and periods (“.”). There is one and only one unit location label in a location code and it is the first element in the location code.

The planar location label consists of the prefix “P” followed by a non-zero decimal number with no leading zeroes. Planar location labels are present in location codes for planars and all locations on a planar. There is at most one planar location label in a location code. When present, the planar location label immediately follows the unit location label in the location code. Planars are uniquely labeled within a unit.

An air handler location label consists of the prefix “A” followed by a non-zero decimal number with no leading zeroes. A location code may have zero or more air handler location labels. When present, the air handler location label follows the location label of the resource onto which the air handler is mounted, usually a unit or planar. Examples of air handlers include blowers and fans.

The card connector location label consists of the prefix “C” followed by a non-zero decimal number with no leading zeroes. A location code may contain zero or more card connector location labels. When present, the card connector location label follows the location label of the resource onto which the card is mounted, usually a planar or another card. Examples of cards include: Plug-in I/O cards, processor cards, daughter cards, DIMMs, regulator cards, MCMs, L3 cache modules, jumper cards, pass-through interposers, and pluggable module chips.

A device location label consists of the prefix “D” followed by a non-zero decimal number with no leading zeroes. A location code may have zero or more device location labels. When present, the device location label follows the location label of the resource onto which the device is mounted, usually a planar. Device location labels are used for devices for which a physical location can be determined. These are usually mounted in enclosures that have rigid placement rules and, often, additional hardware support for location determination, such as SES (Storage Enclosure Services) devices.

An electrical location label consists of the prefix “E” followed by a non-zero decimal number with no leading zeroes. A location code may have zero or more electrical location labels. When present, the electrical location label follows the location label of the resource onto which the electrical resource is mounted, usually a unit or planar. Examples of electrical resources include: batteries, power supplies, and chargers.

A port location label consists of the prefix “T” followed by a non-zero decimal number with no leading zeroes. A location code may have zero or more port location labels. When present, the port location label follows the location label of the resource onto which the port is mounted, usually a card or planar. Examples of resources with a port location label include: ports, connectors, cable connectors, jacks, and interposers.

A worldwide unique identifier location label consists of the prefix “W” followed by a maximum of 16 uppercase hexadecimal digits with no leading zeroes. A location code may have zero or one worldwide unique identifier location labels. When present, the worldwide unique identifier location label follows the location label of the resource that interfaces with the resource having the worldwide unique identifier, usually a port.

A logical path location label consists of the prefix “L” followed by a decimal or hexadecimal number with no leading zeros. Refer to through to determine when decimal and hexadecimal values are allowed. A location code may have zero or more logical path location labels. When present, the logical path location label follows the location label of the resource that interfaces with the resource being located, usually a port or worldwide unique identifier. The numeric value portion of the logical path label is a portion of the address, appropriate to the protocol in use, which identifies the resource to be located.

A virtual planar label consists of the prefix “V” followed by a non-zero decimal number with no leading zeroes. A location code may have zero or one virtual planar location labels. When present, the virtual planar location label will immediately follow the unit location label in a location code. There is no physical label in the system or any I/O drawer corresponding to the virtual planar location label. Virtual planars are uniquely labeled within a system.

A firmware location label consists of the prefix “Y” followed by a non-zero decimal number with no leading zeroes. A location code may have zero or one firmware location labels. A firmware location code will always contain a unit location label as its first element and a firmware location label its last element.

The horizontal placement location label of an empty space in a rack consists of the prefix “N” followed by a non-zero decimal number with no leading zeroes. A location code may have zero or one horizontal placement location labels. When present, the horizontal placement location label immediately follows the EIA location label.

The EIA location label of an empty space in a rack consists of the prefix “X” followed by a non-zero decimal number with no leading zeroes. A location code may have zero or one EIA location labels. When present, the EIA location label immediately follows the frame location label.

The frame location label of an empty space in a rack consists of the prefix “F” followed by a non-zero decimal number with no leading zeroes. A location code may have zero or more frame location labels. When present, the frame location label immediately follows the unit location label.

A virtual function label consists of the prefix “S” followed by a zero-starting decimal number with no leading zeros. A location code may have zero or more virtual function labels. When present, the virtual function label is appended to the location code of the port that the virtual function uses.

The Mechanical location label consists of the prefix “M” followed by a nonzero decimal number with no leading zeroes. A location code my have zero or more Mechanical location labels. When present, the Mechanical location label follows the location label of the resource onto which the mechanical device is mounted. Examples of resources with a mechanical location label include: plumbing, valves, and latches.

The Resource location label consists of the prefix “R” followed by a nonzero decimal number with no leading zeroes. A location code my have zero or more Resource location labels. When present, the Resource location label follows the location label of the parent FRU. Resource location labels are resources, that are not FRUs, but that need a location code label to be properly identified in the error log. An example of a Resource is a module on the System backplane that is not a separate FRU, but which needs to be separately identified in the system error log for a fail in place type of service strategy.

This section describes the rules for building a location code. See also the types of location code labels.

Any reference to a FRU must reference the official location code. Unofficial internal forms or values of location codes which system components may use for internal convenience are not to be presented to customers, service personnel, etc. They are to be kept internal to those components.

Physical path location codes are permanent. Physical path location codes will not change unless there has been a change of hardware. Logical path location codes are dependent on configuration information and are therefore not permanent. Whenever reasonable and possible, logical path location codes will persist across power cycles of the system.

Location codes are formed by concatenating one or more location labels together. Location labels start at the largest or most general resource (the unit) and proceed to the most specific in order of containment. The location labels are separated by dashes (“-”).

Location codes are no more than 79 characters in length. The lengths of individual location labels vary.

The unit location label may contain uppercase letters, digits, and periods. All other location labels contain only upper case letters and digits. This will avoid problems when printing or displaying the location codes on double byte devices.

In so far as it is possible, location labels must match the labels that are present on the hardware. Generally, there are labels visible on the hardware to identify connectors, slots, etc. These physical labels must adhere to this specification and must be reflected in the corresponding location codes. This will eliminate the need for the user to translate between the location code presented in logs, displays, reports, and instructions and the location label found on the hardware.

Some FRUs (Field Replaceable Units) contain more than one logical resource or function. The physical location code refers to the physical FRU. So all the logical resources or functions on a FRU have the same physical location code. Connectors on a FRU have different location codes except for the case of multiple connectors for one port.

Some IOAs have multiple connectors (for example, a D-connector and an RJ-45 connector) for one port. Since there is only one port involved, both connectors have the same location code.

For sequentially numbered location labels (planar, card, device, air handler, electrical), each FRU has its own numbering space for its child location labels. That numbering space begins with 1 and increments by 1 for each child location label. Number is in decimal. For example, if there were two planars in a unit, each planar having five card connectors, then each planar would show child location labels of C1, C2, C3, C4, and C5. This means that for each parent, the child location labels begin with a count of one. As a further example, if there were two adapters in adjacent PCI slots each with two port connectors, the ports on the first adapter would have location labels T1 and T2, and the ports on the second adapter would have location labels of T1 and T2. Note: Model-specific modifications to this numbering rule may be made, when similar models of a product line are housed in the same enclosure/rack, and the equivalent slots and connectors from each model are lined up with each other as seen by the customer. Then the location code numbering of these equivalent slots and connectors may be the same for each model, even though numbers may be skipped or appear to be out of order on specific models.

Locations are numbered left to right, top to bottom, back to front with respect to the parent FRU, as viewed from the service position. However, a location label does not change based on the orientation of a piece of hardware within its parent hardware, for FRUs that may have more than one way of being oriented. If a CEC or I/O drawer is used both in standalone and rack mounted configurations, the rack mounted configuration takes precedence in determining location numbering.

The unit location code is the unit location label, Un, for the unit. The unit location label is permanent. The unit location labels may not be etched on the containing racks, since it may not be possible to determine them during manufacture. A system will have a unit location code composed of the machine type, model, and serial number of the system with the components separated by periods ('.'). For example, a system with machine type 9117, model 250, and serial number 10-ABCDE would have a location code of: U9117.250.10ABCDE Some I/O Drawers and CECs may be assigned machine type, model, and serial numbers (MTMS) by manufacturing. Other I/O Drawers and CECs may be assigned feature code, count, and serial numbers by manufacturing. The same requirements for uniqueness apply to both identification schemes. The data is formatted in exactly the same way. And, for the purposes of location codes, the data will be used in exactly the same way. Drawers and CECs which have a machine type, model, and serial number which the system can obtain will have a unit location code composed of the machine type, model, and serial number with the components separated by periods (“.”). For example, a drawer with machine type 5703, model 012, and serial number 10-30490 would have a location code of: U5703.012.1030490 Drawers and CECs which have a feature code, count, and serial number which the system can obtain will have a unit location code composed of the feature code, count, and serial number with the components separated by periods (‘.’), for readability. For example, a drawer with feature code 0573, count 001, and serial number 10-40320 would have a location code of: U0573.001.1040320 Additionally, the count portion of the location code unit label may be modified by firmware at boot time to reflect information about the physical location. It may be modified according to whatever scheme appropriate for the unit's configuration -- provided all other location code rules are followed and that the scheme generates the same value every time when no actual or relative physical location change has been made. For example, TUn (“TU” to indicate the Top CEC Unit, n=1,2,3, or 4 to indicate which drawer numbered top to bottom) may be substituted for the actual count value, so an imaginary CEC following this scheme might have a unit label of: U1234.TU1.5678901 Enclosure feature code/count must never collide with one another or with any machine type/model. Likewise, enclosure machine type/model must never collide with one another or any enclosure feature code/count. Drawers for which the system cannot obtain a machine type, model, and serial or a feature code, count, and serial number, will have a location code of the form Uttaa. In this form, the tt is an alphabetic string identifying the kind of drawer, for example, SSA. The aa is a string provided by the rules of the OS to identify the instance of the drawer within the particular system. For example: USSABKUP. The lengths of both tt and aa will vary depending on the kind of drawer. The OS must provide mechanisms by which the customer can ensure the uniqueness of these values.

Planar location codes are formed by appending the planar location label, Pn, to the location code of the unit that contains the planar. The Pn value is assigned during the engineering design and manufacturing process, is unique within the unit, is physically displayed on the parent resource, and is present in the VPD of the parent resource. This process is the same irrespective of the kind of planar involved. Note: In some implementations, a planar is not a separate FRU but is considered to be part of the enclosure. For consistency of the user interface, the enclosure in these cases is still considered to have a location code consisting entirely of a unit location label. In these cases, the planar has a location code consisting of both the unit location label and the planar location label. This is done even though the planar is not a separate FRU. In these cases, service related VPD and errors will be reported with the planar location code.

Card connector location codes are formed by appending the card connector location label, Cn, to the location code of the resource to which the card is docked. The location label, Cn, assigned in the engineering and manufacturing process, is unique within the parent resource, is physically displayed on the parent resource, and is present in the VPD of the parent resource. The process is the same irrespective of the kind of card involved.

Riser card connector location codes are formed by appending the card location label, Cn, of the child card to the location code of the parent card to which it is attached. For example: U5702.115.1031010-P3-C4-C2

The Blade daughter card slot can actually contain multiple partitionable endpoints depending on the type of daughter card attached. The PCI-E bus can be split (bifurcated) between two PHB's that are separately DLPAR-able (just not hot-pluggable) resources. When that occurs, a -L# suffix is required after the -C# of the daughter card slot to distinctly identify between the two PE's. For example, when the daughter card contains two 4x PCIE devices, the location code for the two PE's might be: U78A0.001.DNWGDG0-P1-C10-L1 U78A0.001.DNWGDG0-P1-C10-L2 The actual daughter card device ports, in this example, will have the -T# suffix (starting from 1) on top of those. For example, a 4-port PCI-E Ethernet daughter card, might have location codes like: U78A0.001.DNWGDG0-P1-C10-L1-T1 U78A0.001.DNWGDG0-P1-C10-L1-T2 U78A0.001.DNWGDG0-P1-C10-L2-T1 U78A0.001.DNWGDG0-P1-C10-L2-T2 If only a single PCI device is on the daughter card, then the -L# suffix should not be used, as the -C# is sufficient to identify the PE and device.

Virtual card connector location codes are formed as though there were a virtual planar with card slots. For example, the location code for a virtual IOA in partition 5 and in virtual slot 3 would be of the form: U9117.001.1076DEF-V5-C4 The partition number 5 is specified in the V label and the virtual slot number 3 is specified in the C label. Also note that the U label specifies the system type, model, and serial (the system location code), not the enclosure type, model, and serial. Some operating systems may append a T label to the virtual IOA location code. For example: U9117.001.1076DEF-V5-C4-T1

Port location codes are formed by appending the port location label, Tn, to the location code of the resource on which the port connector is mounted. The location label, Tn, assigned in the engineering and manufacturing process, is unique within the parent resource, is physically displayed on the parent resource, and is present in the VPD of the parent resource.

If a resource without slot map VPD has port numbers physically marked on it, the hard coded slot map will reflect the marked numbers and letters with a “T” prefix. Any letters will be folded to uppercase to avoid double byte display concerns. (Note: only letters 'A' - 'F' may be used in a port location label. Other letters on the card will be ignored and numbers will be assigned for uniqueness.) It is recognized that location labels formed in this way may not conform to the location label rules stated in . If the port labels are not marked on the standalone adapter, the hard coded slot map will specify location labels of Tn, where n is decimal and equal to the port address (i.e. port 0 will map to T1, port 1 will map to T2, etc.) Whenever possible, the hardware design should be such that this will lead to the preferred left to right, top to bottom, front to back ordering. For standalone adapters that can be installed in multiple systems, ports are labeled beginning with the PCI connector and continuing toward the opposite edge of the card and from tailstock forward toward the opposite edge of the card. If the adapter is imbedded on a FRU which does not have port location labels marked on it and has ports for other functions, then the numbering to the ports in the hard coded slot map must take into account the other ports on the FRU. The hard coded slot map will comply with the left to right, bottom to top, front to back ordering guidelines. In this case, the first port for the imbedded adapter may be other than T0 and may not be contiguous.

If the port number cannot be determined from VPD or VPD plus configuration or addressing information, software or firmware must infer the port number. For SCSI IOAs with multiple PCI configuration spaces, each port has its own configuration space. For multiport SCSI IOAs with a single PCI configuration space, firmware or software will add n+1 to the base port's distinguishing value to obtain the port number for the nth port. Thus port 0 (usually closest to the PCI connector edge of the card) will have label T1, port 1 will have label T2, etc.

Devices whose parent supports location label VPDSES devices on SCSI backplanes contain VPD that has a slot map. The slot map associates a SCSI LUN with a location label. Some backplanes that do not actually have SES support have a virtual SES that provides the same function. It is assumed that future protocols will support equivalent function. (that is, mounted/docked on a backplane that supports location information for docked devices) will have physical location codes. For example, U5734.001.10ABCDE-P3-D19 Physical device location codes are formed by appending the physical device location label, Dn, to the location code of the resource to which the device is docked. The location label, Dn, assigned in the engineering and manufacturing process, is unique within the parent resource, is physically displayed on the parent resource, and is present in the VPD of the parent resource. Notes: AIX will use logical path location codes for SCSI devices even in situations where a SES device is available to provide device location label information. In some cases, a location code may need to be displayed or logged before the information from the backplane is available to form the physical location code. In these cases, a logical path location code will be formed according to the applicable rules and used temporarily. Once the information needed to form the physical device label is available, the physical device location code will be used.

SCSI (Small Computer System Interface) devices whose parent does not support location label VPD will have location codes that are composed of the location code of the controlling SCSI port followed by the SCSI Target (0-15) and SCSI LUN (Logical Unit Number). A SCSI logical-path example is: U7043.150.1076543-P4-T3-L13-L0 (Decimal L values)

SAS (Serial SCSI) devices whose parent FRU does not support location label VPD will have location codes that are composed of the location code of the controlling SAS adapter followed by a series of port labels, “-L#”, for each SAS port traversed from the adapter down to the drive followed by the SCSI LUN (Logical Unit Number). The number value of the “-L#” label will be the lowest phy in the outgoing SAS port with # being a decimal value. For example: U7043.150.1076543-P1-C3-L3-L1-L5-L0

The desired form of the location code is based on the physical-path location codes obtained from VPD. For example: U5734.001.1076543-P2-D4 For an IDE device that had an older form of VPD (without physical location codes), then its location code would have looked like: Ux-Px-(Cx)-Tx-L# (from -L0 to -L3 where: L0 = primary/master L1 = primary/slave L2 = secondary/master L3 = secondary/slave)

Fibre channel devices that are not mounted/docked on a backplane that supports location code VPD will have location codes composed of the location of the port on the controlling IOA followed by the worldwide unique port identifier and LUN. The number value (#) of the “-L#” label is a hexadecimal value. An example FC disk attached to a physical adapter is: U787A.001.1012345-P1-C5-T2-W123456789ABCDEF0-L1A05000000000000

Single Root IO Virtualization allows for multiple “virtual functions” to share the same physical port of a PCI adapter. The -S# suffix, appended to the physical location code of the port (-T#), is used to identify the unique virtual function using that port. The number value (#) of the “-S#” label is a zero starting decimal value determined and managed by the software layer that owns the physical functions of the SR-IOV adapter. For an SR-IOV ethernet adapter, the third virtual function for the first ethernet port would look like: U7043.150.1076543-P1-C5-T1-S2

Group labels appear on parent FRUs to indicate groupings such as port or DIMM pairs. Group labels are not part of the location label or location code. Group labels may be part of slot map VPD and may be processed by software that displays information on the corresponding FRUs.

A Sandwich FRU has a single location label to describe its location just as any single FRU would.

A Sandwich FRU is like any single FRU in that it has one numbering space for numbering its child locations.

The location code reported by a sensor is the location code of the FRU being monitored by the sensor.

The location code of a sensor is the location code of the FRU on which the sensor is located.

The VPD that reports an indicator will give the location label of the resource identified by the indicator, not the location label of the indicator itself.

The location code of an indicator is the location code of the FRU on which the indicator is located.

The location specified for firmware is left to the platform except that the location code must match the scope of the firmware and the location code must follow the form specified above, beginning with a unit location label and ending with a firmware location label. For example, firmware for port 2 (T location label value) on planar 1 could have a location code of the form: U7879.001.1054321-P1-Y2 If the firmware is considered to be system wide, then the planar location label would not be present and the unit location label specifies the system location code not the CEC enclosure location code: U9117.001.1054321-Y1

The unit location label for a BPA and its components consists of the “U” prefix and the MTMS of the rack of which the BPA is a component. In some configurations, there are two BPAs in one rack. If they were treated separately, the second BPA would have the same location label as the first which would lead to location code collisions. Therefore, from the perspective of location codes, the two BPAs will be treated as on BPA. The planar location labels and, when necessary, other location labels within the second BPA are incremented so that they are not the same as the labels in the first BPA. For example, the front side BPA has a planar P1 and the back side BPA has a planar P2 etc.

The unit location label of an Internal Battery Feature (IBF) is the unit location label of the BPA to which it belongs. The planar location labels and, if necessary, other location labels within the IBF are incremented so that they are not the same as the labels in the BPA or any other IBF belonging to that BPA.

In some configurations, there are media drawers that do not have a MTMS. The unit location label for these media drawers is the unit location label of the CEC to which it belongs. The planar location labels and, if necessary, other location labels within the media are incremented so that they are not the same as the labels in any other media drawer in the system or any labels in the CEC.

The horizontal placement location label begins with the prefix “N” followed by the digit “1” for the left side of the frame (viewed from the front) or the digit “2” for the right side of the frame (when viewed from the front).

The EIA location label begins with the prefix “X” followed by a nonzero digit which represents the EIA location of the bottom of the unit that is or would be in the frame at that location.

The disk storage module in a blade chassis may consist of a backplane and a set of disks that plug into the backplane. Such a storage module is assigned an enclosure feature code which is used to define the unit location label (Un) of a disk in a storage module. In some blade chassis there may be multiple identical storage modules. All storage modules have a unit location with the same enclosure feature code. The backplane within the left storage module has label P1, the backplane in the next storage enclosure has label P2, and so on, to help with disk identification.

There are multiple occasions where devices may be added after the system has booted and the addition did not use any dynamic reconfiguration flows. In this situation, the O/S does not have adequate information from the device tree's “ibm,loc-code” properties to construct a correct physical location code. One example of this is with IDE/SCSI drives that are hot-pluggable, where the O/S only knows the logical location code from the IDE/SCSI bus. Firmware, however, may know the physical location code of the drive based on the unit-address. Similarly, a USB root-hub may have multiple down-facing ports with different physical location codes, but the root-hub is only a single device tree node, so only a single location code can be provided with just the “ibm,loc-code” property. The “ibm,loc-code-map” property contains a list of pairs (unit-address, location code), both as encoded strings. It describes the physical location code for each potential child node. R1--1. The instance of each USB root-hub in the device tree must contain the “ibm,loc-code-map” property if the root-hub has multiple down-facing ports. This applies to both the OHCI and EHCI interfaces of a USB adapter. Lack of this property implies there is only a single down-facing root-hub port from that USB interface. R1--2. To determine the location code for an end device associated with leaf open firmware node, the O/S must use the “ibm,loc-code-map” entry with a matching unit-address, if it exists, in preference to the parent's “ibm,loc-code” property. R1--3. The “ibm,loc-code-map” property must not contain an entry for a port from an embedded IOA that is not externally connected, or if the location code is undeterminable. R1--4. If the unit-address architecture for certain node types do not strictly bind a particular unit-address with a hardware location, the “ibm,loc-code-map” property must not exist in the parent of those nodes.

The root hub port number used determines the location code up to the Tn suffix. There can be zero or many intervening hubs, and the intervening “Ln” location labels are in path order. All immediate children are of root hubs are represented by “L1”. For devices not directly attached to the root hub, the “Ln” will correspond to the software port number, n, of the parent hub that a device is attached to, counting from 1. For example, the location code for a USB device attached to an IOA imbedded on a backplane with location label P1, using port T5, and with an intervening hub under which the device is attached to the third port would be: U787A.001.10ABCDE-P1-T5-L1-L3

A Coherent Platform Facility serves as the parent node for Coherent Platform Function devices. These devices describe the virtual topology of the coherently attached function. The location code is derived from the physical resource loca- tion code that the coherent platform facility is representing. For example, the form of the location code is: U1234.001.1054321-P1-C7

A Coherent Platform Function comprises a coherently attached functional unit. These location codes are formed by ap- pending a -Sy-Sz label which is a zero starting decimal value that describes the resources within the Coherent Platform Facility that are used by the Coherent Platform Function. For example, the form of the location code is: U1234.001.1054321-P1-C7-S0-S1

The resource location label consists of the prefix 'R' followed by a non-zero decimal number. A resource location code identifies a chip or function embedded on a FRU. There may be multiple resources associated with a FRU. The numbering of the resources on a particular FRU should match the left to right, top to bottom positioning of the resources on the FRU when the FRU is in a typical service position. It should be noted that embedded adapters with internal ports existed prior to introduction of the resource label. Use of the resource label for unique partitionable endpoint identification may or may not be retrofitted to those adapters as they are carried forward to new platforms.

A physical location code is tied to the connector that a FRU plugs into. If two different parts with different part numbers can plug into the same connector, both parts will have the same location code. However, if two different parts can plug into two different connectors but share the same physical space when either is installed, those parts should each have a different location code. For example, if two different GX adapters (such as the Bjorn IB adapter and Newcombe PCI slot riser on Jupiter-IOC) connect to the same planar using the same connector, they should both be assigned the same location code. But if a GX adapter or a PCI adapter can be installed on a planar, but not both at the same time as they both can't fit at the same time given the placement of the connectors on the planar, both slots should be assigned unique location codes.

A PCI-E attached I/O drawer is an I/O drawer that attaches to a GX adapter in the CEC via PCI-E cables (as opposed to RIO or IB cables). There are two different types of PCI-E attached I/O drawers: ones where PHB(s) on the GX adapter connect directly to I/O devices in the drawer and ones where the PHB(s) on the GX adapter connect to switches (or other fan-out logic) in the I/O drawer. In the former case, the partitionable endpoint (PE) is the logical PHB connection to the device. In the latter case, the PEs are the slots wired to the downstream switch ports. For GX cards whose PHBs connect directly to devices in the I/O drawer (such as Bluehawk), the location code and DRC name of the I/O slot partitionable endpoint will be of the form Ucec-Pw-Cx- Ty-Lz. Here, Ucec is the type/model/serial of the CEC that contains the GX adapter, Pw is the planar that contains the GX adapter, Cx is the GX adapter, Ty is one of the ports on the adapter, and Lz is a logical label representing a logical PCI-e connection to an I/O device at the other end of the PCI-e cable plugged into that port (note that there may be multiple Cx labels if the GX adapter doesn't plug directly into the planar in the system in question). This location code and DRC name will be generated by system firmware for each PE on each GX adapter that is installed in the system and that supports direct-connect drawers (i.e. drawers without a PCI-E switch in them). The location code and DRC name will be generated regardless of whether or not a PCI-E cable is attached to the GX adapter. It is permissible to append additional labels beyond the L label to create different location codes for FRUs/devices downstream from the I/O device in the drawer that is attached to the PCI-e cable. It is not required that all subsequent labels be logical labels. For GX cards whose ports connect to a PCI-E switch in an I/O drawer via PCI-E cables, the location code format has not yet been defined.

The location code for a virtual SCSI (vSCSI) device is formed by appending an L label to the location code of the parent virtual IOA. The L label contains a 48 or 64 bit hexadecimal value that uniquely identifies the virtualized SCSI device. A virtual SCSI device attached to a virtual IOA at U9119.MME.1085B17-V4-C5-T1 would have a location code of the form: U9119.MME.1085B17-V4-C5-T1-L8100000000000000 Note that some old pSeries firmware may represent the virtualized device identifier as W8100000000000000-L0 rather than simply L8100000000000000. This approach was abandoned in late 2008. See for a description of the virtual IOA location code.

The location code for a virtual fibre channel device is formed by appending the worldwide unique port identifier (W label) and LUN (L label) to the location code of the parent virtual IOA. The values of the L and W labels are both in hexadecimal. A fibre channel disk attached to a virtual IOA at U9119.MME.1085B17-V4-C5-T1 would have a location code of the form: U9119.MME.1085B17-V2-C4-T1-W123456789ABCDEF0-L1A05000000000000 See for a description of the virtual IOA location code.

Non-volatile memory (NVM) devices that are not mounted/docked on a backplane that supports location code VPD will have location codes composed of the location code of the controlling IOA followed by a L label. The number value of L label is a decimal value, and it is the unique NVMe namespace identifier. An NVMe device controlled by an IOA at U787A.001.1012345-P1-C5 would have a location code of the form: U787A.001.1012345-P1-C5-L3

The location code for a virtual coherent accelerator (CA) function is formed by appending two S labels, the first specifying the identifier of the physical function and the second specifying the identifier of the logical function, both in decimal, to the location code of the physical CAPI adapter. A virtual CA function associated with physical function 1 and logical function 2 on the CAPI adapter at location U78CA.001.1234567-P1-C4-C1 would have location code: U78CA.001.1234567-P1-C4-C1-S1-S2

The set of all Vital Product Data (VPD) from the FRUs of a system is the product topology information which uniquely defines that system’s hardware and firmware elements. The system VPD describes a system in terms of various FRUs, part numbers, serial numbers and other characterizing features. With VPD, mechanisms may be provided for collecting information such as field performance and failure data on any FRU in a system. Also, with the feedback from the field into an installed system data base, the delivery of complete and accurate Miscellaneous Equipment Specifications (MESs) to customers can be assured. R1--1. FRUs used in LoPAR platforms must provide machine-readable VPD as defined in . R1--2. LoPAR platforms must support the collection of, and provide availability to, Vital Product Data. Platform Implementation Notes: It is the intent of this architecture that the FRUs of a system be self describing using VPD. There are FRU’s which have VPD which is not in the format described herein, such as JEDEC. In the case of use of these parts, the firmware may choose to translate the FRU VPD data into the LoPAR format when the OF device tree is being generated. For I/O adapters which have different VPD, their device driver must perform the reading and translation.

Architecture Note: Even though only a few large and small resource tags have been defined (see the ), the current definition will allow all possible tags except for (0x00). This will allow later devices with a new, previously undefined tag, to work. R1--1. Vital Product Data when reported to the OS via ibm,get-vpd or the OF device tree, must conform to the data structures describe in the , section 6.4The PCI 2.1 VPD keywords are PN, FN, EC, MN, SN, LI, RL, RM, NA, DD, DG, LL, VI, FU, SI, and Z0-ZZ, except as follows: The VPD will consist of only the following sequence of tags: Large Resource type identifier string tag (type 2, byte 0 = 0x82) with FRU name, Large Resource type VPD keywords tag (type 16, byte 0 = 0x90) with FRU VPD keywords, Small Resource type end tag (type 15) with or without checksum covering the above. Only resource tags, lengths and checksums are binary. All other data must be in ASCII format. Architecture Note: There are three keywords (FU, SI and VI) which allow binary data. There are no other exceptions. Also, the length code following a large resource tag is Little-Endian. That is, the first byte is the low order byte and the second byte is the high order byte of the length. Implementation Notes: Version 2.2 of the PCI Local Bus Specification changed the format and location of VPD information. With that change, a device with Version 2.2 VPD will result in no VPD being detected by the firmware. In this case the selected device driver will have to access and reformat the VPD information so that the format of the data provided to the OS is in the format which is required by the OS. The definition of a small resource tag is where bit 7 is 0. Then bit 6 through 3 are the type and bits 2 through 0 are the length. An end tag is a type of 15. Thus a 0x78 is a small resource end tag of length 0 and 0x79 is a small resource end tag of length 1. The valid end tags are 0x78 through 0x7F. R1--2. The end tag checksum, when provided to the OS, must cover all resources beginning with the first byte (a resource tag) up to, but not including, the Small Resource Type End tag. R1--3. If the platform determines that the VPD that it has collected is invalid, then the platform must discard any collected data and replace it with: Large Resource type identifier string tag (type 2, byte 0 = 0x82) with value ‘NOT_VALID_VPD’. Large Resource type VPD keywords tag (type 16, byte 0 = 0x90) containing the “YL” keyword and associated location code data. Small Resource Type End tag with or without a checksum covering the above. R1--4. If the device VPD is valid, all of the device VPD must be transferred including the Small Resource Type End Tag. R1--5. A “YL” keyword must be added to the Large Resource type VPD keywords tag (type 16, byte 0 = 0x90) when the VPD is reported to the OS via either the ibm,get-vpd RTAS call or the OF device tree. The checksum byte after the (0x79) resource tag will cause the binary sum of all the bytes from the first large resource tag, carries being discarded, to result in 0x00. As noted in Requirement , the (0x79) small resource tag is not included in this sum.

The exact format of the VPD is vendor-specific but falls within the specification as defined in the following subsections.

The fields defined in are stored in VPD modules at the time of manufacturing. R1--1. LoPAR platforms and FRUs must provide VPD fields marked as required in and for all VPD fields provided must adhere to the definitions specified by . R1--2. Each system must have VPD that contains the system’s SE keyword (see Requirements , , , and ) and the system’s TM keyword (see Requirements , , , and ). The description (large resource type of 0x82) for this VPD in the “ibm,vpd” property must be “System VPD”. R1--3. VPD for memory FRUs must contain the SZ keyword. Platform Implementation Note: There are circumstances where vendor preference or manufacturing processes may require that some fields be omitted (for example; Serial Number). This should be treated as an exception and should be accompanied by an appropriate level of risk assessment. In the case of an SN exception, the SN should be omitted, not made blank, NULL, or a fixed value. Keyword Data Type Data Length (Bytes) Required?A lack of a hard requirement in this column does not mean that the keyword is never required; only that it is not required all the time. Keywords which are not marked as “Required” are required when appropriate for the specific keyword. Description A1 ASCII Up to 16 -- Storage Facility Image MTMS - Logical ID Length (MTMS-a####). Linkage between logical entities. Examples: Used on Disk FRU resource to link disk to array site. Used on array site resource to link array site to array. Used on array resource to link array to rank. Used on rank resource to link rank to segment pool. AC ASCII Up to 32 -- Account Name Used on HMC resource. AD ASCII Up to 10 -- Addressing Field AP ASCII Up to 16 -- Asset Protection Key Password AS ASCII Up to 8 -- Reserved AT - - -- Reserved AX ASCII Up to 32 -- AIX name B1 ASCII A multiple of 16, up to a max of 240 -- Contains 1 to 15 instances of the following 16 byte definition, concatenated together. Contains the base ethernet MAC address and an instance count. The count specifies the number of valid MAC addresses starting with the base MAC address and incrementing by one for each successive MAC address, until the specified number of MAC addresses have been created. The field contains the ASCII coded hexadecimal representation of the binary value, as follows: Bytes 1 - 12 Base MAC address 13 - 14 Reserved (ASCII “00”) 15 - 16 Count B2 ASCII A multiple of 32, up to a max of 224 -- Contains 1 to 7 instances of the following 32 byte definition, concatenated together. SAS WWIDs. The Count field is the number of available WWIDs starting from the base and incrementing by 1 for each new WWID. The field contains the ASCII coded hexadecimal representation of the binary value, as follows: Bytes 1 - 16 Base SAS WWID 17 - 24 Reserved (ASCII “00000000”) 25 - 32 Count BC ASCII Up to 12 -- Bar Code BH ASCII 2 -- BatcH code - used for vintage if no serial number BR ASCII 2 -- Brand keyword value “xy” Note: The following are the values currently defined. To get other product specific values, go through the normal LoPAR change process. x = Type of machine “B” - Reserved “C” - Reserved “D” - Reserved “I” - Reserved “N” - Reserved “O” - Reserved “P” - Reserved “S” - IBM Power Systems™ platforms “T” - OEM Power Systems platforms Other values are reserved. y = Specific Information “0” - no specific information Other values are reserved. BT ASCII 10 -- Battery Replacement date in YYYY-MM-DD format. Used on Primary Power Supply FRU in rack enclosure. CC ASCII 4 Required when a CCIN is required by code to configure or service the component Customer Card Identification Number (CCIN) CE ASCII 1 -- CCIN Extender CD ASCII Up to 10 -- Card ID CI ASCII 16 -- CEC ID - of the CEC, that is the logical controller of an MTMS (machine-type-model-serial #), like a drawer. The 16 byte CI field definition is TTTT-MMM SSSSSSS where: TTTT-MMM is an 8 byte field. The high order 4 bytes are the system type, followed by a dash, followed by the 3 low order bytes which is the model. blank is a 1 byte separator character, that separates the type-model from the serial #. SSSSSSS is the 7 byte serial number. The high order 2 bytes are the “plant of manufacture” and the low order 5 bytes are the “sequence number”. CL ASCII Up to 32 -- Code Level, LID keyword Format: fix pack MIF name, “space”, Load ID (8 characters), time stamp (12 characters) The fix pack name must be the same as the name used in the MI keyword and is delimited by a space. The time stamp is, hours (2 characters) + Minutes (2 characters) + Year (4 characters) + Month (2 characters) + Day (2 characters). The LID level reported is the current active level. Note: There is no correlation between the CL keyword value and which of the 3 candidate fixpack levels are reported in the MI keyword. CN ASCII Up to 7 -- Customer Number CV ASCII Up to 4 -- Country Number DC ASCII 2 1 12                                     -- Action Code, timestamp blank (space) TimeStamp: yyyymmddhhmm Action Codes: BD = Build Date AM = added as MES AB = added as bulk MES AI = available at install ID = field install date AC = added with field EC AU = added from unknown source AR = added in repair action AT = added temporarily in field AH = added manually in field Returned on history file: RU = removed unknown (field) RR = removed in repair action RC = removed with EC RT = removed temporarily / powered off (field) RM = removed permanently (field) RN = removed to another system DD - - -- Reserved -- used for MicroChannel Architecture VPD DG - - -- Reserved -- used for MicroChannel Architecture VPD DU ASCII Up to 10 -- Drawer Unit DL ASCII Up to 10 -- Drawer Level DP ASCII Up to 255 -- Disk Space Characteristics Used on Disk resource. Comma separated string. Example (in the following, the “<“, “>”, and text in between these would be replaced by a value representing the quantity specified by the words between “<” and “>”): “VN=<Volume Serial Number>, VD=<Vendor>, DT=<Disk Type>, DC=<Disk-Capacity>, DR=<Disk-RPM>, DS=<Disk-Interface-Speed>, AP=<Array-Site-Position>, ST=<Status>” DS ASCII Up to 30 -- Displayable Message (if not defined, created by the contents of the ID large resource (82)) EA ASCII Up to 24 -- Electronic Message for electronic customer support (ECS) EC ASCII 12 Required if the part number is not changed with every modification Engineering Change Level (technical features, revision level, vintage level) ET ASCII 2 -- Enclosure Type. This value is defined in the . The ASCII value specified below is the ASCII representation of the hexadecimal representation of the byte value defined in the SMBIOS specification (for example, 0x0B becomes “0B”). Bit 7 of the byte number is the chassis lock bit (if present value is a 1, otherwise if either a lock is not present or it is unknown if the enclosure has a lock, the value is a 0). If the chassis lock bit is set, the following get changed to the corresponding ASCII representation (for example, “01” becomes “81”, “10” becomes “90”) “01” Other “02” Unknown “03” Desktop “04” Low Profile Desktop “05” Pizza Box “06” Mini Tower “07” Tower “08” Portable “09” LapTop “0A” Notebook “0B” Hand Held “0C” Docking Station “0D” All in One “0E” Sub Notebook “0F” Space-saving “10” Lunch Box “11” Main Server Chassis “12” Expansion Chassis “13” SubChassis “14” Bus Expansion Chassis “15” Peripheral Chassis “16” RAID Chassis “17” Rack Mount Chassis “18” Sealed-case PC FC ASCII 8 -- The Feature Code is 8 bytes formatted as 4 characters, a dash, and three characters. FD ASCII 7 -- Field Bill of Material (FBM) EC level FG ASCII 4 -- FlaG Field: The first two bytes contain a VPD flag in the form of VS. V=V indicates that there is VPD. V=N indicates there is no VPD. S=S indicates that the VPD contains a slot map. S=P indicates there is a port map. S=N indicates no slot map or port map. S=B indicates both a slot map and a port map. The right two characters contain the FRU identification keyword. FI ASCII 2 - 8 -- Frame ID: 2 hex byte value for SPCN or 8 character logical frame number for DASD backplane. FL ASCII Up to 16 -- FRU Label: This is a variable length ASCII character data area for the FRU Label. FN ASCII Up to 8 Required FRU Number (Board, card, or assembly Field Replacement Unit number). FU Binary Up to 10 -- Function Unit - This function identifies which function in a multi-function IOA this VPD data applies to. Only one FU field can appear per VPD tag. Data is binary encoded. H1 ASCII 1 -- Partition HSL Pool Used on a partition resource that is part of a storage facility image. ID ASCII 2 -- Two ASCII characters are used to identify each system in a Storage Facility. Valid values are 00 and 01. IF ASCII Up to 16 -- Storage Facility MTMS - InterfaceID Length (MTMS-####). Identifies one or more adapter I/O interfaces in the storage facility that interconnect device adapters and storage enclosures. Used on Device Adapter FRUs in I/O enclosure and on Storage Enclosures. Device Adapters have two Interfaces Ids (comma separated string), and storage enclosures have one. The number could change for future products.   L1 L2 L3 L4 L5 L6 ASCII   Up to 30 Up to 30 Up to 30 Up to 10 Up to 30 Up to 12 -- Location Information: Individual or Company Name Street Address City, State, Country Zip Code Contact Name Contact Phone Number LA ASCII 32 -- LIC Node Alternate Bus VPD: This fixed format data field contains 32 bytes of LIC I/O node alternate bus VPD data. LE ASCII Up to 17 -- LIC VMRF Example: SEA 5.1.0.0345. Used on a partition resource that is part of a storage facility image or on an enclosure or enclosure resource that has a firmware level. LI ASCII Up to 10 -- Adapter Software Identification LL ASCII Up to 10 -- Adapter Software Level LN ASCII 32 -- LIC Node VPD: Fixed format 32 bytes of VPD data. LO ASCII 2 -- Location (INternal/EXternal) LP ASCII 32 -- LIC Node Primary Bus VPD: Fixed format 32 bytes of VPD data. LS ASCII Up to 255 -- Logical Space Characteristics Used on Storage Logical resources. Examples: Used on Array resource. Comma separated string. Including: “AN=Array Serial Number, AT=Array-Type, AC=Array Configuration, Rank Position”. Used on Rank resource. Comma separated string. Including: “RN=Rank Serial Number, ST=Segment-Type(FB-1G, CKD-Mod1), SS=Segments(####), SU=Segments-Used, RG=Rank Group(#)”. Used on Segment Pool resource. Comma separated string. Including: “ST=Segment-Type(FB-1G, CKD-Mod1), SS=Segments(####), SU=Segments-Used, VS=Virtual-Segments(####), VU=Virtual-Segments-Used(####)”, RG=Rank-Group(#). MD ASCII 4 -- Model Number: 3 characters with a leading blank. ME ASCII 8 -- Microcode Service Entitlement Expiration Date This is the date a customer's system firmware service warranty period expires. System firmware images with MG dates that are later than a system's ME date are not entitled to be flashed on that system. Format:yyyymmdd MF ASCII 2 -- Map Format: Two hex characters identify the slot or port map format that follows. This keyword must immediately precede the SM or PM keyword. MG ASCII 8 -- Microcode General Availability/Release Date This is the date the system firmware image was released and published for customer use. Format:yyyymmdd MI ASCII Up to 40 -- Microcode Image This keyword is only used to describe dual sided alterable system firmware Image which can be altered by the OS via the ibm,update-flash-64-and-reboot RTAS call. Both the ibm,validate-flash-image and the ibm,manage-flash-image RTAS calls are supported. May or may not be able to be updated via non-OS visible means. Format: t side Microcode Image name, “space”, p side Microcode Image name, “space”, booted Microcode Image name The Microcode Image name must be a 9 character name of the form: “NNSSS_FFF” where “NN” is a two character name (assigned by the GFW Firmware Distribution Coordinator) used to identify a set of platforms; “SSS” is a 3 character code stream indicator; “_” is a separation character for readability; and, “FFF” is a 3 character identifier of the current microcode level. Note: The booted fix pack level reported may not match the current p-side or t-side level as a result of concurrent update. The important information is what is in flash, and that is what is being reported. The hypervisor will have to cache the value for the booted level, and should go to FSP to check what's current on flash for the p-side and t-side levels. ML ASCII Up to 40 -- Microcode Level This keyword is only used to describe dual sided alterable system firmware images which can be altered by the OS via the ibm,update-flash-64-and-reboot RTAS call. Both the ibm,validate-flash-image and the ibm,manage-flash-image RTAS calls are supported. May or may not be able to be updated via non-OS visible means. Format: t side Microcode Level name, “space”, p side Microcode Level name, “space”, booted Microcode Level name The Microcode Image name must be a 8 character name of the form: “FWVRE.MF” where "FW" is a static prefix representing 'firmware' “V” is Version - Power Processor Level "R" is Revision - Typically GA number from the processor level "E" is Extension - Typically zero. If non-zero, designates off cycle single system release "M" is Modification - associated Service Pack Level (0-Z) "F" is Fix Level - Typically zero. If non-zero, designate off cycle, targeted fixes Note: The booted fix pack level reported may not match the current p-side or t-side level as a result of concurrent update. The important information is what is in flash, and that is what is being reported. The hypervisor will have to cache the value for the booted level, and should go to FSP to check what's current on flash for the p-side and t-side levels. MN ASCII 10 -- Manufacturer ID (source of device, name and location) MP ASCII 3 -- Module Plug count. This counter keeps track of the numbers of times a module has been plugged, so that reliability statistics can be kept. MS ASCII Up to 6 -- MES Number MU ASCII 32 -- Machine Universal Unit ID (UUID). The value is the ASCII coded hexadecimal representation of the 16 byte binary value. N5 ASCII Up to 228 -- Processor CoD Capacity Card Info N6 ASCII Up to 231 -- Memory CoD Capacity Card Info N7 ASCII Up to 144 -- Processor on Demand billing data N8 ASCII Up to 145 -- Memory on Demand billing data NA ASCII Up to 16 -- Network Address (ASCII coded hexadecimal representation of the binary value.) NC ASCII Up to 25 -- This keyword is used to describe the prefix name of the file used to install a single sided alterable system firmware or adapter/device microcode image. When this keyword is present, the complete file name will be described by the content of the NC keyword, concatenated with “.”, concatenated with the content of the RM keyword. NN ASCII 16 -- World Wide Node Name - IEEE assigned 64 bit identifier (16 hexadecimal digits) for Storage Facility. Valid values are 0-9, A-F. NT ASCII Up to 32 -- Sub-machine type NV ASCII Up to 24 -- NVRAM ID, part number, location and size NX - - -- Reserved OS ASCII Up to 17 -- OS name and level. The OS level is shown in the form of: V.R.M.F where V is the version, R is the release, M is the modification, and F is the fix. PA ASCII 1 -- Op Panel installed flag. “Y” = yes a panel is installed, “N” = no a panel is not installed. The absence of this keyword means, that an Op Panel is installed. PC ASCII Up to 16 -- Processor Component Definition PD ASCII Up to 8 -- Power dissipation/consumption PI ASCII Up to 8 -- Processor ID or unique ID (used for licensing control) PL ASCII Up to 32 -- Location code PM ASCII Up to 16 -- Port Map: Contains the RIO Port Map label information. Must be preceded by the MF keyword. PN ASCII 12 Required if it is different from the FRU number (FN) Part number of assembly. PO ASCII Up to 16 -- SPCN VPD: Identification of the SPCN VPD area on the I/O backplane. PP ASCII 32 -- Power Parameters: SPCN field identifying Power node parameters. PR ASCII 16 -- Power: 16 ASCII hexadecimal characters that represent the 8 bytes of binary information for Power Control. R1 ASCII Up to 16 -- Rack MTMS - Rack Location Length (MTMS-Exx). - used on storage enclosure resources. R2 ASCII 1 -- Rack Number Used on Rack enclosure resources. Provides an ordered number of racks in the storage facility. RA - - -- Reserved RD ASCII 16 -- Power Domain ID - is the MTMS of the BPA, that powers an MTMS (Machine-Type-Model-Serial #), like a CEC or drawer. The 16 byte RD field definition is: TTTT-MMM SSSSSSS where: TTTT-MMM is an 8 byte field. The high order 4 bytes are the system type, followed by a dash, followed by the 3 low order bytes which is the model. blank is a 1 byte separator character, that separates the type-model from the serial #. SSSSSSS is the 7 byte serial number. The high order 2 bytes are the “plant of manufacture” and the low order 5 bytes are the “sequence number”. RI ASCII 4 -- Power Resource ID: A 4 byte hex field providing a unique logical ID for the power resource. RJ ASCII Up to 16 -- RIO-G Loop Used on I/O enclosure resource. Identifies RIO-G loop on the reporting system. RK ASCII 16 -- Rack Unique ID - is the 64 bit Dallas “1-wire” unique ROM code. The first 8 bits are a 1-Wire family code. The next 48 bits are a unique serial number. The last 8 bits are a CRC of the first 56 bits. Each of the 16 4-bit nibbles are converted to 16 ASCII characters, in the range 0-9 or A-F. RL ASCII Up to 24 -- This keyword is only used to describe single sided non-alterable system firmware or adapter/device microcode image which can not be altered by any means; OS visible or non-OS visible. A single alphanumeric character string that defines the level of the image. ROM id, Location ID, ROM part number, FW part number, FW level, FW code, release date, FW size. RM ASCII Up to 25 -- This keyword is only used to describe single sided alterable system firmware or adapter/device microcode image which can be altered by the OS. The OS alters the system firmware image via the ibm,update-flash-64-and-reboot RTAS call. Neither the ibm,validate-flash-image nor the ibm,manage-flash-image RTAS calls are supported. May or may not be able to be updated via non-OS visible means. A single alphanumeric character string that defines the level of the image. ROM id, Location ID, ROM part number, FW part number, FW level, FW code, release date, FW size RN ASCII Up to 2 -- Rack Name RP ASCII 1 -- RIO-G Position Offset Used on I/O enclosure resource. Identifies the distance in enclosures from the reporting system - first enclosure is offset 1. RS ASCII Up to 128 -- IBM LoPAR Compliant platform unique VPD: Start of a data area. RT ASCII 4 -- Record Type. Contains a four character Record Name that represents a VPD Definition. The following list associates Record Names with their VPD Definitions. “VSYS” - System MTMS VPD “VCEN” - Enclosure MTMS VPD “VINI” - FRU VPD record RW - - -- Reserved RX ASCII Up to 25 -- This keyword is only used to describe single sided microcode image which can not be altered by the OS, but may be updated via non-OS visible means. A single alphanumeric character string that defines the level of the image. S1 ASCII Up to 8 -- Serial Number of attached machine S3 ASCII 16 -- Storage Facility MTMS Length (MTMS). Used on system resource, partition resources, array-site, resources, array resources, rank resources, storage pool resources, and enclosure resources in a storage facility to identify the storage facility. S4 ASCII Up to 16 -- Storage Facility Image MTMS Length (MTMS). Used on partition, array-site, array, rank, and storage pool, and enclosure-FRU resources, associated with a storage facility image. SC ASCII Up to 44 -- Specify codes SE ASCII Up to 7 See Requirements , , , , and Machine or Cabinet Serial Number. SF ASCII Up to 8 -- Field Change Shipping Instruction (FCSI) number SG ASCII 7 -- 2 high order bytes are the “plant of manufacture code”, followed by the low order 5 bytes, which are the “unit sequence number”. This unit sequence number must be DDDD0, ADDD0, AADD0, AAAD0, or AAAA0 where D is a digit 0-9 and A is an alphabetic character A-Z excluding E, I, J, O, Q, S, U. The right most character of the unit sequence number must be set to 0. SI Binary Up to 10 -- Subsystem Vendor ID. Data is binary encoded. SL - - -- Reserved SM ASCII Up to 16 -- Slot Map: Contains Slot Map information. Must be preceded by the MF keyword. SN ASCII 12 Required and must be unique for each part with the same FN Serial Number 12 characters. SU ASCII 12 See notes The System Unique Identifier (SUID) is a twelve hexadecimal character value that is unique to a given system anywhere in the world. The number range is obtained from the Institute of Electrical and Electronic Engineers. There are no IBM asset protection considerations involved. SY ASCII 7 -- System Number (only one allowed) SZ ASCII Up to 10 For memory FRUs, see Requirement Size in decimal, with no leading zeroes. For memory (for example, cards and DIMMs), it provides the memory size in MB’s. As an example, a 32 GB memory card would be coded as 32768. Tl ASCII 8 -- Attached machine type-model TM ASCII 8 See Requirements , , , , and The high order 4 bytes are the “Machine Type”, the next byte is a dash, followed by the 3 byte “Model”. TN ASCII 8 -- The high order 4 bytes are the “Machine Type”, the next byte is a dash, followed by the 3 byte “Model”. U1 ASCII Up to 255 -- Logical Configuration String Used on a partition resource that is: CKD3380=####, CKD3390=####, SCSI512=####, SCSI520=####, SCSI Host Ports=####, SCSI LUN Groups=####. Used on device adapter or host adapter FRU for logical configuration information, if any. Used on Storage Enclosure. Comma separated string including “BA=Base Address(xx)”. U2 ASCII Up to 255 -- Host Inventory Used on a partition resource that is part of a storage facility image for storage facility image logical configuration. Comma separated string. Including: “Host OS Type1=####, Host OS Type 2=####, . . .”. U3 ASCII Up to 255 -- Reserved for future use. Used on partition resource or Storage Configuration resources. U4 ASCII Up to 255 -- Reserved for future use. Used on partition resource or Storage Configuration resources. U5 ASCII Up to 255 -- Reserved for future use. Used on partition resource or Storage Configuration resources. U6 ASCII Up to 255 -- Reserved for future use. Used on partition resource or Storage Configuration resources. U7 ASCII Up to 255 -- Reserved for future use. Used on partition resource or Storage Configuration resources. U8 ASCII Up to 255 -- Reserved for future use. Used on partition resource or Storage Configuration resources. U9 ASCII Up to 255 -- Reserved for future use. Used on partition resource or Storage Configuration resources. VE - - -- Reserved -- used for MicroChannel Architecture VPD VI Binary Up to 10 -- Vendor ID / Device ID Only one VI may appear per VPD tag. WN ASCII 16 -- Contains the ASCII coded hexadecimal World Wide Port Name (WWPN). YK ASCII 4 See Requirement Ties together multiple enclosures that share the same combined SE and TM. Notes referenced in : When the BR keyword indicates “S” or “T” for the type of machine, this field must be present and must be non-blank. Implementation Note: The following keywords are defined in this architecture with the same or similar usage: AD, CD, DC, DL, DS, DU, EC, FC, FN, LO, NA, P C, PI, PN, RL, RN, SN, SZ, TM, and US.

Three fields are available for user, system or product specific data for which no unique keyword has been defined. The first and second ranges of fields in the list are not addressed in the PCI Specifications and are unique to LoPAR platforms. U0 - UZ User specific N0 - NF ReservedV0 - VF Reserved Y0 - YZ System Information specific Z0 - ZZ Product specific Note: If firmware/software has a specific need for a keyword, then it must be provided by the appropriate component VPD. The Y? and Z? fields defined in are specific to LoPAR platforms. As a need for these fields is determined, they will be defined in this document. The table contains several keywords which have been defined as place holders. Keyword Data Type Data Length (Bytes) Description N5 ASCII Up to 56 Processor CoD Capacity Card Info per N6 ASCII Up to 56 Memory CoD Capacity Card Info per U? ASCII Up to 128 User Data:? = 0...9, A...Z Y0 ASCII 64 2 2 24 24 12 Board Repair Actions: # times board repaired # times board updated with code patches Copy of system ID Y2 field Copy of system ID TM field Copy of system ID PI field Y1 ASCII 24 2 2   8 12 Error Descriptor: # allowable messages # valid messages Messages of 20 bytes each, first, last and most recent 4 messages Error Code Date/Time Stamp: yyyymmddhhmm Y2 ASCII 24 4 4 4 12 Only in system VPD EEPROM: Manufacturer’s Location Machine Type Model ID Cabinet Serial Number YK ASCII Up to 4 Ties together multiple enclosures that share the same combined SE and TM. See Requirement . YL ASCII Up to 255 Hardware Location Code (see ) Z? ASCII Up to 255 Product Specific Information: may be keyword oriented and ‘,’ delimited.