OpenBMC固件升级实战：BMC/BIOS/CPLD三方联动与回退机制

OpenBMC固件升级实战：BMC/BIOS/CPLD三方联动与回退机制

发布时间：2026/9/13 3:06:06
OpenBMC固件升级实战：BMC/BIOS/CPLD三方联动与回退机制 跑服务器这行搞久了手里肯定会攒下几个刷砖又救活的惊悚故事。尤其在BMC这一层OpenBMC的固件升级涉及BMC自身、BIOS、CPLD三方联动的场景稍不留神就是一台机器灯火通明、控制台全黑。这篇直接把我在实际项目里摸出来的升级管理逻辑、状态机流转和排障链路摊开讲每种固件为什么不能照搬同一套方案也一并说清楚。1. 先看懂服务器里的三套固件BMC、BIOS、CPLD各自在管什么在动手设计升级流程前得先把三者的分工和风险边界理顺。很多人在这一块犯的毛病是把它们当成三个普通flash里的镜像来管理但它们的启动时序、烧写环境和失效模式完全不同。1.1 BMC是整个带外管理的中枢挂了连渣都看不到OpenBMC跑在服务器主板的BMC芯片上一般是Aspeed AST2500/AST2600这类SoC。它干的活是独立的带外管理不管你主操作系统卡成什么样只要主板接了电源、BMC自己的小系统还活着你就能通过Redfish、IPMI、Web界面看到电源状态、温度、风扇转速甚至强制下电重启。这里有个关键特性BMC的flash里实际上有两个镜像分区一个是当前运行的booted image另一个是备用的other image。OpenBMC在编译时会布局好这两个bank固件升级时先把新image写到非活动bank校验通过后翻转启动标志。这个设计直接影响后面的升级策略后面会细讲。从我们的运维视角来看BMC固件是最后一道防线。它的升级是所有固件升级里风险最高、影响最广的一环因为它一旦损坏你连IPMI都进不去更谈不上通过BMC去刷BIOS和CPLD了。1.2 BIOS承上启下但它的刷新路径往往要借道BMCBIOS或者更严谨地说平台的UEFI固件在X86服务器里的角色不用多解释——初始化CPU、内存、PCIe总线然后引导Bootloader和操作系统。它的flash通常在SPI总线上物理上挂在PCHPlatform Controller Hub下面。但问题在于在服务器场景里你通常没有办法像在台式机上一样插个U盘进BIOS界面去刷。机架服务器很多是上架后死都不肯再接显示器的或者干脆是Headless运维。这时候刷新BIOS的路径就变成了BMC通过某种通道拿到BIOS镜像写到SPI flash上。常见的通道有这么几条通过BMC内部的SPI从控制器访问BIOS flashAspeed SoC自带这个能力通过PCH的SMM/Host Interface让BIOS在运行时接收BMC下发的内容通过CPLD间接操作但那通常只是给BIOS发重置信号不是刷flash因为路径复杂BIOS升级对镜像格式、地址偏移和校验算法极其敏感。一个字节错位就是整块板子PSU灯亮但CPU不跑。1.3 CPLD是硬件时序的螺丝刀升级时需要格外小心CPLDComplex Programmable Logic Device在这三兄弟里最不起眼但它管着最底层的东西上电时序、复位信号、PCIe时钟控制、甚至BMC与主板其他部件的信号桥接。服务器开机的第一步往往就是CPLD按顺序拉高/拉低各种电源使能信号时序错了主板直接不启动。CPLD的升级是所有固件升级里最让人头疼的一项原因有三个它的flash空间小但逻辑密集一个错误的烧写可能让电源时序逻辑立即失效升级过程不能断电一旦中断CPLD里可能留下一份残缺的逻辑最坏情况是主板再也无法上电坏的CPLD可没有BMC那样的双bank机制很多低成本板子就是单镜像刷挂就只能上JTAG恢复所以实际生产项目里CPLD的升级频率远远低于BMC和BIOS而且通常会限定在出厂初始化或硬件调试阶段进行线上批量推送的情况少之又少。2. OpenBMC的固件升级架构到底有哪些服务在背后协同OpenBMC并不是一个单一的固件项目它是一整套基于Linux的软件栈。固件升级功能也散落在多个组件里核心依赖是phosphor-software-manager但真正可用的上层入口是Redfish的UpdateService接口。这一节把架构串起来顺便说清楚为什么一个简单上传镜像并刷新的操作在代码层面要拆成好几步。2.1 从Redfish UpdateService到软件对象一条主干链路OpenBMC标准的固件升级流程从用户视角看是这样一个请求# 上传BMC固件镜像并触发升级 curl -k -H X-Auth-Token: $TOKEN \ -F imageimage-bmc.mtd \ https://$BMC_IP/redfish/v1/UpdateService/Actions/UpdateService.Update这个请求进来后bmcweb会把镜像存到/tmp/images/目录下然后给phosphor-software-manager发一个D-Bus信号告诉它新镜像到了。接下来脚本会检查镜像的MANIFEST文件提取版本号、镜像类型、用途等信息在D-Bus上创建对应的软件对象。这个软件对象是后续所有操作的锚点。每个对象代表一个固件镜像路径大概长这样/xyz/openbmc_project/software/{hash_id}对象里挂着一系列属性最核心的包括Activation当前激活状态比如Active、Failed、Activating、ReadyRequestedActivation用户请求的目标状态Version镜像版本号Purpose镜像用途比如BMC、BIOS、CPLD、Host、Other看到这里你应该明白了OpenBMC把BMC、BIOS、CPLD的升级统一建模成了软件对象状态机上层接口可以做到统一但具体到每种镜像刷写逻辑各不相同。2.2 各组件分工bmcweb、phosphor-software-manager、image管理脚本一张表看清组件职责组件职责关键路径bmcweb提供Redfish接口接收上传文件鉴权/redfish/v1/UpdateServicephosphor-software-manager监听新镜像事件创建软件对象驱动状态机/xyz/openbmc_project/softwareimage管理脚本解析MANIFEST校验hash决定刷入哪个bank/etc/init.d/下相关脚本phosphor-software-manager调用的shell/python脚本u-boot env / bootloader层根据启动标志决定从哪个bank启动BMCflash的U-Boot环境变量flashcp/flash_erase实际擦除和写入flash的工具/usr/sbin/这个分层设计的好处是上层Redfish接口不用管底层刷写细节底层刷写逻辑也不需要关心用户是Web点按钮、命令行敲curl还是IPMI命令触发的。做二次开发的时候你基本只需要关注phosphor-software-manager和image管理脚本这两个层面的逻辑。3. BMC固件升级的完整链路从镜像上传到双bank切换BMC固件升级是所有升级里最核心、也最需要小心设计的一环。下面以OpenBMC 2.x/2.7的常用流程为例完整走一遍。3.1 镜像的MANIFEST与校验机制一份OpenBMC镜像文件通常是个tar包里面包含MANIFEST、image-kernel、image-rofs、image-rwfs等文件。MANIFEST是纯文本里面有一堆键值对大概是这个画风purposexyz.openbmc_project.Software.Image.Purpose.BMC version2.13.0-dev-1234 image-download-uri image-sha512abc123...phosphor-software-manager收到新镜像后会先做两件事验证version字段是否符合预期的格式版本号乱写会导致后面排序和对比出错然后校验sha512。校验通过才进入Ready状态否则直接标记Failed。这里有个实践中容易踩的坑镜像tar包里的路径名和MANIFEST里的字段名都必须严格匹配比如MANIFEST如果写的是purpose你把它改成image-purpose看起来好像更语义化但phosphor-software-manager不认会直接报错。很多二次开发团队喜欢改字段名让对方看得更清楚结果就是升级接口直接废掉。3.2 双bank机制与触发方式OpenBMC的BMC固件存储在设计上跟普通嵌入式设备不太一样。很多方案是只有一个rootfs直接覆盖刷写但OpenBMC标准做法是双镜像交替bank0 / bank1分别保存一套完整的image-kernel image-rofs image-rwfs当前运行的往往是其中一套另一套空闲刷写时先刷空闲bank刷完校验然后通过U-Boot环境变量如bootcount、openbmc_my_bank翻转启动顺序这套机制带来的好处是即使新image启动失败U-Boot会在多次启动失败后自动回退到上一个bank。这是服务器场景下刷BMC固件不怕变砖的最大底气。实际触发升级的命令大概是# 重置请求让软件对象从Ready进入激活流程 busctl set-property \ xyz.openbmc_project.Software.Manager \ /xyz/openbmc_project/software/{hash_id} \ xyz.openbmc_project.Software.Activation \ RequestedActivation \ s xyz.openbmc_project.Software.Activation.RequestedActivations.Active那一刻phosphor-software-manager会去调用image管理的shell脚本脚本里核心的步骤差不多是这样再次校验镜像的CONFIG_LAYOUT确认镜像布局跟当前平台匹配找到当前空闲的bank编号flash_erase那个bank上的各个分区flashcp写入kernel、rofs、rwfs顺序不能乱全部写完后再读flash回验一遍hash校验OK更新U-Boot的环境变量指向新bank很多从ARM嵌入式转过来的人一开始不理解为什么OpenBMC刷写要花好几分钟——因为在AST2600上整个rootfs镜像动辄几百MBSPI flash的写入速度本来就不快擦除还要先erase blocks反复的read-back校验又占时间。这是正常的不是系统卡死了。3.3 为何推荐Active和Booted要分开跟踪细心的读者会发现软件对象属性里除了Active还会出现Booted这个属性。什么意思呢Active表示新的image已经被刷进flash并且激活标志已翻转Booted表示当前运行的BMC就是从这份image boot起来的。在实践中这两个状态经常会短期不一致。因为BMC固件有时是刷完但不立即重启的要等运维挑个低峰窗口再reboot。这时候软件对象的Activation可能是Active但Booted还是false——因为BMC还在老镜像里跑着。管理平台做固件版本展示的时候如果把Active当现在跑的版本就会闹出笑话监控显示BMC版本已经2.13了但BMC实际响应的Redfish FirmwareVersion还是2.12。所以做自动化巡检脚本时最好以Booted属性为准配合BMC的/xyz/openbmc_project/software/bmc/primary或/redfish/v1/UpdateService/FirmwareInventory里的状态字段综合判断。3.4 升级失败后的回退逻辑上文说了双bank的最大好处是能回退。U-Boot里通常会配置bootcount和altbootcmdBMC每次启动时bootcount递增如果U-Boot发现bootcount超过阈值就认为当前bank启动失败自动从另一个bank启动并且会把环境变量里的优先级顺序做一次翻转这个机制在刷BMC时给人极强的安全感。但注意一点它不是一个无条件的保证。如果新镜像的问题在于启动后几分钟才崩溃比如某个驱动在业务运行时才panicU-Boot层面是检测不到的此时只能靠系统里的watchdog或bmc的软复位逻辑来发现异常。做一个完整的升级管理系统时这类延时故障往往是设计和验证里最容易被忽视的环节。4. BIOS和CPLD的升级为什么不能照搬BMC的双bank思路BMC的双bank机制很诱人于是很多人想当然地认为BIOS和CPLD也可以照同样的路子做。实际开发后会发现这两个家伙的水深多了。4.1 BIOS升级的常见通道和实现方式在OpenBMC平台上做BIOS升级用的镜像文件通常是一个capsuleUEFI Update Capsule或者厂商自定义的binary。OpenBMC的软件架构里跟BIOS镜像相关的Purpose字段是xyz.openbmc_project.Software.Image.Purpose.Host或者BIOS具体看平台怎么定义。刷新路径更多时候是这样方式A通过Aspeed的SPI从控制器直接写BIOS flashAST2600有一个专用SPI控制器可以映射到BIOS flash的物理地址。OpenBMC里面对应的设备节点一般是/dev/mtd/bios。升级脚本做的事情大致是flash_erase /dev/mtd/bios、flashcp image /dev/mtd/bios。这个操作一旦出错板子直接不开机除非你后面还有JTAG兜底。方式B通过BIOS自身的Runtime接口接收镜像这种方式更安全因为真正的刷写动作是BIOS自己在SMM模式下做的BMC只是把数据推过去。OpenBMC里有组件如intel-phi或ibm-panel相关实现做这个事。但这个方案强依赖BIOS厂商的支持不是每个平台都能用。在写产品级代码时我最常用的判断是平台支持Runtime接收就走Runtime平台不支持才考虑SPI直写并且直写前必须对镜像做严格的平台ID匹配校验。4.2 版本匹配与平台ID校验一个字节都可能白屏BIOS镜像比BMC镜像更讲究平台匹配。你拿一颗EPYC平台的BIOS往Xeon平台上写大概率不是能不能开机的问题是这块板子可能直接没有显示信号。所以做BIOS升级管理时版本校验至少要有两层解析镜像里的Platform ID字段跟BMC里记录的主板型号比对比对镜像里的Board ID和Board RevisionOpenBMC里这一块通常是靠image-manager脚本或专门的PLDM/BMC工具实现的。用Redfish接口时你可以在更新前先GET一下/redfish/v1/UpdateService/FirmwareInventory/下的BIOS组件看看当前版本的字段结构和镜像里是否吻合。我在生产环境见过一次事故某批主板硬件改版从Rev A改成Rev B但BIOS镜像还是绑定Rev A的Platform ID运维同事在管理平台上批量刷上去结果几十台机器全部起不来最后全靠一台一台拆机接JTAG恢复。平台ID字段和硬件版本字段的校验永远不能省。4.3 CPLD升级的JTAG/SPI路径与单镜像风险CPLD镜像在OpenBMC里同样有软件对象但它的刷写路径通常跟前两者都不一样。常见做法是通过BMC的GPIO模拟JTAG时序或者通过SoC的SPI/JTAG控制器去访问CPLD的JTAG TAP口。这就出现一个让很多新手懵圈的问题**为什么CPLD镜像要跟BMC/BIOS分开处理**原因是CPLD本身没有运行操作系统然后自己刷自己的能力。它的逻辑永远在运行你要刷它就必须有一个外部主体BMC来控制JTAG/SPI去改写它的flash。在改写的过程中CPLD不可能把当前正在跑的时序逻辑切掉所以一旦flash写出错它的时序逻辑可能就无法保持原来的行为。另外CPLD镜像通常体积很小几百KB到头了但里面的逻辑密度高。它不像Linux文件系统可以随便做双bank——成本敏感的主板通常只给CPLD配一个小flash没有第二个bank也没有U-Boot帮你回退。因此升级CPLD的流程设计必须强制加写后回读校验并且在产品验证阶段安排一个升级中途断电/意外中断的故障注入测试看恢复是否可行不可行的话就得在运维流程里明确CPLD升级只允许在设备离线维护窗口执行而且必须连接串口或JTAG到现场做好人工救援准备。4.4 三种固件升级的顺序不是你想先刷谁就刷谁很多新人在做全量固件升级时习惯先刷BMC再刷BIOS最后刷CPLD理由是按重要性从高到低。但实际工程上这个顺序很多时候是反过来的原因在于依赖关系。一个合理的推荐顺序通常是这样先看是否存在跨版本的硬件兼容问题。比如BIOS版本太老不认识新CPLD的逻辑定义或者CPLD时序逻辑变了老的BMC镜像对应不上。先刷CPLD再刷BIOS最后刷BMC。CPLD是最底层硬件逻辑刷完后平台的基础时序就定了接着刷BIOS让固件与硬件逻辑对齐最后刷BMC确保带外管理与前述两者匹配。如果产品有明确的厂商升级矩阵遵循厂商矩阵排列因为它里面会考虑PLDM固件更新规范或特定平台的验证结果。实际项目里最常见的翻车场景之一就是运维贪方便直接跳级BMC已经从老版本升到新版本但BIOS还停在两年前的老版本然后某些新加的BMC传感器读数对BIOS的ACPI表不兼容整机上报错误信息。在升级管理方案中我建议把升级顺序写进自动化流程的参数校验里而不是靠人记忆。5. 生产环境里真正的坑版本校验、异常恢复与升级记录管理再好的架构设计落地到生产环境都逃不过细节翻车。这一节把我自己踩过的、以及在多个项目里排查过的问题归纳出来每一条都是真金白银换来的经验。5.1 版本号踩坑字符串比较的陷阱OpenBMC的版本号在D-Bus对象里是字符串但很多管理平台会用字符串比较来判断A版本是否比B版本新这种比较在纯整数版本号里还行碰到带字母的就翻车。比如2.13.0和2.9.0直接按字符串比较2.9.0 2.13.0会成立因为字符逐个对比时第3个字符9大于1于是平台可能拒绝你升级到更高版本这是一个特别低级但又特别容易犯的错。正确做法是用专门的版本比较函数比如Python的packaging.version.Version或者把版本拆成元组再比较。凡是系统里出现版本太低不允许升级的判断逻辑必须对着这两个版本实测一遍别只测递增序列。5.2 镜像文件一致性验证别相信网络传输BMC在升级前最重要的一步是hash校验但很多时候校验只针对tar包本身而对内部子文件的校验不够严格。例如就发生过这种情况image-bmc.mtd在下载过程中损坏了一个字节但管理平台并没有对内部文件做二次hash直接就把Image交给phosphor-software-manager结果擦除完写进去后才发现kernel起不来只能现场救援。所以在设计升级链路时至少要有两级验证BMC收到镜像后对整体tar包的SHA512校验这是OpenBMC标准行为刷写前image脚本对image-kernel、image-rofs等内部文件做一次CRC或SHA校验不少平台做了但定制时经常被砍掉别砍真出事时你会后悔的5.3 升级过程被中断进程管理与外因断电因为BMC升级会真实地对flash做擦写如果中间掉电或者SSH被切断、进程被killflash里可能残留一个写了一半的镜像。尽管双bank机制能让你在下次启动时自动回退但flash自身的磨损和部分写入的block状态仍然可能埋下隐患。处理这个问题的常见做法是为升级进程设置systemd服务并在服务里防止意外停止例如用RemainAfterExityes、加上watchdog心跳确保升级脚本对SIGTERM/SIGINT做了处理不要默认退出而是等当前flash block写完再收尾在断电场景下如果产品允许建议给BMC flash加一个独立的atexit检查逻辑每次启动时检测有没有未完成的升级事务有的话直接标记该bank为invalid并强制走另一个bank5.4 管理平台的升级记录不记录等于没升级在多人协作的运维环境里最可怕的事情不是升级失败而是升级完没人知道升级了什么、什么时候升的、用的哪个镜像哈希。OpenBMC的D-Bus软件对象会保留下一次升级的Version字段但管理平台如果不主动去持久化重启后这些历史信息就丢了。我在自研平台里会额外做一张升级审计表每次升级前把当前版本、目标版本、镜像SHA256、操作人、时间、升级结果全记上。刷完以后BMC侧的/var/log/里也会留份日志但那是设备本地视角跟管理平台的全局视角不是一回事。这张审计表在事后排查是不是上一次升级引入的兼容问题时价值非常大。没有它出了兼容问题只能靠猜。5.5 一次真实故障排查升级后传感器数据全部异常最后分享一次具体的排查过程这能很好地把上面的机制串起来。现象是某款机型把BMC从2.10升到2.13后Redfish里所有传感器读数都不显示了。第一次怀疑是传感器配置文件的问题但配置文件在BMC镜像里是rofs的一部分不能单独改。于是先从软件对象的状态看起busctl introspect xyz.openbmc_project.Software.Manager \ /xyz/openbmc_project/software/bmc/primary看到Booted确实是最新版本说明启动正常。然后检查D-Bus上的传感器对象xyz.openbmc_project.Sensor.Value都没有报错。最后查BMC日志发现新镜像里的sensor-monitor服务在启动时连不上某个D-Bus接口原因是它依赖的entity-manager配置要从BIOS/CPLD上报的数据里读取FRU信息。回到问题本质这台机器BIOS版本太老被新BMC发现后entity-manager解析BIOS提供的SMBIOS数据时得到了一个不兼容的字段结构服务直接罢工。解决方式不是改BMC而是先升级BIOS再让BMC重新加载entity-manager配置。这个案例再次验证了那一句老话固件升级不是单点操作是整机系统工程。6. 最后分享一点个人体会做了这么多OpenBMC平台的固件升级功能最深的一个感受是表面上是技术问题本质上是流程和预期管理问题。BMC、BIOS、CPLD这三类固件各自的技术方案差异很大但落到运维端全都归结为可预期、可回退、可审计这三个词。我的建议是任何平台在正式交付固件升级功能之前至少做一轮破坏性测试故意传错镜像、上传到一半断网、刷写过程中强制下电、版本号乱填、跨平台刷写全部按故障预案走一遍。这一轮测试虽然麻烦但它能帮你把那些只在用户现场才会炸的雷提前扫干净。如果你正在规划自己的OpenBMC升级管理功能不妨先从简单的做起先跑通BMC自身升级再逐步扩展BIOS、CPLD先保证能刷回去再优化刷得漂亮。服务器这东西稳定压倒一切固件升级尤其如此。