BMC common tool include cmdtool and ipmitool.
Both of them can give an requirement to BMC with suitable command,but the command parameter is difference.Now i will record its way via the ”Get Device ID” command
Under UEFI Shell enviroment:
cmdtool.efi 20 18 01
Under Windows OS CMD windows；
ipmitool.exe -H <SUT_BMC_IP> -I lanplus -U <BMC_USER>-P <BMC PASSWORD> raw 0x06 0x01
Their result are same ,but the command parameter is difference.
we look at the first command cmdtool.efi 20 18 01
the second command ipmitool.exe ….raw 0x06 0x01
0001 1000 shift right for two bits will equal to 0000 0110
00011000—–>>remove 2 bits on the right side—–>>00000110
also ipmitool command parameter transfer to the cmdtool command parameter shoud do an shift left operation.
then when we give the command requirement to BMC, a response will be feedbacked.we need to check the IPMI SPEC to confirm if it is Passed or Failed.
ipmitool .exe…..raw 0x06 0x01
we find the 0x06 (6h) is stand for App in the
IPMI spec page41 capter 5.1
5.1. Message Interface Description
The heart of this specification is the definition of the messages and data formats used for implementing sensors, event messages, Event Generators and Event Receivers, the SDR Repository, and the System Event Log in the platform management architecture. These messages are designed for delivery via a messaging interface with a particular set of characteristics. This section presents the general specification of that interface, and of the messages themselves.
The Message Interface is defined as a ‘request/response’ interface. That is, a request message is used to initiate an action or set data, and a response message is returned to the Requester . In this document, Request Messages are often referred to as ‘commands’ or ‘requests’, and Response Messages as ‘responses’.
All messages in this specification share the same common elements as the payload to the ‘command interpreter’ in the logical device that receives the message. The messaging interfaces differ in the framing, physical addressing, and data integrity mechanisms that are used to deliver this payload.
The following are the common components of messages specified in this document:
Network Function (NetFn) A field that identifies the functional class of the message. The Network
Function clusters IPMI commands into different sets. See Section 5.1, Network Function Codes, for more information.
Request/Response identifier A field that unambiguously differentiates Request Messages from
Response Messages. In the IPMB Protocol, this identifier is ‘merged’ with the Network Function code such that ‘Even’ network function codes identify Request Messages, and ‘Odd’ network function codes identify Response Messages.
Requester’s ID Information that identifies the source of the Request. This information must be sufficient to allow the Response to be returned to the correct Requester. For example, for the IPMB the Requester’s ID consists of the Slave Address and LUN of the Requester device. For a multiple stream system interface the Requester’s ID is the ‘stream id’ for the stream through which the request was issued.
Responder’s ID A field that identifies the Responder to the Request. In Request Messages this field is used to address the Request to the desired Responder, in Response Messages this field is used to assist the Requester in matching up a response with a given request.
Command The messages specified in this document contain a one-byte command field. Commands are unique within a given Network Function. Command values can range from 00h through FDh. Code FEh is reserved for future extension of the specification, and code FFh is reserved for message interface level error reporting on potential future interfaces.
Data The Data field carries the additional parameters for a request or a response, if any.
1.1 Network Function Codes
The network layer in the connection header consists of a six-bit field identifying the function to be accessed. The remaining two bits are the LUN field. The LUN field provides further sub-addressing within the node.
The network function is used to cluster commands into functional command sets. In a parsing hierarchy, the LUN field may be thought of as the selector for a particular Network Function handler in the node, and the Network Function may be considered the selector for a particular command set handler within the node.
The following table defines the supported network functions. With the exception of the Application and Firmware Transfer network functions, the commands and responses for a given network function are not node specific. The format and function for standard command sets is specified later in this specification.
Table 5-, Network Function Codes
|00, 01||Chassis||Chassis Device Requests and Responses||00h identifies the message as a command/request and 01h as a response, relating to the common chassis control and status functions.|
|02*, 03*||Bridge||Bridge Requests and Responses||02h (request) or 03h (response) identifies the message as containing data for bridging to the next bus. This data is typically another message, which may also be a bridging message. This function is
present only on bridge nodes.
|Sensor and Event Requests and Responses||This functionality can be present on any node. 04h identifies the message as a command/request and 05h as a response, relating to the configuration and transmission of Event Messages and system Sensors.|
|06, 07||App||Application Requests and Responses||06h identifies the message as an application command/request and 07h a response. The exact format of application messages is implementation-specific for a particular device, with the exception of App messages that are defined by the IPMI specifications.
Note that it is possible that new versions of this specification will identify new App commands. To avoid possible conflicts with future versions of this specification, it is highly recommended that the OEM/Group network functions be used for providing ‘value added’
functions rather than the App network function code.
then go to IPMI spec page587 Table G-, Command Number Assignments and Privilege Levels
remenber that ipmitool .exe…..raw 0x06 0x01
we find the App 1h , 1h stands for the parameter 0x01 . And click section number 20.1 , it will bring answer to us.
Table G-, Command Number Assignments and Privilege Levels
|Get Device ID||20.1||App||01h|
|Broadcast ‘Get Device ID’||20.9||App||01h|
|Get Self Test Results||20.4||App||04h|
|Manufacturing Test On||20.5||App||05h|
|Set ACPI Power State||20.6||App||06h|
|Get ACPI Power State||20.7||App||07h|
|Get Device GUID||20.8||App||08h|
IPMI spec page243
20.1 Get Device ID Command
This command is used to retrieve the Intelligent Device’s Hardware Revision, Firmware/Software Revision, and Sensor and Event Interface Command specification revision information. The command also returns information
regarding the additional ‘logical device’ functionality (beyond ‘Application’ and ‘IPM’ device functionality) that is provided within the intelligent device, if any.
While broad dependence on OEM-specific functionality is discouraged, two fields in the response allow software to identify controllers for the purpose of recognizing controller specific functionality. These are the Device ID and the Product ID fields. A controller that just implements standard IPMI commands can set these fields to ‘unspecified’.
Table 20-, Get Device ID Command
|Response Data||1||Completion Code|
|2||Device ID. 00h = unspecified.|
 1 = device provides Device SDRs
0 = device does not provide Device SDRs [6:4] reserved. Return as 0.
[3:0] Device Revision, binary encoded.
|4||Firmware Revision 1
 Device available: 0=normal operation, 1= device firmware, SDR Repository update or self-initialization in progress. [Firmware / SDR Repository updates can be differentiated by issuing a Get SDR command and checking the completion code.]
[6:0] Major Firmware Revision, binary encoded.
|5||Firmware Revision 2: Minor Firmware Revision. BCD encoded.|
|6||IPMI Version. Holds IPMI Command Specification Version. BCD encoded. 00h = reserved. Bits 7:4 hold the Least Significant digit of the revision, while bits 3:0 hold the Most Significant bits. E.g. a value of 51h indicates revision
1.5 functionality. 02h for implementations that provide IPMI v2.0 capabilities
per this specification.
|7||Additional Device Support (formerly called IPM Device Support). Lists the IPMI ‘logical device’ commands and functions that the controller supports that are in addition to the mandatory IPM and Application commands.
 Chassis Device (device functions as chassis device per ICMB spec.)
 Bridge (device responds to Bridge NetFn commands)
 IPMB Event Generator (device generates event messages [platform event request messages] onto the IPMB)
 IPMB Event Receiver (device accepts event messages [platform event request messages] from the IPMB)
 FRU Inventory Device
 SEL Device
 SDR Repository Device
 Sensor Device
|8:10||Manufacturer ID, LS Byte first. The manufacturer ID is a 20-bit value that is derived from the IANA ‘Private Enterprise’ ID (see below).
Most significant four bits = reserved (0000b).
000000h = unspecified. 0FFFFFh = reserved. This value is binary encoded.
E.g. the ID for the IPMI forum is 7154 decimal, which is 1BF2h, which would be stored in this record as F2h, 1Bh, 00h for bytes 8 through 10, respectively.
|11:12||Product ID, LS Byte first. This field can be used to provide a number that identifies a particular system, module, add-in card, or board set. The number is specified according to the manufacturer given by Manufacturer ID (see below).
0000h = unspecified. FFFFh = reserved.
|(13:16)||Auxiliary Firmware Revision Information. This field is optional. If present, it holds additional information about the firmware revision, such as boot block or internal data structure version numbers. The meanings of the numbers are specific to the vendor identified by Manufacturer ID (see below). When the vendor-specific definition is not known, generic utilities should display each byte as 2-digit hexadecimal numbers, with byte 13 displayed first as the most- significant byte.|
The following presents additional specifications and descriptions for the Device ID response fields:
Device ID/Device Instance This number is specified by the manufacturer identified by the Manufacturer ID field. The Device ID field allows controller-specific software to identify the unique application command, OEM fields, and functionality that are provided by the controller.
Controllers that have different application commands, or different definitions of OEM fields, are expected to have different Device ID values. Controllers that implement identical sets of applications commands can have the same Device ID in a given system. Thus, a ‘standardized’ controller could be produced where multiple instances of the controller are used in a system, and all have the same Device ID value. [The controllers would still be differentiable by their address, location, and associated information for the controllers in the Sensor Data Records.]
The Device ID is typically used in combination with the Product ID field such that the Device IDs for different controllers are unique under a given Product ID. A controller can optionally use the Device ID as an ‘instance’ identifier if more than one controller of that kind is used in the system. Though implementing a Device GUID is the preferred method for uniquely identifying controllers. (See section 20.8, Get Device GUID) This field is binary encoded.
Device Revision The least significant nibble of the Device Revision field is used to identify when significant hardware changes have been made to the implementation of the management controller that cannot be covered with a single firmware release.
That is, this field would be used to identify two builds off the same code firmware base, but for different board fab levels. For example, device revision “1” might be required for ‘fab X and earlier’ boards, while device revision “2” would be for ‘fab Y and later’ boards. This field is binary encoded and unsigned.
Firmware Revision 1 Major Revision. 7-bits. This field holds the major revision of the firmware. This field shall be incremented on major changes or extensions of the functionality of the firmware – such as additions, deletions, or modifications of the command set. This field is binary encoded and unsigned.
The Device Available bit is used to indicate whether normal command set operation is available from the device, or it is operating in a state where only a subset of the normal commands are available. This will typically be because the device is in a firmware update state. It may also indicate that full command functionality is not available because the device is in its initialization phase or an SDR update is in progress.
Note that the revision information obtained when the Device Available bit is ‘1’ shall be indicative of the code version that is in effect. Thus, the version information may vary with the Device Available bit state.
Firmware Revision 2 Minor Revision. This field holds the minor revision of the firmware. This field will increment for minor changes such as bug fixes. This field is BCD encoded.
IPMI Version This field holds the version of the IPMI specification that the controller is compatible with. This indicates conformance with this document, including event message formats and mandatory command support. This field is BCD encoded with bits 7:4 holding the Least Significant digit of the revision and bits 3:0 holding the Most Significant bits.
The value shall be 02h for implementations that provide IPMI v2.0 capabilities per this specification.
|This field indicates the logical device support that the device provides in addition
to the IPM and Application logical devices.
Manufacturer ID This field uses the Internet Assigned Numbers Authority (http://www.iana.org/) SMI Network Management Private Enterprise Codes a.k.a. “Enterprise Numbers” for identifying the manufacturer responsible for the specification of functionality of the vendor (OEM) -specific commands, codes, and interfaces used in the controller.
For example, an event in the SEL could have OEM values in the event record. An application that parses the SEL could extract the controller address from the event record contents and use it to send the ‘Get Device ID’ command and retrieve the Manufacturer ID. A manufacturer-specific application could then do further interpretation based on a-priori knowledge of the OEM field, while a generic cross-platform application would typically just use the ID to present the manufacturer’s name alongside uninterpreted OEM event values.
The manufacturer that defines the functionality is not necessarily the manufacturer that created the physical microcontroller. For example, Vendor A may create the controller, but it gets loaded with Vendor B’s firmware. The Manufacturer ID would be for Vendor B, since they’re the party that defined the controller’s functionality.
The Manufacturer ID value from the Get Device ID command does not override Manufacturer or OEM ID fields that are explicitly defined as part of a command or record format.
If no vendor-specific functionality is defined, it is recommended that the field can either be loaded with the Manufacturer ID of the party that is responsible for the firmware for the controller, or the value FFFFh to indicate ‘unspecified’.
This field is binary encoded, and unsigned.
Product ID This value can be used in combination with the Manufacturer ID and Device ID values to identify the product-specific element of the controller-specific functionality. This number is specified by the manufacturer identified by the Manufacturer ID field.
Typically, a controller-specific application would use the Product ID to identify the type of board, module, or system that the controller is used in, instead of using the data from the FRU information associated with the controller.
|Auxiliary Firmware Revision Information||This field is optional. If present, it holds additional information about the firmware revision, such as boot block or internal data structure version numbers. The meanings of the numbers are specific to the vendor identified by Manufacturer ID (above). When the vendor-specific definition is not known, generic utilities should display each byte as 2-digit hexadecimal numbers, with byte 13 displayed first as
the most-significant byte.