概要
openUBMC 26.06 版本新增了对 Intel 等 x86 平台的基础支持。在此基础上，百敖面向 Intel 服务器平台完善了商业发行版，新增故障诊断、远程调试、负载与功耗管理、RAS 错误处理等能力，并延续对国产平台的兼容支持。
这些能力横跨 BMC、CPU/PCH、BIOS 和操作系统。CATERR、IERR 等严重故障发生后，BMC 通过 PECI 接口获取 故障现场的CPU寄存器；CPU/PCH 的远程调试依赖 BMC的JTAG接口；利用率采集和功率封顶分别由 CUPS 与 Node Manager 承担；系统的可纠正错误由之前的BIOS SMM处理 Offload 到BMC处理。
本文围绕上述链路，介绍百敖在 Intel 平台上的适配工作，以及这些能力如何进入 openUBMC 26.06 商业发行版。
01 Intel 平台适配的难点，在于跨固件链路
ACD、ASD、CUPS/Node Manager 和 RAS Offload 依赖不同的硬件接口与处理机制。PECI 负责获取 CPU 状态，JTAG 用于 CPU/PCH 调试，功耗管理需要平台侧数据和控制接口，RAS Offload 还涉及 BIOS、BMC 与操作系统之间的错误处理协同。
因此，适配验证必须覆盖完整链路：故障能否触发采集，数据能否读回并解析，功耗设置是否生效，错误处理能否按预期在 BMC 与操作系统之间流转。任何一环缺失，相关能力都无法正常工作。
在Birch Stream 平台适配中，一些客户相关功能的设计方案并不完全跟Intel CRB服务器设计保持一致，例如ASD功能。Intel通常采用BMC的原生JTAG接口连接CPU，ASD源码中默认也走原生JTAG方式，但部分厂商改用普通GPIO连接CPU，需要BMC通过GPIO模拟JTAG的方式调试CPU，导致ASD源码不能直接使用，无法验证此功能。
在深入阅读ASD源码后，在源码中添加了通过GPIO模拟JTAG的软件方案，并适配相关的GPIO为JTAG功能。但在实际调试中发现GPIO模拟的JTAG频率与时序远低于硬件JTAG，且频率不稳定,导致JTAG返回的数据总是有部分异常。通过不断地优化软件JTAG频率，最终通过这种方式能正常调试CPU，达到了公板上ASD功能同样的效果。
02 从自动留存现场到远程调试：ACD 与 ASD
ACD：严重故障发生后，先保留 CPU 现场
服务器发生 CATERR、IERR 等严重故障时，操作系统可能已无法提供完整的故障现场。百敖在 BMC 侧接入 ACD（自主崩溃转储）能力，由 BMC 通过 PECI 获取 CPU 寄存器信息。
整条链路从故障信号开始，CPU 触发CATERR/IERR等严重故障后，BMC 经GPIO中断监测到故障发生，从而触发ACD故障采集流程。ACD启动后，先根据当前的CPU型号加载并解析对应的数据采集JSON配方文件，得到需要采集的寄存器及对应的PECI读取方式清单，接着按照配方通过 PECI接口逐段MCA、Uncore等寄存器数据，生成包含各寄存器结果的JSON 文件，至此ACD数据采集完成。最后由通过BMC中集成的Intel BAFI工具自动解析该JSON结果文件，并将解析出的故障原因写回原JSON结果文件中。从而整个故障信息采集、故障诊断流程完成，不再依赖操作系统保留现场。
在openUBMC上集成ACD和BAFI等功能时，由于openUBMC与OpenBMC等代码平台上组件的管理形式不同，其各组件是以Conan包的形式进行管理，因此需要先将这些原本OpenBMC格式的功能包及其相关的依赖包添加为新的组件，并进行Conan化改造，整个改造过程中，功能包的源码没有改变，主要是修改了组件的构建方式。相关组件构建通过后，还需要适配对应的设备驱动，先根据功能包中原有的接口要求在新BMC芯片上适配对应的PECI内核驱动和硬件抽象层驱动代码。驱动编译通过后，再将上述的功能包和依赖包组件添加到manifest中，从而集成到openUBMC中。最后将构建出来的整包在QEMU上模拟运行，模拟验证无异常后即可烧录到机器上进行全面验证。
ASD：通过 BMC 进入 CPU/PCH 调试
Intel 平台的运行管理分为两条链路。CUPS 负责采集 CPU 核心、内存和 IIO 总线利用率，为 BMC 提供平台负载数据；Node Manager 负责设置整机、CPU、内存和 PCIe 的功耗阈值，执行功率封顶。
在openUBMC上集成CUPS和Node Manager功能时， 其适配方案与上述的ACD一致，都是依赖PECI驱动，先将功能包和对应的依赖包进行Conan化改造，构建成功后，再将这些新增的组件添加到manifest中完成功能集成。
ASD 提供故障后的结构化信息，当需要进一步定位 CPU 或 PCH 问题时，ASD 通过 BMC 内置的 JTAG 接口建立远程调试通道，减少对现场 XDP 硬件调试工具的依赖。
在openUBMC上集成ASD功能时，其适配方案与上述的ACD基本一致，只是其依赖JTAG驱动而非PECI驱动，先将功能包和对应的依赖包进行Conan化改造，构建成功后，再适配对应的JTAG内核驱动和硬件抽象层驱动代码，最后将新增的组件添加到manifest中完成功能集成。
03 利用率采集与功率封顶：CUPS 与 Node Manager
Intel 平台的运行管理分为两条链路。CUPS 负责采集 CPU 核心、内存和 IIO 总线利用率，为 BMC 提供平台负载数据；Node Manager 负责设置整机、CPU、内存和 PCIe 的功耗阈值，执行功率封顶。
在openUBMC上集成CUPS和Node Manager功能时， 其适配方案与上述的ACD一致，都是依赖PECI驱动，先将功能包和对应的依赖包进行Conan化改造，构建成功后，再将这些新增的组件添加到manifest中完成功能集成。
CUPS 输出利用率数据，Node Manager 下发功耗约束。百敖将两项能力接入 openUBMC 后，运维侧既可以观察负载分布，也可以针对不同功耗域设置上限。
04 将可纠正错误处理从 BIOS SMM 转移到 BMC
传统路径下，硬件错误触发 SMI，CPU 随后进入 BIOS SMM 环境完成寄存器读取和错误处理。错误处理会占用业务 CPU。
在搭载 Granite Rapids 处理器的 Birch Stream 平台上，百敖接入 RAS Offload：可纠正错误触发 BMC 硬件中断，由 BMC 读取相关寄存器并完成处理；只有需要操作系统介入时，才通过 SCI 发出通知。
在openUBMC上集成RAS Offload 功能时，其适配方案与上述的ACD方案一致，依赖的也是PECI驱动，先将功能包和对应的依赖包进行Conan化改造，构建成功后，再将这些新增的组件添加到manifest中完成功能集成。
当前方案覆盖内存、PCIe、UPI、CXL 和 SPD I3C 等可纠正错误。处理位置从业务 CPU 转移到 BMC 后，可以减少 SMI/SMM 路径对业务运行的干扰。
05 产品化集成：进入百敖 openUBMC 26.06 商业发行版
完成 Intel 平台适配后，百敖将 ACD、ASD、CUPS、Node Manager 和 RAS Offload 集成到基于社区 26.06 版本构建的商业发行版中，并叠加平台适配、缺陷修复和增强模块。
商业发行版还包括浏览器原生 Web SOL、固件升级和 AI 运维助手。Web SOL 支持复制粘贴、历史日志保存、窗口滚动和字体调整；固件更新包括 BIOS OOB 更新、微码 OOB 更新和 SMM Runtime 更新；AI 运维助手用于查询硬件状态和调度已授权的运维操作。
百敖使用 iTestSmart V1.0.42 对版本进行自动化验证，开放测试用例共计 1803 条，综合通过率为 94%，并对用户指南、IPMI/Redfish 接口文档和告警处理手册进行标准化整理。
总结：从平台适配到商业交付
从 ACD、ASD 到 CUPS、Node Manager 和 RAS Offload，Intel 平台适配贯穿 CPU/PCH、BMC、BIOS 与操作系统。百敖将这些链路接入 openUBMC，并在国产平台兼容能力之外，完成了 openUBMC 26.06 在 Intel x86 服务器平台上的落地。
在商业发行版中，上述 Intel 平台能力与 Web SOL、BIOS/微码/SMM Runtime 更新、1803 条开放测试用例、配套文档和技术支持一并交付。
欢迎关注openUBMC
【版权声明】Copyright © 2026 openUBMC Community。本文由openUBMC社区首发，欢迎遵照CC-BY-SA 4.0协议规定转载。转载时敬请在正文注明并保留原文链接和作者信息。
【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。