OpenBMC 发展现状与基础介绍笔记

OpenBMC 发展现状与基础介绍笔记

OpenBMC 是一个开源且成熟的 BMC（基板管理控制器）代码库与解决方案，已被国内外多家互联网公司、服务器厂商、云计算运营商和 BMC 代码库 IP 厂商大力投入，并有望在下一代硬件平台（如英特尔 Birch Stream）上实现商用落地。

核心要点

OpenBMC 是什么

OpenBMC（Open Baseboard Management Controller）是一个开源的 BMC 代码库，提供了完整的 BMC 解决方案。它由 Linux Foundation 维护，代码托管在 GitHub 上，社区中包括 Facebook、英特尔、IBM、Google、浪潮、联想等多家厂商的贡献。

为什么重要

传统 BMC 方案（如 AMI 等厂商的闭源方案）正在逐步被开源方案替代。OpenBMC 的优势在于其开放性和社区驱动的持续迭代，使厂商可以在其基础上进行二次开发，适配自有硬件平台。

行业现状与应用前景

• 国内外许多互联网公司、服务器厂商、云计算（云服务器）运营商以及提供 BMC 代码库的 IP 厂商都在向 OpenBMC 大力投入。
• 部分厂商已初步具备产品化的 OpenBMC 能力，预计在下一代平台上（例如英特尔 Birch Stream 潮流平台）会实际使用或对外发布搭载 OpenBMC 商用版本的商用机器。
• 在英特尔下一代 Birch Stream 平台中，主板上的 CPLD（或其他相关硬件组件）将被去除，原有功能将移入 BMC 中实现；英特尔已基于其 OpenBMC 分支开发了这部分功能。

社区参与情况

• OpenBMC 社区可从 GitHub 搜索 "openbmc" 找到。
• 社区中包含多个子模块/仓库，其中第一个是 Linux Foundation 版本的 OpenBMC 主工程（Yocto 构建的主工程）。
• 社区维护状况存在一定问题：很多厂商使用了社区代码，但没有回馈贡献。

主要贡献者（按提交数，2019年11月数据）：

最近一次统计（2022年12月）： 有更多厂商参与进来，包括 Google、SEL PUT、IBM、浪潮、英特尔、联想等。但很多厂商仍是把社区代码拿过来自行开发，并未向社区回馈。可写脚本将这些贡献导出并统计。

详细解析

OpenBMC 社区的主要模块

打开 GitHub 上的 OpenBMC 主工程（Linux Foundation 版本），可见以下模块：

• 主工程（Yocto 构建主工程） ：基于 Yocto 构建框架，是编译整个 OpenBMC 镜像的入口。
• 文档（docs） ：存放项目文档。
• First D-Bus Interfaces：定义 D-Bus 接口。
• SDBusPlus：对 C 语言的 sd-bus 接口进行了 C++ 封装，方便调用。
• D-Bus Sensors：用于监控 sensor 的模块。
• BMC Web：提供 Web Server 功能。
• Entity Manager：板级配置管理模块。
• D-Bus 相关的其他独立模块：各个模块相对独立，各自维护。
• DMTF 组织新定义的协议（如 PLDM） ：用于监控或升级部件的协议，实现基于 D-Bus。

编译环境搭建

支持的操作系统版本

• 推荐使用 Ubuntu 18、20 或 22 版本，这几个版本基本都可以编译通过。
• 官方文档中在 Yocto 相关位置有具体说明。

依赖包安装

在 Ubuntu 系统上需要安装所有指定的依赖包。编译环境搭建比较简单：将这些包全部装上，基本就能用了。

编译步骤（演示过程）

1. 获取主工程代码：从 GitHub 下载 openbmc 主工程。
2. 进入工程目录：源码目录下最初没有 build 目录，需要通过执行 setup 脚本生成。
3. 运行 `. setup`：作用是设置具体的机型（machine），该脚本最终会调用 openbmc-env 脚本，配置当前终端的大量环境变量。因此，每次编译 OpenBMC 项目时，都需要先执行 `. setup` 来配置当前终端的环境变量。
4. 选择机型：执行 . setup 后可以看到很多选项，例如：

• AS2600（厂商自行开发的芯片适配）
• ST260、ST2500（未来的 ST2700）
• 其他厂商开发的机型（如 IBM 主要使用的镜像）
• 初学者推荐选择一个功能较全的默认机型

1. 编译目标：通常编译目标为 openbmc-image，即编译出 OpenBMC 镜像。也可以指定其他编译目标，例如只编译内核、或编译上层应用的某个模块。
2. 执行编译：执行类似 bitbake obmc-image 的命令。

• 首次编译需要：从网上下载各个模块的源码。主工程基本不包含各模块的代码，每个模块的源码地址由主工程指定，在编译时通过 do_fetch 操作获取源码。
• 时间估计：网络不好时可能需要几天；网络较好时大约需要一个晚上。
• 常见问题：会有很多包 fetch 不到源码、下载失败、编译不通过的情况，这属于正常现象，只能多试几次。

1. 编译产物路径：编译成功后，镜像位于 tmp/deploy/images/ 目录下（按机型区分），可看到：

• 内核镜像
• BMC 镜像（软链接，指向实际二进制镜像，该镜像是用 ta 工具打包好的可烧录镜像）

1. 部署/升级：

• 一般通过 scp 将镜像传到 BMC 的某个路径下，然后 reboot BMC，使 BMC 通过该镜像刷新其 flash。
• 或者通过 Redfish 或 Web 页面接口上传镜像。
• BMC 会先做校验（非加密校验），校验通过后解包，然后升级内部包含的镜像（包括根文件系统、U-Boot 等）。

编译时间说明：由于首次编译需要获取大量源码和下载依赖，耗时相当长。网络状况不佳时可能需要数天。

通过 QEMU 虚拟机运行 OpenBMC

适用场景：自己在家开发，没有对应硬件机器时，可以使用 QEMU 工具运行 OpenBMC。

使用步骤

1. 获取预编译镜像：OpenBMC 社区有自己的 Jenkins 服务器，可以从该网站上获取最近编译好的 QEMU 虚拟机镜像。

• 网站上有 master 分支的构建结果，包含多种机型的预编译镜像（包括刚刚编译的那个 ROM 镜像，以及其他机型）。

1. 下载 BMC 镜像和 QEMU 虚拟机镜像：分别下载 BMC 镜像和对应的虚拟机镜像文件。
2. 启动虚拟机：用 QEMU 运行刚才下载的镜像，就可以看到 OpenBMC 的长相。
3. 登录：用户名 root，密码是 0penBMC（注意大小写，B 是大写）。

运行后的基本操作

• `busctl`：最常用的命令，因为 OpenBMC 各模块之间通过 D-Bus 交互，用 busctl 可以查看所有 D-Bus 服务。
• `systemctl`：OpenBMC 使用 systemd 管理服务，可以查看所有 service，通过名字猜测其功能，例如：
• 风扇控制（温度相关）
• 日志管理
• 网络管理
• D-Bus 工具
• 配置管理
• BMC 升级/版本管理
• 状态管理
• 时间同步
• 用户管理
• 每个 service 都有对应的 D-Bus 接口，基本都可以通过 busctl 查看。
• busctl 可以展示：
• Bus name（D-Bus 路径/对象）
• Interface（D-Bus 规范中标准的 interface）
• Method（方法）
• Property（属性，如布尔类型会显示出来）
• 可以登录 Web 页面查看 OpenBMC 的界面，界面还可以，但内容比较有限。
• 通过 QEMU 运行 OpenBMC 时，可以通过修改 QEMU 设备源码来增加调试功能，例如增加一个设备或增加一个 Windows Sensor。

Yocto 构建框架原理

OpenBMC 使用 Yocto 作为构建框架（通过 bitbake 命令驱动），官网地址在 Yocto 网站（yoctoproject.org）。

代码结构

• 主工程代码中有多个厂商目录：包括 ABBM、Facebook、Andes、ARM、Speed（以及惠普等），这些平台都可以用。
• `.bb` 文件：构建配方文件。OpenBMC 的模块大多以 .bb 文件的形式组织。
• `.bbappend` 文件：对当前模块进行修改的追加配方，可通过它在构建工具中配置指定修改内容，包括打补丁等。例如 IBM、Google、Facebook、Andes、OpenPOWER 等都有各自的 append 文件。

构建依赖链示例

以 obmc-image 编译目标为例，其执行过程：

1. 查看 obmc-image 的 .bb 文件，其中定义了 IMAGE_FEATURES 等变量。
2. IMAGE_FEATURES 引用的具体特性定义在 features 目录下，例如 obmc-bmc-web 特性对应的文件。
3. 该特性文件指向 packagegroup-obmc-apps-bmcweb，这是一个 packagegroup 配方。
4. packagegroup-obmc-apps-bmcweb 的 .bb 文件定义了 PACKAGES 变量和 RDEPENDS（运行时依赖）。
5. RDEPENDS 具体依赖两个配方：bmcweb 和另一个模块。
6. bmcweb 的 .bb 文件指定了源码获取地址（模块在 GitHub 上的仓库地址）、协议（git 或 http 等）。
7. 依赖关系中还包括 systemd 功能、Web 服务器 service、构建工具、其他模块等。

总结：OpenBMC 的所有特性基本上都是这样一步一步通过配方链配置下来的。

学习建议

• Yocto 构建框架学习曲线比较陡峭，需要慢慢学、每天学一点；经过一段时间学习后基本能掌握，不会有什么特别难的地方，但需要投入时间。
• 官网有大量文档，网上也有各种视频和资料可供学习。

代码架构与设计模式

进程间通信：D-Bus

• OpenBMC 主要使用 D-Bus 作为进程间通信接口，也可能用到其他机制（如 socket），但主要基于 D-Bus。
• D-Bus 只是一个协议/规范，规范文档在网上可以搜到，定义了：
• 类型签名（如 y 表示 BYTE、b 表示 BOOLEAN 等）
• 消息类型：共四种——
• signal（信号）
• method call（方法调用）
• method return（方法返回）
• error（错误）
• 标准接口命名通常以 org.freedesktop.DBus 开头。

D-Bus 调试工具：busctl

busctl 是 OpenBMC 中调试 D-Bus 的主要工具，功能强大：

• busctl + 指定 bus 名字/对象路径，可以查看方法、属性、接口等。
• busctl monitor 可以监控 D-Bus 当前的消息，支持指定过滤条件（match），例如监控特定消息类型（method call、method return、error、signal）、特定 service 等。
• 监控输出示例：可见到 signal 消息。

异步编程模型：Boost.Asio

• OpenBMC 大部分 C++ 模块采用 Boost.Asio（boost::asio）异步单线程模式。
• 与传统的 BMC 代码（如 AMI 等厂商）中使用 while(1) 或 for(;;) 轮询循环不同，OpenBMC 的模块通常不会出现 while(1) 或 for(;;)。
• 执行模式：
• 每个模块最终有一个 io.run()（L.run()）调用。
• 初始化时发起一个异步操作，由操作系统执行；操作完成后，指定的回调函数被放入一个任务队列。
• io.run() 的作用是依次执行任务队列中排队的任务。
• 轮询循环也是通过这种方式实现：发起一个异步任务（如读取温度 sensor），完成后再把下一个读温度的任务放回队列，形成永不结束的循环。
• Boost.Asio 当前版本（截至视频时）为 1.81，最新为 1.82 beta；OpenBMC 的模块和内核版本都跟得比较新。
• 内核版本：当前最新的 LTS（长期支持）版本为 5.15，OpenBMC 使用 5.15。
• 编译器版本：GCC 12.2。OpenBMC 的交叉编译工具链名称类似 arm-bmc-openbmc（arm-...-linux-gnueabi 等），编译器可能打了补丁，使用最新的 GCC 12.2。

硬件驱动框架：Linux 设备树 + Hardware Monitor

• OpenBMC 的硬件监控驱动基于 Linux 内核的 Hardware Monitor（hwmon） 驱动框架。
• 驱动框架本身是 Linux 内核自带的机制；驱动需要在设备树（device tree）中配置好，内核才能找到对应驱动。
• 上层应用通过设备节点（如 sysfs 文件）访问硬件。
• 使用方式：
• 读取转速/温度：cat 对应文件（如 fanX_input、tempX_input）。
• 控制风扇：write 到对应文件（如 PWM 控制文件）。
• 在虚拟机上运行时因为没有实际的硬件连接，可能读取不到正常数据；在真实板子上运行时会正常返回。
• 优点：简便，读写逻辑都封装在驱动中。
• 局限：不够灵活，因为所有设备都需要在设备树中提前配好。对于外插卡（如背板、RAID 卡等），一开始并不知道具体插什么型号，很难在设备树里提前配置，因此设备树 + hwmon 的方式在部分场景不太适用。也可用 UDEV 方式，但效果不太好。

构建工具

• OpenBMC 使用 Yocto（bitbake）作为主要构建系统。
• 其他模块可能使用 CMake 或 Make。
• 例如之前 IPMI 的 ipmid 相关模块使用 Make 构建，比较复杂；现在基本已迁移到 Meson 构建系统。社区最新的 host 模块也已改为 Meson 构建。
• Meson 构建工具也值得学习。

现有经验者需要补充的知识

对于已经熟悉其他 BMC 代码库（如 AMI 的代码）的人，学习 OpenBMC 需要补充的知识：

1. C++ 语言：需要先学习几周。
2. D-Bus：协议规范、调试工具。
3. Boost.Asio：异步编程模型。
4. Linux 设备树 + hwmon：驱动框架。
5. Yocto/bitbake 构建工具。
6. Meson 构建工具（如涉及相关模块）。

方法与步骤

编译 OpenBMC 镜像的完整步骤

1. 准备环境：安装 Ubuntu 18/20/22，安装所有依赖包。
2. 获取源码：从 GitHub 克隆 openbmc 主工程。
3. 配置终端环境：在工程根目录执行 . setup，选择目标机型。
4. 启动编译：执行 bitbake obmc-image（或指定其他编译目标）。
5. 等待编译完成：首次编译可能需要几小时到几天（取决于网络状况），失败需多试几次。
6. 获取镜像：从 tmp/deploy/images/<机型>/ 目录获取编译产物。
7. 部署：通过 Redfish/Web 页面上传镜像，或 scp 到 BMC 后 reboot。

使用 QEMU 快速体验 OpenBMC

1. 访问 OpenBMC 社区的 Jenkins 服务器。
2. 下载 master 分支预编译的 QEMU 镜像（BMC 镜像和虚拟机镜像）。
3. 用 QEMU 启动虚拟机镜像。
4. 登录（root / 0penBMC）。
5. 使用 busctl 查看 D-Bus 服务、systemctl 查看相关服务。

通过 busctl 查看模块信息的操作

• busctl：列出所有 D-Bus 服务。
• busctl <service>：查看指定服务的对象路径。
• busctl <service> <object>：查看接口、方法、属性。
• busctl monitor [match]：监控 D-Bus 消息，可指定消息类型和服务来源。

案例与数据

社区贡献统计案例

官方维基（Wiki）页面提供 "Release Project Metrics"（项目进展统计），可从 2019 年 11 月开始查看各厂商对 OpenBMC 社区的提交笔数。IBM 是提交最多的厂商，英特尔、浪潮等也有较多提交。2022 年 12 月的最新统计显示参与厂商更多，但仍有很多厂商未向社区回馈贡献。

编译时间示例

• 网络不好时可能需要数天。
• 网络较好时约需一个晚上。
• 已编译过的环境中再次编译会非常快（演示中立即完成）。

模块示例：IPMI 构建工具演进

• 之前 IPMI 相关的 ipmid 使用 Make 构建，很复杂。
• 目前社区（包括 host 模块）已迁移到 Meson 构建系统。

限制与待确认问题

• 社区维护：OpenBMC 社区存在大量厂商"只取不予"的情况，社区维护"有点不太好"，很多厂商未回馈贡献。
• QEMU 虚拟机限制：在虚拟机上运行时，传感器没有实际硬件支持，读取不到正常数据；实际板卡运行时会正常。
• 设备树灵活性限制：设备树 + hwmon 驱动框架不适合外插卡等需要灵活拓扑的场景。
• 首次编译：需要从网络获取大量源码，网络不好时可能耗费数天，且频繁出现源码下载失败需重试的情况。
• 学习的时长：从其他 BMC 代码库转到 OpenBMC 需要学习 C++、D-Bus、Boost.Asio、设备树、Yocto、Meson 等多个技能，每个都需要数周时间。

行动清单

• 在 GitHub 上搜索并浏览 openbmc 主工程及各个子模块。
• 查看 OpenBMC 社区 Wiki 中的项目进展数据。
• 搭建 Ubuntu 编译环境，安装全部依赖包。
• 执行 . setup 配置机型。
• 执行 bitbake obmc-image 编译镜像。
• 从 Jenkins 下载 QEMU 镜像快速体验。
• 学习 D-Bus 协议规范（包括类型签名、消息类型、标准接口命名）。
• 学习 busctl 工具的使用。
• 学习 Boost.Asio 异步编程模型。
• 学习 Linux 设备树和 hwmon 驱动框架。
• 学习 Yocto/bitbake 构建框架。
• 学习 Meson 构建工具。

总结

OpenBMC 是一个成熟的、开源的 BMC 解决方案，其核心特征包括：使用 D-Bus 进行进程间通信、使用 Boost.Asio 实现异步单线程编程、使用 Linux 设备树 + hwmon 驱动框架、使用 Yocto 构建系统、使用 systemd 管理系统服务。它已被业界广泛采用，但社区贡献回馈不足是明显问题。编译环境搭建相对简单，但首次全量编译耗时较长；QEMU 虚拟机提供了无硬件条件下的体验途径。学习 OpenBMC 需要掌握 C++、D-Bus、Boost.Asio、设备树、Yocto 等多方面知识，建议从简单模块开始循序渐进。

后续可能的深入方向包括：单独任务讲解（如新增一个设备具体怎么加）、适配实际机型涉及到的模块（如温度 sensor 涉及 Entity Manager、内核设备树、D-Bus Sensors、FRU 配置、SEL 生成等）、各模块源码解析（如 Entity Manager 分为 entity-manager 和 device 两个 service，其中 device 较简单，entity-manager 较复杂，包含各种异步调用；dbus-sensors 是传感器监控进程）。