[{"data":1,"prerenderedAt":228},["ShallowReactive",2],{"\u002Fen\u002Fblogs\u002F20260903ubmc-baiao":3,"content-doc-\u002Fzh\u002Fblogs\u002F20260903ubmc-baiao":4,"surround-\u002Fzh\u002Fblogs\u002F20260903ubmc-baiao":221},null,{"id":5,"title":6,"author":7,"body":11,"category":212,"company":3,"coverImage":99,"date":213,"description":27,"extension":214,"location":3,"logo":3,"logoDark":3,"meta":215,"navigation":216,"path":217,"seo":218,"stem":219,"version":3,"__hash__":220},"content\u002Fzh\u002Fblogs\u002F20260903UBMC-baiao.md","从故障诊断到 RAS Offload：百敖 openUBMC 的 Intel 平台适配实践",[8],{"name":9,"description":10},"汪涛","南京百敖软件有限公司技术总监，openUBMC技术委员会委员，在BMC、BIOS等固件领域从事研发15年，多次承担国家科技支撑计划，拥有丰富的服务器固件领域研发经验。",{"type":12,"value":13,"toc":195},"minimark",[14,18,22,25,28,31,35,38,41,44,47,49,53,64,67,70,73,81,84,87,90,93,101,103,107,109,111,117,120,122,126,129,132,135,141,144,146,150,153,156,159,161,165,168,171,173,177],[15,16,17],"h2",{"id":17},"概要",[19,20,21],"p",{},"openUBMC 26.06 版本新增了对 Intel 等 x86 平台的基础支持。在此基础上，百敖面向 Intel 服务器平台完善了商业发行版，新增故障诊断、远程调试、负载与功耗管理、RAS 错误处理等能力，并延续对国产平台的兼容支持。",[19,23,24],{},"这些能力横跨 BMC、CPU\u002FPCH、BIOS 和操作系统。CATERR、IERR 等严重故障发生后，BMC 通过 PECI 接口获取 故障现场的CPU寄存器；CPU\u002FPCH 的远程调试依赖 BMC的JTAG接口；利用率采集和功率封顶分别由 CUPS 与 Node Manager 承担；系统的可纠正错误由之前的BIOS SMM处理 Offload 到BMC处理。",[19,26,27],{},"本文围绕上述链路，介绍百敖在 Intel 平台上的适配工作，以及这些能力如何进入 openUBMC 26.06 商业发行版。",[29,30],"hr",{},[15,32,34],{"id":33},"_01-intel-平台适配的难点在于跨固件链路","01 Intel 平台适配的难点，在于跨固件链路",[19,36,37],{},"ACD、ASD、CUPS\u002FNode Manager 和 RAS Offload 依赖不同的硬件接口与处理机制。PECI 负责获取 CPU 状态，JTAG 用于 CPU\u002FPCH 调试，功耗管理需要平台侧数据和控制接口，RAS Offload 还涉及 BIOS、BMC 与操作系统之间的错误处理协同。",[19,39,40],{},"因此，适配验证必须覆盖完整链路：故障能否触发采集，数据能否读回并解析，功耗设置是否生效，错误处理能否按预期在 BMC 与操作系统之间流转。任何一环缺失，相关能力都无法正常工作。",[19,42,43],{},"在Birch Stream 平台适配中，一些客户相关功能的设计方案并不完全跟Intel CRB服务器设计保持一致，例如ASD功能。Intel通常采用BMC的原生JTAG接口连接CPU，ASD源码中默认也走原生JTAG方式，但部分厂商改用普通GPIO连接CPU，需要BMC通过GPIO模拟JTAG的方式调试CPU，导致ASD源码不能直接使用，无法验证此功能。",[19,45,46],{},"在深入阅读ASD源码后，在源码中添加了通过GPIO模拟JTAG的软件方案，并适配相关的GPIO为JTAG功能。但在实际调试中发现GPIO模拟的JTAG频率与时序远低于硬件JTAG，且频率不稳定,导致JTAG返回的数据总是有部分异常。通过不断地优化软件JTAG频率，最终通过这种方式能正常调试CPU，达到了公板上ASD功能同样的效果。",[29,48],{},[15,50,52],{"id":51},"_02-从自动留存现场到远程调试acd-与-asd","02 从自动留存现场到远程调试：ACD 与 ASD",[54,55,56],"ul",{},[57,58,59],"li",{},[60,61,63],"h3",{"id":62},"acd严重故障发生后先保留-cpu-现场","ACD：严重故障发生后，先保留 CPU 现场",[19,65,66],{},"服务器发生 CATERR、IERR 等严重故障时，操作系统可能已无法提供完整的故障现场。百敖在 BMC 侧接入 ACD（自主崩溃转储）能力，由 BMC 通过 PECI 获取 CPU 寄存器信息。",[19,68,69],{},"整条链路从故障信号开始，CPU 触发CATERR\u002FIERR等严重故障后，BMC 经GPIO中断监测到故障发生，从而触发ACD故障采集流程。ACD启动后，先根据当前的CPU型号加载并解析对应的数据采集JSON配方文件，得到需要采集的寄存器及对应的PECI读取方式清单，接着按照配方通过 PECI接口逐段MCA、Uncore等寄存器数据，生成包含各寄存器结果的JSON 文件，至此ACD数据采集完成。最后由通过BMC中集成的Intel BAFI工具自动解析该JSON结果文件，并将解析出的故障原因写回原JSON结果文件中。从而整个故障信息采集、故障诊断流程完成，不再依赖操作系统保留现场。",[19,71,72],{},"在openUBMC上集成ACD和BAFI等功能时，由于openUBMC与OpenBMC等代码平台上组件的管理形式不同，其各组件是以Conan包的形式进行管理，因此需要先将这些原本OpenBMC格式的功能包及其相关的依赖包添加为新的组件，并进行Conan化改造，整个改造过程中，功能包的源码没有改变，主要是修改了组件的构建方式。相关组件构建通过后，还需要适配对应的设备驱动，先根据功能包中原有的接口要求在新BMC芯片上适配对应的PECI内核驱动和硬件抽象层驱动代码。驱动编译通过后，再将上述的功能包和依赖包组件添加到manifest中，从而集成到openUBMC中。最后将构建出来的整包在QEMU上模拟运行，模拟验证无异常后即可烧录到机器上进行全面验证。",[54,74,75],{},[57,76,77],{},[60,78,80],{"id":79},"asd通过-bmc-进入-cpupch-调试","ASD：通过 BMC 进入 CPU\u002FPCH 调试",[19,82,83],{},"Intel 平台的运行管理分为两条链路。CUPS 负责采集 CPU 核心、内存和 IIO 总线利用率，为 BMC 提供平台负载数据；Node Manager 负责设置整机、CPU、内存和 PCIe 的功耗阈值，执行功率封顶。",[19,85,86],{},"在openUBMC上集成CUPS和Node Manager功能时， 其适配方案与上述的ACD一致，都是依赖PECI驱动，先将功能包和对应的依赖包进行Conan化改造，构建成功后，再将这些新增的组件添加到manifest中完成功能集成。",[19,88,89],{},"ASD 提供故障后的结构化信息，当需要进一步定位 CPU 或 PCH 问题时，ASD 通过 BMC 内置的 JTAG 接口建立远程调试通道，减少对现场 XDP 硬件调试工具的依赖。",[19,91,92],{},"在openUBMC上集成ASD功能时，其适配方案与上述的ACD基本一致，只是其依赖JTAG驱动而非PECI驱动，先将功能包和对应的依赖包进行Conan化改造，构建成功后，再适配对应的JTAG内核驱动和硬件抽象层驱动代码，最后将新增的组件添加到manifest中完成功能集成。",[19,94,95],{},[96,97],"img",{"alt":98,"src":99,"title":100},"alt text","\u002Fcategory\u002Fblog\u002F20260904UBMC-baiao\u002F1.png","ASD 远程调试界面示意",[29,102],{},[15,104,106],{"id":105},"_03-利用率采集与功率封顶cups-与-node-manager","03 利用率采集与功率封顶：CUPS 与 Node Manager",[19,108,83],{},[19,110,86],{},[19,112,113],{},[96,114],{"alt":98,"src":115,"title":116},"\u002Fcategory\u002Fblog\u002F20260904UBMC-baiao\u002F2.png","CUPS 服务运行日志示意",[19,118,119],{},"CUPS 输出利用率数据，Node Manager 下发功耗约束。百敖将两项能力接入 openUBMC 后，运维侧既可以观察负载分布，也可以针对不同功耗域设置上限。",[29,121],{},[15,123,125],{"id":124},"_04-将可纠正错误处理从-bios-smm-转移到-bmc","04 将可纠正错误处理从 BIOS SMM 转移到 BMC",[19,127,128],{},"传统路径下，硬件错误触发 SMI，CPU 随后进入 BIOS SMM 环境完成寄存器读取和错误处理。错误处理会占用业务 CPU。",[19,130,131],{},"在搭载 Granite Rapids 处理器的 Birch Stream 平台上，百敖接入 RAS Offload：可纠正错误触发 BMC 硬件中断，由 BMC 读取相关寄存器并完成处理；只有需要操作系统介入时，才通过 SCI 发出通知。",[19,133,134],{},"在openUBMC上集成RAS Offload 功能时，其适配方案与上述的ACD方案一致，依赖的也是PECI驱动，先将功能包和对应的依赖包进行Conan化改造，构建成功后，再将这些新增的组件添加到manifest中完成功能集成。",[19,136,137],{},[96,138],{"alt":98,"src":139,"title":140},"\u002Fcategory\u002Fblog\u002F20260904UBMC-baiao\u002F3.png","传统 RAS 路径与 BMC RAS Offload 路径对比",[19,142,143],{},"当前方案覆盖内存、PCIe、UPI、CXL 和 SPD I3C 等可纠正错误。处理位置从业务 CPU 转移到 BMC 后，可以减少 SMI\u002FSMM 路径对业务运行的干扰。",[29,145],{},[15,147,149],{"id":148},"_05-产品化集成进入百敖-openubmc-2606-商业发行版","05 产品化集成：进入百敖 openUBMC 26.06 商业发行版",[19,151,152],{},"完成 Intel 平台适配后，百敖将 ACD、ASD、CUPS、Node Manager 和 RAS Offload 集成到基于社区 26.06 版本构建的商业发行版中，并叠加平台适配、缺陷修复和增强模块。",[19,154,155],{},"商业发行版还包括浏览器原生 Web SOL、固件升级和 AI 运维助手。Web SOL 支持复制粘贴、历史日志保存、窗口滚动和字体调整；固件更新包括 BIOS OOB 更新、微码 OOB 更新和 SMM Runtime 更新；AI 运维助手用于查询硬件状态和调度已授权的运维操作。",[19,157,158],{},"百敖使用 iTestSmart V1.0.42 对版本进行自动化验证，开放测试用例共计 1803 条，综合通过率为 94%，并对用户指南、IPMI\u002FRedfish 接口文档和告警处理手册进行标准化整理。",[29,160],{},[15,162,164],{"id":163},"总结从平台适配到商业交付","总结：从平台适配到商业交付",[19,166,167],{},"从 ACD、ASD 到 CUPS、Node Manager 和 RAS Offload，Intel 平台适配贯穿 CPU\u002FPCH、BMC、BIOS 与操作系统。百敖将这些链路接入 openUBMC，并在国产平台兼容能力之外，完成了 openUBMC 26.06 在 Intel x86 服务器平台上的落地。",[19,169,170],{},"在商业发行版中，上述 Intel 平台能力与 Web SOL、BIOS\u002F微码\u002FSMM Runtime 更新、1803 条开放测试用例、配套文档和技术支持一并交付。",[29,172],{},[15,174,176],{"id":175},"欢迎关注openubmc","欢迎关注openUBMC",[54,178,179,188],{},[57,180,181,182],{},"社区官网：",[183,184,185],"a",{"href":185,"rel":186},"https:\u002F\u002Fwww.openubmc.cn",[187],"nofollow",[57,189,190,191],{},"代码仓地址：",[183,192,193],{"href":193,"rel":194},"https:\u002F\u002Fgitcode.com\u002FopenUBMC",[187],{"title":196,"searchDepth":197,"depth":197,"links":198},"",4,[199,201,202,207,208,209,210,211],{"id":17,"depth":200,"text":17},2,{"id":33,"depth":200,"text":34},{"id":51,"depth":200,"text":52,"children":203},[204,206],{"id":62,"depth":205,"text":63},3,{"id":79,"depth":205,"text":80},{"id":105,"depth":200,"text":106},{"id":124,"depth":200,"text":125},{"id":148,"depth":200,"text":149},{"id":163,"depth":200,"text":164},{"id":175,"depth":200,"text":176},"essentials","2026\u002F09\u002F04","md",{},true,"\u002Fzh\u002Fblogs\u002F20260903ubmc-baiao",{"title":6,"description":27},"zh\u002Fblogs\u002F20260903UBMC-baiao","p6qv5dmcWmjZ-AFcFy7shJpSrLuMW-jUF_WlkYHORps",[222,225],{"path":223,"title":224},"\u002Fzh\u002Fblogs\u002F20260723ubmc","刀片服务器健康管理破局：昆仑太科依托 openUBMC 北向自接入实现整机协同",{"path":226,"title":227},"\u002Fzh\u002Fblogs\u002F20260929ubmc-ruantonghuafang","基于 openUBMC 构建 Agent 驱动的 BMC 研发工作流",1793275600676]