BMC升级CSR卡在31%失败

交流互助区
2

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

结论

本次BMC升级CSR卡在31%失败的根本原因是BMC与IEU Riser卡之间的EEPROM写入通信失败，具体表现为ioctl(HISPORT_CMD_WRITE) failed错误。最有效且已被验证的解决方案是执行AC断电重启后再尝试升级。此问题属于典型的硬件链路状态残留导致的通信异常，在OpenUBMC系统升级中具有一定普遍性。

:pushpin: 最终建议操作顺序：
断电重启 → 检查通道状态 → 重新升级，即可大概率解决问题。

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

BMC升级CSR卡在31%失败问题分析与解决方案

问题概述

在对BMC进行CSR（Component Self-Description Record）升级时，升级过程卡在31%并最终失败。根据提供的日志信息，该问题发生在软件版本为OpenUBMC2509的环境中，通过SSH执行ipmctset -d upgrade命令进行升级时出现。

核心错误分析

主要错误日志

2026-02-12 06:59:27.415699 general_hardware ERROR: sr_upgrade.lua(180): [SRUpgrade] chip write error: BMC.Error.Unknow: ... chip: Eeprom_IEU_01010103, bus: Hisport_18, write failed: hisport.lua:94: response error, ioctl(HISPORT_CMD_WRITE) failed: Unknown error 290, write protect: 0
2026-02-12 06:59:33.832474 general_hardware ERROR: sr_upgrade.lua(233): [SRUpgrade] :write_header failed
...
2026-02-12 06:59:49.602143 general_hardware ERROR: sr_upgrade.lua(310): [SRUpgrade] upgrade failed, uid: 00000001040302044499
2026-02-12 06:59:49.608740 firmware_mgmt ERROR: control.lua(201): Upgrade HWSR process failed, ret=-1

错误类型解析

BMC.Error.Unknow 错误：

  • 这是一个通用错误代码，表示BMC系统在操作过程中遇到了未知或未分类的错误条件。
  • 在本次场景中，该错误明确指向了EEPROM写入失败的问题。

ioctl(HISPORT_CMD_WRITE) failed: Unknown error 290：

  • 表明在尝试通过Hisport总线向EEPROM写入数据时发生了底层通信故障。
  • 错误290具体指代硬件层面的I/O操作失败。

问题根本原因

基于知识图谱和日志数据分析，本次升级失败的根本原因如下：

1. 硬件通信链路问题

  • 直接原因：系统无法成功向Eeprom_IEU_01010103设备的Hisport_18总线写入数据。
  • 潜在因素：
    • I2C/HISPORT总线通信不稳定或中断
    • 目标EEPROM硬件故障或接触不良
    • 总线地址冲突或设备未正确识别

2. 通道状态配置问题

根据知识库中类似问题的分析，可能存在如下情况：

  • 在混合使用不同版本固件时，I2C通道的控制权可能不在BMC侧。
  • 当BMC尝试访问EEPROM时，若通道仍由MCU控制（通道状态为0），而BMC未先执行切换操作，则会导致访问失败。
  • 特别是在从老版本升级到新版本后又降级的情况下，容易出现此类通道状态不一致问题。

3. 写保护机制异常

虽然日志显示write protect: 0（写保护关闭），但实际硬件层面可能仍存在写保护状态，导致写入操作被拒绝。

解决方案与建议

:white_check_mark: 方案一：断电重启后再升级（推荐）

这是已在类似案例中被验证有效的解决方案。

# 执行硬重启（AC Cycle）
1. 关闭设备电源
2. 等待10-15秒
3. 重新上电启动
4. 重新尝试CSR升级

原理：

  • 断电可重置所有硬件模块的状态，包括MCU、BMC和I2C总线控制器。
  • 确保I2C通道恢复到初始状态，避免残留状态导致通信失败。
  • 类似问题（如ID Upgrade BP_Cpld Process Failure）已通过此方法成功解决。

:white_check_mark: 方案二：检查并手动切换I2C通道状态

如果断电重启无效，可尝试手动检查并设置通道状态：

# 查询当前通道状态（示例命令）
mdbctl call Chip_MCU1_01010103 bmc.kepler.Chip.BlockIO ComboWriteRead 0 0x20 0x0e 0x0c 0x80 0x00 0x02 0x02 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x59 0x21 40

# 若通道不在BMC侧（状态非1），则手动切换至BMC侧
mdbctl call Chip_MCU1_01010103 bmc.kepler.Chip.BlockIO ComboWriteRead 0 0x20 0x0f 0x0d 0x80 0x00 0x01 0x02 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x01 0x4b 0x21 40

注意：具体命令参数需根据实际硬件架构调整。

:white_check_mark: 方案三：确认EEPROM健康状态

  1. 使用工具检测目标EEPROM是否在线：

    # 检查设备是否存在
i2cdetect -y <bus_number>

  2. 验证EEPROM可读性：

    # 读取EEPROM头部信息
dd if=/sys/bus/i2c/devices/<device>/eeprom bs=1 count=128

  3. 若读取失败，考虑硬件连接问题或EEPROM损坏。

:white_check_mark: 方案四：验证固件包完整性与兼容性

确保使用的CSR HPM包：

  • 是针对当前硬件平台（如S920X20）正确构建的
  • 经过正确签名且未损坏
  • 与当前BMC固件版本（OpenUBMC2509）兼容

可通过以下方式验证：

# 检查文件大小和MD5校验和
md5sum /tmp/csral1.hpm

# 确保/tmp目录有足够空间（至少2倍于包大小）
df -h /tmp

预防措施与最佳实践

措施 说明
升级前断电重启 建议在任何固件升级前执行AC Cycle，确保系统处于一致状态
避免跨版本跳跃升级 尤其是从老版本5.5升级后再降级，易引发通道状态混乱
保持通道状态监控 开发阶段应定期检查I2C通道归属状态
日志分析先行 出现write_header failed和BMC.Error.Unknow组合时，优先排查硬件通信问题

结论

本次BMC升级CSR卡在31%失败的根本原因是BMC与IEU Riser卡之间的EEPROM写入通信失败，具体表现为ioctl(HISPORT_CMD_WRITE) failed错误。最有效且已被验证的解决方案是执行AC断电重启后再尝试升级。此问题属于典型的硬件链路状态残留导致的通信异常，在OpenUBMC系统升级中具有一定普遍性。

:pushpin: 最终建议操作顺序：
断电重启 → 检查通道状态 → 重新升级，即可大概率解决问题。

相关链接：

  1. 升级CSR ALL包时，00000001040302044498 IEU Riser CSR升级失败
  2. 2512LTS 版本升级问题
  3. 升级白牌包到5%失败
  4. bmc是否支持无感升级