Emerson ATCA-9305 User Manual
System Management:
Message Bridging
7-8
The following example illustrates how the Send/Get Message and Get Address Info com-
mands can be used by the payload software to get the physical location of the board in the
shelf:
mands can be used by the payload software to get the physical location of the board in the
shelf:
1
The payload software sends the Get Address Info command to the BMR-H8S-AMCc,
requesting address information for FRU device 0. Using the SIPL protocol:
requesting address information for FRU device 0. Using the SIPL protocol:
[B0 xx 01 00]
2
The BMR-H8S-AMCc returns its IPMB address in the Get Address Info reply. In this example,
72
72
16
is the IPMB-0 address of the IPMC.
{B4 00 01 00 00 FF 72 FF 00 01 07]
3
The payload software composes a Get Address Info command requesting the responder to
provide its addressing information for FRU device 0. The request is composed in the IPMB
format. The responder address is set to 20
provide its addressing information for FRU device 0. The request is composed in the IPMB
format. The responder address is set to 20
16
(for the shelf manager). The requester address
is set to the value obtained in the previous step.
{20 B0 30 72 00 01 00 8D]
4
The payload software forwards the command composed in the previous step to the shelf
manager using the Send Message command. The Send/Get Message in SIPL format is:
manager using the Send Message command. The Send/Get Message in SIPL format is:
[18 xx 34 40 20 B0 30 72 00 01 00 8D]
5
The BMR-H8S-AMCc firmware sends the Get Address Info request to the shelf manager,
waits for a reply to this request, and sends this reply to the payload software in the Send/Get
Message response.
waits for a reply to this request, and sends this reply to the payload software in the Send/Get
Message response.
[1C 00 34 00 72 B4 DA 20 00 01 00 00 41 82 FF 00 FF 00 1E]
6
The payload software extracts the Get Address info reply from the Send/Get Message
response and retrieves the physical address of the board from it.
response and retrieves the physical address of the board from it.
The second message bridging implementation, bridging via LUN 10, allows the payload to
receive responses to requests sent to IPMB-0 via the Send Message command with request
tracking disabled, as well as receive requests from IPMB-0. To provide this functionality, the
ATCA-9305 IPMC places all messages coming to LUN 10 from IPMB-0 in a dedicated Receive
Message Queue, and those messages are processed by the payload instead of the IPMC
firmware. To read messages from the Receive Message Queue, the payload software uses
the standard Get Message command. The payload software is notified about messages
coming to LUN 10 via the Get Status command of the SIPL protocol and the payload notifi-
cation mechanism, or, if the LPC/KCS-based Payload Interface is used, using the KCS inter-
rupt. The Receive Message Queue of the ATCA-9305 IPMC is limited to 128 bytes, which is
sufficient for storing at least three IPMB messages, but may be not enough for a larger num-
ber of messages. Taking this into account, the payload software must read messages from
the queue as fast as possible, caching them on the on-carrier payload side for further han-
receive responses to requests sent to IPMB-0 via the Send Message command with request
tracking disabled, as well as receive requests from IPMB-0. To provide this functionality, the
ATCA-9305 IPMC places all messages coming to LUN 10 from IPMB-0 in a dedicated Receive
Message Queue, and those messages are processed by the payload instead of the IPMC
firmware. To read messages from the Receive Message Queue, the payload software uses
the standard Get Message command. The payload software is notified about messages
coming to LUN 10 via the Get Status command of the SIPL protocol and the payload notifi-
cation mechanism, or, if the LPC/KCS-based Payload Interface is used, using the KCS inter-
rupt. The Receive Message Queue of the ATCA-9305 IPMC is limited to 128 bytes, which is
sufficient for storing at least three IPMB messages, but may be not enough for a larger num-
ber of messages. Taking this into account, the payload software must read messages from
the queue as fast as possible, caching them on the on-carrier payload side for further han-