limingfeng
2026 年4 月 29 日 09:50
1
在进行固件升级测试时，尝试连续升级多个组件：
先升级 CPLD（已确认升级成功:日志显示升级完成，SMC 查询版本已更新）
未进行重启，直接继续升级 BMC
BMC 固件文件上传成功，但Web 页面提示升级操作失败
2000-01-02 06:57:57.753595 firmware_mgmt NOTICE: utils.lua(34): The file path is Local.
2000-01-02 06:57:57.842793 firmware_mgmt ERROR: state_wait_restart.lua(31): Accycle or BMCreset is about to be performed during firmware actived, please wait
2000-01-02 06:57:57.843978 firmware_mgmt WARNING: init.lua(97): state_handle.lua:61 > state_wait_restart.lua:37 > state_wait_restart.lua:32: An error occurred during the firmware upgrade process. Details: Accycle or BMCreset is about to be performed during firmware actived, please wait
答案内容由AI生成，仅供参考：
不支持直接连续升级（CPLD → BMC）而不重启。
系统出于稳定性与安全性考虑 ，禁止在有固件等待激活（如 CPLD）的情况下启动 BMC 升级。该行为是 预期设计 ，而非缺陷。
建议严格按照“一升级一激活 ”的原则执行多组件固件升级。
点击此处查看详细分析解答
根据提供的日志信息和系统机制分析，系统在当前状态下不支持在CPLD升级完成后立即进行BMC固件升级而中间不重启 。以下是详细分析：
步骤1： 成功升级 CPLD，SMC 查询显示版本已更新。步骤2： 未重启系统，直接尝试升级 BMC。结果：
BMC 固件文件上传成功。
Web 页面提示升级操作失败。
BMC 日志报错：Accycle or BMCreset is about to be performed during firmware actived, please wait
关键错误日志如下：
2000-01-02 06:57:57.842793 firmware_mgmt ERROR: state_wait_restart.lua(31): Accycle or BMCreset is about to be performed during firmware actived, please wait
2000-01-02 06:57:57.843978 firmware_mgmt WARNING: init.lua(97): ... An error occurred during the firmware upgrade process. Details: Accycle or BMCreset is about to be performed during firmware actived, please wait
state_wait_restart.lua 是 固件管理模块 中负责监控重启状态的脚本。错误表明：系统检测到正在等待电源循环（Accycle）或 BMC 重启（BMCreset）以激活之前的固件更新（如 CPLD 升级） 。
在此状态下，系统锁定新的固件升级任务 ，防止并发冲突或状态异常。
CPLD 升级的生效方式
冷升级模式（Cold Upgrade） ：需通过 BMC 重启 或 系统下电上电（AC cycle） 才能生效。即使升级操作完成，若未执行重启，系统仍处于 “待生效 ” 状态。
在此期间，固件管理系统会 标记系统为“升级进行中”状态 ，并阻止其他关键固件（如 BMC）的升级。
【openUBMC 支持CPLD升级平滑生效特性设计说明书.md】 提到：
平滑生效场景：CPLD升级后等待BMC平滑重启时生效。
直接生效场景：仅在系统下电时升级才可直接生效。
若未满足生效条件，则进入“注册生效”模式，等待 BMC 重启。
BMC 固件升级的前提条件
BMC 固件升级要求系统处于 稳定状态 ，且无正在进行的激活流程。
若存在待处理的激活任务（如 CPLD 等待重启生效），firmware_mgmt 模块将 拒绝新升级请求 ，以保障系统可靠性。
要实现 CPLD → BMC 的连续升级 ，必须按以下顺序执行：
升级 CPLD 固件
执行 BMC 平滑重启（BMCRestart）或 AC Power Cycle
再进行 BMC 固件升级
问题
解决方案
连续升级失败
在 CPLD 升级后执行 BMC 重启或 AC 下电上电 ，确保固件激活完成后再升级 BMC
避免误操作
在 Web 页面或 CLI 中增加状态检查：查询 FirmwareActiveStatus 或 UpgradeStage 是否为 COMPLETED
自动化脚本建议
在升级流程中加入判断逻辑：
if UpgradeStage != COMPLETED then
wait_for_reboot_or_exit()
end
不支持直接连续升级（CPLD → BMC）而不重启。
系统出于稳定性与安全性考虑 ，禁止在有固件等待激活（如 CPLD）的情况下启动 BMC 升级。该行为是 预期设计 ，而非缺陷。
建议严格按照“一升级一激活 ”的原则执行多组件固件升级。
从firmware_mgmt的日志看，似乎是CPLD升级完成后由于当前满足生效条件，立刻开始执行CPLD的生效了。请检查下你的CPLD生效条件是如何配置的（例如下电时生效）？再确认下上传CPLD固件包进行升级时，环境是否已经满足了生效条件的要求？
如果CPLD升级完成后，环境当前不满足生效条件，则firmware_mgmt会注册一个待生效的固件信息，需要手动选择这个待生效的固件进行生效操作。此时在手动生效这个固件之前，是可以继续升级其他固件的。
limingfeng
2026 年5 月 8 日 08:14
4
CPLD应该是无感升级，BMC查询拓展板CPLD的版本也确实更新了，如果固件生效完成了还可以升级其他固件吗，还是还是需要重启BMC？
通常来说，CPLD生效完成后会执行对应的生效动作，而这个生效动作一般都是AC。你上面截图的日志部分显示固件管理这边由于准备执行AC（或BMC复位），所以此时不能立刻升级下一个固件。
其他有一些种类的固件，升级完成后是没有这些对应生效动作的，例如MCU，这种情况下你升级完MCU之后不会发生AC或BMC复位，就可以再升级下一个固件。
你提到CPLD执行的是无感升级，无感升级应该是不会注册生效任务的，但是从前面的现象来看是执行了生效的，似乎不是无感升级流程。如果你对这块CPLD升级时具体做了什么还有疑问，可以提供完整的日志我检查下。
limingfeng
2026 年5 月 9 日 08:51
6
limingfeng
2026 年5 月 9 日 08:56
7
下面貼了日志， 我对无感升级的理解可能错了， 我应该是热升级， 从查看CPLD的版本号看已经更新完成了，但是流程还是需要执行复位或者AC，可能是我的cpld生效文件配置有问题吗
从general_hardware的升级日志看，你的cpld升级走的是正常的冷升级流程，这种升级流程会先写入升级文件，然后等待带内上下电的状态满足要求时，再执行生效步骤，然后执行AC操作。走的并非是你所说的热升级流程，所以会有帖子一开始所描述的现象。（继续升级下一个固件时，由于当前正在生效CPLD并准备AC操作，不允许升级）
如果想要热升级CPLD，需要固件包的update.cfg文件中配置HotValidList=1这个属性，指明这一片CPLD需要热升级。可以检查下是否有配置相关字段。
limingfeng
2026 年5 月 11 日 03:02
9
目前用的update.cfg是参考的社区教程做的， 里面有两个Firmware对象，教程里面说第一个是对应valid.vme，第二个对应cpld.vme。
我看了一部分代码升级好像是只关注Firmware1，如果热升级的话还需要valid.vme吗， 增加HotValidList=1是每个都需要增加吗
[Firmware]
#载板在线升级包
[Firmware1]
limingfeng
2026 年5 月 11 日 04:28
11
设备是一块拓展板CPLD，2个模组CPLD，现在是用升级拓展板的CPLD来看问题， 修改了update.cfg在FirmWare1对象增加了HotValidList=1之后日志里面能看到HotList有值了，不过看日志生效的动作好像是从db里面取得，还是需要AC。load_cpld_single
lisongwei
2026 年5 月 11 日 06:32
12
从日志内容看，本次升级走的还是冷升级流程。HotValidList像是配置上了但是没生效。判断CPLD冷升级或是热升级的分支是在fw_upgrade.lua文件中的check_hot_upgrade进行的，而这个函数几个可能分支的日志打印都没有。检查下你当前运行的组件版本是否比较老，fw_upgrade.lua文件中有没有这个函数，可以更新组件代码到社区最新后再试一下
limingfeng
2026 年5 月 11 日 07:40
13
应该是因为厂商模式为1所以没有进去check_hot_upgrade的流程， 这个热升级和厂商模式有关系吗， 现在配置的是1，然后 defs.CPLD_SUPPLIER_MODE.SINGLE定义的也是1，载板CPLD就是安陆的，这个需要怎么改吗， 是直接改升级配置的MultipleSuppliersMode改成大于1这样行吗？
if *signal*.upg_cfg_list\[index\].supplier_mode > defs.CPLD_SUPPLIER_MODE.SINGLE then
ret = check_hot_upgrade(*signal*.upg_cfg_list, index)
end
lisongwei
2026 年5 月 11 日 11:13
14
可以此处MultipleSuppliersMode修改为多厂商模式试下。另外注意，多厂商模式时升级/生效文件不能命名成cpld.vme/valid.vme，而是需要加上序号，例如改为cpld01.vme/valid01.vme。可以这样再试下。
limingfeng
2026 年5 月 12 日 01:40
15
修改vme文件名为cpld01.vme和valid01.vme后成功实现了热升级， 多谢~
limingfeng
2026 年5 月 12 日 07:47
16
遇到一个 CPLD 设备识别的新问题，换了一款CPLD芯片升级时候日志报错说不支持的CPLD设备，实际芯片为安路EF3::EF3LAOCG642B
general_hardware ERROR: cpld_chip.lua(48): Invalid cpld device id CC3F(1)
看了下 cpld_chip.lua 的 support_list，里面没有这个CC3F的 device id。
local support_list = {
-- 安路
anlu_ef2l15 = {id = 0x04004c37, get_file_id_func = get_anlu_file_id},
anlu_ef2 = {id = 0x03004c37, get_file_id_func = get_anlu_file_id},
anlu_ef3 = {id = 0x00008c3b, get_file_id_func = get_anlu_file_id},
anlu_3f0f9 = {id = 0x0003f0f9, get_file_id_func = get_anlu_file_id},
-- lattice
lattice_ef2 = {id = 0x012bd043, get_file_id_func = get_lattice_file_id},
lattice_ef3 = {id = 0x612bd043, get_file_id_func = get_lattice_file_id},
lattice_lcmxo2_4000hc = {id = 0x012bc043, get_file_id_func = get_lattice_file_id},
-- 紫光
pango_ef2 = {id = 0x0042a899, get_file_id_func = get_pangu_file_id},
pango_ef3 = {id = 0x0042b988, get_file_id_func = get_pangu_file_id},
pango = {id = 0x0042b899, get_file_id_func = get_pangu_file_id},
}
看上去不同型号使用的是同一套函数句柄/处理逻辑，所以我直接在 support_list 里补了一个映射，实测升级和启动都正常，没有发现异常。
想确认一下：
这种直接补 support_list 的做法是否有风险？
正常情况下，这类新增 device id 的标准处理流程一般是怎样的？
lisongwei
2026 年5 月 12 日 11:55
18
确认需要新增的话，这里直接新增你需要的device id合入代码即可。
结论
不支持直接连续升级（CPLD → BMC）而不重启。
问题现象总结
日志分析
固件升级生效机制说明
解决方案