通过I2C方式升级安陆CPLD(型号EF2L5BG256B)问题汇总

gaoqh · 2026 年7 月 10 日 07:31

问题描述

一、当前进展：

客户采购的是安陆EF2L5BG256B型号，提供的BIN升级文件大小为160KB，执行到下方报错弹出。

把条件去掉后，执行，报错

write信息打印：

hexdump bin文件：

二、问题，请问

1、当前UBMC通过I2C升级CPLD，兼容的是安陆的哪些型号，SMC命令字需要配置哪些？

2、客户给的cmd是C1~C5，init.lua里定义的是1\2 ，这匹配么？是到hwproxy转换的么？

3、上面的报错如何解决？

环境信息

操作系统：
软件版本：OpenUBMC2512
硬件配置：

重现步骤

[第一步]
[第二步]
[第三步]

期望结果

[您希望实现什么]

实际结果

[实际发生了什么，包含错误信息]

尝试过的解决方案

[列出您已经尝试过的解决方案及结果]

分析结论

[详细总结您对此问题的分析结论]

ubmc_assistant · 2026 年7 月 10 日 07:41

答案内容由AI生成，仅供参考：
结论：目前无法确认匹配关系，建议直接调用iic_upgrade_cpld函数，避免手动组装命令；若必须使用特定命令，需查阅相关硬件手册或联系安陆技术支持。

总结：您遇到的报错大概率是升级链路配置错误（JTAG替代I2C）或CSR属性遗漏。按照上述步骤逐一排查，尤其优先核对UpdateLink和I2CUpgradeChip是否生效。

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

根据提供的知识库信息，现针对您提出的三个问题逐一分析解答。请注意，上下文并未涵盖安陆EF2L5BG256B型号的专属细节，以下内容均基于已知的通用I2C升级CPLD流程和相关故障案例。

1. 当前UBMC通过I2C升级CPLD兼容的安陆型号与SMC命令字配置

兼容型号

上下文多次提及“安陆cpld（Anlogic CPLD）”并确认openUBMC支持通过I2C对其进行升级。但未列出具体支持的型号清单，例如您提到的EF2L5BG256B是否已在兼容列表中，需查阅社区硬件兼容性列表或实际硬件验证。
升级可行性依赖于硬件I2C拓扑、CPLD自身是否支持I2C协议以及CSR（System Requirements）中正确配置相关属性。

SMC命令字配置

逻辑固件升级需要两步：获取厂商信息和执行I2C升级。
在LogicFirmware类配置中，需指定以下关键属性（来源：文档块1、9）：

属性	作用	配置示例
`SmcChip`	关联SMC芯片，IIC升级时用于获取CPLD厂商信息。	`"#/Smc_EnclSMC"`
`I2CUpgradeChip`	指定I2C链路上用于数据传输的Chip对象。	`"#/Chip_Cpld"`
`I2CUpgradeLockChip`	I2C总线锁对应的Chip对象。	`"#/Chip_Cpld"`

代码层面，通过iic_upgrade_cpld函数调度流程，其内部调用get_cpld_manufature获取制造商，然后根据制造商类型读取对应的bin文件（如cpld01.bin）并执行烧录。
您提到的“C1~C5”命令字，上下文中未出现相关定义或映射关系。HPM包内的update.cfg中通过update_link=1指定走I2C链路，其余命令交互由底层通用模块（如hwproxy）处理，但具体转换逻辑不在当前知识库范围内。

2. 客户提供的cmd（C1~C5）与init.lua中定义的1/2是否匹配及是否经hwproxy转换

当前上下文未找到直接证据

文档块4的日志中提到了init.lua(98)，但仅是上传文件的日志，无命令字定义。
社区讨论（文档块6）中指出，升级链路由HPM包中的update.cfg控制：update_link='1'进入I2C升级分支，否则走JTAG升级。关于命令字（如C1~C5）的映射，通常是在BMC固件或底层I2C驱动中完成，CSR配置层面不涉及。
您的截图显示init.lua里定义了1\2，可能是将上层命令转化为内部索引。但知识库没有记录hwproxy或类似转换模块的具体说明，建议检查以下两点：
1. 确认客户提供的命令格式是否与底层I2C驱动所需匹配（例如C1对应寄存器地址0xC1？）。
2. 参考iic_process.lua中的处理逻辑（文档块2），该脚本根据制造商类型选择不同的bin文件，但未显示对命令的显式转换。

结论：目前无法确认匹配关系，建议直接调用iic_upgrade_cpld函数，避免手动组装命令；若必须使用特定命令，需查阅相关硬件手册或联系安陆技术支持。

3. 报错如何解决

您提到的报错（图像未能显示）在上下文中有多个相似案例，归纳如下：

常见错误及根因

错误表现	可能原因	对应案例
升级到约47%时失败，`block写失败`	代码误入JTAG升级分支，`obj_fw.update_chip`等信息为`nil`。	文档块2（cpld采用i2c升级失败问题分析）
升级流程正常，但AC后版本未更新	CPLD自身时钟配置错误或版本包与实际硬件不匹配。	文档块5（I2C接口CPLD固件升级）
升级过程中无内核日志打印	I2C设备或总线锁配置不当。	文档块2

针对性解决方案

确认升级链路配置
- 检查HPM包内的update.cfg文件，必须设置UpdateLink=1，否则代码会走JTAG分支。
- 修改后重新打包进行升级。
核实SR（CSR）配置
- 在LogicFirmware对象中，确保使用I2CUpgradeChip（而非UpgradeChip），并正确关联I2CUpgradeLockChip和SmcChip。
- 参考文档块4中的正确示例：
```
"LogicFirmware_BCU_1": {
  "I2CUpgradeChip": "#/Chip_Cpld",
  "I2CUpgradeLockChip": "#/Chip_Cpld",
  "SmcChip": "#/Smc_EnclSMC",
  // ... 其他必要属性
}
```
检查I2C硬件参数
- 确认I2C地址、时序、超时设置与CPLD规格匹配。例如文档块4中Chip_Cpld配置了地址120（0x78）、地址宽度1、偏移宽度1等。
验证CPLD固件包完整性
- 如果升级流程已正确执行但版本未变，优先检查：
  - 包内bin文件是否正确（可通过校验和/签名确认）。
  - CPLD版本号是否与环境一致（避免重复升级相同版本）。
- 文档块5中得出结论为“CPLD版本中时钟配置有问题”，需与安陆确认该型号的固件配置是否适用于当前硬件修订。
启用详细日志
- 通过app.log和linux_kernel日志定位具体失败点。若obj_fw.update_chip.Write为nil，表明未正确加载I2C芯片对象，回溯上层配置。