Authors:
- Samer El-Haj-Mahmoud, Arm
- Christian Walter , 9elements
The demands placed on modern data center infrastructures continue to grow, and with them, the need for open, flexible, and future-proof server manageability. To address this challenge, Arm and 9elements Cyber Security have teamed up on a project that not only brings a prototype of OpenBMC to the Arm Neoverse Compute Subsystem (CSS), but also illustrates how modern communication protocols and industry standards are shaping next-generation server management.
Baseboard Management Controllers (BMCs) and the software interfaces they provide, such as Redfish and Intelligent Platform Management Interface (IPMI), are essential in the server management landscape. They enable features that are expected by datacenter and enterprise users, ranging from remote server monitoring and control to deployment, hardware lifecycle management, and fault management and troubleshooting. It is important for Arm based servers to establish a system architecture that ensures compatibility with off-the-shelf hardware and software components that rely on these technologies.
By embracing industry standards principles, the project is a proof-of-concept that demonstrates how OpenBMC on Arm Fixed Virtual Platform (FVP) can serve as a blueprint for modern Arm server platforms. It highlights the benefits of open-source firmware combined with Arm’s standard-driven approach—where each component, from the BMC layer to the manageability protocols, aligns with a common set of expectations. This, in turn, reduces complexity, improves interoperability, and paves the way for advanced features that can be easily integrated and scaled.
SBMR: Applying industry standards to management of Arm server
Central to Arm’s vision of manageable servers is the Arm Server Base Manageability Requirements (SBMR) specification. SBMR standardizes how BMCs expose essential management capabilities by forming a baseline of BMC interoperability between Arm Hosts (in-band) and datacenter infrastructure (out-of-band). This ensures that all Arm-based servers, including its firmware capabilities (such as monitoring system health, updating firmware, and reading sensor data), adhere to consistent, vendor-neutral manageability frameworks. SBMR builds on top of widely adopted management industry standards, such as:
SBMR adds Arm specific requirements and choices that are based on these industry standards. It also addresses considerations that are special to Arm servers, which are not fully covered in the industry standards.
In addition to the specification, Arm provides an open-source SBMR Architecture Compliance Suite, SBMR-ACS. This is an open-source test tool that uses the Robot automation framework, and targets IPMI and Redfish interfaces compliance testing according to the SBMR as well as the DMTF, OCP, and IPMI industry standards.
Understanding the PLDM and MCTP standards
(Source: https://www.dmtf.org/sites/default/files/standards/documents/DSP2015_2.2.0.pdf )
PLDM (Platform Level Data Model) and MCTP (Management Component Transport Protocol) are both industry-standard specifications published by DMTF. They form a key part of the modular, layered approach to out-of-band management.
PLDM
PLDM defines a standardized data model and message formats for representing platform management data. By abstracting low-level details, PLDM enables firmware components, host software, and management controllers to communicate seamlessly about system states, health metrics, and events. It is an effective interface & data model for efficient access to:
- Low-level platform inventory, BIOS, and config data
- Platform monitoring/control, alerting, event log, firmware update, etc.
- Redfish enablement for managed devices (RDE)
- Defines low level data representations and commands
- Provides transport independent Request/Response Model
- Supports a subtype to distinguish types of PLDM Messages
- Allows messages to be grouped based on the functions
- Allows the discovery of the functionality supported
MCTP
MCTP defines a transport-agnostic protocol that can run over various physical interfaces—such as SMBus/I2C, PCIe, I3C, USB, and Serial. It supports logical addressing based on Endpoint IDs and provides simple message fragmentation/reassembly with the built-in capability discovery. This flexibility allows MCTP to serve as a common transport layer for different management protocols, including PLDM. With MCTP as the underlying fabric, system components can talk to each other in a standardized way, regardless of the underlying hardware bus or topology.
Developing firmware ahead of hardware availability
As a first step, and as a proof-of-concept, Arm and 9elements ported OpenBMC—an open-source BMC firmware stack— to the Arm’s Base FVP. The Base FVP acts as an emulated environment that closely mirrors the behavior of a real Arm SoC, offering developers a stable, configurable platform to validate firmware features without relying on physical hardware. There are several virtual platform SKUs:
- Pure architectural reference cores (Base FVPs)
- Virtual production-like systems:
- Arm Neoverse cores
- System and Manageability Control subsystems
FVP closely models new Arm architectural features:
- Allows faster prototyping of features on top of an architected mechanism.
- Up-to-date interconnect IP modelling (CMN)
- GIC, SMMU
- Focuses on correctness of the emulated system and not on providing complete IO sub-systems
For further information about using Arm Base FVP, refer to: https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-docs/-/blob/master/docs/aemfvp-a/user-guide.rst
This leverages the Arm FVP models to showcase the modern communication protocol between the BMC and the Arm SoC processor. These protocols operate on the SBMR-defined SoC in-band and side-band interfaces by using virtual wire interfaces (virtual UART).
Our proof-of-concept prototype uses:
- The Base FVP to represent the BMC
- The Neoverse Infra Reference Design (RD) FVP to simulate the Manageability Control Processor (MCP) (in a physical server this is the sub-system that provides Arm SoC temperature, RAS events to the BMC)
- PLDM (Platform Level Data Model) over MCTP (Management Component Transport Protocol), transmitted over a side-band interface between the MCP and BMC. In the project, we use MCTP/PLDM over virtual UART. This is normally done over I2C or I3C or other interfaces on physical platforms
- Intelligent Platform Management Interface (IPMI) in-band communicates via virtual UART between the Application Processors (APs) and the BMC. This is normally done over SMBus/I2C on physical platforms
This setup enables:
- MCTP Endpoint Discovery
The mctpd daemon runs as a system service to manage MCTP endpoint discovery. It exposes a D-Bus interface for discovering new MCTP endpoints and notifies the pldmd daemon to perform PLDM terminus initialization. Additionally, it provides several functions for configuring remote endpoints.
- PLDM Terminus Initialization
The pldmd daemon will discover and initialize the PLDM terminus based on the D-Bus interface that mctpd exposed. It will assign a Terminus ID (TID) to the PLDM terminus and query PLDM terminus' capabilities. Once the PLDM terminus is identified, the pldmd daemon will parse the Platform Descriptor Records (PDR) for sensor data monitoring and expose the corresponding D-Bus object for temperature sensor data.
- Sensor Reading and Event Message on Redfish
The sensor reading data monitored by the pldmd daemon will be exposed and accessible via the bmcweb service. And end-users can query and monitor this data through the Redfish API. In addition to sensor reading data, PLDM Event Messages, such as Common Platform Error Record (CPER) events, can be transferred from the MCP to the BMC. These PLDM events will also be exposed and accessible via the Redfish API.
- IPMI In-band communication
The IPMI Serial interface protocol has been integrated into the ipmid daemon, allowing it to handle IPMI requests from the Host (in the pre-boot UEFI environment as well as the Operating System) and send responses back. During boot time, the Host can communicate with the BMC via IPMI in-band to query BMC information or send boot information, such as boot progress codes, to the BMC.
Getting started
All the source code of this proof-of-concept has been up-streamed and merged into the OpenBMC master branch. Please refer to the ‘Readme’ here to try it out: https://github.com/openbmc/openbmc/tree/master/meta-evb/meta-evb-arm/meta-evb-fvp-base
