openUBMC 中 BMC 与 BIOS 启动顺序的管理机制

在 openUBMC 系统中，BMC（Baseboard Management Controller） 与 BIOS（Basic Input/Output System） 的启动顺序管理是确保系统稳定启动、设备对象正确初始化以及数据可靠上报的关键环节。尤其是在使用电源键启动等场景下，若 BIOS 启动早于 BMC 服务准备就绪，可能导致 BIOS 上报的版本、配置或硬件信息无法被 BMC 正确接收和处理，从而引发资源缺失、日志报错或功能异常。

openUBMC 通过一系列机制来协调和保障 BMC 与 BIOS 的启动顺序，避免因并行启动导致的问题。

一、BMC 启动流程：确保核心服务优先就绪

openUBMC 采用 Systemd + Skynet 的架构实现服务的并行拉起与依赖管理，其启动流程设计如下：

1. Systemd 并行启动服务

   • 使用 Systemd 实现多服务并发启动，提升整体启动速度。
   • 通过定义服务间的依赖关系（如 After=、Requires=），确保关键服务（如 ipmi_core、dbus、bios 组件）在特定顺序下启动。

2. Skynet 框架内子服务协作

   • 单个服务内部使用 Skynet（C+Lua 实现的轻量级服务器框架） 拉起子模块。
   • 例如，bios 组件作为独立服务由 Systemd 启动，在 Skynet 中进一步初始化配置接口、证书管理、启动项设置等功能。

3. 资源对象注册机制

   • openUBMC 将硬件资源抽象为“资源对象”，并通过 资源协作接口 注册到系统中。
   • bios 组件必须在 BMC 启动阶段完成注册（路径如 bmc.kepler.bios），否则其他模块无法识别其存在。

示例：组件未注册导致的错误日志

当 BMC 重启后 bios 服务未及时拉起时，可能出现以下日志：

[bios]StartupCheck failed, error: org.freedesktop.DBus.Error.ServiceUnknown: The name bmc.kepler.bios was not provided by any .service files

这表明 BIOS 上报信息时，BMC 的 bios 服务尚未注册，无法处理请求。

二、BIOS 启动等待机制：防止信息丢失

为避免 BIOS 在 BMC 服务未准备好时提前启动并发送数据，openUBMC 设计了明确的 BIOS 启动等待机制 和 超时控制策略。

1. 明确的超时时间：5分钟等待 BIOS 启动完成

根据文档《openUBMC 支持CPLD无感升级特性设计说明书》中的描述：

• 刷新 Flash 后，需要 等待 BIOS 启动完成，超时时间为 5 分钟。
• BIOS 启动完成或超时后，系统才进入下一阶段（如逻辑数据持久化、消费模块协同等）。

此机制确保：

• BMC 有足够的窗口期准备接收 BIOS 发送的信息（如 IPMI 命令、版本上报等）。
• 即使 BIOS 启动较快，也不会因无人接收而导致数据丢失。

2. BIOS 上报行为依赖 BT 通道状态

BIOS 通过 BT over IPMI（Block Transfer）通道向 BMC 发送关键信息（如 ReportBiosVersionToBmc.efi 模块上报 BIOS 版本）。

然而，若 BT 通道中断或未初始化成功，可能出现：

bt ctrl: 0x0 —— BIOS 发送数据后未收到响应

这通常由 CPLD 逻辑异常或 BMC 未准备好 BT 控制寄存器引起。

解决方法：

• 检查 CPLD 逻辑 是否支持 BT 中断正常触发。
• 确保 BMC 在 BIOS 启动前完成 BT 通道初始化。

三、应对“并行启动”场景：电源键启动的风险与规避

问题场景：电源键触发导致 BIOS 先于 BMC 启动

用户反馈：使用电源键启动时，BIOS 和 BMC 可能并行启动，导致 BIOS 上报数据时 BMC 的 bios 服务尚未注册，造成：

• 信息丢失
• 日志中出现 ServiceUnknown 错误
• PCIe 设备、内存等信息上报失败

解决方案与设计原则

1. 依赖检查与重试机制

• BMC 侧组件（如 maca）在启动时会对依赖服务（如 bmc.kepler.bios）进行 启动检查（StartupCheck）。
• 若发现服务未就绪，会 自动重试拉起或等待，直至服务可用或达到最大尝试次数。

2. 日志与可观测性支持

• 升级或启动过程中记录 BIOS 启动状态到日志，便于事后分析。
• 如出现 StartupCheck failed 多次重试的情况，可定位为启动时序问题。

3. 最小系统模式提供恢复能力

• 若因启动异常导致部分低可信组件未启动，系统可进入 最小系统模式（“逃生通道”）。
• 此模式下仅保留核心服务，可用于诊断和恢复。

4. 硬件设计协同控制上电时序

• 在实际硬件设计中，可通过 CPLD 控制上电顺序。
• 例如：由 BMC 或 SMC 下发命令，控制 CPU 侧上电时机，确保 BMC 已完全启动后再启动 BIOS。

来自论坛讨论：

“我们这边上电是载板上的 CPLD 控制的……可以通过 SMC 命令字和 CPLD 通信，进行手动上电。”
—— 论坛用户反馈

四、总结：openUBMC 如何保证 BMC 与 BIOS 的启动顺序

建议实践

1. 避免直接使用电源键冷启动，建议通过 BMC 发送电源控制命令（如 IPMI Chassis Control）统一管理上电时序。
2. 升级后检查日志是否有 StartupCheck failed 或 ServiceUnknown 报错，如有则需优化启动依赖配置。
3. 定制载板时，将上电控制权交给 CPLD，并接受 BMC 指令调度，实现精确的启动时序管理。

通过上述软硬件协同机制，openUBMC 能有效应对 BMC 与 BIOS 并行启动带来的挑战，确保系统的稳定性与可靠性。