OpenBMC overview – IBM Developer

Build cloud-native applications for regulated workloads with IBM Cloud for Financial Services Learn more

OpenBMC overview


OpenBMC is a free open source software management Linux® distribution that is designed for the embedded environment. In this article, we provide an overview of OpenBMC and its components.

Based on Yocto, it consists of the following components:


All the services are managed by systemd in OpenBMC.

For example:

If you want to power on the host, you can run the following commands either in the BMC shell or from remote through REST API:

systemctl start
curl -c cjar -b cjar -k -H "Content-Type: application/json" -d '{"data": "xyz.openbmc_project.State.Host.Transition.On"}' -X PUT https://${bmc}/xyz/openbmc_project/state/host0/attr/RequestedHostTransition

Both do the same thing eventually, that is to start the, which depends on the following services/targets:

systemctl list-dependencies --no-pager
● ├─mapper-wait@-org-openbmc-control-chassis0.service
● ├─obmc-enable-host-watchdog@0.service
● ├─op-occ-enable@0.service
● ├─pcie-slot-detect@0.service
● ├─phosphor-gpio-monitor@checkstop.service
● ├─phosphor-watchdog@poweron.service
● ├─start_host@0.service
● ├─
● │ ├─avsbus-disable@0.service
● │ ├─avsbus-enable@0.service
● │ ├─avsbus-workaround@0.service
● │ ├─cfam_override@0.service
● │ ├─fsi-bind@0.service
● │ ├─fsi-scan@0.service
● │ ├─...
● │ └─
● │   ├─mboxd.service
● │   ├─obmc-console@ttyVUART0.service

Systemd starts all the dependent services or targets, such as:

  • to power on the chassis
  • phosphor-watchdog@poweron.service to monitor the power on progress
  • start_host@0.service to start the host system

The host system starts after all the dependent services start.


Let us walk through the code and get an overview of the components.

Important notes:

  • The following code structure reflects to OpenBMC tag v2.3.
  • Starting from 194ff4f, the meta-machines are moved to top level, maintained in separated repositories, and managed by a subtree. Though the following code structure is older, it reflects the entire picture of the components in OpenBMC.

The major parts:

Dir What it is
import-layers The imported component from yocto and meta-openembedded
meta-openbmc-bsp The bsp related components, mainly for aspeed, for example, uboot/kernel configs
meta-phosphor Contains all the components of OpenBMC, for example, uboot/kernel, and phosphor-xxx services
meta-openbmc-machines Machine-specific configurations
meta-openbmc-machines/meta-openpower/common Components specific to OpenPOWER

phosphor services

Most OpenBMC services are in meta-phosphor/common/recipes-phosphor/.

Dir What it is
chassis Chassis control, for example, power on, off, and reset button
console The console server/client for VUART
datetime The time manager
dbus Dbus related services, for example, mapper, and dbus interfaces
dump The debug collector, for example, handler of checkstop
fans The fan presence, monitor, and controller
flash The manager of BMC and host flash, for example, software manager
gpio The GPIO monitor, for example, monitor checkstop, or button press
host The services to control host, for example, start host
images The build images, for example, obmc-phosphor-image, initramfs, and debug tarball
interfaces The rest server for dbug interfaces
inventory The inventory manager
ipmi IPMI related services, for example, host ipmid, net ipmid, and configurations of IPMI sensors
leds The LED manager
logging The log manager, including ffdc
mboxd The mboxd service, implementing the mailbox protocol
mrw MRW related tools, for example, the tool to parse MRW and generate YAML configurations
network The network manager
packagegroups Define which packages are included
sensors The hwmon service that maps hwmon sysfs to dbus
settings The settings manager
state The state manager to handle BMC, Host, and Chassis states
users The user manager
watchdog The watchdog service
webui The reference WebUI for OpenBMC


OpenBMC is based on Yocto, and the build has the concept of layers, where each component is overrided or appended by the upper layer.

For example, an output similar to the following is displayed while building Romulus:

Build Configuration:

Let us take the Linux kernel as an example. The Linux kernel recipe in OpenBMC is linux-obmc, and we can find it in the following layers:

  • meta-phosphor/common/recipes-kernel/linux/
  • meta-openbmc-bsp/meta-aspeed/meta-ast2500/recipes-kernel/linux/
  • meta-openbmc-machines/meta-openpower/meta-ibm/meta-romulus/recipes-kernel/linux/

Thus, linux-obmc is defined as follows:

  • Defined in meta-phosphor that specifies the Linux kernel’s URI and revision
  • Has a bbappend in meta-ast2500 that added the defconfig for the AST2500 chip
  • Has a bbappend in meta-romulus that added the extra kernel configurations specific to Romulus

Putting the above together, linux-obmc is built with the specified source URI, revision, and configurations.

It is similar for any other component for how it is defined and configured.