MCP sideband channel

Important

This feature might not be applicable to all Platforms. Please check individual Platform pages, section Supported Features to confirm if this feature is listed as supported.

Overview

Server systems generally hosts a myriad of IPs/controllers within a single system. For Neoverse Reference Design platforms, this could range from SCP (system control processor), AP (application processor), MCP (manageability control processor) etc. In production environments, an additional board management controller would also be added to the system which would help system adminstrators to monitor the live status of the system remotely. In such environments, communication between these controllers and especially between the BMC and other components is of utmost importance. The system administrator can rely on the status of the system from the BMC only if such a reliable communication enables these controllers to talk to the BMC. MCP sideband channel feature aims at show-casing one such means of communication using PLDM<->MCTP protocol stack.

SBMR specification recommends certain guidelines in using these stacks to implement the MCP sideband channel. Care has been taken to align to the specification in areas where it was feasible to do so. However, please note that Neoverse Reference Design platforms doesn’t support a BMC and therefore all the communication as of now is implemented via a loopback on MCP itself. MCP has been chosen as the controller for showcasing the feature as one of its core responsibilities is to to communicate and share information with the BMC. If the system supports sensors and effecters with little or no-intelligence to it, the MCP can read and write data from them and transfer them over to the BMC.

What does MCP sideband channel showcase?

MCP sideband channel show-cases packet transactions over a PLDM<->MCTP stack based system implemented on MCP. Packets are sent and received on MCP over a loopback interface which mimics the physical layer.

Firmware on MCP has been segregated to implement a MCP terminal and a BMC terminal. The feature show-cases BMC as the primary terminal trying to discover information about the secondary terminal, MCP. PLDM discovery, as quoted in the PLDM specification has been implemented in firmware. BMC terminal uses PLDM discovery to send out request packets to figure out the terminal ID, PLDM types, PLDM commands and the version for these commmands. MCP also holds a dummy PDR record. A PDR record could be thought of as a block of semantic information required to understand how sensor/effecter data on a particular terminal could be parsed at a node remote to the one that forms it. In our example, if we assume the MCP terminal to be connected to a sensor, it is essential for the BMC terminal to understand how to read/parse the sensor data. MCP terminal is required to form PDR records and transfer it to the BMC terminal on request to aid in this scenario. The dummy PDR held by the MCP terminal is retrieved as part of PLDM discovery.

For more information on the design of firmware, refer to MCP sideband channel design

Building and running MCP sideband channel

Note

This section assumes the user has completed the chapter Getting Started and has a functional working environment.

Follow the instructions as given in Busybox Boot to boot linux busybox on the platform.

The feature is setup in such a way that the BMC firmware automatically starts off with PLDM discovery to identify and retrieve information from MCP terminal. On MCP controller’s uart terminal, you should be able to see the logs starting with the following prints.

[    0.000000] [MCP]: mcp context:
[    0.000000] [PLDM_FW]:
[    0.000000] [PLDM_FW]: pldm tid:                       0
[    0.000000] [PLDM_FW]: pldm type count:                2
[    0.000000] [PLDM_FW]: global enable:                  0
[    0.000000] [PLDM_FW]: receiver addr:                  0
[    0.000000] [PLDM_FW]: heartbeat timer:                0
[    0.000000] [PLDM_FW]: transport protocol type:        0

Decoding output logs

The output logs can be decoded as follows.

The first part of the logs point to the PLDM terminal information for MCP terminal within the segregated firmware. This represents the PLDM TID and different sets of PLDM features supported on the MCP terminal. At this point, the BMC terminal is yet to discover this information.

[    0.000000] [MCP]: mcp context:
[    0.000000] [PLDM_FW]:
[    0.000000] [PLDM_FW]: pldm tid:                       0
[    0.000000] [PLDM_FW]: pldm type count:                2
[    0.000000] [PLDM_FW]: global enable:                  0
[    0.000000] [PLDM_FW]: receiver addr:                  0
[    0.000000] [PLDM_FW]: heartbeat timer:                0
[    0.000000] [PLDM_FW]: transport protocol type:        0
[    0.000000] [PLDM_FW]: pldm type:                      0
[    0.000000] [PLDM_FW]: version count:                  1
[    0.000000] [PLDM_FW]: version[0] :           f1.f0.f0.0
[    0.000000] [PLDM_FW]: commands count:                 4
[    0.000000] [PLDM_FW]: command[0]:                     2
[    0.000000] [PLDM_FW]: command[1]:                     3
[    0.000000] [PLDM_FW]: command[2]:                     4
[    0.000000] [PLDM_FW]: command[3]:                     5
[    0.000000] [PLDM_FW]: pldm type:                      2
[    0.000000] [PLDM_FW]: version count:                  1
[    0.000000] [PLDM_FW]: version[0] :           f1.f2.f0.0
[    0.000000] [PLDM_FW]: commands count:                 3
[    0.000000] [PLDM_FW]: command[0]:                    49
[    0.000000] [PLDM_FW]: command[1]:                    57
[    0.000182] [PLDM_FW]: command[2]:                    81

This is followed by the BMC terminal initiating the actual PLDM discovery.

[    0.000282] [BMC]: pldm discovery start ...

What follows is a set of PLDM<->MCTP based requests and responses to tranfer MCP terminal’s PLDM terminal information. Each command transaction involves 2 cycles of PLDM<->MCTP stack walk. This is better explained in the MCP sideband channel design section. For brevity, a small snippet of the trasaction has been pasted below.

• A request being sent

[    0.000482] [MCTP]: sending pkt, len 8
[    0.000607] [LOOPBACK]: sending packet onto loopback bus
[    0.000982] [LOOPBACK]: receiving packet from loopback bus

• Corresponding response  being sent

[    0.001082] [MCTP]: sending pkt, len 9
[    0.001214] [LOOPBACK]: sending packet onto loopback bus
[    0.001388] [LOOPBACK]: receiving packet from loopback bus

• Similar cycle for other PLDM commands

[    0.001482] [MCTP]: sending pkt, len 12
[    0.001682] [LOOPBACK]: sending packet onto loopback bus
[    0.001822] [LOOPBACK]: receiving packet from loopback bus
[    0.001982] [MCTP]: sending pkt, len 7
[    0.002082] [LOOPBACK]: sending packet onto loopback bus
[    0.002182] [LOOPBACK]: receiving packet from loopback bus

[    0.002382] [MCTP]: sending pkt, len 17
[    0.002482] [LOOPBACK]: sending packet onto loopback bus
[    0.002582] [LOOPBACK]: receiving packet from loopback bus
[    0.002782] [MCTP]: sending pkt, len 44
[    0.002882] [LOOPBACK]: sending packet onto loopback bus
[    0.003037] [LOOPBACK]: receiving packet from loopback bus

Once all transactions are done, the discovery completes gracefully.

[    0.007282] [PLDM_FW]: pldm discovery complete

Finally, BMC terminal prints all the data it received from MCP terminal. This has to match with the prints put out by MCP terminal before the transactions started.

[    0.007482] [PLDM_FW]:
[    0.007549] [PLDM_FW]: pldm tid:                       0
[    0.007682] [PLDM_FW]: pldm type count:                2
[    0.007782] [PLDM_FW]: global enable:                  2
[    0.007982] [PLDM_FW]: receiver addr:                  8
[    0.008082] [PLDM_FW]: heartbeat timer:                0
[    0.008282] [PLDM_FW]: transport protocol type:        0
[    0.008382] [PLDM_FW]: pldm type:                      0
[    0.008503] [PLDM_FW]: version count:                  1
[    0.008682] [PLDM_FW]: version[0] :           f1.f0.f0.0
[    0.008850] [PLDM_FW]: commands count:                 4
[    0.008982] [PLDM_FW]: command[0]:                     2
[    0.009082] [PLDM_FW]: command[1]:                     3
[    0.009284] [PLDM_FW]: command[2]:                     4
[    0.009382] [PLDM_FW]: command[3]:                     5
[    0.009482] [PLDM_FW]: pldm type:                      2
[    0.009718] [PLDM_FW]: version count:                  1
[    0.009805] [PLDM_FW]: version[0] :           f1.f2.f0.0
[    0.009982] [PLDM_FW]: commands count:                 3
[    0.010152] [PLDM_FW]: command[0]:                    49
[    0.010282] [PLDM_FW]: command[1]:                    57
[    0.010412] [PLDM_FW]: command[2]:                    81

The fields global enable, receiver addr, heartbeat timer and transport protocol type could hold different values on BMC terminal when compared to MCP terminal. receiver addr corresponds to the address of BMC terminal and rest of fields corresponds to configurations that enable events that BMC terminal is interested in. This data is send to the MCP terminal from the BMC terminal along the discovery process to let the MCP terminal know what all events it is interested in receiving notification from and the address to which those events needs to be forwarded. At the time when MCP context is printed, these fields are not yet set.

In addition to the PLDM information that BMC terminal has received, a PDR record has also been received (rather retrieved) by the BMC terminal. This is the last set of data to appear in the logs. The PDR record is printed as raw bytes here.

[    0.010582] [PLDM_FW]: pdr [0]:
[    0.010682] [PLDM_FW]:                                1
[    0.010782] [PLDM_FW]:                                0
[    0.010882] [PLDM_FW]:                                0
[    0.011082] [PLDM_FW]:                                0
[    0.011193] [PLDM_FW]:                                2
[    0.011382] [PLDM_FW]:                                3
[    0.011540] [PLDM_FW]:                                4
[    0.011682] [PLDM_FW]:                                0
[    0.011800] [PLDM_FW]:                                5
[    0.011982] [PLDM_FW]:                                0
[    0.012082] [PLDM_FW]:                                6
[    0.012182] [PLDM_FW]:                                0
[    0.012408] [PLDM_FW]:                                7
[    0.012494] [PLDM_FW]:                                0
[    0.012682] [PLDM_FW]:                                8
[    0.012842] [PLDM_FW]:                                0
[    0.012982] [PLDM_FW]:                                9
[    0.013082] [PLDM_FW]:                                0
[    0.013282] [PLDM_FW]:                               10
[    0.013382] [PLDM_FW]:                                0
[    0.013482] [PLDM_FW]:                               11
[    0.013709] [PLDM_FW]:                               12
[    0.013782] [PLDM_FW]:                               13
[    0.013982] [PLDM_FW]:                               14

MCP sideband channel design

PLDM<->MCTP transactions are in a way analogous to TCP/IP transaction for any application protocol. Take the example of an FTP server running over TCP/IP. FTP, the application layer deals with transferring chunks of file data as packets. Further, we have TCP as the transport layer underneath which deals with fragmentation, re-ordering, acknowledgment of receipt etc to make sure the transport went through well. Similarly PLDM acts as the application layer. PLDM specification dictates what data to transferred in each packet. MCTP is the transport layer. Like TCP, it deals with fragmentation and re-ordering.

Following PLDM commands have been used in the in the feature.

PLDM Command	PLDM Type	Code Value
GetTID	PLDM BASE	0x02
GetPLDMVersion	PLDM BASE	0x03
GetPLDMTypes	PLDM BASE	0x04
GetPLDMCommands	PLDM BASE	0x05
SetEventReceiver	PLDM PLATFORM	0x04
GetPDR	PLDM PLATFORM	0x51

PLDM specification defines the request and response formats for each of these commands. To better understand the transactions, GetTID could be taken as an example. BMC terminal forms the GetTID PLDM packet and transfers it to MCTP layer. MCTP forwards the command to the loopback interface which sends the packet to itself. Loopback receiver then forwards the packet to MCTP which forwards it to the MCP terminal. This could be thought as the first cycle or the request cycle.

MCP terminal decodes the packet, forms the response and sends it back to MCTP. The packet essentially traverses one more cycle until it finally reaches BMC terminal. This could be thought of as the second cycle or the response cycle. For multip-part transactions, the number of cycles to complete one command transfer may not be limited to two cycles.

MCP sideband channel software makes use of the following specifications.

• PLDM Base specification

• PLDM Platform specification

• PLDM Codes

• PLDM over MCTP Binding

• MCTP specification

Following thrid party libraries also have been used.

• libpldm

• libmctp