You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
4863 lines
200 KiB
XML
4863 lines
200 KiB
XML
7 years ago
|
<?xml version="1.0"?>
|
||
5 years ago
|
<chapter xmlns="http://docbook.org/ns/docbook"
|
||
|
xmlns:xl="http://www.w3.org/1999/xlink"
|
||
7 years ago
|
xml:id="dbdoclet.50569341_39268"
|
||
5 years ago
|
version="5.0"
|
||
7 years ago
|
xml:lang="en">
|
||
|
<title>Product Topology</title>
|
||
|
|
||
|
<section xml:id="dbdoclet.50569341_34882">
|
||
|
<title>VPD and Location Code OF Properties</title>
|
||
5 years ago
|
<para>A set of OF properties is defined to facilitate asset protection and
|
||
|
RAS capabilities in LoPAR systems. The following properties are defined in
|
||
7 years ago
|
<xref linkend="LoPAR.DeviceTree"/>):</para>
|
||
|
|
||
5 years ago
|
<itemizedlist>
|
||
7 years ago
|
<listitem>
|
||
|
<para><emphasis role="bold"><literal>“ibm,vpd”</literal></emphasis></para>
|
||
|
</listitem>
|
||
5 years ago
|
|
||
7 years ago
|
<listitem>
|
||
|
<para><emphasis role="bold"><literal>“ibm,loc-code”</literal></emphasis></para>
|
||
|
</listitem>
|
||
5 years ago
|
</itemizedlist>
|
||
7 years ago
|
|
||
|
<variablelist>
|
||
|
<varlistentry xml:id="dbdoclet.50569341_64684">
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_34882"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
the location code for that hardware entity.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_34882"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<para>OF nodes that do not represent an instance
|
||
|
of a hardware entity (FRU) do not have a location code and thus these nodes,
|
||
7 years ago
|
except for the OF root node, do not include the <emphasis role="bold"><literal>“ibm,loc-code”</literal></emphasis> property.</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
<emphasis role="bold"><literal>“ibm,vpd”</literal></emphasis> property. </para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry xml:id="dbdoclet.50569341_27357">
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_34882"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
must include the <emphasis role="bold"><literal>“ibm,vpd”</literal></emphasis> property.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_34882"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
<xref linkend="dbdoclet.50569341_55947"/>.</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
entity.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_34882"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
n.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry xml:id="dbdoclet.50569341_63284">
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_34882"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
<emphasis role="bold"><literal>“ibm,vpd”</literal></emphasis> properties. </para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
|
</variablelist>
|
||
|
<para><emphasis role="bold">Architecture Notes:</emphasis></para>
|
||
|
|
||
5 years ago
|
<itemizedlist>
|
||
7 years ago
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
the dynamically reconfigurable entity case.</para>
|
||
|
</listitem>
|
||
5 years ago
|
|
||
7 years ago
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
tree node that includes those properties.</para>
|
||
|
</listitem>
|
||
5 years ago
|
|
||
7 years ago
|
<listitem>
|
||
5 years ago
|
<para>A FRU can be considered dynamically reconfigurable if the hardware
|
||
|
is enabled for dynamic reconfiguration and full platform support might be
|
||
7 years ago
|
implemented at a later date. </para>
|
||
|
</listitem>
|
||
5 years ago
|
</itemizedlist>
|
||
7 years ago
|
|
||
5 years ago
|
<para><emphasis role="bold">Platform Implementation Note:</emphasis> If a location
|
||
7 years ago
|
does not return VPD, the property would contain a null entry for the VPD.</para>
|
||
|
</section>
|
||
5 years ago
|
|
||
7 years ago
|
<section xml:id="dbdoclet.50569341_23269">
|
||
|
<title>System Identification</title>
|
||
5 years ago
|
<para><xref linkend="LoPAR.DeviceTree"/> provides properties in the
|
||
7 years ago
|
“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">
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_23269"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
||
|
<listitem>
|
||
|
<para><emphasis>(Requirement Number Reserved For Compatibility)</emphasis></para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_23269"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<para>Each system enclosure (generally, a drawer),
|
||
7 years ago
|
must have the VPD SE and TM keywords (see <xref linkend="dbdoclet.50569341_47429"/>).</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry xml:id="dbdoclet.50569341_39729">
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_23269"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
keywords.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry xml:id="dbdoclet.50569341_31199">
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_23269"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
enclosure for a multi-enclosure platform.</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
bottom of the rack. Specific numbering is platform dependent.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry xml:id="dbdoclet.50569341_98827">
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_23269"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
construct <emphasis role="bold"><literal>“system-id”</literal></emphasis>.</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
purposes.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_23269"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
of the following: </para>
|
||
|
|
||
5 years ago
|
<orderedlist numeration="loweralpha">
|
||
7 years ago
|
<listitem>
|
||
5 years ago
|
<para>The RL keyword must be provided if the platform does not support
|
||
7 years ago
|
the <emphasis>ibm,update-flash-64-and-reboot</emphasis> RTAS call. </para>
|
||
|
</listitem>
|
||
|
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
<emphasis>ibm,validate-flash-image</emphasis> RTAS calls. </para>
|
||
|
</listitem>
|
||
|
|
||
|
<listitem>
|
||
5 years ago
|
<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>
|
||
7 years ago
|
RTAS calls.</para>
|
||
|
</listitem>
|
||
|
|
||
|
<listitem>
|
||
5 years ago
|
<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>
|
||
7 years ago
|
RTAS calls.</para>
|
||
|
</listitem>
|
||
5 years ago
|
</orderedlist>
|
||
7 years ago
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_23269"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-7.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
dependent instance of the firmware.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_23269"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-8.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
Platform Firmware”. </para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_23269"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-9.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
<emphasis>ibm,get-vpd</emphasis> RTAS call.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_23269"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-10.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
system firmware.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
|
|
||
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_23269"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-11.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<para>Service processor firmware VPD must be
|
||
|
found in the root node if the service processor firmware is a separate FRU from
|
||
7 years ago
|
the system firmware.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry xml:id="dbdoclet.50569341_39191">
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_23269"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-12.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
environment. </para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry xml:id="dbdoclet.50569341_14313">
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_23269"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-13.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
‘marked’ processor enclosure.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry xml:id="dbdoclet.50569341_68839">
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_23269"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-14.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
service or reconfiguration of the system. </para>
|
||
5 years ago
|
<para><emphasis role="bold">Implementation Note:</emphasis> A change in either TM or
|
||
7 years ago
|
SE would indicate a system replacement as opposed to a reconfiguration.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
|
</variablelist>
|
||
|
|
||
5 years ago
|
<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
|
||
7 years ago
|
System Identifier Field which follows. </para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
field, allowing service personnel to move the old SE to the new FRU.</para>
|
||
|
</section>
|
||
5 years ago
|
|
||
7 years ago
|
<section xml:id="dbdoclet.50569341_35066">
|
||
|
<title>Hardware Location Codes</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
places:</para>
|
||
|
|
||
5 years ago
|
<orderedlist>
|
||
7 years ago
|
<listitem>
|
||
|
<para>These location codes would be included as a property,
|
||
5 years ago
|
<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
|
||
7 years ago
|
are physically located in the platform.</para>
|
||
|
</listitem>
|
||
|
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
<emphasis>check-exception</emphasis> services. </para>
|
||
|
</listitem>
|
||
5 years ago
|
</orderedlist>
|
||
7 years ago
|
|
||
5 years ago
|
<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
|
||
7 years ago
|
(teletypewriter) terminals.</para>
|
||
5 years ago
|
<para>Location Codes are globally unique within a system and are persistent
|
||
7 years ago
|
between system reboots and power cycles.</para>
|
||
|
|
||
|
<variablelist>
|
||
|
<varlistentry xml:id="dbdoclet.50569341_25472">
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_35066"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<para>All platforms must implement the
|
||
7 years ago
|
Converged Location Codes option.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_35066"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<para>Location codes must be globally unique
|
||
|
within a system, including across multiple CECs of a clustered system, and must
|
||
7 years ago
|
be persistent across multiple system reboots and power cycles.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
|
</variablelist>
|
||
|
|
||
5 years ago
|
<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
|
||
7 years ago
|
Complex) might be something like this: </para>
|
||
|
|
||
|
<itemizedlist mark="none">
|
||
|
<listitem>
|
||
|
<para>U7879.001.1012345-P2-C3</para>
|
||
|
</listitem>
|
||
|
</itemizedlist>
|
||
|
|
||
5 years ago
|
<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.
|
||
7 years ago
|
Periods may be used to improve readability of the location code.</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
the Converged Location Codes option.</para>
|
||
|
|
||
5 years ago
|
|
||
7 years ago
|
<variablelist>
|
||
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_35066"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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>
|
||
7 years ago
|
property in the <emphasis role="bold"><literal>root</literal></emphasis> node of the device tree.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_35066"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
<xref linkend="dbdoclet.50569341_41991"/>.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_35066"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
<xref linkend="dbdoclet.50569341_41991"/>. </para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
|
</variablelist>
|
||
|
|
||
|
<section xml:id="dbdoclet.50569341_81497">
|
||
|
<title>Converged Location Code Labels</title>
|
||
5 years ago
|
<para>This section describes the types of location code labels. See also
|
||
|
<xref linkend="dbdoclet.50569341_41991"/> for the rules for building a location
|
||
7 years ago
|
code.</para>
|
||
|
|
||
|
<section>
|
||
|
<title>Prefix Summary Table</title>
|
||
5 years ago
|
<para>The prefix of a converged location code is as defined in this
|
||
7 years ago
|
section.</para>
|
||
|
|
||
|
<variablelist>
|
||
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_81497"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Air handler (for example: blower, fan, motor scroll
|
||
7 years ago
|
assembly, motor drive assembly). <xref linkend="dbdoclet.50569341_Air-Handler-Location-Label"/>.</para>
|
||
|
</entry>
|
||
|
</row>
|
||
|
<row>
|
||
|
<entry>
|
||
|
<para> C</para>
|
||
|
</entry>
|
||
|
<entry>
|
||
5 years ago
|
<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).
|
||
7 years ago
|
<xref linkend="dbdoclet.50569341_Card-Location-Label"/>.</para>
|
||
|
</entry>
|
||
|
</row>
|
||
|
<row>
|
||
|
<entry>
|
||
|
<para> D</para>
|
||
|
</entry>
|
||
|
<entry>
|
||
5 years ago
|
<para> Device (for example: Diskette, DASD, Operator Panel, SES
|
||
|
(Storage Enclosure Services) Device).
|
||
7 years ago
|
<xref linkend="dbdoclet.50569341_Device-Location-Label"/>.</para>
|
||
|
</entry>
|
||
|
</row>
|
||
|
<row>
|
||
|
<entry>
|
||
|
<para> E</para>
|
||
|
</entry>
|
||
|
<entry>
|
||
5 years ago
|
<para> Electrical (for example: Battery, Power Supply,
|
||
7 years ago
|
Charger). <xref linkend="dbdoclet.50569341_Electrical-Location-Label"/>.</para>
|
||
|
</entry>
|
||
|
</row>
|
||
|
<row>
|
||
|
<entry>
|
||
|
<para> F</para>
|
||
|
</entry>
|
||
|
<entry>
|
||
5 years ago
|
<para> Frame. See
|
||
7 years ago
|
<xref linkend="dbdoclet.50569341_43571"/>.</para>
|
||
|
</entry>
|
||
|
</row>
|
||
|
<row>
|
||
|
<entry>
|
||
|
<para> L</para>
|
||
|
</entry>
|
||
|
<entry>
|
||
5 years ago
|
<para> Logical Path (for example: SCSI Target, IDE Address,
|
||
|
ATAPI Address, Fibre Channel LUN, etc.).
|
||
7 years ago
|
<xref linkend="dbdoclet.50569341_Logical-Path-Label1"/>.</para>
|
||
|
</entry>
|
||
|
</row>
|
||
|
<row>
|
||
|
<entry>
|
||
|
<para> M</para>
|
||
|
</entry>
|
||
|
<entry>
|
||
5 years ago
|
<para> Mechanical (Plumbing, Valves, Latches). See
|
||
7 years ago
|
<xref linkend="dbdoclet.50569341_55481"/>.</para>
|
||
|
</entry>
|
||
|
</row>
|
||
|
<row>
|
||
|
<entry>
|
||
|
<para> N</para>
|
||
|
</entry>
|
||
|
<entry>
|
||
5 years ago
|
<para> Horizontal placement for an empty rack location. See
|
||
7 years ago
|
<xref linkend="dbdoclet.50569341_88482"/>.</para>
|
||
|
</entry>
|
||
|
</row>
|
||
|
<row>
|
||
|
<entry>
|
||
|
<para> P</para>
|
||
|
</entry>
|
||
|
<entry>
|
||
5 years ago
|
<para> Planar (for example: Backplane, Board).
|
||
7 years ago
|
<xref linkend="dbdoclet.50569341_33230"/>.</para>
|
||
|
</entry>
|
||
|
</row>
|
||
|
<row>
|
||
|
<entry>
|
||
|
<para> R</para>
|
||
|
</entry>
|
||
|
<entry>
|
||
5 years ago
|
<para> Resource (identifies a resource that is not a FRU, but
|
||
|
needs identification in the error log). See
|
||
7 years ago
|
<xref linkend="dbdoclet.50569341_70735"/>.</para>
|
||
|
</entry>
|
||
|
</row>
|
||
|
<row>
|
||
|
<entry>
|
||
|
<para> S</para>
|
||
|
</entry>
|
||
|
<entry>
|
||
5 years ago
|
<para> SR-IOV adapter virtual function. See
|
||
7 years ago
|
<xref linkend="dbdoclet.50569341_40590"/>.</para>
|
||
|
</entry>
|
||
|
</row>
|
||
|
<row>
|
||
|
<entry>
|
||
|
<para> T</para>
|
||
|
</entry>
|
||
|
<entry>
|
||
5 years ago
|
<para> Port (for example: Port, Connector, Cable Connector,
|
||
|
Jack, Interposer).
|
||
7 years ago
|
<xref linkend="dbdoclet.50569341_Port-Location-Label"/>.</para>
|
||
|
</entry>
|
||
|
</row>
|
||
|
<row>
|
||
|
<entry>
|
||
|
<para> U</para>
|
||
|
</entry>
|
||
|
<entry>
|
||
5 years ago
|
<para> Unit (for example: System, CEC, Card Cage, Drawer,
|
||
|
Chassis (Unpopulated drawer)).
|
||
7 years ago
|
<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>
|
||
5 years ago
|
<para> Worldwide unique ID (for example: Fibre Channel).
|
||
7 years ago
|
<xref linkend="dbdoclet.50569341_Worldwide-Unique-Identifer"/>.</para>
|
||
|
</entry>
|
||
|
</row>
|
||
|
<row>
|
||
|
<entry>
|
||
|
<para> X</para>
|
||
|
</entry>
|
||
|
<entry>
|
||
5 years ago
|
<para> EIA value for empty rack location. See
|
||
7 years ago
|
<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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
card.</para>
|
||
5 years ago
|
<para>Examples of cards include: Plug-in I/O cards, processor cards,
|
||
|
daughter cards, DIMMs, regulator cards, MCMs, L3 cache modules, jumper cards,
|
||
7 years ago
|
pass-through interposers, and pluggable module chips.</para>
|
||
|
</section>
|
||
|
|
||
|
<section xml:id="dbdoclet.50569341_Device-Location-Label">
|
||
|
<title>Device Location Label</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
mounted, usually a planar.</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
determination, such as SES (Storage Enclosure Services) devices.</para>
|
||
|
</section>
|
||
|
|
||
|
<section xml:id="dbdoclet.50569341_Electrical-Location-Label">
|
||
|
<title>Electrical Location Label</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
which the electrical resource is mounted, usually a unit or planar.</para>
|
||
5 years ago
|
<para>Examples of electrical resources include: batteries, power
|
||
7 years ago
|
supplies, and chargers.</para>
|
||
|
</section>
|
||
|
|
||
|
<section xml:id="dbdoclet.50569341_Port-Location-Label">
|
||
|
<title>Port Location Label</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
mounted, usually a card or planar.</para>
|
||
5 years ago
|
<para>Examples of resources with a port location label include: ports,
|
||
7 years ago
|
connectors, cable connectors, jacks, and interposers.</para>
|
||
|
</section>
|
||
|
|
||
|
<section xml:id="dbdoclet.50569341_Worldwide-Unique-Identifer">
|
||
|
<title>Worldwide Unique Identifier</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
a port or worldwide unique identifier.</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
to be located.</para>
|
||
|
</section>
|
||
|
|
||
|
<section xml:id="dbdoclet.50569341_42347">
|
||
|
<title>Virtual Planar Location Label</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
location label its last element.</para>
|
||
|
</section>
|
||
|
|
||
|
<section xml:id="dbdoclet.50569341_88482">
|
||
|
<title>Horizontal Placement Location Label</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
label immediately follows the EIA location label.</para>
|
||
|
</section>
|
||
|
|
||
|
<section xml:id="dbdoclet.50569341_19418">
|
||
|
<title>EIA Location Label</title>
|
||
5 years ago
|
<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,
|
||
7 years ago
|
the EIA location label immediately follows the frame location label.</para>
|
||
|
</section>
|
||
|
|
||
|
<section xml:id="dbdoclet.50569341_43571">
|
||
|
<title>Frame Location Label</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
label.</para>
|
||
|
</section>
|
||
|
|
||
|
<section xml:id="dbdoclet.50569341_40590">
|
||
|
<title>Virtual Function Location Label</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
function uses.</para>
|
||
|
</section>
|
||
|
|
||
|
<section xml:id="dbdoclet.50569341_55481">
|
||
|
<title>Mechanical Location Label</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
which the mechanical device is mounted. </para>
|
||
5 years ago
|
<para>Examples of resources with a mechanical location label include:
|
||
7 years ago
|
plumbing, valves, and latches.</para>
|
||
|
</section>
|
||
|
|
||
|
<section xml:id="dbdoclet.50569341_70735">
|
||
|
<title>Resource Location Label</title>
|
||
5 years ago
|
<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.
|
||
7 years ago
|
</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para>This section describes the rules for building a location code. See
|
||
|
also <xref linkend="dbdoclet.50569341_81497"/> the types of location code
|
||
7 years ago
|
labels. </para>
|
||
|
|
||
|
<section>
|
||
|
<title>Usage of Location Codes</title>
|
||
5 years ago
|
<para>Any reference to a FRU must reference the official location
|
||
7 years ago
|
code.</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
components.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Persistence of Location Codes</title>
|
||
5 years ago
|
<para>Physical path location codes are permanent. Physical path location
|
||
7 years ago
|
codes will not change unless there has been a change of hardware.</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
system.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Forming Location Codes</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
location labels are separated by dashes (“-”).</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Length Restrictions</title>
|
||
5 years ago
|
<para>Location codes are no more than 79 characters in length. The
|
||
7 years ago
|
lengths of individual location labels vary. </para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Location Labels Content</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
double byte devices.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Physical Representation</title>
|
||
5 years ago
|
<para>In so far as it is possible, location labels must match the labels
|
||
7 years ago
|
that are present on the hardware. </para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
hardware.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Multiple Function FRUs</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
multiple connectors for one port. </para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Multiple Connectors for One Port</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
connectors have the same location code.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Location Label Numbering Scope</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
would show child location labels of C1, C2, C3, C4, and C5.</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
adapter would have location labels of T1 and T2.</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
specific models.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>FRU Orientation</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
oriented.</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
location numbering.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Unit Location Codes</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
during manufacture. </para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
serial number 10-ABCDE would have a location code of:</para>
|
||
|
|
||
|
<itemizedlist mark="none">
|
||
|
<listitem>
|
||
|
<para>U9117.250.10ABCDE</para>
|
||
|
</listitem>
|
||
|
</itemizedlist>
|
||
|
|
||
5 years ago
|
<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
|
||
7 years ago
|
data will be used in exactly the same way.</para>
|
||
5 years ago
|
<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,
|
||
7 years ago
|
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>
|
||
|
|
||
5 years ago
|
<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
|
||
7 years ago
|
code of:</para>
|
||
|
|
||
|
<itemizedlist mark="none">
|
||
|
<listitem>
|
||
|
<para>U0573.001.1040320</para>
|
||
|
</listitem>
|
||
|
</itemizedlist>
|
||
|
|
||
5 years ago
|
<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
|
||
7 years ago
|
following this scheme might have a unit label of:</para>
|
||
|
|
||
|
<para>U1234.TU1.5678901</para>
|
||
|
|
||
5 years ago
|
<para>Enclosure feature code/count must never collide with one another or
|
||
|
with any machine type/model. Likewise, enclosure machine type/model must never
|
||
7 years ago
|
collide with one another or any enclosure feature code/count.</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
the customer can ensure the uniqueness of these values.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Planar Location Codes</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
irrespective of the kind of planar involved.</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
will be reported with the planar location code.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Card Connector Location Codes</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
resource.</para>
|
||
5 years ago
|
<para>The process is the same irrespective of the kind of card
|
||
7 years ago
|
involved.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Riser Card Connector Location Codes</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
device.</para>
|
||
|
</section>
|
||
|
|
||
|
<section xml:id="dbdoclet.50569341_32742">
|
||
|
<title>Virtual Card Connector Location Codes</title>
|
||
5 years ago
|
<para>Virtual card connector location codes are formed as
|
||
7 years ago
|
though there were a virtual planar with card slots.
|
||
5 years ago
|
For example, the location code for a virtual IOA in partition
|
||
7 years ago
|
5 and in virtual slot 3 would be of the form:</para>
|
||
7 years ago
|
<itemizedlist mark="none">
|
||
|
<listitem>
|
||
7 years ago
|
<para>U9117.001.1076DEF-V5-C4</para>
|
||
|
</listitem>
|
||
|
</itemizedlist>
|
||
5 years ago
|
<para>The partition number 5 is specified in the V label
|
||
7 years ago
|
and the virtual slot number 3 is specified in the C
|
||
5 years ago
|
label. Also note that the U label specifies the system
|
||
7 years ago
|
type, model, and serial (the system location code),
|
||
|
not the enclosure type, model, and serial.</para>
|
||
5 years ago
|
|
||
|
<para>Some operating systems may append a T label
|
||
7 years ago
|
to the virtual IOA location code. For example:</para>
|
||
|
<itemizedlist mark="none">
|
||
|
<listitem>
|
||
|
<para>U9117.001.1076DEF-V5-C4-T1</para>
|
||
7 years ago
|
</listitem>
|
||
|
</itemizedlist>
|
||
|
</section>
|
||
5 years ago
|
|
||
7 years ago
|
<section xml:id="dbdoclet.50569341_26909">
|
||
|
<title>Port Location Codes</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
<xref linkend="dbdoclet.50569341_Port-Location-Label"/>.</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
card.</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
contiguous. </para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Determining Port Number</title>
|
||
5 years ago
|
<para>If the port number cannot be determined from VPD or VPD plus
|
||
|
configuration or addressing information, software or firmware must infer the
|
||
7 years ago
|
port number.</para>
|
||
|
|
||
5 years ago
|
<itemizedlist>
|
||
7 years ago
|
<listitem>
|
||
5 years ago
|
<para>For SCSI IOAs with multiple PCI configuration spaces, each port
|
||
7 years ago
|
has its own configuration space. </para>
|
||
|
</listitem>
|
||
5 years ago
|
|
||
7 years ago
|
<listitem>
|
||
5 years ago
|
<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,
|
||
7 years ago
|
etc.</para>
|
||
|
</listitem>
|
||
5 years ago
|
</itemizedlist>
|
||
7 years ago
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Physical Device Location Codes</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
location codes. For example, </para>
|
||
|
|
||
5 years ago
|
<itemizedlist mark="none">
|
||
7 years ago
|
<listitem>
|
||
|
<para>U5734.001.10ABCDE-P3-D19</para>
|
||
|
</listitem>
|
||
|
</itemizedlist>
|
||
|
|
||
5 years ago
|
<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
|
||
7 years ago
|
resource.</para>
|
||
|
<para><emphasis role="bold">Notes:</emphasis></para>
|
||
5 years ago
|
<orderedlist>
|
||
7 years ago
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
information.</para>
|
||
|
</listitem>
|
||
|
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
device location code will be used.</para>
|
||
|
</listitem>
|
||
|
</orderedlist>
|
||
|
</section>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
7 years ago
|
<title>SCSI Device Logical Path Location Codes -- Real</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
is:</para>
|
||
|
|
||
5 years ago
|
<itemizedlist mark="none">
|
||
7 years ago
|
<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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
# being a decimal value. For example:</para>
|
||
5 years ago
|
<itemizedlist mark="none">
|
||
7 years ago
|
<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>
|
||
5 years ago
|
<para>The desired form of the location code is based on the physical-path
|
||
7 years ago
|
location codes obtained from VPD. For example:</para>
|
||
|
|
||
5 years ago
|
<itemizedlist mark="none">
|
||
7 years ago
|
<listitem>
|
||
|
<para>U5734.001.1076543-P2-D4</para>
|
||
|
</listitem>
|
||
|
</itemizedlist>
|
||
|
|
||
5 years ago
|
<para>For an IDE device that had an older form of VPD (without physical
|
||
7 years ago
|
location codes), then its location code would have looked like:</para>
|
||
|
|
||
5 years ago
|
<itemizedlist mark="none">
|
||
7 years ago
|
<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>
|
||
5 years ago
|
<title>Fibre Channel Device Logical Path Location Codes --
|
||
7 years ago
|
Real</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
is:</para>
|
||
5 years ago
|
|
||
|
<itemizedlist mark="none">
|
||
7 years ago
|
<listitem>
|
||
|
<para>U787A.001.1012345-P1-C5-T2-W123456789ABCDEF0-L1A05000000000000</para>
|
||
|
</listitem>
|
||
|
</itemizedlist>
|
||
|
</section>
|
||
|
|
||
|
<section xml:id="dbdoclet.50569341_30561">
|
||
5 years ago
|
<title>Location Codes for SR-IOV Adapter Virtual
|
||
7 years ago
|
Functions</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
adapter.</para>
|
||
5 years ago
|
<para>For an SR-IOV ethernet adapter, the third virtual function for the
|
||
7 years ago
|
first ethernet port would look like:</para>
|
||
|
|
||
5 years ago
|
<itemizedlist mark="none">
|
||
7 years ago
|
<listitem>
|
||
|
<para>U7043.150.1076543-P1-C5-T1-S2</para>
|
||
|
</listitem>
|
||
|
</itemizedlist>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Group Labels</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
that displays information on the corresponding FRUs. </para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Sandwich FRU Location Label </title>
|
||
5 years ago
|
<para>A Sandwich FRU has a single location label to describe its location
|
||
7 years ago
|
just as any single FRU would.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Sandwich FRU Child Location Labels</title>
|
||
5 years ago
|
<para>A Sandwich FRU is like any single FRU in that it has one numbering
|
||
7 years ago
|
space for numbering its child locations.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Location Code Reported by Sensors</title>
|
||
5 years ago
|
<para>The location code reported by a sensor is the location code of the
|
||
7 years ago
|
FRU being monitored by the sensor.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Sensor Locations</title>
|
||
5 years ago
|
<para>The location code of a sensor is the location code of the FRU on
|
||
7 years ago
|
which the sensor is located.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Location Code Reported for Indicators</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
indicator itself.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Indicator Locations</title>
|
||
5 years ago
|
<para>The location code of an indicator is the location code of the FRU
|
||
7 years ago
|
on which the indicator is located.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Firmware Location Codes</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
location label value) on planar 1 could have a location code of the form:</para>
|
||
|
|
||
5 years ago
|
<itemizedlist mark="none">
|
||
7 years ago
|
<listitem>
|
||
|
<para>U7879.001.1054321-P1-Y2</para>
|
||
|
</listitem>
|
||
|
</itemizedlist>
|
||
|
|
||
5 years ago
|
<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
|
||
7 years ago
|
system location code not the CEC enclosure location code:</para>
|
||
|
|
||
5 years ago
|
<itemizedlist mark="none">
|
||
7 years ago
|
<listitem>
|
||
|
<para>U9117.001.1054321-Y1</para>
|
||
|
</listitem>
|
||
|
</itemizedlist>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Bulk Power Assembly (BPA) Location Codes</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
component. </para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
BPA has a planar P2 etc.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Internal Battery Features Location Codes</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
that BPA. </para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Media Drawer Location Codes</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
labels in the CEC.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Horizontal Placement Location Labels</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
side of the frame (when viewed from the front).</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>EIA Location Label</title>
|
||
5 years ago
|
<para>The EIA location label begins with the prefix “X”
|
||
|
followed by a nonzero digit which represents the EIA location of the bottom of
|
||
7 years ago
|
the unit that is or would be in the frame at that location.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Blade Chassis Location Codes</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
location label (Un) of a disk in a storage module.</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
disk identification.</para>
|
||
|
</section>
|
||
|
|
||
|
<section xml:id="sec_prod_topo_hotplug_dev">
|
||
|
<title>Location Codes for Hot-pluggable Devices</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
can be provided with just the <emphasis role="bold"><literal>“ibm,loc-code”</literal></emphasis> property.</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
node.</para>
|
||
|
|
||
|
<variablelist>
|
||
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="sec_prod_topo_hotplug_dev"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
interface.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="sec_prod_topo_hotplug_dev"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
<emphasis role="bold"><literal>“ibm,loc-code”</literal></emphasis> property.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="sec_prod_topo_hotplug_dev"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
location code is undeterminable.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="sec_prod_topo_hotplug_dev"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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>
|
||
7 years ago
|
property must not exist in the parent of those nodes. </para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
|
</variablelist>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Location Code for USB Attached Devices</title>
|
||
5 years ago
|
<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,
|
||
7 years ago
|
counting from 1. </para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
be:</para>
|
||
|
|
||
5 years ago
|
<itemizedlist mark="none">
|
||
7 years ago
|
<listitem>
|
||
|
<para>U787A.001.10ABCDE-P1-T5-L1-L3</para>
|
||
|
</listitem>
|
||
|
</itemizedlist>
|
||
|
</section>
|
||
5 years ago
|
|
||
|
<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>
|
||
|
|
||
5 years ago
|
<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>
|
||
5 years ago
|
|
||
5 years ago
|
<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>
|
||
5 years ago
|
|
||
5 years ago
|
<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>
|
||
5 years ago
|
|
||
5 years ago
|
<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>
|
||
5 years ago
|
|
||
5 years ago
|
<section xml:id="sec_virtual_fibre_channel_device_location_codes">
|
||
|
<title>Virtual Fibre Channel Device Location Codes</title>
|
||
5 years ago
|
|
||
5 years ago
|
<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>
|
||
5 years ago
|
|
||
5 years ago
|
<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>
|
||
7 years ago
|
</section>
|
||
7 years ago
|
</section>
|
||
|
|
||
|
<section xml:id="dbdoclet.50569341_29745">
|
||
|
<title>Vital Product Data</title>
|
||
|
|
||
|
<section xml:id="sec_prod_topo_vpd_intro">
|
||
|
<title>Introduction</title>
|
||
5 years ago
|
<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
|
||
7 years ago
|
assured.</para>
|
||
|
|
||
|
<variablelist>
|
||
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_29745"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<para>FRUs used in LoPAR platforms must
|
||
|
provide machine-readable VPD as defined in
|
||
7 years ago
|
<xref linkend="dbdoclet.50569341_29745"/>.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_29745"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<para>LoPAR platforms must support the
|
||
7 years ago
|
collection of, and provide availability to, Vital Product Data.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
|
</variablelist>
|
||
|
<para><emphasis role="bold">Platform Implementation Notes:</emphasis></para>
|
||
|
|
||
5 years ago
|
<orderedlist>
|
||
7 years ago
|
<listitem>
|
||
5 years ago
|
<para>It is the intent of this architecture that the FRUs of a system
|
||
7 years ago
|
be self describing using VPD. </para>
|
||
|
</listitem>
|
||
|
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
VPD, their device driver must perform the reading and translation.</para>
|
||
|
</listitem>
|
||
5 years ago
|
</orderedlist>
|
||
7 years ago
|
</section>
|
||
|
|
||
|
<section xml:id="dbdoclet.50569341_39089">
|
||
|
<title>VPD Data Structure Description</title>
|
||
5 years ago
|
<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,
|
||
7 years ago
|
previously undefined tag, to work.</para>
|
||
|
|
||
|
<variablelist>
|
||
|
<varlistentry xml:id="dbdoclet.50569341_65980">
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_39089"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
Z0-ZZ</para></footnote>, except as follows:</para>
|
||
|
|
||
5 years ago
|
<itemizedlist>
|
||
7 years ago
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
covering the above.</para>
|
||
|
</listitem>
|
||
5 years ago
|
|
||
7 years ago
|
<listitem>
|
||
5 years ago
|
<para>Only resource tags, lengths and checksums are binary. All other
|
||
7 years ago
|
data must be in ASCII format.</para>
|
||
|
</listitem>
|
||
5 years ago
|
</itemizedlist>
|
||
7 years ago
|
|
||
5 years ago
|
<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
|
||
7 years ago
|
the length. </para>
|
||
|
<para><emphasis role="bold">Implementation Notes:</emphasis></para>
|
||
|
|
||
5 years ago
|
<orderedlist>
|
||
7 years ago
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
to the OS is in the format which is required by the OS.</para>
|
||
|
</listitem>
|
||
|
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
0x7F.</para>
|
||
|
</listitem>
|
||
5 years ago
|
</orderedlist>
|
||
7 years ago
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry xml:id="dbdoclet.50569341_52346">
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_39089"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
including, the Small Resource Type End tag.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry xml:id="dbdoclet.50569341_20102">
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_39089"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
with:</para>
|
||
|
|
||
5 years ago
|
<itemizedlist>
|
||
7 years ago
|
<listitem>
|
||
5 years ago
|
<para>Large Resource type identifier string tag (type 2, byte 0 = 0x82)
|
||
7 years ago
|
with value ‘NOT_VALID_VPD’.</para>
|
||
|
</listitem>
|
||
5 years ago
|
|
||
7 years ago
|
<listitem>
|
||
5 years ago
|
<para>Large Resource type VPD keywords tag (type 16, byte 0 = 0x90)
|
||
|
containing the “YL” keyword and associated location code
|
||
7 years ago
|
data.</para>
|
||
|
</listitem>
|
||
5 years ago
|
|
||
7 years ago
|
<listitem>
|
||
5 years ago
|
<para>Small Resource Type End tag with or without a checksum covering
|
||
7 years ago
|
the above.</para>
|
||
|
</listitem>
|
||
5 years ago
|
</itemizedlist>
|
||
7 years ago
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_39089"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<para>If the device VPD is valid, all of the
|
||
7 years ago
|
device VPD must be transferred including the Small Resource Type End Tag.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry>
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569341_39089"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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>
|
||
7 years ago
|
RTAS call or the OF device tree.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
|
</variablelist>
|
||
5 years ago
|
<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
|
||
7 years ago
|
included in this sum.</para>
|
||
|
</section>
|
||
|
|
||
|
<section>
|
||
|
<title>Keyword Format Definition</title>
|
||
5 years ago
|
<para>The exact format of the VPD is vendor-specific but falls within the
|
||
7 years ago
|
specification as defined in the following subsections.</para>
|
||
|
|
||
|
<section xml:id="sec_prod_topo_vpd_fieldss">
|
||
|
<title>VPD fields</title>
|
||
5 years ago
|
<para>The fields defined in <xref linkend="dbdoclet.50569341_47429"/> are
|
||
7 years ago
|
stored in VPD modules at the time of manufacturing.</para>
|
||
|
|
||
|
<variablelist>
|
||
|
<varlistentry xml:id="dbdoclet.50569341_55947">
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="sec_prod_topo_vpd_fieldss"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
linkend="dbdoclet.50569341_47429"/>.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry xml:id="dbdoclet.50569341_65708">
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="sec_prod_topo_vpd_fieldss"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<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>
|
||
7 years ago
|
property must be “System VPD”.</para>
|
||
|
</listitem>
|
||
|
</varlistentry>
|
||
5 years ago
|
|
||
7 years ago
|
<varlistentry xml:id="dbdoclet.50569341_96984">
|
||
5 years ago
|
<term><emphasis role="bold">R1-<xref linkend="sec_prod_topo_vpd_fieldss"
|
||
7 years ago
|
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
|
||
|
<listitem>
|
||
5 years ago
|
<para>VPD for memory FRUs must contain
|
||
7 years ago
|
the SZ keyword.</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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?>
|
||
5 years ago
|
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
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Contains 1 to 15 instances of the following 16 byte
|
||
7 years ago
|
definition, concatenated together. </para>
|
||
5 years ago
|
<para>Contains the base ethernet MAC address and an instance
|
||
7 years ago
|
count. </para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
created.</para>
|
||
5 years ago
|
<para>The field contains the ASCII coded hexadecimal
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Contains 1 to 7 instances of the following 32 byte
|
||
7 years ago
|
definition, concatenated together. </para>
|
||
|
<para>SAS WWIDs. </para>
|
||
5 years ago
|
<para>The Count field is the number of available WWIDs starting
|
||
7 years ago
|
from the base and incrementing by 1 for each new WWID.</para>
|
||
5 years ago
|
<para>The field contains the ASCII coded hexadecimal
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para><emphasis role="bold">Note:</emphasis> The following are the values
|
||
|
currently defined. To get other product specific values, go through the normal
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Battery Replacement date in YYYY-MM-DD format. Used on
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Required when a CCIN is required by code to configure or
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> CEC ID - of the CEC, that is the logical controller of
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
the model.</para>
|
||
|
</listitem>
|
||
|
<listitem>
|
||
5 years ago
|
<para>blank is a 1 byte separator character, that separates
|
||
7 years ago
|
the type-model from the serial #.</para>
|
||
|
</listitem>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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?>
|
||
5 years ago
|
fix pack MIF name, “space”, Load ID (8
|
||
7 years ago
|
characters), time stamp (12 characters)<?linebreak?>
|
||
5 years ago
|
The fix pack name must be the same as the name used in
|
||
7 years ago
|
the MI keyword and is delimited by a space.<?linebreak?>
|
||
5 years ago
|
The time stamp is, hours (2 characters) + Minutes (2
|
||
|
characters) + Year (4 characters) + Month (2 characters) + Day (2 characters).
|
||
7 years ago
|
The LID level reported is the current active level. </para>
|
||
5 years ago
|
<para><emphasis role="bold">Note:</emphasis> There is no correlation
|
||
|
between the CL keyword value and which of the 3 candidate fixpack levels are
|
||
7 years ago
|
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?>
|
||
5 years ago
|
Example (in the following, the “<“,
|
||
|
“>”, and text in between these would be replaced by a value
|
||
|
representing the quantity specified by the words between “<”
|
||
7 years ago
|
and “>”):<?linebreak?>
|
||
5 years ago
|
“VN=<Volume Serial Number>,
|
||
|
VD=<Vendor>, DT=<Disk Type>, DC=<Disk-Capacity>,
|
||
|
DR=<Disk-RPM>, DS=<Disk-Interface-Speed>,
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Displayable Message (if not defined, created by the
|
||
7 years ago
|
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?>
|
||
5 years ago
|
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”
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> The Feature Code is 8 bytes formatted as 4 characters, a
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Frame ID: 2 hex byte value for SPCN or 8 character
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> FRU Label: This is a variable length ASCII character
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> FRU Number (Board, card, or assembly Field Replacement
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Function Unit - This function identifies which function
|
||
|
in a multi-function IOA this VPD data applies to. Only one FU field can appear
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Two ASCII characters are used to identify each system in
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> LIC Node Alternate Bus VPD: This fixed format data field
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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?>
|
||
5 years ago
|
Used on Array resource. Comma separated string.
|
||
|
Including: “AN=Array Serial Number, AT=Array-Type, AC=Array
|
||
7 years ago
|
Configuration, Rank Position”. <?linebreak?>
|
||
5 years ago
|
Used on Rank resource. Comma separated string. Including:
|
||
|
“RN=Rank Serial Number, ST=Segment-Type(FB-1G, CKD-Mod1),
|
||
7 years ago
|
SS=Segments(####), SU=Segments-Used, RG=Rank Group(#)”. <?linebreak?>
|
||
5 years ago
|
Used on Segment Pool resource. Comma separated string.
|
||
|
Including: “ST=Segment-Type(FB-1G, CKD-Mod1), SS=Segments(####),
|
||
|
SU=Segments-Used, VS=Virtual-Segments(####),
|
||
7 years ago
|
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>
|
||
7 years ago
|
<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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
ME date are not entitled to be flashed on that system.</para>
|
||
|
<para>Format:<?linebreak?>yyyymmdd</para>
|
||
|
</entry>
|
||
|
</row>
|
||
7 years ago
|
<row>
|
||
|
<entry>
|
||
|
<para> MF </para>
|
||
|
</entry>
|
||
|
<entry>
|
||
|
<para> ASCII</para>
|
||
|
</entry>
|
||
|
<entry>
|
||
|
<para> 2</para>
|
||
|
</entry>
|
||
|
<entry>
|
||
|
<para> --</para>
|
||
|
</entry>
|
||
|
<entry>
|
||
5 years ago
|
<para> Map Format: Two hex characters identify the slot or port
|
||
|
map format that follows. This keyword must immediately precede the SM or PM
|
||
7 years ago
|
keyword.</para>
|
||
|
</entry>
|
||
|
</row>
|
||
7 years ago
|
<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>
|
||
7 years ago
|
<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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
able to be updated via non-OS visible means.</para>
|
||
|
<para>Format:<?linebreak?>
|
||
5 years ago
|
t side Microcode Image name, “space”, p
|
||
|
side Microcode Image name, “space”, booted Microcode Image
|
||
7 years ago
|
name</para>
|
||
5 years ago
|
<para>The Microcode Image name must be a 9 character name of
|
||
7 years ago
|
the form:<?linebreak?>
|
||
|
<emphasis role="bold"><literal>“NNSSS_FFF”</literal></emphasis>
|
||
|
</para>
|
||
|
<para>where</para>
|
||
5 years ago
|
<para>“NN” is a two character name (assigned by
|
||
|
the GFW Firmware Distribution Coordinator) used to identify a set of
|
||
7 years ago
|
platforms;<?linebreak?>
|
||
5 years ago
|
“SSS” is a 3 character code stream
|
||
7 years ago
|
indicator;<?linebreak?>
|
||
5 years ago
|
“_” is a separation character for
|
||
7 years ago
|
readability; and,<?linebreak?>
|
||
5 years ago
|
“FFF” is a 3 character identifier of the
|
||
7 years ago
|
current microcode level.</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
be updated via non-OS visible means.</para>
|
||
|
<para>Format:<?linebreak?>
|
||
5 years ago
|
t side Microcode Level name, “space”, p
|
||
|
side Microcode Level name, “space”, booted Microcode Level
|
||
7 years ago
|
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?>
|
||
5 years ago
|
"E" is Extension - Typically zero. If non-zero,
|
||
7 years ago
|
designates off cycle single system release<?linebreak?>
|
||
|
"M" is Modification - associated Service Pack Level (0-Z)<?linebreak?>
|
||
5 years ago
|
"F" is Fix Level - Typically zero. If non-zero, designate
|
||
7 years ago
|
off cycle, targeted fixes</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Module Plug count. This counter keeps track of the
|
||
|
numbers of times a module has been plugged, so that reliability statistics can
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Machine Universal Unit ID (UUID). The value is the ASCII
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Network Address (ASCII coded hexadecimal representation
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
“.”, 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>
|
||
5 years ago
|
<para> World Wide Node Name - IEEE assigned 64 bit identifier
|
||
7 years ago
|
(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>
|
||
5 years ago
|
<para>The OS level is shown in the form of: V.R.M.F where V is
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Op Panel installed flag. “Y” = yes a panel
|
||
|
is installed, “N” = no a panel is not installed. The absence of
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Port Map: Contains the RIO Port Map label information.
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Required if it is different from the FRU number
|
||
7 years ago
|
(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>
|
||
5 years ago
|
<para> SPCN VPD: Identification of the SPCN VPD area on the I/O
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Power Parameters: SPCN field identifying Power node
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Power: 16 ASCII hexadecimal characters that represent
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para>Length (MTMS-Exx). - used on storage enclosure
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para>Used on Rack enclosure resources. Provides an ordered
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Power Domain ID - is the MTMS of the BPA, that powers an
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
the model.</para>
|
||
|
</listitem>
|
||
|
<listitem>
|
||
5 years ago
|
<para>blank is a 1 byte separator character, that separates
|
||
7 years ago
|
the type-model from the serial #.</para>
|
||
|
</listitem>
|
||
|
<listitem>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Power Resource ID: A 4 byte hex field providing a unique
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para>Used on I/O enclosure resource. Identifies RIO-G loop on
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
the first 56 bits.<?linebreak?>
|
||
5 years ago
|
Each of the 16 4-bit nibbles are converted to 16 ASCII
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
character string that defines the level of the image.<?linebreak?>
|
||
5 years ago
|
ROM id, Location ID, ROM part number, FW part number, FW
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
string that defines the level of the image.</para>
|
||
5 years ago
|
<para>ROM id, Location ID, ROM part number, FW part number, FW
|
||
7 years ago
|
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?>
|
||
5 years ago
|
Used on I/O enclosure resource. Identifies the distance
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Record Type. Contains a four character Record Name that
|
||
|
represents a VPD Definition. The following list associates Record Names with
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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?>
|
||
5 years ago
|
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
|
||
7 years ago
|
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?>
|
||
5 years ago
|
Length (MTMS). Used on partition, array-site, array,
|
||
|
rank, and storage pool, and enclosure-FRU resources, associated with a storage
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> See Requirements
|
||
|
<xref linkend="dbdoclet.50569341_50574" xrefstyle="select: nopage"/>,
|
||
7 years ago
|
<xref linkend="dbdoclet.50569341_39729" xrefstyle="select: nopage"/>,
|
||
5 years ago
|
<xref linkend="dbdoclet.50569341_39191" xrefstyle="select: nopage"/>,
|
||
|
<xref linkend="dbdoclet.50569341_68839" xrefstyle="select: nopage"/>, and
|
||
7 years ago
|
<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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Slot Map: Contains Slot Map information. Must be
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> See Requirements
|
||
7 years ago
|
<xref linkend="dbdoclet.50569341_50574" xrefstyle="select: nopage"/>,
|
||
|
<xref linkend="dbdoclet.50569341_39729" xrefstyle="select: nopage"/>,
|
||
|
<xref linkend="dbdoclet.50569341_14313" xrefstyle="select: nopage"/>,
|
||
5 years ago
|
<xref linkend="dbdoclet.50569341_68839" xrefstyle="select: nopage"/>, and
|
||
7 years ago
|
<xref linkend="dbdoclet.50569341_65708" xrefstyle="select: nopage"/></para>
|
||
|
</entry>
|
||
|
<entry>
|
||
5 years ago
|
<para> The high order 4 bytes are the “Machine
|
||
|
Type”, the next byte is a dash, followed by the 3 byte
|
||
7 years ago
|
“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>
|
||
5 years ago
|
<para> The high order 4 bytes are the “Machine
|
||
|
Type”, the next byte is a dash, followed by the 3 byte
|
||
7 years ago
|
“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?>
|
||
5 years ago
|
Used on a partition resource that is: CKD3380=####,
|
||
|
CKD3390=####, SCSI512=####, SCSI520=####, SCSI Host Ports=####, SCSI LUN
|
||
7 years ago
|
Groups=####. <?linebreak?>
|
||
5 years ago
|
Used on device adapter or host adapter FRU for logical
|
||
7 years ago
|
configuration information, if any. <?linebreak?>
|
||
5 years ago
|
Used on Storage Enclosure. Comma separated string
|
||
7 years ago
|
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?>
|
||
5 years ago
|
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=####, .
|
||
7 years ago
|
. .”.</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>
|
||
5 years ago
|
<para> Reserved for future use. Used on partition resource or
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Reserved for future use. Used on partition resource or
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Reserved for future use. Used on partition resource or
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Reserved for future use. Used on partition resource or
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Reserved for future use. Used on partition resource or
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Reserved for future use. Used on partition resource or
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Reserved for future use. Used on partition resource or
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Contains the ASCII coded hexadecimal World Wide Port
|
||
7 years ago
|
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>
|
||
5 years ago
|
<para> Ties together multiple enclosures that share the same
|
||
7 years ago
|
combined SE and TM.</para>
|
||
|
</entry>
|
||
|
</row>
|
||
|
</tbody>
|
||
|
</tgroup>
|
||
|
</table>
|
||
|
<para><emphasis role="bold">Notes referenced in <xref linkend="dbdoclet.50569341_47429"/>:</emphasis>
|
||
|
</para>
|
||
5 years ago
|
<orderedlist>
|
||
7 years ago
|
<listitem xml:id="dbdoclet.50569341_42716">
|
||
5 years ago
|
<para>When the
|
||
|
BR keyword indicates “S” or “T” for the type of
|
||
7 years ago
|
machine, this field must be present and must be non-blank.</para>
|
||
|
</listitem>
|
||
5 years ago
|
</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,
|
||
7 years ago
|
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>
|
||
5 years ago
|
<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
|
||
7 years ago
|
unique to LoPAR platforms.</para>
|
||
|
|
||
5 years ago
|
<orderedlist>
|
||
7 years ago
|
<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>
|
||
5 years ago
|
</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
|
||
7 years ago
|
VPD.</para>
|
||
5 years ago
|
<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
|
||
7 years ago
|
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="LoPAR.RTAS"/></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="LoPAR.RTAS"/></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>
|
||
5 years ago
|
<para> Ties together multiple enclosures that share the same
|
||
|
combined SE and TM. See Requirement
|
||
7 years ago
|
<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>
|
||
5 years ago
|
<para> Product Specific Information: may be keyword oriented
|
||
7 years ago
|
and ‘,’ delimited.</para>
|
||
|
</entry>
|
||
|
</row>
|
||
|
</tbody>
|
||
|
</tgroup>
|
||
|
</table>
|
||
|
</section>
|
||
|
</section>
|
||
|
</section>
|
||
|
</chapter>
|