CPU模组在线升级CPLD失败

xuzhijia · 2026 年3 月 4 日 06:28

问题描述

在web升级签完名的CPU模组的CPLDhpm包升级失败

环境信息

软件版本：[OpenUBMC2503]

尝试过的解决方案

已和客户确认，BMC通过LocalBus总线连接载板CPLD

根据日志信息定位到出错的general_hardware/src/lualib/unit_manager/class/logic_fw/upgrade/drivers_api.lua下的get_cpld_device_info函数并新增了打印函数

发现id_list为空

请问下可能是什么原因导致的

ubmc_assistant · 2026 年3 月 4 日 06:34

答案内容由AI生成，仅供参考：

结论

升级失败的根本原因是：BMC 无法通过 JTAG 链路读取到 CPLD 的 IDCODE，id_list 返回为空，导致驱动判定无目标设备，升级中止。

这通常由以下两个主要原因之一引起：

硬件链路问题：JTAG 通路被模拟开关阻断，或 LocalBus 配置错误，导致 BMC 与 CPLD 之间通信链路不通。
CSR 配置错误：未正确配置 Cpld 或 Smc 组件的通信通道（BusType=LocalBus）、地址、通道号等参数。

解决方案建议

1. 检查并确保 JTAG 通路已切换至 BMC 控制

根据电路图，确认 模拟开关 的控制信号已由 BMC 正确拉高/拉低，使 JTAG 通路连接到 BMC 侧。
建议使用示波器或逻辑分析仪验证 JTAG_TMS、TCK、TDI 等信号是否正常。
可尝试手动下发命令强制切换通路（如有提供 API）。

2. 核查 CSR 中 Cpld 组件配置

确保 Cpld 对象的 CSR 配置正确，关键字段如下：

{
  Name = "BCU_CPLD1",
  BusType = "LocalBus",        -- 必须为 LocalBus
  Channel = 1,                 -- 对应 LocalBus 编号
  Address = 0x96,              -- I2C 地址（如通过 SMC 协议访问）
  ChipType = "CPLD",
  Protocol = "SMC",            -- 推荐使用 SMC 协议
  Supported = true,
  BaseOffset = "expr(0x100)",  -- 如用于汇聚访问
}

特别注意：若使用天池架构，推荐使用 SMC 协议 + LocalBus 与 CPLD 通信，而非直接 JTAG。

3. 验证硬件上电状态

确认目标 CPLD 已正常上电，无短路或电源异常。
检查复位信号是否释放。

4. 捕获并分析完整日志

收集完整的 app.log 和 ipmi.log，重点关注 hwproxy 模块是否有 I2C/JTAG 通信失败记录。

查找类似错误：

read failed: i2c.lua:117: response error
ioctl(CPLD_CMD_LOAD_CPLD) failed: 21

5. 参考类似问题解决方案

根据知识库中 “硬盘背板CPLD升级报错” 案例（topic_id=1977）：

“630版本升级失败的原因是因为硬件链路不通，330版本上升级没有报错，是因为软件没有检测这类错误，实际升级未生效。通过更换硬件，问题已解决。”

说明此类问题在新版本中因增强了链路检测而暴露出来，旧版本可能“静默失败”。

总结

项目	内容
问题现象	Web 升级 CPU 模组 CPLD 失败，进度 95%，`id_list` 为空
直接原因	`getChipIdcode()` 返回空列表，无法识别 CPLD 设备
根本原因	JTAG/LocalBus 通信链路异常或 CSR 配置错误
解决方案	① 检查模拟开关通路；② 核对 CSR 配置；③ 验证硬件状态
风险提示	若链路不通，即使固件签名验证成功，实际写入也不会生效

点击此处查看详细分析解答

CPU模组在线升级CPLD失败问题分析报告

问题概述

用户在使用 OpenUBMC2503 版本通过 Web 界面对 CPU模组的CPLD 进行 HPM 固件升级时，升级过程在 95% 左右失败，返回错误码 -1。相关日志显示升级流程能正常进入 PREPARE 和 PROCESS 阶段，但在执行 load_cpld_multi_supplier_mode 时，调用底层驱动获取 CPLD 芯片 IDCODE 失败，id_list 始终为空，最终导致升级中断。

关键日志分析

根据提供的日志信息，核心问题出现在以下流程中：

1. 升级阶段执行正常

[on_upgrade_prepare] start upgrade BP_Cpld
[cpld]Start the system[1] BP_Cpld prepare phase
...
[on upgrade process] start upgrade BP_Cpld
[cpld]Start the system[1] BP_Cpld upgrade process phase

升级流程已正确触发，BP_Cpld 固件类型识别无误。
固件包签名验证、解析等前置步骤成功完成。

2. 固件匹配成功

cpld fw matched, system id = 1, fw.uid = 00000001020302041496, fw.csr.Name = BCU_CPLD1
[cpld]get cpld packages successful

HPM 包中的固件与目标设备（BCU_CPLD1）成功匹配。
固件文件已正确加载。

3. 关键失败点：无法获取CPLD设备信息

[cpld]____load_cpld_multi_supplier_mode____
[cpld]get cpld device info failed

用户对 drivers_api.lua 中 get_cpld_device_info 函数增加了调试日志后发现：

[cpld]pcall ok: true
[cpld]id_list length:

pcall 执行成功（返回 ok: true），说明 Lua 调用未抛异常。
但 id_list 为空表（#id_list = 0），表明底层驱动调用 getChipIdcode() 返回了空列表。

根本原因分析

驱动调用路径清晰

general_hardware 模块通过 unit_manager 管理 CPLD 升级。

调用链为：

upgrade_subject → process.lua → drivers_api.lua → chip_info:getChipIdcode()

getChipIdcode() 是通过 hwproxy 服务访问底层硬件芯片的接口。

问题定位：JTAG 链路通信失败

id_list 为空表明 BMC 无法通过 JTAG 链路读取到任何 CPLD 芯片的 IDCODE。可能原因如下：

可能原因	分析说明	是否支持
1. 硬件链路不通（JTAG或LocalBus）	若 JTAG 总线未正确连通，或中间模拟开关未切换至 BMC 控制路径，则无法访问 CPLD。且用户提供的电路设计图显示使用了模拟开关，若控制逻辑未正确配置，BMC 将无法接管 JTAG 通路。	高可能性
2. CSR 配置错误	`Smc` 或 `Cpld` 对象的 CSR 配置中，若 `BusType`、`Address`、`Channel` 等参数错误，会导致 `hwproxy` 找不到正确的通信路径。例如，应配置为 `LocalBus` 而非 `I2C` 或 `JTAG` 直连。	需检查
3. CPLD 芯片未上电或处于复位状态	在升级过程中，若目标 CPLD 未正常供电或处于复位态，则无法响应 JTAG 指令。	可能
4. 多供应商模式兼容性问题	日志显示调用的是 `load_cpld_multi_supplier_mode`，该模式依赖精确的 IDCODE 匹配。若实际硬件 IDCODE 与 CSR 中定义不符，也可能导致识别失败。	但不应导致 id_list 为空

结论

升级失败的根本原因是：BMC 无法通过 JTAG 链路读取到 CPLD 的 IDCODE，id_list 返回为空，导致驱动判定无目标设备，升级中止。

这通常由以下两个主要原因之一引起：

硬件链路问题：JTAG 通路被模拟开关阻断，或 LocalBus 配置错误，导致 BMC 与 CPLD 之间通信链路不通。
CSR 配置错误：未正确配置 Cpld 或 Smc 组件的通信通道（BusType=LocalBus）、地址、通道号等参数。

解决方案建议

1. 检查并确保 JTAG 通路已切换至 BMC 控制

根据电路图，确认 模拟开关 的控制信号已由 BMC 正确拉高/拉低，使 JTAG 通路连接到 BMC 侧。
建议使用示波器或逻辑分析仪验证 JTAG_TMS、TCK、TDI 等信号是否正常。
可尝试手动下发命令强制切换通路（如有提供 API）。

2. 核查 CSR 中 Cpld 组件配置

确保 Cpld 对象的 CSR 配置正确，关键字段如下：

{
  Name = "BCU_CPLD1",
  BusType = "LocalBus",        -- 必须为 LocalBus
  Channel = 1,                 -- 对应 LocalBus 编号
  Address = 0x96,              -- I2C 地址（如通过 SMC 协议访问）
  ChipType = "CPLD",
  Protocol = "SMC",            -- 推荐使用 SMC 协议
  Supported = true,
  BaseOffset = "expr(0x100)",  -- 如用于汇聚访问
}

特别注意：若使用天池架构，推荐使用 SMC 协议 + LocalBus 与 CPLD 通信，而非直接 JTAG。

3. 验证硬件上电状态

确认目标 CPLD 已正常上电，无短路或电源异常。
检查复位信号是否释放。

4. 捕获并分析完整日志

收集完整的 app.log 和 ipmi.log，重点关注 hwproxy 模块是否有 I2C/JTAG 通信失败记录。

查找类似错误：

read failed: i2c.lua:117: response error
ioctl(CPLD_CMD_LOAD_CPLD) failed: 21

5. 参考类似问题解决方案

根据知识库中 “硬盘背板CPLD升级报错” 案例（topic_id=1977）：

“630版本升级失败的原因是因为硬件链路不通，330版本上升级没有报错，是因为软件没有检测这类错误，实际升级未生效。通过更换硬件，问题已解决。”

说明此类问题在新版本中因增强了链路检测而暴露出来，旧版本可能“静默失败”。

总结

项目	内容
问题现象	Web 升级 CPU 模组 CPLD 失败，进度 95%，`id_list` 为空
直接原因	`getChipIdcode()` 返回空列表，无法识别 CPLD 设备
根本原因	JTAG/LocalBus 通信链路异常或 CSR 配置错误
解决方案	① 检查模拟开关通路；② 核对 CSR 配置；③ 验证硬件状态
风险提示	若链路不通，即使固件签名验证成功，实际写入也不会生效

建议操作顺序：

检查并确认 JTAG 模拟开关控制逻辑正确；
核实 CSR 中 Cpld 和 Smc 配置；
使用 ipmitool 或调试命令测试底层通信；
若仍失败，建议抓取 i2c-tool 或 jtag-tool 层面的底层通信日志进一步分析。

如需，可提供典型 CSR 配置模板用于比对。

lisongwei · 2026 年3 月 4 日 06:42

首先log的使用方法有问题，这个是格式化打印函数，应当为log:notice(‘[cpld]pcall ok: %s’, ok)''这样。

其次如果确认此处的pcall有问题，建议先检查一下chip_info的配置是否正确。该变量来自于CSR文件中LogicFirmware对象的ChipInfo属性，检查下该属性是否正确配置。

xuzhijia · 2026 年3 月 4 日 07:04

id_list确实为空

目前配置ChipInfo配置的为JtagOverLocalBus_1下的Cpld_1,其他配置也均已列出，现在id_list为空，也就是说可能是Cpld_1的链路配置错误？

“JtagOverLocalBus_1”: {
“Chips”: [
“Cpld_1”
]
}

“Cpld_1”: {
“HealthStatus”: 0
},
“LogicFirmware_BCU_1”: {
“UId”: “00000001020302041496”,
“Name”: “BCU_CPLD1”,
“Manufacturer”: “Huawei”,
“Version”: “#/Accessor_LogicVerId.Value”,
“Location”: 6288,
“UpgradeChip”: “#/Cpld_1”,
“ChipInfo”: “#/Cpld_1”,
“Routes”: “#/Accessor_JtagSwitch.Value”,
“DefaultRoute”: 0,
“FirmwareRoute”: 1,
“ValidMode”: 0,
“ValidAction”: 0,
“SoftwareId”: “CPLD-BC82AMDT”
},
“LogicFirmware_BCU_2”: {
“Name”: “BCU_CPLD2”,
“Manufacturer”: “Huawei”,
“Version”: “#/Accessor_Cpld2VersionID.Value”,
“Location”: 6293,
“UpgradeChip”: “#/Cpld_1”,
“ChipInfo”: “#/Cpld_1”,
“Routes”: “#/Accessor_JtagSwitch.Value”,
“DefaultRoute”: 0,
“FirmwareRoute”: 2,
“SoftwareId”: “CPLD-BC82AMDT”
},
“Accessor_JtagSwitch”: {
“Chip”: “#/Smc_ExpBoardSMC”,
“Offset”: 469776896,
“Size”: 1,
“Mask”: 255,
“Type”: 0,
“Value”: 0
},

lisongwei · 2026 年3 月 4 日 08:09

GetChipIdCode正常执行了，但是返回结果为空。可能的情况有两种：CSR中配置的硬件链路不正确（例如JtagOverLocalBus_0/JtagOverLocalBus_1这种），或者硬件链路本身异常，需要排查一下

排查后可以使用这个命令直接调用GetChipIdCode接口检查结果：
mdbctl call Cpld_1_010101 bmc.kepler.Chip.JtagTarget GetChipIdcode 0（将Cpld_xxxx换成对应的器件）

xuzhijia · 2026 年5 月 29 日 09:35

你好，现在是调用该方法CPLD_1_010101为空，CPLD_1_0101为35899，这说明了什么问题？

hardware全部升级日志如下


2000-01-01 00:16:22.417066 general_hardware NOTICE: upgrade_subject.lua(63): [on_upgrade_prepare] firmware_type:BP_Cpld cur_firmware_type:BP_Cpld
2000-01-01 00:16:22.417288 general_hardware NOTICE: upgrade_subject.lua(71): [on_upgrade_prepare] start upgrade BP_Cpld
2000-01-01 00:16:22.417459 general_hardware NOTICE: signal.lua(100): [cpld]Start the system[1] BP_Cpld upgrade prepare phase
2000-01-01 00:16:22.520021 general_hardware NOTICE: upgrade_subject.lua(78): [on_upgrade_prepare] end upgrade BP_Cpld
2000-01-01 00:16:22.529659 general_hardware NOTICE: fw_upgrade.lua(118): [cpld]get cpld_valid :nil
2000-01-01 00:16:22.530430 general_hardware NOTICE: fw_upgrade.lua(53): cpld cold upgrade, upgrade list = 1,
2000-01-01 00:16:22.531246 general_hardware NOTICE: fw_cfgs.lua(70): check fw uid(00000001020302041496) id(255) id_ex(4294967295) exist success
2000-01-01 00:16:22.886038 general_hardware NOTICE: fw_init.lua(163): get fw version 1.01
2000-01-01 00:16:22.886244 general_hardware NOTICE: fw_upgrade.lua(95): [cpld]get verion[1.01]
2000-01-01 00:16:24.079968 general_hardware NOTICE: upgrade_subject.lua(88): [on_upgrade_process] start upgrade BP_Cpld
2000-01-01 00:16:24.081265 general_hardware NOTICE: signal.lua(121): [cpld]Start the system[1] BP_Cpld upgrade process phase
2000-01-01 00:16:24.179300 general_hardware NOTICE: upgrade_subject.lua(95): [on_upgrade_process] end upgrade BP_Cpld
2000-01-01 00:16:24.179820 general_hardware NOTICE: fw_cfgs.lua(70): check fw uid(00000001020302041496) id(255) id_ex(4294967295) exist success
2000-01-01 00:16:24.180097 general_hardware NOTICE: process.lua(38): cpld fw matched, system_id = 1, fw.uid = 00000001020302041496, fw.csr.Name = BCU_CPLD1
2000-01-01 00:16:24.258169 hardware ERROR: tar.c(664): __extract_file: lchown on file(cpld01.vme) failed!
2000-01-01 00:16:24.259773 hardware ERROR: tar.c(664): __extract_file: lchown on file(valid01.vme) failed!
2000-01-01 00:16:24.261039 hardware ERROR: tar.c(664): __extract_file: lchown on file(cpld02.vme) failed!
2000-01-01 00:16:24.262823 hardware ERROR: tar.c(664): __extract_file: lchown on file(valid02.vme) failed!
2000-01-01 00:16:24.302264 hardware ERROR: tar.c(664): __extract_file: lchown on file(cpld03.vme) failed!
2000-01-01 00:16:24.302900 hardware ERROR: tar.c(664): __extract_file: lchown on file(valid03.vme) failed!
2000-01-01 00:16:24.303333 general_hardware NOTICE: process.lua(295): [cpld]get cpld packages successful
2000-01-01 00:16:27.843131 general_hardware NOTICE: process.lua(201): [cpld]_____load_cpld_multi_supplier_mode_____
2000-01-01 00:16:39.166262 general_hardware NOTICE: process.lua(179): [cpld]get cpld device info failed

现在仍然是[cpld]get cpld device info failed，但多了 tar.c(664): __extract_file: lchown on file(cpld01.vme) failed!的报错

话题		回复	浏览量
在线升级CPU模组CPLD失败 lchown on file failed 交流互助区提问求助	5	85	2026 年6 月 1 日
CPLD固件更新失败问题咨询交流互助区提问求助	4	220	2025 年6 月 16 日
bmc插卡为非天池架构时，EXU升级主板CPLD报错问题求助交流互助区提问求助	5	243	2025 年6 月 28 日
【升级基础板CPLD卡在47%】 Hardware SIG 提问求助	3	75	2026 年6 月 20 日
硬盘背板CPLD升级在Prepare阶段失败交流互助区提问求助	2	22	2026 年7 月 27 日

CPU模组在线升级CPLD失败

问题描述

环境信息

尝试过的解决方案

结论

解决方案建议

1. 检查并确保 JTAG 通路已切换至 BMC 控制

2. 核查 CSR 中 Cpld 组件配置

3. 验证硬件上电状态

4. 捕获并分析完整日志

5. 参考类似问题解决方案

总结

CPU模组在线升级CPLD失败问题分析报告

问题概述

关键日志分析

1. 升级阶段执行正常

2. 固件匹配成功

3. 关键失败点：无法获取CPLD设备信息

根本原因分析

驱动调用路径清晰

问题定位：JTAG 链路通信失败

结论

解决方案建议

1. 检查并确保 JTAG 通路已切换至 BMC 控制

2. 核查 CSR 中 Cpld 组件配置

3. 验证硬件上电状态

4. 捕获并分析完整日志

5. 参考类似问题解决方案

总结

相关话题