Article
OpenBMC overview
OpenBMC components and layersOverview
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:
- U-boot
- Linux Kernel
- Services managed by systemd
Systemd
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 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:
obmc-chassis-poweron@0.targetto power on the chassisphosphor-watchdog@poweron.serviceto monitor the power on progressstart_host@0.serviceto 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 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 |
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, an 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:
- Defined in
meta-phosphorthat specifies the Linux kernel's URI and revision - Has a bbappend in
meta-ast2500that added the defconfig for the AST2500 chip - Has a bbappend in
meta-romulusthat 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.