Basic Mode

Basic Mode eliminates much of the overhead associated with PPP/UDP mode. Instead of encapsulating IPMI messages within an RMCP message in a UDP datagram in a PPP frame, the IPMI messages are simply encoded and framed for serial transmission. The price of this efficiency is that the remote console application cannot take advantage of built-in support for PPP and UDP in the operating system, but will need to implement IPMI communications routines on top of the OS’s generic support for asynchronous serial communications.

Since Session IDs are not part of the basic IPMI message, only a single IPMI session is supported in Basic Mode.

The BMC can use whatever Session ID value it wants for the Get Session Challenge and Activate Session commands.

13.4.1 Basic Mode Packet Framing

Framing is done with special characters to delimit the start and end of a Basic Mode packet, and to indicate the sequence for an escaped data byte (see following section). Framing and data byte escaping are applied after the message fields have been formatted. These special characters are specified in the following table.

Table 13-5, Basic Mode Special Characters

Description Value

Start Character A0h

Stop Character A5h

Packet Handshake Character A6h Data Escape Character AAh

Basic Mode messages can be thought of as IPMB messages with the I²C start and stop condition framing replaced with start and stop characters, and with the addition of data byte escaping to ensure that the framing characters are not encountered within the body of the packet. The Packet Handshake character is a special value that is used for implementing a level of software flow control with the remote application accessing the BMC.

See Section 13.4.5, Packet Handshake.

13.4.2 Data Byte Escaping

The Start, Stop, and Escape characters are disallowed within the body of the message. This is done to ensure that the start and end of a message is unambiguously delimited. If a byte matching one of the special characters is encountered in the data to be transmitted, it is encoded into a corresponding two-character sequence for transmission. This encoding is summarized in the following table.

Table 13-6, BASIC MODE Data Byte Escape Encoding

Data Byte Encoded Sequence A0h AAh (ESC), B0h A5h AAh (ESC), B5h AAh AAh (ESC), BAh A6h AAh (ESC), B6h 1Bh <ESC> AAh (ESC), 3Bh

The first character of the sequence is always the Escape character. Only the special Basic Mode characters plus the ASCII Escape <ESC> character, 1Bh, are escaped. (The ASCII Escape <ESC> character, 1Bh, is escaped to

enable the BMC to snoop for certain escape sequences in the data stream, such as the <ESC>( and <ESC>Q patterns.) All other byte values in the message are transmitted without escaping.

When the packet is received, the process is reversed. If the two-byte ‘escaped’ sequence is detected in the packet, it is converted to the corresponding data byte value. The BMC shall reject any messages that have illegal character combinations or exceed message buffer length limits. The BMC may not send an error response for these conditions.

13.4.3 Message Fields

The message fields follow those used for the IPMB, as specified in the Intelligent Platform Management Bus Communications Protocol v1.0 Specification, with the exception of the Requester’s (rq) Slave Address and Responder’s (rs) Slave Address fields, which have slightly different definitions. Note, framing and data byte escaping are applied after the message fields have been formatted. The general message format is illustrated in the following figure:

Figure 13-2, Basic Mode Message Fields

rsAddr (SA or SWID)

rqSeq / rsLUN cmd rqAddr

(SA or SWID) Request

rsAddr (SA or SWID)

net Fn (even) / rsLUN

checksum

Response

rqAddr (SA or SWID)

net Fn (odd) / rqLUN

rqSeq / rqLUN cmd data bytes (0 or more)

checksum

checksum

completion code

response data bytes (0 or more)

checksum

Where:

checksum 2's complement checksum of preceding bytes in the connection header or between the previous checksum. 8-bit checksum algorithm: Initialize checksum to 0. For each byte, checksum = (checksum + byte) modulo 256. Then checksum = - checksum. When the checksum and the bytes are added together, modulo 256, the result should be 0.

cmd Command Byte

completion code Completion code returned in the response to indicated success/failure status of the request.

data As required by the particular request or response for the command

LUN The lower 2-bits of the netFn byte identify the logical unit number, which provides further sub-addressing within the target node.

netFn Network Function code rq Abbreviation for ‘Requester’.

rqLUN Requester’s LUN.

rqAddr Requester's Address. 1 byte. LS bit is 0 for Slave Addresses and 1 for Software IDs. Upper 7-bits hold Slave Address or Software ID, respectively. This byte is 20h when the BMC is the requester.

rqSeq Sequence number, generated by the requester.

rs Abbreviation for ‘Responder’.

rsLUN Responder’s LUN

rsAddr Responder's Slave Address. 1 byte. LS bit is 0 for Slave Addresses and 1 for Software IDs.

Upper 7-bits hold Slave Address or Software ID, respectively. This byte is 20h when the BMC is the responder.

Seq Sequence number. This field is used to verify that a response is for a particular instance of a request. Refer to [IPMB] for additional information on use of the Seq field.

13.4.4 Message Retries

Basic Mode Messaging utilizes the same retry mechanisms used for the IPMB, as specification in the Intelligent Platform Management Bus Communications Protocol v1.0 Specification. The remote application timeout should be based on the IPMB timeout specifications, with additional time added for delay due to the phone system. A remote application can determine this additional delay for a given connection based on the time it takes to receive the Handshake character.

13.4.5 Packet Handshake

The handshake character is used to signal that the BMC has freed space in its input buffers for a new, incoming IPMI Message. The BMC typically returns a Handshake character within one millisecond of being able to accept a new message, unless the controller has already initiated a message transmission, or an operation such as firmware update has been initiated.

An implementation can either send the handshake character in the middle of the transmission or elect to wait to transmit the handshake character until the transmission in-progress has completed. If the implementation waits for the transmission to complete, the handshake character will typically be sent within one millisecond after the message transmission completed.

If the implementation elects to send the Handshake character in the middle of an outgoing message

transmission, it must not insert the Handshake character immediately following a Data Escape character. The reason for this is to allow the remote console application some flexibility in whether it processes the Handshake character before or after removing data escaping.