BCU显示的CSR data version不对

Hardware SIG
1

问题描述

BCU的connector使用天池方式加载，BCU的CSR文件中定义的format version: 3.00, data version: 3.00，实际在自发现阶段data version被EEPROM中的版本号覆盖了，导致版本信息显示不对。

环境信息

  • 操作系统：openEuler 2203 SP3

  • 软件版本：OpenUBMC2509

  • 硬件配置：鲲鹏920模组

期望结果

ipmcget -d v显示的BCU CSR版本与BMC固件中打包的CSR文件信息一致。

实际结果

ipmcget -d v显示的BCU CSR版本为EEPROM中的版本，为0.01。

framework.log日志中看到CSR版本号被更新：

1970-01-01 00:00:39.857483 hwdiscovery NOTICE: hwcomponent.lua(309): [self-discovery] name: Connector_BCU_1_0101, position: 010101, current: 1, previous: 0,uptime: 40 s
1970-01-01 00:00:40.056883 hwdiscovery NOTICE: init.lua(162): position: 010101, get csr data from /opt/bmc/sr/14100513_00000001020302066283.sr, format version: 3.00, data version: 3.00
1970-01-01 00:00:40.057649 hwdiscovery NOTICE: init.lua(318): position: 010101, Data version field 3 are replaced by Eeprom data version 0.01
1970-01-01 00:00:40.059328 hwdiscovery NOTICE: hwcomponent.lua(205): position: 010101, load sr data successfully, uptime: 41 s, cost: 150ms
1970-01-01 00:00:40.061347 hwdiscovery NOTICE: hwcomponent.lua(226): position: 010101, start to process sr data, source: /opt/bmc/sr/14100513_00000001020302066283.sr, format version: 3.00, data version: 0.01, uptime: 41 s
2

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

BCU显示的CSR Data Version不对的问题分析与解决方案

根据您提供的问题描述、环境信息和日志内容，该问题是由于 天池架构下 BCU 组件在硬件自发现过程中，其 CSR 的 Data Version 被 EEPROM 中的版本号覆盖 所致。以下是详细的分析与解决方案。

:magnifying_glass_tilted_left: 问题定位

:white_check_mark: 现象总结：

  • 期望结果：ipmcget -d v 显示的 BCU CSR 版本应为 BMC 固件中打包的 .sr 文件定义的版本（format version: 3.00, data version: 3.00）。
  • 实际结果：显示的 data version 为 0.01，与 EEPROM 中存储的版本一致。
  • 关键日志证据：
    hwdiscovery NOTICE: init.lua(318): position: 010101, Data version field 3 are replaced by Eeprom data version 0.01
hwdiscovery NOTICE: hwcomponent.lua(226): start to process sr data, source: ..., data version: 0.01

这表明：尽管加载的是 BMC 内置的 .sr 文件（来源 /opt/bmc/sr/*.sr），但其 Data Version 被主动替换成了 EEPROM 中的数据版本。

:puzzle_piece: 根本原因分析

1. 天池组件 CSR 加载策略机制

在 OpenUBMC 的硬件自发现框架中，对于“天池架构”组件（如 BCU、EXU 等），CSR 数据可能来自两个源：

  • 内置 CSR：位于 /opt/bmc/sr/ 目录下的 .sr 文件（随 BMC 固件打包）；
  • EEPROM CSR：存储在板卡 EEPROM 中的 CSR 数据（用于支持带外升级或现场维护）。

根据 《硬件自发现CSR选择策略》文档（ID: 4）：

“如果来源为 Local（即内置 CSR），且为天池组件，那么对外显示的数据版本将会被 Eeprom 的数据版本替换”，但“实际生效的是内置 CSR 的数据”。

这意味着：

  • 配置内容 取自 BMC 内置 .sr 文件（功能正确）；
  • 版本显示（Data Version） 却取自 EEPROM（导致 ipmcget -d v 显示异常）；

该行为是系统有意设计的行为，目的是反映硬件侧真实烧录的配置版本状态，但在调试或版本一致性要求高的场景下会导致误解。

2. EEPROM 中 CSR 版本过旧

从日志 data version: 0.01 推断：

  • BCU 板卡的 EEPROM 中仍保留着旧版本的 CSR 元数据头（尤其是 Eeprom Header 中的 Data Version 字段）；
  • 即使升级了 BMC 固件并替换了 /opt/bmc/sr/ 下的 .sr 文件，EEPROM 未同步更新；
  • 自发现服务（hwdiscovery）读取到 EEPROM 中的 Data Version = 0.01 后，在展示层将其覆盖到最终资源树中。

:warning: 注意：这不影响功能逻辑，因为真正加载的 CSR 内容来自 .sr 文件，但仅版本号显示错误。

:hammer_and_wrench: 解决方案

:white_check_mark: 方案一：同步更新 BCU 板卡 EEPROM 中的 CSR 版本（推荐）

确保 EEPROM 中的 CSR 元信息与 BMC 固件中的一致。

步骤如下：

  1. 准备新的 CSR HPM 升级包

    • 使用 BMC Studio 工具导出新的 CSR 文件；
    • 将 .sr 文件打包成 HPM 格式升级包；
    • 在打包时确保 Data Version 设置为 3.00。

  2. 烧录到 BCU 板卡的 EEPROM

    • 通过命令行或工具下发 HPM 包升级 BCU 的 CSR；
    • 或使用 conman 或 D-Bus 接口调用 SRUpgrade 流程完成升级。
    # 示例：调用升级（具体路径视环境而定）
busctl call bmc.kepler.upgrade /bmc/kepler/SRUpgrade bmc.kepler.SRUpgrade StartUpgrade

  3. 验证 EEPROM 更新成功

    • 重启系统后，检查日志是否还有 replaced by Eeprom data version 0.01；
    • 使用工具读取 EEPROM 偏移地址中的 Eeprom Header，确认 Data Version 已更新。

:white_check_mark: 方案二：临时通过调试方式强制使用内置版本号（仅限测试）

若仅为调试目的，希望 ipmcget 显示内置 .sr 文件的版本，可通过以下方式绕过覆盖逻辑。

方法：修改 csr_version.json 配置

csr_version.json 是决定内置 CSR 版本管理的关键文件（路径：/opt/bmc/sr/csr_version.json）。

操作步骤：

  1. 编辑 /opt/bmc/sr/csr_version.json

    {
  "14100513_00000001020302066283": {
    "FormatVersion": "3.00",
    "DataVersion": "3.00",
    "Merged": true
  }
}

    :white_check_mark: 确保 DataVersion 至少不低于 EEPROM 中的值，且格式匹配。

  2. 重启 hwdiscovery 进程

    killall hwdiscovery
# 或
systemctl restart hwdiscovery

  3. 观察日志是否仍出现版本替换

    • 若 init.lua(318): Data version field ... replaced 日志消失，则修复成功。

:pushpin: 原理：当 hwdiscovery 组件版本 ≥ 1.60.5 时，若 csr_version.json 中存在记录，会以之为准，并可能跳过 EEPROM 版本覆盖逻辑。

:white_check_mark: 方案三：禁用 EEPROM 读取（仅用于定位问题）

临时禁用 EEPROM 访问，强制系统忽略 EEPROM 中的 CSR 版本。

操作：

# 禁用 I2C 总线（假设 BCU EEPROM 接在 I2c_1 上）
busctl call bmc.kepler.hwproxy /bmc/kepler/Bus/I2c/I2c_1 bmc.kepler.Bus SetAccessibility a{ss}bq 0 false 1800

:warning: 注意：这是破坏性操作，可能导致其他硬件识别异常，仅用于验证问题是出在 EEPROM。

:toolbox: 辅助诊断方法

1. 查看当前加载的 CSR 来源

在一键收集的日志包中：

dump_info/AppDump/hwdiscovery/
├── 14100513_00000001020302066283.sr    → 来源内置
└── xxxxxxxx_xxxxxxxx.bin               → 来源 EEPROM
  • .sr：表示加载自 BMC 内置；
  • .bin：表示来自 EEPROM。

2. 查询 CSR 版本显示字段含义

  • EffectiveDataVersion：实际对外显示的版本（可能被 EEPROM 覆盖）；
  • LocalDataVersion：内置 CSR 的原始版本；
  • EepromDataVersion：EEPROM 中读取的版本。

可通过 busctl 查询对应 Connector 对象属性验证。

:white_check_mark: 最佳实践建议

措施 说明
统一升级流程 升级 BMC 固件的同时，必须同步升级所有天池板卡 EEPROM 中的 CSR 信息。
版本一致性检查 发布前使用自动化脚本校验 /opt/bmc/sr/ 与 EEPROM 中的版本是否一致。
开发期启用调试模式 在 csr_version.json 中显式声明版本，避免 EEPROM 干扰调试结果。
文档化烧录流程 明确定义板卡生产/维护时 CSR 烧录的标准操作流程。

:books: 相关文档参考

:white_check_mark: 结论

:red_exclamation_mark: 本问题本质上是“显示不一致”，而非功能故障。

系统实际使用的是 BMC 内置 .sr 文件的配置（正确），但由于天池架构的版本继承机制，Data Version 显示被 EEPROM 覆盖。

:white_check_mark: 推荐解决路径：

  1. 使用 BMC Studio 制作包含新版 Data Version 的 CSR HPM 包；
  2. 升级 BCU 板卡 EEPROM 中的 CSR 数据；
  3. 验证 ipmcget -d v 输出为 3.00，问题解决。

如需长期避免此类问题，建议建立 BMC 与板卡 CSR 版本联动发布的机制。

相关链接：

  1. 关于板卡自发现是使用EEPROM中的SR还是使用BMC中的SR的问题
  2. 0.5.317版本的bmcgo，出BMC签名包失败问题
  3. 【教学培训篇】新增组件
  4. 【iTestSmart】ipmi查看计算板的CSR版本，测试结果Fail。
  5. 板卡适配指南 | 文档中心 | openUBMC
3

我理解设计就是这样的：
固件的版本号显示的是eeprom中的data_version；实际生效的则是data_version更高的那个。
这样设计应该是为了确认eeprom中的csr的版本，可以用来判断升级csr包是否升级成功。

4

仅版本显示会显示Eeprom里面的版本号。

实际生效的csr内容会以bmc内置和Eeprom里的CSR版本号更高的为准。

例如当前内置的版本号是3.00， Eeprom里面是0.01， 3.00 > 0.01，实际生效csr内容会以内置的为准，版本号显示Eeprom里面的版本号0.01。

可以通过一键收集日志AppDump/hwdiscovery目录里面的收集到的csr看到实际生效的版本