<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright (c) 2016, 2020 OpenPOWER Foundation
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<chapter xmlns= "http://docbook.org/ns/docbook"
xmlns:xl="http://www.w3.org/1999/xlink"
xml:id="dbdoclet.50569341_39268"
version="5.0"
xml:lang="en">
<title > Product Topology</title>
<section xml:id= "dbdoclet.50569341_34882" >
<title > VPD and Location Code OF Properties</title>
<para > A set of OF properties is defined to facilitate asset protection and
RAS capabilities in LoPAR systems. The following properties are defined in
<xref linkend= "dbdoclet.50569368_31220" /> ):</para>
<itemizedlist >
<listitem >
<para > <emphasis role= "bold" > <literal > “ ibm,vpd” </literal> </emphasis> </para>
</listitem>
<listitem >
<para > <emphasis role= "bold" > <literal > “ ibm,loc-code” </literal> </emphasis> </para>
</listitem>
</itemizedlist>
<variablelist >
<varlistentry xml:id= "dbdoclet.50569341_64684" >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_34882"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis> </term>
<listitem >
<para > 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
<emphasis role= "bold" > <literal > “ ibm,loc-code” </literal> </emphasis> property with a value that represents
the location code for that hardware entity.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_34882"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis> </term>
<listitem >
<para > 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 <emphasis role= "bold" > <literal > “ ibm,loc-code” </literal> </emphasis> property.</para>
<para > <emphasis role= "bold" > Architecture Note:</emphasis> 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
<emphasis role= "bold" > <literal > openprom</literal> </emphasis> node is a system node and thus should have neither the
<emphasis role= "bold" > <literal > “ ibm,loc-code” </literal> </emphasis> property nor the
<emphasis role= "bold" > <literal > “ ibm,vpd” </literal> </emphasis> property. </para>
</listitem>
</varlistentry>
<varlistentry xml:id= "dbdoclet.50569341_27357" >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_34882"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis> </term>
<listitem >
<para > 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 <emphasis role= "bold" > <literal > “ ibm,vpd” </literal> </emphasis> property.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_34882"
xrefstyle="select: labelnumber nopage"/>-4.</emphasis> </term>
<listitem >
<para > An instance of a hardware entity (FRU) must
have one and only one <emphasis role= "bold" > <literal > “ ibm,vpd” </literal> </emphasis> property
element that defines the VPD keywords specified in Requirement
<xref linkend= "dbdoclet.50569341_55947" /> .</para>
<para > <emphasis role= "bold" > Platform Implementation Note:</emphasis> In general, an
instance of a hardware entity has a single <emphasis role= "bold" > <literal > “ ibm,vpd” </literal> </emphasis>
property element that is in one of the nodes that also contains an
<emphasis role= "bold" > <literal > “ ibm,loc-code” </literal> </emphasis> property element for that
entity.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_34882"
xrefstyle="select: labelnumber nopage"/>-5.</emphasis> </term>
<listitem >
<para > An OF device tree node that includes the
<emphasis role= "bold" > <literal > “ ibm,vpd” </literal> </emphasis> property must also include an
<emphasis role= "bold" > <literal > “ ibm,loc-code” </literal> </emphasis> 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 <emphasis role= "bold" > <literal > “ ibm,loc-code” </literal> </emphasis>
property and the nth set of tags in
the <emphasis role= "bold" > <literal > “ ibm,vpd” </literal> </emphasis> property for all values of
n.</para>
</listitem>
</varlistentry>
<varlistentry xml:id= "dbdoclet.50569341_63284" >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_34882"
xrefstyle="select: labelnumber nopage"/>-6.</emphasis> </term>
<listitem >
<para > 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 <emphasis role= "bold" > <literal > “ ibm,loc-code” </literal> </emphasis> and
<emphasis role= "bold" > <literal > “ ibm,vpd” </literal> </emphasis> properties. </para>
</listitem>
</varlistentry>
</variablelist>
<para > <emphasis role= "bold" > Architecture Notes:</emphasis> </para>
<itemizedlist >
<listitem >
<para > The root node is the appropriate OF node (for Requirement <xref
linkend="dbdoclet.50569341_63284"/>) 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.</para>
</listitem>
<listitem >
<para > A dynamically reconfigurable entity may consist of more than one
FRU. In this case, the first element of both the <emphasis role= "bold" > <literal > “ ibm,vpd” </literal> </emphasis>
property and the <emphasis role= "bold" > <literal > “ ibm,loc-code” </literal> </emphasis> property for the dynamically
reconfigurable entity must define the VPD and location code for the OF device
tree node that includes those properties.</para>
</listitem>
<listitem >
<para > 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. </para>
</listitem>
</itemizedlist>
<para > <emphasis role= "bold" > Platform Implementation Note:</emphasis> If a location
does not return VPD, the property would contain a null entry for the VPD.</para>
</section>
<section xml:id= "dbdoclet.50569341_23269" >
<title > System Identification</title>
<para > <xref linkend= "dbdoclet.50569368_91814" /> provides properties in the
“ OF Root Node” section called <emphasis role= "bold" > <literal > “ system-id” </literal> </emphasis>
and<emphasis role= "bold" > <literal > “ model” </literal> </emphasis> .</para>
<variablelist >
<varlistentry xml:id= "dbdoclet.50569341_50574" >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_23269"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis> </term>
<listitem >
<para > <emphasis > (Requirement Number Reserved For Compatibility)</emphasis> </para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_23269"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis> </term>
<listitem >
<para > Each system enclosure (generally, a drawer),
must have the VPD SE and TM keywords (see <xref linkend= "dbdoclet.50569341_47429" /> ).</para>
</listitem>
</varlistentry>
<varlistentry xml:id= "dbdoclet.50569341_39729" >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_23269"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis> </term>
<listitem >
<para > The SE and TM keywords for a
master enclosure must be contained in the <emphasis role= "bold" > <literal > “ ibm,vpd” </literal> </emphasis>
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 <xref linkend= "dbdoclet.50569341_47429" /> ) for a secondary
enclosure must be contained in the <emphasis role= "bold" > <literal > “ ibm,vpd” </literal> </emphasis>
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.</para>
</listitem>
</varlistentry>
<varlistentry xml:id= "dbdoclet.50569341_31199" >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_23269"
xrefstyle="select: labelnumber nopage"/>-4.</emphasis> </term>
<listitem >
<para > The enclosure must also be
represented in the corresponding element of the <emphasis role= "bold" > <literal > “ ibm,loc-code” </literal> </emphasis>
property with the location code of the
enclosure for a multi-enclosure platform.</para>
<para > <emphasis role= "bold" > Implementation Note:</emphasis> 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.</para>
</listitem>
</varlistentry>
<varlistentry xml:id= "dbdoclet.50569341_98827" >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_23269"
xrefstyle="select: labelnumber nopage"/>-5.</emphasis> </term>
<listitem >
<para > If the system contains multiple processor enclosures, firmware
must use the VPD SE field from the first or ‘ marked’ processor
enclosure (see <xref linkend= "dbdoclet.50569341_47429" /> ) to
construct <emphasis role= "bold" > <literal > “ system-id” </literal> </emphasis> .</para>
<para > <emphasis role= "bold" > Implementation Note:</emphasis> 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.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_23269"
xrefstyle="select: labelnumber nopage"/>-6.</emphasis> </term>
<listitem >
<para > 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: </para>
<orderedlist numeration= "loweralpha" >
<listitem >
<para > The RL keyword must be provided if the platform does not support
the <emphasis > ibm,update-flash-64-and-reboot</emphasis> RTAS call. </para>
</listitem>
<listitem >
<para > The RM keyword must be provided if the platform supports only a
single flash image updated via the <emphasis > ibm,update-flash-64-and-reboot</emphasis>
service and does not support the <emphasis > ibm,manage-flash-image</emphasis> and
<emphasis > ibm,validate-flash-image</emphasis> RTAS calls. </para>
</listitem>
<listitem >
<para > The MI keyword must be provided if the platform supports dual
flash images via the <emphasis > ibm,update-flash-64-and-reboot</emphasis> , the
<emphasis > ibm,manage-flash-image</emphasis> , and the <emphasis > ibm,validate-flash-image</emphasis>
RTAS calls.</para>
</listitem>
<listitem >
<para > The ML keyword must be provided if the platform supports dual
flash images via the <emphasis > ibm,update-flash64-and-reboot</emphasis> ,
the <emphasis > ibm,manage-flash-image</emphasis> , and the <emphasis > ibm,validate-flash-image</emphasis>
RTAS calls.</para>
</listitem>
</orderedlist>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_23269"
xrefstyle="select: labelnumber nopage"/>-7.</emphasis> </term>
<listitem >
<para > 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.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_23269"
xrefstyle="select: labelnumber nopage"/>-8.</emphasis> </term>
<listitem >
<para > The description (large resource type of
0x82) for the system firmware VPD in the <emphasis role= "bold" > <literal > “ ibm,vpd” </literal> </emphasis>
property must be “ System Firmware or
Platform Firmware” . </para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_23269"
xrefstyle="select: labelnumber nopage"/>-9.</emphasis> </term>
<listitem >
<para > System firmware VPD must be found in the
<emphasis role= "bold" > <literal > root</literal> </emphasis> node if the system supports only static VPD,
otherwise system firmware VPD must be provided via the
<emphasis > ibm,get-vpd</emphasis> RTAS call.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_23269"
xrefstyle="select: labelnumber nopage"/>-10.</emphasis> </term>
<listitem >
<para > The description (large resource type of
0x82) for the service processor firmware VPD in the <emphasis role= "bold" > <literal > “ ibm,vpd” </literal> </emphasis>
property must be “ Service Processor
Firmware” , if the service processor firmware is a separate FRU from the
system firmware.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_23269"
xrefstyle="select: labelnumber nopage"/>-11.</emphasis> </term>
<listitem >
<para > Service processor firmware VPD must be
found in the root node if the service processor firmware is a separate FRU from
the system firmware.</para>
</listitem>
</varlistentry>
<varlistentry xml:id= "dbdoclet.50569341_39191" >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_23269"
xrefstyle="select: labelnumber nopage"/>-12.</emphasis> </term>
<listitem >
<para > The VPD SE field (see <xref linkend= "dbdoclet.50569341_47429" /> )
must be electronically stored in a manner that is not modifiable in a user
environment. </para>
</listitem>
</varlistentry>
<varlistentry xml:id= "dbdoclet.50569341_14313" >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_23269"
xrefstyle="select: labelnumber nopage"/>-13.</emphasis> </term>
<listitem >
<para > There must be a property, <emphasis role= "bold" > <literal > “ model” </literal> </emphasis> ,
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 <xref linkend= "dbdoclet.50569341_47429" /> ) of the first or
‘ marked’ processor enclosure.</para>
</listitem>
</varlistentry>
<varlistentry xml:id= "dbdoclet.50569341_68839" >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_23269"
xrefstyle="select: labelnumber nopage"/>-14.</emphasis> </term>
<listitem >
<para > The values of the type/model (TM) and system serial number (SE)
(see <xref linkend= "dbdoclet.50569341_47429" /> ) must remain the same even with
service or reconfiguration of the system. </para>
<para > <emphasis role= "bold" > Implementation Note:</emphasis> A change in either TM or
SE would indicate a system replacement as opposed to a reconfiguration.</para>
</listitem>
</varlistentry>
</variablelist>
<para > This definition of the<emphasis role= "bold" > <literal > “ system-id” </literal> </emphasis>
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. </para>
<para > <emphasis role= "bold" > Hardware Implementation Note:</emphasis> 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.</para>
</section>
<section xml:id= "dbdoclet.50569341_35066" >
<title > Hardware Location Codes</title>
<para > 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:</para>
<orderedlist >
<listitem >
<para > These location codes would be included as a property,
<emphasis role= "bold" > <literal > “ ibm,loc-code” </literal> </emphasis> , under device nodes in
the OF device tree, to provide identification of where those device functions
are physically located in the platform.</para>
</listitem>
<listitem >
<para > 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 <emphasis > event-scan</emphasis> and
<emphasis > check-exception</emphasis> services. </para>
</listitem>
</orderedlist>
<para > <emphasis role= "bold" > Software Note:</emphasis> 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.</para>
<para > Location Codes are globally unique within a system and are persistent
between system reboots and power cycles.</para>
<variablelist >
<varlistentry xml:id= "dbdoclet.50569341_25472" >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_35066"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis> </term>
<listitem >
<para > All platforms must implement the
Converged Location Codes option.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_35066"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis> </term>
<listitem >
<para > 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.</para>
</listitem>
</varlistentry>
</variablelist>
<para > Converged location codes<footnote xml:id= "pgfId-997585" > <para > The
term “ converged” is historic, based on merging (converging)
several previous versions of location codes.</para> </footnote> 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: </para>
<itemizedlist mark= "none" >
<listitem >
<para > U7879.001.1012345-P2-C3</para>
</listitem>
</itemizedlist>
<para > 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.</para>
<para > The existence of the
<emphasis role= "bold" > <literal > “ ibm,converged-loc-codes” </literal> </emphasis> property in the
<emphasis role= "bold" > <literal > root</literal> </emphasis> node of the device tree indicates that the platform implements
the Converged Location Codes option.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_35066"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis> </term>
<listitem >
<para > <emphasis role= "bold" > For the Converged Location Codes
option:</emphasis> The platform must implement the <emphasis role= "bold" > <literal > “ ibm,converged-loc-codes” </literal> </emphasis>
property in the <emphasis role= "bold" > <literal > root</literal> </emphasis> node of the device tree.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_35066"
xrefstyle="select: labelnumber nopage"/>-4.</emphasis> </term>
<listitem >
<para > <emphasis role= "bold" > For the Converged Location Codes
option:</emphasis> The location code contained in each instance of the
property <emphasis role= "bold" > <literal > “ ibm,loc-code” </literal> </emphasis> must match the
format as described in the sections under <xref linkend= "dbdoclet.50569341_81497" /> and
<xref linkend= "dbdoclet.50569341_41991" /> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_35066"
xrefstyle="select: labelnumber nopage"/>-5.</emphasis> </term>
<listitem >
<para > <emphasis role= "bold" > For the Converged Location Codes
option:</emphasis> Extended error logs reported to the OS by <emphasis > event-scan</emphasis>
or<emphasis > check-exception</emphasis> 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 <xref linkend= "dbdoclet.50569341_81497" /> and
<xref linkend= "dbdoclet.50569341_41991" /> . </para>
</listitem>
</varlistentry>
</variablelist>
<section xml:id= "dbdoclet.50569341_81497" >
<title > Converged Location Code Labels</title>
<para > This section describes the types of location code labels. See also
<xref linkend= "dbdoclet.50569341_41991" /> for the rules for building a location
code.</para>
<section >
<title > Prefix Summary Table</title>
<para > The prefix of a converged location code is as defined in this
section.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_81497"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis> </term>
<listitem >
<para > <emphasis role= "bold" > For the Converged Location
Codes option:</emphasis> The location code prefixes specified in
<xref linkend= "dbdoclet.50569341_97021" /> must be used in constructing location
codes.</para>
</listitem>
</varlistentry>
</variablelist>
<table frame= "all" pgwide= "1" xml:id= "dbdoclet.50569341_97021" >
<title > Converged Location Code Prefix Values </title>
<tgroup cols= "2" >
<colspec colname= "c1" colwidth= "20*" align= "center" />
<colspec colname= "c2" colwidth= "80*" />
<thead valign= "middle" >
<row >
<entry >
<para >
<emphasis role= "bold" > Prefix</emphasis>
</para>
</entry>
<entry align= "center" >
<para >
<emphasis role= "bold" > Meaning</emphasis>
</para>
</entry>
</row>
</thead>
<tbody valign= "middle" >
<row >
<entry >
<para > A</para>
</entry>
<entry >
<para > Air handler (for example: blower, fan, motor scroll
assembly, motor drive assembly). <xref linkend= "dbdoclet.50569341_Air-Handler-Location-Label" /> .</para>
</entry>
</row>
<row >
<entry >
<para > C</para>
</entry>
<entry >
<para > 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).
<xref linkend= "dbdoclet.50569341_Card-Location-Label" /> .</para>
</entry>
</row>
<row >
<entry >
<para > D</para>
</entry>
<entry >
<para > Device (for example: Diskette, DASD, Operator Panel, SES
(Storage Enclosure Services) Device).
<xref linkend= "dbdoclet.50569341_Device-Location-Label" /> .</para>
</entry>
</row>
<row >
<entry >
<para > E</para>
</entry>
<entry >
<para > Electrical (for example: Battery, Power Supply,
Charger). <xref linkend= "dbdoclet.50569341_Electrical-Location-Label" /> .</para>
</entry>
</row>
<row >
<entry >
<para > F</para>
</entry>
<entry >
<para > Frame. See
<xref linkend= "dbdoclet.50569341_43571" /> .</para>
</entry>
</row>
<row >
<entry >
<para > L</para>
</entry>
<entry >
<para > Logical Path (for example: SCSI Target, IDE Address,
ATAPI Address, Fibre Channel LUN, etc.).
<xref linkend= "dbdoclet.50569341_Logical-Path-Label1" /> .</para>
</entry>
</row>
<row >
<entry >
<para > M</para>
</entry>
<entry >
<para > Mechanical (Plumbing, Valves, Latches). See
<xref linkend= "dbdoclet.50569341_55481" /> .</para>
</entry>
</row>
<row >
<entry >
<para > N</para>
</entry>
<entry >
<para > Horizontal placement for an empty rack location. See
<xref linkend= "dbdoclet.50569341_88482" /> .</para>
</entry>
</row>
<row >
<entry >
<para > P</para>
</entry>
<entry >
<para > Planar (for example: Backplane, Board).
<xref linkend= "dbdoclet.50569341_33230" /> .</para>
</entry>
</row>
<row >
<entry >
<para > R</para>
</entry>
<entry >
<para > Resource (identifies a resource that is not a FRU, but
needs identification in the error log). See
<xref linkend= "dbdoclet.50569341_70735" /> .</para>
</entry>
</row>
<row >
<entry >
<para > S</para>
</entry>
<entry >
<para > SR-IOV adapter virtual function. See
<xref linkend= "dbdoclet.50569341_40590" /> .</para>
</entry>
</row>
<row >
<entry >
<para > T</para>
</entry>
<entry >
<para > Port (for example: Port, Connector, Cable Connector,
Jack, Interposer).
<xref linkend= "dbdoclet.50569341_Port-Location-Label" /> .</para>
</entry>
</row>
<row >
<entry >
<para > U</para>
</entry>
<entry >
<para > Unit (for example: System, CEC, Card Cage, Drawer,
Chassis (Unpopulated drawer)).
<xref linkend= "dbdoclet.50569341_Unit-Location-Label" /> .</para>
</entry>
</row>
<row >
<entry >
<para > V</para>
</entry>
<entry >
<para > Virtual Planar. See <xref linkend= "dbdoclet.50569341_42347" /> .</para>
</entry>
</row>
<row >
<entry >
<para > W</para>
</entry>
<entry >
<para > Worldwide unique ID (for example: Fibre Channel).
<xref linkend= "dbdoclet.50569341_Worldwide-Unique-Identifer" /> .</para>
</entry>
</row>
<row >
<entry >
<para > X</para>
</entry>
<entry >
<para > EIA value for empty rack location. See
<xref linkend= "dbdoclet.50569341_19418" /> .</para>
</entry>
</row>
<row >
<entry >
<para > Y</para>
</entry>
<entry >
<para > Firmware FRU. See <xref linkend= "dbdoclet.50569341_39159" /> .</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</section>
<section xml:id= "dbdoclet.50569341_Unit-Location-Label" >
<title > Unit Location Label</title>
<para > 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.</para>
</section>
<section xml:id= "dbdoclet.50569341_33230" >
<title > Planar Location Label</title>
<para > 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.</para>
<para > Planars are uniquely labeled within a unit.</para>
</section>
<section xml:id= "dbdoclet.50569341_Air-Handler-Location-Label" >
<title > Air Handler Location Label</title>
<para > 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.</para>
<para > Examples of air handlers include blowers and fans.</para>
</section>
<section xml:id= "dbdoclet.50569341_Card-Location-Label" >
<title > Card Connector Location Label</title>
<para > 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.</para>
<para > 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.</para>
</section>
<section xml:id= "dbdoclet.50569341_Device-Location-Label" >
<title > Device Location Label</title>
<para > 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.</para>
<para > 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.</para>
</section>
<section xml:id= "dbdoclet.50569341_Electrical-Location-Label" >
<title > Electrical Location Label</title>
<para > 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.</para>
<para > Examples of electrical resources include: batteries, power
supplies, and chargers.</para>
</section>
<section xml:id= "dbdoclet.50569341_Port-Location-Label" >
<title > Port Location Label</title>
<para > 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.</para>
<para > Examples of resources with a port location label include: ports,
connectors, cable connectors, jacks, and interposers.</para>
</section>
<section xml:id= "dbdoclet.50569341_Worldwide-Unique-Identifer" >
<title > Worldwide Unique Identifier</title>
<para > 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.</para>
</section>
<section xml:id= "dbdoclet.50569341_Logical-Path-Label1" >
<title > Logical Path Label</title>
<para > A logical path location label consists of the prefix
“ L” followed by a decimal or hexadecimal number with no leading
zeros. Refer to <xref linkend= "dbdoclet.50569341_26909" /> through
<xref linkend= "sec_nvme_device_logical_path_location_codes" /> 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.</para>
<para > 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.</para>
</section>
<section xml:id= "dbdoclet.50569341_42347" >
<title > Virtual Planar Location Label</title>
<para > 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.</para>
<para > Virtual planars are uniquely labeled within a system.</para>
</section>
<section xml:id= "dbdoclet.50569341_39159" >
<title > Firmware Location Label</title>
<para > 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.</para>
</section>
<section xml:id= "dbdoclet.50569341_88482" >
<title > Horizontal Placement Location Label</title>
<para > 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.</para>
</section>
<section xml:id= "dbdoclet.50569341_19418" >
<title > EIA Location Label</title>
<para > 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.</para>
</section>
<section xml:id= "dbdoclet.50569341_43571" >
<title > Frame Location Label</title>
<para > 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.</para>
</section>
<section xml:id= "dbdoclet.50569341_40590" >
<title > Virtual Function Location Label</title>
<para > 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.</para>
</section>
<section xml:id= "dbdoclet.50569341_55481" >
<title > Mechanical Location Label</title>
<para > 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. </para>
<para > Examples of resources with a mechanical location label include:
plumbing, valves, and latches.</para>
</section>
<section xml:id= "dbdoclet.50569341_70735" >
<title > Resource Location Label</title>
<para > 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.
</para>
<para > 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.</para>
</section>
</section>
<section xml:id= "dbdoclet.50569341_41991" >
<title > Converged Location Code Rules</title>
<para > This section describes the rules for building a location code. See
also <xref linkend= "dbdoclet.50569341_81497" /> the types of location code
labels. </para>
<section >
<title > Usage of Location Codes</title>
<para > Any reference to a FRU must reference the official location
code.</para>
<para > 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.</para>
</section>
<section >
<title > Persistence of Location Codes</title>
<para > Physical path location codes are permanent. Physical path location
codes will not change unless there has been a change of hardware.</para>
<para > 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.</para>
</section>
<section >
<title > Forming Location Codes</title>
<para > 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 (“ -” ).</para>
</section>
<section >
<title > Length Restrictions</title>
<para > Location codes are no more than 79 characters in length. The
lengths of individual location labels vary. </para>
</section>
<section >
<title > Location Labels Content</title>
<para > 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.</para>
</section>
<section >
<title > Physical Representation</title>
<para > In so far as it is possible, location labels must match the labels
that are present on the hardware. </para>
<para > 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.</para>
</section>
<section >
<title > Multiple Function FRUs</title>
<para > 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. </para>
</section>
<section >
<title > Multiple Connectors for One Port</title>
<para > 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.</para>
</section>
<section >
<title > Location Label Numbering Scope</title>
<para > 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.</para>
<para > 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.</para>
<para > <emphasis role= "bold" > Note:</emphasis> 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.</para>
</section>
<section >
<title > FRU Orientation</title>
<para > 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.</para>
<para > 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.</para>
</section>
<section >
<title > Unit Location Codes</title>
<para > 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. </para>
<para > 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:</para>
<itemizedlist mark= "none" >
<listitem >
<para > U9117.250.10ABCDE</para>
</listitem>
</itemizedlist>
<para > 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.</para>
<para > 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:</para>
<itemizedlist mark= "none" >
<listitem >
<para > U5703.012.1030490</para>
</listitem>
</itemizedlist>
<para > 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:</para>
<itemizedlist mark= "none" >
<listitem >
<para > U0573.001.1040320</para>
</listitem>
</itemizedlist>
<para > 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:</para>
<para > U1234.TU1.5678901</para>
<para > 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.</para>
<para > 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.</para>
</section>
<section >
<title > Planar Location Codes</title>
<para > 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.</para>
<para > <emphasis role= "bold" > Note:</emphasis> 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.</para>
</section>
<section >
<title > Card Connector Location Codes</title>
<para > 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.</para>
<para > The process is the same irrespective of the kind of card
involved.</para>
</section>
<section >
<title > Riser Card Connector Location Codes</title>
<para > 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:</para>
<para > U5702.115.1031010-P3-C4-C2</para>
</section>
<section >
<title > Blade Daughter Card Connector Location Codes</title>
<para > 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:</para>
<itemizedlist mark= "none" >
<listitem >
<para > U78A0.001.DNWGDG0-P1-C10-L1</para>
</listitem>
<listitem >
<para > U78A0.001.DNWGDG0-P1-C10-L2</para>
</listitem>
</itemizedlist>
<para > 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:</para>
<itemizedlist mark= "none" >
<listitem >
<para > U78A0.001.DNWGDG0-P1-C10-L1-T1</para>
</listitem>
<listitem >
<para > U78A0.001.DNWGDG0-P1-C10-L1-T2</para>
</listitem>
<listitem >
<para > U78A0.001.DNWGDG0-P1-C10-L2-T1</para>
</listitem>
<listitem >
<para > U78A0.001.DNWGDG0-P1-C10-L2-T2</para>
</listitem>
</itemizedlist>
<para > 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.</para>
</section>
<section xml:id= "dbdoclet.50569341_32742" >
<title > Virtual Card Connector Location Codes</title>
<para > 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:</para>
<itemizedlist mark= "none" >
<listitem >
<para > U9117.001.1076DEF-V5-C4</para>
</listitem>
</itemizedlist>
<para > 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.</para>
<para > Some operating systems may append a T label
to the virtual IOA location code. For example:</para>
<itemizedlist mark= "none" >
<listitem >
<para > U9117.001.1076DEF-V5-C4-T1</para>
</listitem>
</itemizedlist>
</section>
<section xml:id= "dbdoclet.50569341_26909" >
<title > Port Location Codes</title>
<para > 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.</para>
<section xml:id= "dbdoclet.50569341_Port-Labeling-Rules-No-VPD" >
<title > Resources without Port VPD</title>
<para > 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
<xref linkend= "dbdoclet.50569341_Port-Location-Label" /> .</para>
<para > 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.</para>
<para > 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. </para>
</section>
<section >
<title > Determining Port Number</title>
<para > If the port number cannot be determined from VPD or VPD plus
configuration or addressing information, software or firmware must infer the
port number.</para>
<itemizedlist >
<listitem >
<para > For SCSI IOAs with multiple PCI configuration spaces, each port
has its own configuration space. </para>
</listitem>
<listitem >
<para > 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.</para>
</listitem>
</itemizedlist>
</section>
<section >
<title > Physical Device Location Codes</title>
<para > Devices whose parent supports location label
VPD<footnote xml:id= "pgfId-531393" > <para > SES 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. </para> </footnote>
(that is, mounted/docked on a backplane
that supports location information for docked devices) will have physical
location codes. For example, </para>
<itemizedlist mark= "none" >
<listitem >
<para > U5734.001.10ABCDE-P3-D19</para>
</listitem>
</itemizedlist>
<para > 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.</para>
<para > <emphasis role= "bold" > Notes:</emphasis> </para>
<orderedlist >
<listitem >
<para > 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.</para>
</listitem>
<listitem >
<para > 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.</para>
</listitem>
</orderedlist>
</section>
</section>
<section >
<title > SCSI Device Logical Path Location Codes -- Real</title>
<para > 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:</para>
<itemizedlist mark= "none" >
<listitem >
<para > U7043.150.1076543-P4-T3-L13-L0 <?linebreak?>
(Decimal L values)</para>
</listitem>
</itemizedlist>
</section>
<section >
<title > SAS Device Logical Path Location Codes</title>
<para > 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:</para>
<itemizedlist mark= "none" >
<listitem >
<para > U7043.150.1076543-P1-C3-L3-L1-L5-L0</para>
</listitem>
</itemizedlist>
</section>
<section xml:id= "dbdoclet.50569341_35517" >
<title > IDE/ATAPI Device Logical Path Location Codes</title>
<para > The desired form of the location code is based on the physical-path
location codes obtained from VPD. For example:</para>
<itemizedlist mark= "none" >
<listitem >
<para > U5734.001.1076543-P2-D4</para>
</listitem>
</itemizedlist>
<para > For an IDE device that had an older form of VPD (without physical
location codes), then its location code would have looked like:</para>
<itemizedlist mark= "none" >
<listitem >
<para > Ux-Px-(Cx)-Tx-L# <?linebreak?>
(from -L0 to -L3 where:<?linebreak?>
L0 = primary/master<?linebreak?>
L1 = primary/slave<?linebreak?>
L2 = secondary/master<?linebreak?>
L3 = secondary/slave)</para>
</listitem>
</itemizedlist>
</section>
<section >
<title > Fibre Channel Device Logical Path Location Codes --
Real</title>
<para > 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:</para>
<itemizedlist mark= "none" >
<listitem >
<para > U787A.001.1012345-P1-C5-T2-W123456789ABCDEF0-L1A05000000000000</para>
</listitem>
</itemizedlist>
</section>
<section xml:id= "dbdoclet.50569341_30561" >
<title > Location Codes for SR-IOV Adapter Virtual
Functions</title>
<para > 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.</para>
<para > For an SR-IOV ethernet adapter, the third virtual function for the
first ethernet port would look like:</para>
<itemizedlist mark= "none" >
<listitem >
<para > U7043.150.1076543-P1-C5-T1-S2</para>
</listitem>
</itemizedlist>
</section>
<section >
<title > Group Labels</title>
<para > 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. </para>
</section>
<section >
<title > Sandwich FRU Location Label </title>
<para > A Sandwich FRU has a single location label to describe its location
just as any single FRU would.</para>
</section>
<section >
<title > Sandwich FRU Child Location Labels</title>
<para > A Sandwich FRU is like any single FRU in that it has one numbering
space for numbering its child locations.</para>
</section>
<section >
<title > Location Code Reported by Sensors</title>
<para > The location code reported by a sensor is the location code of the
FRU being monitored by the sensor.</para>
</section>
<section >
<title > Sensor Locations</title>
<para > The location code of a sensor is the location code of the FRU on
which the sensor is located.</para>
</section>
<section >
<title > Location Code Reported for Indicators</title>
<para > 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.</para>
</section>
<section >
<title > Indicator Locations</title>
<para > The location code of an indicator is the location code of the FRU
on which the indicator is located.</para>
</section>
<section >
<title > Firmware Location Codes</title>
<para > 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:</para>
<itemizedlist mark= "none" >
<listitem >
<para > U7879.001.1054321-P1-Y2</para>
</listitem>
</itemizedlist>
<para > 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:</para>
<itemizedlist mark= "none" >
<listitem >
<para > U9117.001.1054321-Y1</para>
</listitem>
</itemizedlist>
</section>
<section >
<title > Bulk Power Assembly (BPA) Location Codes</title>
<para > 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. </para>
<para > 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.</para>
</section>
<section >
<title > Internal Battery Features Location Codes</title>
<para > 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. </para>
</section>
<section >
<title > Media Drawer Location Codes</title>
<para > 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.</para>
</section>
<section >
<title > Horizontal Placement Location Labels</title>
<para > 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).</para>
</section>
<section >
<title > EIA Location Label</title>
<para > 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.</para>
</section>
<section >
<title > Blade Chassis Location Codes</title>
<para > 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.</para>
<para > 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.</para>
</section>
<section xml:id= "sec_prod_topo_hotplug_dev" >
<title > Location Codes for Hot-pluggable Devices</title>
<para > 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 <emphasis role= "bold" > <literal > “ ibm,loc-code” </literal> </emphasis> 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 <emphasis role= "bold" > <literal > “ ibm,loc-code” </literal> </emphasis> property.</para>
<para > The <emphasis role= "bold" > <literal > “ ibm,loc-code-map” </literal> </emphasis> 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.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "sec_prod_topo_hotplug_dev"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis> </term>
<listitem >
<para > The instance of each USB root-hub in
the device tree must contain the <emphasis role= "bold" > <literal > “ ibm,loc-code-map” </literal> </emphasis> 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.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "sec_prod_topo_hotplug_dev"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis> </term>
<listitem >
<para > To determine the location code for an
end device associated with leaf open firmware node, the O/S must use the
<emphasis role= "bold" > <literal > “ ibm,loc-code-map” </literal> </emphasis> entry with a matching
unit-address, if it exists, in preference to the parent's
<emphasis role= "bold" > <literal > “ ibm,loc-code” </literal> </emphasis> property.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "sec_prod_topo_hotplug_dev"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis> </term>
<listitem >
<para > The <emphasis role= "bold" > <literal > “ ibm,loc-code-map” </literal> </emphasis> 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.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "sec_prod_topo_hotplug_dev"
xrefstyle="select: labelnumber nopage"/>-4.</emphasis> </term>
<listitem >
<para > If the unit-address architecture for
certain node types do not strictly bind a particular unit-address with a
hardware location, the <emphasis role= "bold" > <literal > “ ibm,loc-code-map” </literal> </emphasis>
property must not exist in the parent of those nodes. </para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section >
<title > Location Code for USB Attached Devices</title>
<para > 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. </para>
<para > 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:</para>
<itemizedlist mark= "none" >
<listitem >
<para > U787A.001.10ABCDE-P1-T5-L1-L3</para>
</listitem>
</itemizedlist>
</section>
<section >
<title > Location Code for Coherent Platform Facility</title>
<para > 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:</para>
<itemizedlist mark= "none" >
<listitem >
<para > U1234.001.1054321-P1-C7</para>
</listitem>
</itemizedlist>
</section>
<section >
<title > Location Code for Coherent Platform Function</title>
<para > 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:</para>
<itemizedlist mark= "none" >
<listitem >
<para > U1234.001.1054321-P1-C7-S0-S1</para>
</listitem>
</itemizedlist>
</section>
<section xml:id= "sec_resource_location_codes" >
<title > Resource Location Codes</title>
<para > 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.</para>
<para > 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.</para>
</section>
<section xml:id= "sec_multiple_frus_same_physical_space" >
<title > Multiple FRUs In The Same Physical Space</title>
<para > 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.</para>
</section>
<section xml:id= "sec_pcie_attached_io_drawers" >
<title > PCI-E Attached I/O Drawers</title>
<para > 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.</para>
<para > 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.</para>
<para > 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.</para>
</section>
<section xml:id= "sec_virtual_scsi_device_location_codes" >
<title > Virtual SCSI (vSCSI) Device Location Codes</title>
<para > 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.</para>
<para > See <xref linkend= "dbdoclet.50569341_32742" /> for a description of the
virtual IOA location code.</para>
</section>
<section xml:id= "sec_virtual_fibre_channel_device_location_codes" >
<title > Virtual Fibre Channel Device Location Codes</title>
<para > 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:</para>
<itemizedlist mark= "none" >
<listitem >
<para > U9119.MME.1085B17-V2-C4-T1-W123456789ABCDEF0-L1A05000000000000</para>
</listitem>
</itemizedlist>
<para > See <xref linkend= "dbdoclet.50569341_32742" /> for a description of the
virtual IOA location code.</para>
</section>
<section xml:id= "sec_nvme_device_logical_path_location_codes" >
<title > NVMe Device Logical Path Location Codes</title>
<para > 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:</para>
<itemizedlist mark= "none" >
<listitem >
<para > U787A.001.1012345-P1-C5-L3</para>
</listitem>
</itemizedlist>
</section>
<section xml:id= "sec_virtual_capi_function_location_codes" >
<title > Virtual Coherent Accelerator (CAPI) Function Location Codes</title>
<para > 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:</para>
<itemizedlist mark= "none" >
<listitem >
<para > U78CA.001.1234567-P1-C4-C1-S1-S2</para>
</listitem>
</itemizedlist>
</section>
</section>
</section>
<section xml:id= "dbdoclet.50569341_29745" >
<title > Vital Product Data</title>
<section xml:id= "sec_prod_topo_vpd_intro" >
<title > Introduction</title>
<para > 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.</para>
<variablelist >
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_29745"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis> </term>
<listitem >
<para > FRUs used in LoPAR platforms must
provide machine-readable VPD as defined in
<xref linkend= "dbdoclet.50569341_29745" /> .</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_29745"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis> </term>
<listitem >
<para > LoPAR platforms must support the
collection of, and provide availability to, Vital Product Data.</para>
</listitem>
</varlistentry>
</variablelist>
<para > <emphasis role= "bold" > Platform Implementation Notes:</emphasis> </para>
<orderedlist >
<listitem >
<para > It is the intent of this architecture that the FRUs of a system
be self describing using VPD. </para>
</listitem>
<listitem >
<para > 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.</para>
</listitem>
</orderedlist>
</section>
<section xml:id= "dbdoclet.50569341_39089" >
<title > VPD Data Structure Description</title>
<para > <emphasis role= "bold" > Architecture Note:</emphasis> Even though only a few
large and small resource tags have been defined (see the
<xref linkend= "dbdoclet.50569387_65468" /> ), the current definition will allow all
possible tags except for (0x00). This will allow later devices with a new,
previously undefined tag, to work.</para>
<variablelist >
<varlistentry xml:id= "dbdoclet.50569341_65980" >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_39089"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis> </term>
<listitem >
<para > Vital Product Data when reported to the OS via
<emphasis > ibm,get-vpd</emphasis> or the OF device tree, must conform to the data
structures describe in the <xref linkend= "dbdoclet.50569387_65468" /> , section
6.4<footnote xml:id= "pgfId-538056" > <para > The PCI 2.1 VPD keywords are PN, FN,
EC, MN, SN, LI, RL, RM, NA, DD, DG, LL, VI, FU, SI, and
Z0-ZZ</para> </footnote> , except as follows:</para>
<itemizedlist >
<listitem >
<para > 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.</para>
</listitem>
<listitem >
<para > Only resource tags, lengths and checksums are binary. All other
data must be in ASCII format.</para>
</listitem>
</itemizedlist>
<para > <emphasis role= "bold" > Architecture Note:</emphasis> 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. </para>
<para > <emphasis role= "bold" > Implementation Notes:</emphasis> </para>
<orderedlist >
<listitem >
<para > Version 2.2 of the <emphasis > PCI Local Bus
Specification</emphasis> 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.</para>
</listitem>
<listitem >
<para > 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.</para>
</listitem>
</orderedlist>
</listitem>
</varlistentry>
<varlistentry xml:id= "dbdoclet.50569341_52346" >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_39089"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis> </term>
<listitem >
<para > 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.</para>
</listitem>
</varlistentry>
<varlistentry xml:id= "dbdoclet.50569341_20102" >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_39089"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis> </term>
<listitem >
<para > 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:</para>
<itemizedlist >
<listitem >
<para > Large Resource type identifier string tag (type 2, byte 0 = 0x82)
with value ‘ NOT_VALID_VPD’ .</para>
</listitem>
<listitem >
<para > Large Resource type VPD keywords tag (type 16, byte 0 = 0x90)
containing the “ YL” keyword and associated location code
data.</para>
</listitem>
<listitem >
<para > Small Resource Type End tag with or without a checksum covering
the above.</para>
</listitem>
</itemizedlist>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_39089"
xrefstyle="select: labelnumber nopage"/>-4.</emphasis> </term>
<listitem >
<para > If the device VPD is valid, all of the
device VPD must be transferred including the Small Resource Type End Tag.</para>
</listitem>
</varlistentry>
<varlistentry >
<term > <emphasis role= "bold" > R1-<xref linkend= "dbdoclet.50569341_39089"
xrefstyle="select: labelnumber nopage"/>-5.</emphasis> </term>
<listitem >
<para > 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 <emphasis > ibm,get-vpd</emphasis>
RTAS call or the OF device tree.</para>
</listitem>
</varlistentry>
</variablelist>
<para > 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 <xref
linkend="dbdoclet.50569341_52346"/>, the (0x79) small resource tag is not
included in this sum.</para>
</section>
<section >
<title > Keyword Format Definition</title>
<para > The exact format of the VPD is vendor-specific but falls within the
specification as defined in the following subsections.</para>
<section xml:id= "sec_prod_topo_vpd_fieldss" >
<title > VPD fields</title>
<para > The fields defined in <xref linkend= "dbdoclet.50569341_47429" /> are
stored in VPD modules at the time of manufacturing.</para>
<variablelist >
<varlistentry xml:id= "dbdoclet.50569341_55947" >
<term > <emphasis role= "bold" > R1-<xref linkend= "sec_prod_topo_vpd_fieldss"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis> </term>
<listitem >
<para > LoPAR platforms and FRUs must
provide VPD fields marked as required in
<xref linkend= "dbdoclet.50569341_47429" /> and for all VPD fields provided must adhere
to the definitions specified by <xref
linkend="dbdoclet.50569341_47429"/>.</para>
</listitem>
</varlistentry>
<varlistentry xml:id= "dbdoclet.50569341_65708" >
<term > <emphasis role= "bold" > R1-<xref linkend= "sec_prod_topo_vpd_fieldss"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis> </term>
<listitem >
<para > Each system must have VPD that
contains the system’ s SE keyword (see Requirements
<xref linkend= "dbdoclet.50569341_50574" /> , <xref linkend= "dbdoclet.50569341_39729" /> ,
<xref linkend= "dbdoclet.50569341_39191" /> , and
<xref linkend= "dbdoclet.50569341_68839" /> ) and the system’ s TM keyword (see
Requirements <xref linkend= "dbdoclet.50569341_50574" /> ,
<xref linkend= "dbdoclet.50569341_39729" /> , <xref linkend= "dbdoclet.50569341_14313" /> ,
and <xref linkend= "dbdoclet.50569341_68839" /> ). The description (large resource
type of 0x82) for this VPD in the <emphasis role= "bold" > <literal > “ ibm,vpd” </literal> </emphasis>
property must be “ System VPD” .</para>
</listitem>
</varlistentry>
<varlistentry xml:id= "dbdoclet.50569341_96984" >
<term > <emphasis role= "bold" > R1-<xref linkend= "sec_prod_topo_vpd_fieldss"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis> </term>
<listitem >
<para > VPD for memory FRUs must contain
the SZ keyword.</para>
<para > <emphasis role= "bold" > Platform Implementation Note:</emphasis> 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.</para>
</listitem>
</varlistentry>
</variablelist>
<table frame= "all" pgwide= "1" xml:id= "dbdoclet.50569341_47429" >
<title > LoPAR VPD Fields </title>
<tgroup cols= "5" >
<colspec colname= "c1" colwidth= "8*" align= "center" />
<colspec colname= "c2" colwidth= "10*" align= "center" />
<colspec colname= "c3" colwidth= "10*" align= "center" />
<colspec colname= "c4" colwidth= "12*" align= "center" />
<colspec colname= "c5" colwidth= "60*" />
<thead valign= "middle" >
<row >
<entry >
<para >
<emphasis role= "bold" > Keyword</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > Data Type</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > Data Length (Bytes)</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > Required?</emphasis> <footnote
xml:id="pgfId-1018130"><para > 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.</para> </footnote>
</para>
</entry>
<entry align= "center" >
<para >
<emphasis role= "bold" > Description</emphasis>
</para>
</entry>
</row>
</thead>
<tbody valign= "middle" >
<row >
<entry >
<para > A1</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 16</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Storage Facility Image MTMS - Logical ID<?linebreak?>
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.</para>
</entry>
</row>
<row >
<entry >
<para > AC</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 32</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Account Name<?linebreak?>
Used on HMC resource.</para>
</entry>
</row>
<row >
<entry >
<para > AD</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 10</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Addressing Field</para>
</entry>
</row>
<row >
<entry >
<para > AP</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 16</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Asset Protection Key Password</para>
</entry>
</row>
<row >
<entry >
<para > AS</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 8</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Reserved </para>
</entry>
</row>
<row >
<entry >
<para > AT</para>
</entry>
<entry >
<para > -</para>
</entry>
<entry >
<para > -</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Reserved</para>
</entry>
</row>
<row >
<entry >
<para > AX</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 32</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > AIX name</para>
</entry>
</row>
<row >
<entry >
<para > B1</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > A multiple of 16, up to a max of 240</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Contains 1 to 15 instances of the following 16 byte
definition, concatenated together. </para>
<para > Contains the base ethernet MAC address and an instance
count. </para>
<para > 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.</para>
<para > The field contains the ASCII coded hexadecimal
representation of the binary value, as follows:</para>
<para > Bytes<?linebreak?>
1 - 12 Base MAC address<?linebreak?>
13 - 14 Reserved (ASCII “ 00” )<?linebreak?>
15 - 16 Count</para>
</entry>
</row>
<row >
<entry >
<para > B2</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > A multiple of 32, up to a max of 224</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Contains 1 to 7 instances of the following 32 byte
definition, concatenated together. </para>
<para > SAS WWIDs. </para>
<para > The Count field is the number of available WWIDs starting
from the base and incrementing by 1 for each new WWID.</para>
<para > The field contains the ASCII coded hexadecimal
representation of the binary value, as follows:</para>
<para > Bytes<?linebreak?>
1 - 16 Base SAS WWID<?linebreak?>
17 - 24 Reserved (ASCII “ 00000000” )<?linebreak?>
25 - 32 Count</para>
</entry>
</row>
<row >
<entry >
<para > BC</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 12</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Bar Code</para>
</entry>
</row>
<row >
<entry >
<para > BH</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 2</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > BatcH code - used for vintage if no serial number</para>
</entry>
</row>
<row >
<entry >
<para > BR</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 2</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Brand keyword value “ xy” </para>
<para > <emphasis role= "bold" > Note:</emphasis> The following are the values
currently defined. To get other product specific values, go through the normal
LoPAR change process.</para>
<para > x = Type of machine</para>
<itemizedlist spacing= "compact" >
<listitem >
<para > “ B” - Reserved</para>
</listitem>
<listitem >
<para > “ C” - Reserved</para>
</listitem>
<listitem >
<para > “ D” - Reserved</para>
</listitem>
<listitem >
<para > “ I” - Reserved</para>
</listitem>
<listitem >
<para > “ N” - Reserved</para>
</listitem>
<listitem >
<para > “ O” - Reserved</para>
</listitem>
<listitem >
<para > “ P” - Reserved</para>
</listitem>
<listitem >
<para > “ S” - IBM Power Systems™ platforms</para>
</listitem>
<listitem >
<para > “ T” - OEM Power Systems platforms</para>
</listitem>
<listitem >
<para > Other values are reserved.</para>
</listitem>
<listitem >
<para > y = Specific Information</para>
</listitem>
<listitem >
<para > “ 0” - no specific information</para>
</listitem>
<listitem >
<para > Other values are reserved.</para>
</listitem>
</itemizedlist>
</entry>
</row>
<row >
<entry >
<para > BT</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 10</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Battery Replacement date in YYYY-MM-DD format. Used on
Primary Power Supply FRU in rack enclosure.</para>
</entry>
</row>
<row >
<entry >
<para > CC</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 4</para>
</entry>
<entry >
<para > Required when a CCIN is required by code to configure or
service the component</para>
</entry>
<entry >
<para > Customer Card Identification Number (CCIN)</para>
</entry>
</row>
<row >
<entry >
<para > CE </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 1</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > CCIN Extender </para>
</entry>
</row>
<row >
<entry >
<para > CD</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 10</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Card ID</para>
</entry>
</row>
<row >
<entry >
<para > CI </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 16</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > CEC ID - of the CEC, that is the logical controller of
an MTMS (machine-type-model-serial #), like a drawer.</para>
<para > The 16 byte CI field definition is <literal > TTTT-MMM SSSSSSS</literal> where:</para>
<itemizedlist spacing= "compact" >
<listitem >
<para > <literal > TTTT-MMM</literal> 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.</para>
</listitem>
<listitem >
<para > blank is a 1 byte separator character, that separates
the type-model from the serial #.</para>
</listitem>
<listitem >
<para > <literal > SSSSSSS</literal> 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” .</para>
</listitem>
</itemizedlist>
</entry>
</row>
<row >
<entry >
<para > CL </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 32</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Code Level, LID keyword</para>
<para > Format:<?linebreak?>
fix pack MIF name, “ space” , Load ID (8
characters), time stamp (12 characters)<?linebreak?>
The fix pack name must be the same as the name used in
the MI keyword and is delimited by a space.<?linebreak?>
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. </para>
<para > <emphasis role= "bold" > Note:</emphasis> There is no correlation
between the CL keyword value and which of the 3 candidate fixpack levels are
reported in the MI keyword. </para>
</entry>
</row>
<row >
<entry >
<para > CN </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 7</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Customer Number</para>
</entry>
</row>
<row >
<entry >
<para > CV</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 4</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Country Number</para>
</entry>
</row>
<row >
<entry >
<para > DC </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 2<?linebreak?>
1<?linebreak?>
12<?linebreak?>
  <?linebreak?>
  <?linebreak?>
  <?linebreak?>
  <?linebreak?>
  <?linebreak?>
  <?linebreak?>
  <?linebreak?>
  <?linebreak?>
  <?linebreak?>
  <?linebreak?>
  <?linebreak?>
  <?linebreak?>
  <?linebreak?>
  <?linebreak?>
  <?linebreak?>
  <?linebreak?>
  <?linebreak?>
  </para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Action Code, timestamp<?linebreak?>
blank (space)<?linebreak?>
TimeStamp: yyyymmddhhmm<?linebreak?>
Action Codes:<?linebreak?>
BD = Build Date<?linebreak?>
AM = added as MES<?linebreak?>
AB = added as bulk MES<?linebreak?>
AI = available at install<?linebreak?>
ID = field install date<?linebreak?>
AC = added with field EC<?linebreak?>
AU = added from unknown source<?linebreak?>
AR = added in repair action<?linebreak?>
AT = added temporarily in field<?linebreak?>
AH = added manually in field<?linebreak?>
Returned on history file:<?linebreak?>
RU = removed unknown (field)<?linebreak?>
RR = removed in repair action<?linebreak?>
RC = removed with EC<?linebreak?>
RT = removed temporarily / powered off (field)<?linebreak?>
RM = removed permanently (field)<?linebreak?>
RN = removed to another system</para>
</entry>
</row>
<row >
<entry >
<para > DD</para>
</entry>
<entry >
<para > -</para>
</entry>
<entry >
<para > -</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Reserved -- used for MicroChannel Architecture VPD</para>
</entry>
</row>
<row >
<entry >
<para > DG</para>
</entry>
<entry >
<para > -</para>
</entry>
<entry >
<para > -</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Reserved -- used for MicroChannel Architecture VPD</para>
</entry>
</row>
<row >
<entry >
<para > DU </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 10</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Drawer Unit</para>
</entry>
</row>
<row >
<entry >
<para > DL </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 10</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Drawer Level</para>
</entry>
</row>
<row >
<entry >
<para > DP </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 255</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Disk Space Characteristics<?linebreak?>
Used on Disk resource. Comma separated string. <?linebreak?>
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 “ > ” ):<?linebreak?>
“ 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> ” </para>
</entry>
</row>
<row >
<entry >
<para > DS </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 30</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Displayable Message (if not defined, created by the
contents of the ID large resource (82))</para>
</entry>
</row>
<row >
<entry >
<para > EA</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 24</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Electronic Message for electronic customer support (ECS)</para>
</entry>
</row>
<row >
<entry >
<para > EC</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 12</para>
</entry>
<entry >
<para > Required if the part number is not changed with every modification</para>
</entry>
<entry >
<para > Engineering Change Level (technical features, revision level, vintage level)</para>
</entry>
</row>
<row >
<entry >
<para > ET </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 2</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Enclosure Type.<?linebreak?>
This value is defined in the
<xref linkend= "dbdoclet.50569387_34114" /> . 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” )<?linebreak?>
“ 01” Other<?linebreak?>
“ 02” Unknown<?linebreak?>
“ 03” Desktop<?linebreak?>
“ 04” Low Profile Desktop<?linebreak?>
“ 05” Pizza Box<?linebreak?>
“ 06” Mini Tower<?linebreak?>
“ 07” Tower<?linebreak?>
“ 08” Portable<?linebreak?>
“ 09” LapTop<?linebreak?>
“ 0A” Notebook<?linebreak?>
“ 0B” Hand Held<?linebreak?>
“ 0C” Docking Station<?linebreak?>
“ 0D” All in One<?linebreak?>
“ 0E” Sub Notebook<?linebreak?>
“ 0F” Space-saving<?linebreak?>
“ 10” Lunch Box<?linebreak?>
“ 11” Main Server Chassis<?linebreak?>
“ 12” Expansion Chassis<?linebreak?>
“ 13” SubChassis<?linebreak?>
“ 14” Bus Expansion Chassis<?linebreak?>
“ 15” Peripheral Chassis<?linebreak?>
“ 16” RAID Chassis<?linebreak?>
“ 17” Rack Mount Chassis<?linebreak?>
“ 18” Sealed-case PC</para>
</entry>
</row>
<row >
<entry >
<para > FC</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 8</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > The Feature Code is 8 bytes formatted as 4 characters, a
dash, and three characters.</para>
</entry>
</row>
<row >
<entry >
<para > FD </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 7</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Field Bill of Material (FBM) EC level</para>
</entry>
</row>
<row >
<entry >
<para > FG </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 4</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > 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.</para>
</entry>
</row>
<row >
<entry >
<para > FI </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 2 - 8</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Frame ID: 2 hex byte value for SPCN or 8 character
logical frame number for DASD backplane.</para>
</entry>
</row>
<row >
<entry >
<para > FL </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 16</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > FRU Label: This is a variable length ASCII character
data area for the FRU Label.</para>
</entry>
</row>
<row >
<entry >
<para > FN</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 8</para>
</entry>
<entry >
<para > Required</para>
</entry>
<entry >
<para > FRU Number (Board, card, or assembly Field Replacement
Unit number).</para>
</entry>
</row>
<row >
<entry >
<para > FU </para>
</entry>
<entry >
<para > Binary</para>
</entry>
<entry >
<para > Up to 10</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > 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.</para>
</entry>
</row>
<row >
<entry >
<para > H1 </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 1</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Partition HSL Pool</para>
<para > Used on a partition resource that is part of a storage facility image.</para>
</entry>
</row>
<row >
<entry >
<para > ID</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 2</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Two ASCII characters are used to identify each system in
a Storage Facility. Valid values are 00 and 01.</para>
</entry>
</row>
<row >
<entry >
<para > IF </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 16</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Storage Facility MTMS - InterfaceID</para>
<para > 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.</para>
</entry>
</row>
<row >
<entry >
<para >   <?linebreak?>
L1<?linebreak?>
L2<?linebreak?>
L3<?linebreak?>
L4<?linebreak?>
L5<?linebreak?>
L6</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para >   <?linebreak?>
Up to 30<?linebreak?>
Up to 30<?linebreak?>
Up to 30<?linebreak?>
Up to 10<?linebreak?>
Up to 30<?linebreak?>
Up to 12</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Location Information:<?linebreak?>
Individual or Company Name<?linebreak?>
Street Address <?linebreak?>
City, State, Country<?linebreak?>
Zip Code <?linebreak?>
Contact Name <?linebreak?>
Contact Phone Number </para>
</entry>
</row>
<row >
<entry >
<para > LA</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 32</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > LIC Node Alternate Bus VPD: This fixed format data field
contains 32 bytes of LIC I/O node alternate bus VPD data.</para>
</entry>
</row>
<row >
<entry >
<para > LE </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 17</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > LIC VMRF</para>
<para > 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.</para>
</entry>
</row>
<row >
<entry >
<para > LI </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 10</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Adapter Software Identification</para>
</entry>
</row>
<row >
<entry >
<para > LL</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 10</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Adapter Software Level</para>
</entry>
</row>
<row >
<entry >
<para > LN </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 32</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > LIC Node VPD: Fixed format 32 bytes of VPD data.</para>
</entry>
</row>
<row >
<entry >
<para > LO </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 2</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Location (INternal/EXternal)</para>
</entry>
</row>
<row >
<entry >
<para > LP</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 32</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > LIC Node Primary Bus VPD: Fixed format 32 bytes of VPD data.</para>
</entry>
</row>
<row >
<entry >
<para > LS </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 255</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Logical Space Characteristics<?linebreak?>
Used on Storage Logical resources. <?linebreak?>
Examples: <?linebreak?>
Used on Array resource. Comma separated string.
Including: “ AN=Array Serial Number, AT=Array-Type, AC=Array
Configuration, Rank Position” . <?linebreak?>
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(#)” . <?linebreak?>
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(#).</para>
</entry>
</row>
<row >
<entry >
<para > MD </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 4</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Model Number: 3 characters with a leading blank.</para>
</entry>
</row>
<row >
<entry >
<para > ME </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 8</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Microcode Service Entitlement Expiration Date</para>
<para > 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.</para>
<para > Format:<?linebreak?> yyyymmdd</para>
</entry>
</row>
<row >
<entry >
<para > MF </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 2</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Map Format: Two hex characters identify the slot or port
map format that follows. This keyword must immediately precede the SM or PM
keyword.</para>
</entry>
</row>
<row >
<entry >
<para > MG </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 8</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Microcode General Availability/Release Date</para>
<para > This is the date the system firmware image was released and published for customer use.</para>
<para > Format:<?linebreak?> yyyymmdd</para>
</entry>
</row>
<row >
<entry >
<para > MI </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 40</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Microcode Image</para>
<para > This keyword is only used to describe dual sided
alterable system firmware Image which can be altered by the OS via the
<emphasis > ibm,update-flash-64-and-reboot</emphasis> RTAS call. Both the
<emphasis > ibm,validate-flash-image</emphasis> and the
<emphasis > ibm,manage-flash-image</emphasis> RTAS calls are supported. May or may not be
able to be updated via non-OS visible means.</para>
<para > Format:<?linebreak?>
t side Microcode Image name, “ space” , p
side Microcode Image name, “ space” , booted Microcode Image
name</para>
<para > The Microcode Image name must be a 9 character name of
the form:<?linebreak?>
<emphasis role= "bold" > <literal > “ NNSSS_FFF” </literal> </emphasis>
</para>
<para > where</para>
<para > “ NN” is a two character name (assigned by
the GFW Firmware Distribution Coordinator) used to identify a set of
platforms;<?linebreak?>
“ SSS” is a 3 character code stream
indicator;<?linebreak?>
“ _” is a separation character for
readability; and,<?linebreak?>
“ FFF” is a 3 character identifier of the
current microcode level.</para>
<para > <emphasis role= "bold" > Note:</emphasis> 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.</para>
</entry>
</row>
<row >
<entry >
<para > ML</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 40</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Microcode Level</para>
<para > 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.</para>
<para > Format:<?linebreak?>
t side Microcode Level name, “ space” , p
side Microcode Level name, “ space” , booted Microcode Level
name</para>
<para > The Microcode Image name must be a 8 character name of the form:<?linebreak?>
<emphasis role= "bold" > <literal > “ FWVRE.MF” </literal> </emphasis>
</para>
<para > where<?linebreak?>
"FW" is a static prefix representing 'firmware'<?linebreak?>
“ V” is Version - Power Processor Level<?linebreak?>
"R" is Revision - Typically GA number from the processor level<?linebreak?>
"E" is Extension - Typically zero. If non-zero,
designates off cycle single system release<?linebreak?>
"M" is Modification - associated Service Pack Level (0-Z)<?linebreak?>
"F" is Fix Level - Typically zero. If non-zero, designate
off cycle, targeted fixes</para>
<para > <emphasis role= "bold" > Note:</emphasis> 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.</para>
</entry>
</row>
<row >
<entry >
<para > MN</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 10</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Manufacturer ID (source of device, name and location)</para>
</entry>
</row>
<row >
<entry >
<para > MP </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 3</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Module Plug count. This counter keeps track of the
numbers of times a module has been plugged, so that reliability statistics can
be kept.</para>
</entry>
</row>
<row >
<entry >
<para > MS </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 6</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > MES Number</para>
</entry>
</row>
<row >
<entry >
<para > MU </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 32</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Machine Universal Unit ID (UUID). The value is the ASCII
coded hexadecimal representation of the 16 byte binary value.</para>
</entry>
</row>
<row >
<entry >
<para > N5 </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 228</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Processor CoD Capacity Card Info</para>
</entry>
</row>
<row >
<entry >
<para > N6 </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 231</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Memory CoD Capacity Card Info</para>
</entry>
</row>
<row >
<entry >
<para > N7 </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 144</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Processor on Demand billing data</para>
</entry>
</row>
<row >
<entry >
<para > N8 </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 145</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Memory on Demand billing data</para>
</entry>
</row>
<row >
<entry >
<para > NA </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 16</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Network Address (ASCII coded hexadecimal representation
of the binary value.)</para>
</entry>
</row>
<row >
<entry >
<para > NC</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 25</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > 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.</para>
</entry>
</row>
<row >
<entry >
<para > NN </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 16</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > World Wide Node Name - IEEE assigned 64 bit identifier
(16 hexadecimal digits) for Storage Facility. Valid values are 0-9, A-F.</para>
</entry>
</row>
<row >
<entry >
<para > NT </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 32</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Sub-machine type </para>
</entry>
</row>
<row >
<entry >
<para > NV </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 24</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > NVRAM ID, part number, location and size</para>
</entry>
</row>
<row >
<entry >
<para > NX</para>
</entry>
<entry >
<para > -</para>
</entry>
<entry >
<para > -</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Reserved</para>
</entry>
</row>
<row >
<entry >
<para > OS </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 17</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > OS name and level. </para>
<para > 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.</para>
</entry>
</row>
<row >
<entry >
<para > PA </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 1</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > 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. </para>
</entry>
</row>
<row >
<entry >
<para > PC</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 16</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Processor Component Definition</para>
</entry>
</row>
<row >
<entry >
<para > PD </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 8</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Power dissipation/consumption</para>
</entry>
</row>
<row >
<entry >
<para > PI</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 8</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Processor ID or unique ID (used for licensing control)</para>
</entry>
</row>
<row >
<entry >
<para > PL </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 32</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Location code</para>
</entry>
</row>
<row >
<entry >
<para > PM </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 16</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Port Map: Contains the RIO Port Map label information.
Must be preceded by the MF keyword. </para>
</entry>
</row>
<row >
<entry >
<para > PN</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 12</para>
</entry>
<entry >
<para > Required if it is different from the FRU number
(FN)</para>
</entry>
<entry >
<para > Part number of assembly.</para>
</entry>
</row>
<row >
<entry >
<para > PO </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 16</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > SPCN VPD: Identification of the SPCN VPD area on the I/O
backplane.</para>
</entry>
</row>
<row >
<entry >
<para > PP</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 32</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Power Parameters: SPCN field identifying Power node
parameters.</para>
</entry>
</row>
<row >
<entry >
<para > PR </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 16</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Power: 16 ASCII hexadecimal characters that represent
the 8 bytes of binary information for Power Control.</para>
</entry>
</row>
<row >
<entry >
<para > R1 </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 16</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Rack MTMS - Rack Location</para>
<para > Length (MTMS-Exx). - used on storage enclosure
resources.</para>
</entry>
</row>
<row >
<entry >
<para > R2 </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 1</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Rack Number</para>
<para > Used on Rack enclosure resources. Provides an ordered
number of racks in the storage facility.</para>
</entry>
</row>
<row >
<entry >
<para > RA</para>
</entry>
<entry >
<para > -</para>
</entry>
<entry >
<para > -</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Reserved</para>
</entry>
</row>
<row >
<entry >
<para > RD</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 16</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Power Domain ID - is the MTMS of the BPA, that powers an
MTMS (Machine-Type-Model-Serial #), like a CEC or drawer.<?linebreak?>
The 16 byte RD field definition is: <literal > TTTT-MMM SSSSSSS</literal> where:</para>
<itemizedlist spacing= "compact" >
<listitem >
<para > <literal > TTTT-MMM</literal> 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.</para>
</listitem>
<listitem >
<para > blank is a 1 byte separator character, that separates
the type-model from the serial #.</para>
</listitem>
<listitem >
<para > <literal > SSSSSSS</literal> 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” .</para>
</listitem>
</itemizedlist>
</entry>
</row>
<row >
<entry >
<para > RI </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 4</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Power Resource ID: A 4 byte hex field providing a unique
logical ID for the power resource.</para>
</entry>
</row>
<row >
<entry >
<para > RJ </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 16</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > RIO-G Loop</para>
<para > Used on I/O enclosure resource. Identifies RIO-G loop on
the reporting system. </para>
</entry>
</row>
<row >
<entry >
<para > RK </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 16</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > 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.<?linebreak?>
Each of the 16 4-bit nibbles are converted to 16 ASCII
characters, in the range 0-9 or A-F.</para>
</entry>
</row>
<row >
<entry >
<para > RL </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 24</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > 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.<?linebreak?>
ROM id, Location ID, ROM part number, FW part number, FW
level, FW code, release date, FW size.</para>
</entry>
</row>
<row >
<entry >
<para > RM </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 25</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > 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
<emphasis > ibm,update-flash-64-and-reboot</emphasis> RTAS call. Neither the
<emphasis > ibm,validate-flash-image</emphasis> nor the
<emphasis > ibm,manage-flash-image</emphasis> 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.</para>
<para > ROM id, Location ID, ROM part number, FW part number, FW
level, FW code, release date, FW size</para>
</entry>
</row>
<row >
<entry >
<para > RN </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 2</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Rack Name</para>
</entry>
</row>
<row >
<entry >
<para > RP </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 1</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > RIO-G Position Offset<?linebreak?>
Used on I/O enclosure resource. Identifies the distance
in enclosures from the reporting system - first enclosure is offset 1. </para>
</entry>
</row>
<row >
<entry >
<para > RS </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 128</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > IBM LoPAR Compliant platform unique VPD: Start of a data area. </para>
</entry>
</row>
<row >
<entry >
<para > RT</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 4</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Record Type. Contains a four character Record Name that
represents a VPD Definition. The following list associates Record Names with
their VPD Definitions.</para>
<itemizedlist spacing= "compact" >
<listitem >
<para > “ VSYS” - System MTMS VPD</para>
</listitem>
<listitem >
<para > “ VCEN” - Enclosure MTMS VPD</para>
</listitem>
<listitem >
<para > “ VINI” - FRU VPD record</para>
</listitem>
</itemizedlist>
</entry>
</row>
<row >
<entry >
<para > RW</para>
</entry>
<entry >
<para > -</para>
</entry>
<entry >
<para > -</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Reserved</para>
</entry>
</row>
<row >
<entry >
<para > RX</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 25</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > 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.</para>
</entry>
</row>
<row >
<entry >
<para > S1 </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 8</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Serial Number of attached machine</para>
</entry>
</row>
<row >
<entry >
<para > S3</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 16</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Storage Facility MTMS<?linebreak?>
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.</para>
</entry>
</row>
<row >
<entry >
<para > S4</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 16</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Storage Facility Image MTMS<?linebreak?>
Length (MTMS). Used on partition, array-site, array,
rank, and storage pool, and enclosure-FRU resources, associated with a storage
facility image.</para>
</entry>
</row>
<row >
<entry >
<para > SC </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 44</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Specify codes</para>
</entry>
</row>
<row >
<entry >
<para > SE</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 7</para>
</entry>
<entry >
<para > See Requirements
<xref linkend= "dbdoclet.50569341_50574" xrefstyle= "select: nopage" /> ,
<xref linkend= "dbdoclet.50569341_39729" xrefstyle= "select: nopage" /> ,
<xref linkend= "dbdoclet.50569341_39191" xrefstyle= "select: nopage" /> ,
<xref linkend= "dbdoclet.50569341_68839" xrefstyle= "select: nopage" /> , and
<xref linkend= "dbdoclet.50569341_65708" xrefstyle= "select: nopage" /> </para>
</entry>
<entry >
<para > Machine or Cabinet Serial Number.</para>
</entry>
</row>
<row >
<entry >
<para > SF </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 8</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Field Change Shipping Instruction (FCSI) number</para>
</entry>
</row>
<row >
<entry >
<para > SG</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 7</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > 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.</para>
</entry>
</row>
<row >
<entry >
<para > SI </para>
</entry>
<entry >
<para > Binary</para>
</entry>
<entry >
<para > Up to 10</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Subsystem Vendor ID. Data is binary encoded.</para>
</entry>
</row>
<row >
<entry >
<para > SL</para>
</entry>
<entry >
<para > -</para>
</entry>
<entry >
<para > -</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Reserved</para>
</entry>
</row>
<row >
<entry >
<para > SM </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 16</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Slot Map: Contains Slot Map information. Must be
preceded by the MF keyword.</para>
</entry>
</row>
<row >
<entry >
<para > SN</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 12</para>
</entry>
<entry >
<para > Required and must be unique for each part with the same FN</para>
</entry>
<entry >
<para > Serial Number 12 characters.</para>
</entry>
</row>
<row >
<entry >
<para > SU</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 12</para>
</entry>
<entry >
<para > See notes <xref linkend= "dbdoclet.50569341_42716" /> </para>
</entry>
<entry >
<para > 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.</para>
</entry>
</row>
<row >
<entry >
<para > SY </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 7</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > System Number (only one allowed)</para>
</entry>
</row>
<row >
<entry >
<para > SZ</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 10</para>
</entry>
<entry >
<para > For memory FRUs, see Requirement</para>
<para >
<xref linkend= "dbdoclet.50569341_96984" xrefstyle= "select: nopage" />
</para>
</entry>
<entry >
<para > 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. </para>
</entry>
</row>
<row >
<entry >
<para > Tl </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 8</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Attached machine type-model</para>
</entry>
</row>
<row >
<entry >
<para > TM</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 8</para>
</entry>
<entry >
<para > See Requirements
<xref linkend= "dbdoclet.50569341_50574" xrefstyle= "select: nopage" /> ,
<xref linkend= "dbdoclet.50569341_39729" xrefstyle= "select: nopage" /> ,
<xref linkend= "dbdoclet.50569341_14313" xrefstyle= "select: nopage" /> ,
<xref linkend= "dbdoclet.50569341_68839" xrefstyle= "select: nopage" /> , and
<xref linkend= "dbdoclet.50569341_65708" xrefstyle= "select: nopage" /> </para>
</entry>
<entry >
<para > The high order 4 bytes are the “ Machine
Type” , the next byte is a dash, followed by the 3 byte
“ Model” .</para>
</entry>
</row>
<row >
<entry >
<para > TN</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 8</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > The high order 4 bytes are the “ Machine
Type” , the next byte is a dash, followed by the 3 byte
“ Model” .</para>
</entry>
</row>
<row >
<entry >
<para > U1 </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 255</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Logical Configuration String<?linebreak?>
Used on a partition resource that is: CKD3380=####,
CKD3390=####, SCSI512=####, SCSI520=####, SCSI Host Ports=####, SCSI LUN
Groups=####. <?linebreak?>
Used on device adapter or host adapter FRU for logical
configuration information, if any. <?linebreak?>
Used on Storage Enclosure. Comma separated string
including “ BA=Base Address(xx)” .</para>
</entry>
</row>
<row >
<entry >
<para > U2 </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 255</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Host Inventory<?linebreak?>
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=####, .
. .” .</para>
</entry>
</row>
<row >
<entry >
<para > U3 </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 255</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Reserved for future use. Used on partition resource or
Storage Configuration resources.</para>
</entry>
</row>
<row >
<entry >
<para > U4</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 255</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Reserved for future use. Used on partition resource or
Storage Configuration resources.</para>
</entry>
</row>
<row >
<entry >
<para > U5 </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 255</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Reserved for future use. Used on partition resource or
Storage Configuration resources.</para>
</entry>
</row>
<row >
<entry >
<para > U6 </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 255</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Reserved for future use. Used on partition resource or
Storage Configuration resources.</para>
</entry>
</row>
<row >
<entry >
<para > U7 </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 255</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Reserved for future use. Used on partition resource or
Storage Configuration resources.</para>
</entry>
</row>
<row >
<entry >
<para > U8 </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 255</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Reserved for future use. Used on partition resource or
Storage Configuration resources.</para>
</entry>
</row>
<row >
<entry >
<para > U9 </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 255</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Reserved for future use. Used on partition resource or
Storage Configuration resources.</para>
</entry>
</row>
<row >
<entry >
<para > VE</para>
</entry>
<entry >
<para > -</para>
</entry>
<entry >
<para > -</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Reserved -- used for MicroChannel Architecture VPD</para>
</entry>
</row>
<row >
<entry >
<para > VI </para>
</entry>
<entry >
<para > Binary</para>
</entry>
<entry >
<para > Up to 10</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Vendor ID / Device ID</para>
<para > Only one VI may appear per VPD tag.</para>
</entry>
</row>
<row >
<entry >
<para > WN</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 16</para>
</entry>
<entry >
<para > --</para>
</entry>
<entry >
<para > Contains the ASCII coded hexadecimal World Wide Port
Name (WWPN).</para>
</entry>
</row>
<row >
<entry >
<para > YK</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 4</para>
</entry>
<entry >
<para > See Requirement <xref linkend= "dbdoclet.50569341_39729" xrefstyle= "select: nopage" /> </para>
</entry>
<entry >
<para > Ties together multiple enclosures that share the same
combined SE and TM.</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
<para > <emphasis role= "bold" > Notes referenced in <xref linkend= "dbdoclet.50569341_47429" /> :</emphasis>
</para>
<orderedlist >
<listitem xml:id= "dbdoclet.50569341_42716" >
<para > When the
BR keyword indicates “ S” or “ T” for the type of
machine, this field must be present and must be non-blank.</para>
</listitem>
</orderedlist>
<para > <emphasis role= "bold" > Implementation Note:</emphasis> 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. </para>
</section>
<section >
<title > Additional Fields for Product Specific use</title>
<para > 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.</para>
<orderedlist >
<listitem >
<para > U0 - UZ User specific</para>
</listitem>
<listitem >
<para > N0 - NF Reserved<?linebreak?> V0 - VF Reserved</para>
</listitem>
<listitem >
<para > Y0 - YZ System Information specific</para>
</listitem>
<listitem >
<para > Z0 - ZZ Product specific</para>
</listitem>
</orderedlist>
<para > <emphasis role= "bold" > Note:</emphasis> If firmware/software has a specific
need for a keyword, then it must be provided by the appropriate component
VPD.</para>
<para > The Y? and Z? fields defined in <xref linkend= "dbdoclet.50569341_37470" />
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.</para>
<table frame= "all" pgwide= "1" xml:id= "dbdoclet.50569341_37470" >
<title > LoPAR Usage of Product Specific VPD Fields </title>
<tgroup cols= "4" >
<colspec colname= "c1" colwidth= "10*" align= "center" />
<colspec colname= "c2" colwidth= "10*" align= "center" />
<colspec colname= "c3" colwidth= "10*" align= "center" />
<colspec colname= "c4" colwidth= "70*" />
<thead valign= "middle" >
<row >
<entry >
<para >
<emphasis role= "bold" > Keyword</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > Data Type</emphasis>
</para>
</entry>
<entry >
<para >
<emphasis role= "bold" > Data Length (Bytes)</emphasis>
</para>
</entry>
<entry align= "center" >
<para >
<emphasis role= "bold" > Description</emphasis>
</para>
</entry>
</row>
</thead>
<tbody valign= "middle" >
<row >
<entry >
<para > N5 </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 56</para>
</entry>
<entry >
<para > Processor CoD Capacity Card Info per <xref linkend= "dbdoclet.50569332_47931" /> </para>
</entry>
</row>
<row >
<entry >
<para > N6 </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 56</para>
</entry>
<entry >
<para > Memory CoD Capacity Card Info per <xref linkend= "dbdoclet.50569332_47931" /> </para>
</entry>
</row>
<row >
<entry >
<para > U? </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 128</para>
</entry>
<entry >
<para > User Data:? = 0...9, A...Z</para>
</entry>
</row>
<row >
<entry >
<para > Y0 </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 64</para>
<para > 2<?linebreak?>
2<?linebreak?>
24<?linebreak?>
24<?linebreak?>
12</para>
</entry>
<entry >
<para > Board Repair Actions:</para>
<para > # times board repaired <?linebreak?>
# times board updated with code patches <?linebreak?>
Copy of system ID Y2 field <?linebreak?>
Copy of system ID TM field <?linebreak?>
Copy of system ID PI field </para>
</entry>
</row>
<row >
<entry >
<para > Y1 </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 24</para>
<para > 2<?linebreak?>
2 <?linebreak?>
  <?linebreak?>
8<?linebreak?>
12</para>
</entry>
<entry >
<para > Error Descriptor: </para>
<para > # allowable messages <?linebreak?>
# valid messages <?linebreak?>
Messages of 20 bytes each, first, last and most recent 4 messages<?linebreak?>
Error Code <?linebreak?>
Date/Time Stamp: yyyymmddhhmm</para>
</entry>
</row>
<row >
<entry >
<para > Y2 </para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > 24</para>
<para > 4<?linebreak?>
4<?linebreak?>
4<?linebreak?>
12</para>
</entry>
<entry >
<para > Only in system VPD EEPROM:</para>
<para > Manufacturer’ s Location<?linebreak?>
Machine Type <?linebreak?>
Model ID <?linebreak?>
Cabinet Serial Number </para>
</entry>
</row>
<row >
<entry >
<para > YK</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 4</para>
</entry>
<entry >
<para > Ties together multiple enclosures that share the same
combined SE and TM. See Requirement
<xref linkend= "dbdoclet.50569341_39729" /> .</para>
</entry>
</row>
<row >
<entry >
<para > YL</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 255</para>
</entry>
<entry >
<para > Hardware Location Code (see <xref linkend= "dbdoclet.50569341_35066" /> )</para>
</entry>
</row>
<row >
<entry >
<para > Z?</para>
</entry>
<entry >
<para > ASCII</para>
</entry>
<entry >
<para > Up to 255</para>
</entry>
<entry >
<para > Product Specific Information: may be keyword oriented
and ‘ ,’ delimited.</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</section>
</section>
</section>
</chapter>
