In this blog, we provide an overview of OpenBMC and its components piece by piece.

Overview

OpenBMC is a free open source software management Linux distribution that is designed for the embedded environment.

Based on Yocto, it consists of the following components:

Systemd

All the services are managed by systemd in OpenBMC. For details, see openbmc-systemd.md.

For example:

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


systemctl start obmc-host-start@0.target
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 obmc-host-start@0.target, which depends on the following services/targets:

systemctl list-dependencies obmc-host-start@0.target --no-pager
obmc-host-start@0.target
● ├─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
● ├─obmc-chassis-poweron@0.target
● │ ├─avsbus-disable@0.service
● │ ├─avsbus-enable@0.service
● │ ├─avsbus-workaround@0.service
● │ ├─cfam_override@0.service
● │ ├─fsi-bind@0.service
● │ ├─fsi-scan@0.service
● │ ├─...
● │ └─obmc-standby.target
● │   ├─mboxd.service
● │   ├─obmc-console@ttyVUART0.service
...

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

  • obmc-chassis-poweron@0.target 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.

Components

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 configs
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, Chassis states
users The user manager
watchdog The watchdog service
webui The reference WebUI for OpenBMC

Layers

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, output similar to the following is displayed while building Romulus:


Build Configuration:
...
meta
meta-poky
meta-oe
meta-networking
meta-perl
meta-python
meta-virtualization
meta-phosphor
meta-aspeed
meta-ast2500
meta-openpower
meta-ibm
meta-romulus

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:

  • Firstly 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.

Join The Discussion

Your email address will not be published. Required fields are marked *