Standardizing the Management Controller: RunBMC Comes to OCP
Cloud-scale operators have long known that open source delivers more than shared code—it delivers shared engineering effort. The same logic is now being applied to hardware. Dropbox and Salesforce have contributed version 1.0 of the RunBMC hardware specification to the Open Compute Project (OCP), a community-driven effort to define common interfaces for the baseboard management controllers (BMCs) that sit inside virtually every server.
BMCs are the dedicated processors responsible for out-of-band system management. They handle telemetry such as temperature, voltage, and current readings, and administrators reach them through the Intelligent Platform Management Interface (IPMI) over a network path separate from the host CPU and operating system. That isolation is a security strength, but the software stack itself has historically been closed, buggy, and bloated.
From Proprietary Black Box to Open Standard
The push to fix this began at Facebook in 2014, when engineers designing a new data center switch decided that patching the existing BMC software was not enough. They rebuilt the stack from scratch on top of vendor baseboard development packages, producing OpenBMC, an open source framework now supported by IBM, Intel, Google, Microsoft, and Facebook. OpenBMC addressed the software layer, but the underlying hardware remained inconsistent across platforms.
Dropbox and Salesforce saw an opportunity to extend the same collaborative approach to the silicon. After studying schematics, layouts, and system designs across many OCP platforms, they found that BMC topologies look similar at a high level but diverge significantly in the details. Those variations—in interrupts, serial buses, inputs, and outputs—cascade into the software stack, which must account for every platform-specific quirk.
By defining a common hardware interface, the RunBMC spec aims to make BMC subsystems interchangeable. Standardizing the interface reduces software complexity because design teams no longer need to code around a different hardware layout for each server model.
The Specification in Practice
RunBMC covers most of what a platform needs from its BMC. The specification standardizes all input/output connectivity between the BMC and the host platform, which the designers estimate covers 95–99 percent of typical BMC requirements.
The physical form factor is a 260-pin DDR SO-DIMM connector, with some relaxed dimensions. It fits vertically in 1RU and 2RU servers, and right-angle connector variants provide flexibility in placement.
The interface spec includes a full set of standard connections: RGMII and RMII for Ethernet, LPC and eSPI for host communication, PCI Express, USB, plus serial interfaces, GPIOs, ADCs, PWMs, and TACHs.
| Function | Signal Count for Interface | Number of Interfaces | Number of used pins |
|---|---|---|---|
| Form Factor - 260 SO-DIMM4 | |||
| Power 3.3V | 5 | ||
| VDD_RGMII_REF | 1 | ||
| LPC 3.3v or ESPI 1.8v | 1 | ||
| Power 12 V | 1 | ||
| Ground | 38 | ||
| ADC | 1 | 8 | 8 |
| GPI/ADC | 1 | 8 | 8 |
| PCIe | 7 | 1 | 7 |
| RGMII/1GT PHY | 14 | 1 | 14 |
| VGA / GPIOs | 7 | 1 | 7 |
| RMII/NC-SI | 10 | 1 | 10 |
| Master JTAG/GPIO | 6 | 1 | 6 |
| USB host | 4 | 1 | 4 |
| USB device | 3 | 1 | 3 |
| SPI1: SPI for host - quad capable | 7 | 1 | 7 |
| SPI2: SPI for host | 5 | 1 | 5 |
| FWSPI: SPI for Boot - quad capable | 7 | 1 | 7 |
| SYSSPI: System SPI | 4 | 1 | 4 |
| LPC/eSPI | 8 | 1 | 8 |
| I2C / GPIOs | 2 | 12 | 24 |
| GPIOs / I2C | 2 | 3 | 6 |
| I2C | 2 | 1 | 2 |
| UARTs (TxD, RxD) | 2 | 4 | 8 |
| CONSOLE (Tx, Rx) | 2 | 1 | 2 |
| GPIO / Pass-Through | 2 | 2 | 4 |
| PWM | 1 | 8 | 8 |
| Tacho/GPIOs | 1 | 16 | 16 |
| PECI | 2 | 1 | 2 |
| GPIOs | 1 | 33 | 33 |
| GPIO/GPIO Expanders (Serial GPIO) | 4 | 1 | 4 |
| Reset and Power Good | 1 | 3 | 3 |
| Watchdogs/GPIO | 1 | 2 | 2 |
| BOOT_IND# / GPIO | 1 | 1 | 1 |
| RESERVED/KLUDGE | 1 | 1 | 1 |
Why Modularity Matters
Security
Modern data centers contain a proliferation of server SKUs, each with its own BMC implementation. That variety makes it difficult to secure the management subsystem against attacks such as man-in-the-middle interception. A standardized, modular BMC that evolves on a slower cadence than compute platforms gives designers a stable base to harden. Security features like Titan, Cerberus, or TPM chips that monitor traffic between the I/O and the baseboard can be added directly to the BMC module.
Supply Chain
A modular spec also changes how operators source hardware. Rather than accepting whatever BMC ships with a given server, a cloud provider could select from a small number of validated BMC modules and order them at scale. Early adopters of open hardware standards create economies of scale that benefit later adopters, including smaller operators who may not be first in line for production deployment.
Faster Industry Adoption
The concept has already gained traction. An initial prototype with a very high-density, fine-pitch connector drew strong interest at the 2018 OCP Summit, and feedback from that audience shaped the final specification. By the 2019 OCP Global Summit, multiple vendors were showing next-generation servers with RunBMC support. That quick uptake demonstrates how an open hardware spec can let a relatively small player influence designs from much larger industry vendors.
With the specification now published, the expectation is that community-contributed RunBMC reference boards will follow. The goal is straightforward: bring the same security, efficiency, and cost benefits that open source software brought to cloud infrastructure, extended to the hardware that manages it.
