bingo build产生的csr和psr hpm包升级后一键日志connector获取不到数据

[weixin_41256007 (baixin_lipengbo)]

问题描述

使用bingo build编译CSR和PSR文件生成hpm升级包，BMC升级后发现CSR和PSR正常生效，但是一键日志中hwdicovery看不到加载的CSR以及PSR

环境信息

• 操作系统：无关

• 软件版本：OpenUBMC2512

重现步骤

在文件夹中放入要编译的CSR以及PSR文件，使用bingo build命令编译生成hpm包，在openUBMC升级界面升级hpm包

期望结果

一键日志中能够看到生效的CSR以及PSR文件

实际结果

CSR以及PSR的hpm包正常生效了，但是一键日志中hwdicovery下Connector_PSR_EEP_0101.sr内容为空

查看connectors.txt中加载路径发现并不是从bin文件加载，而是设备树对象

请问通过bingo build编译的CSR和PSR的hpm包是否存在什么缺陷，这种方式是否可行还是说要通过其他方式生成CSR和PSR的hpm包？

[ubmc_assistant (openUBMC_Assistant)]

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

项目	结论
bingo build 有缺陷吗？	否，构建过程正常
.sr 文件升上去了吗？	很可能已写入文件系统
为什么 dump 中为空？	因为系统从 EEPROM 加载，hwdiscovery 未将 EEPROM 数据回写到 dump 文件
如何解决？	提高 .sr 中 DataVersion，确保 DataSource=LOCAL，让系统真正加载本地文件

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

关于 bingo build 生成的 CSR 和 PSR HPM 包升级后无法在一键日志中查看数据的问题分析

根据您的问题描述，您使用 bingo build 编译 CSR 和 PSR 文件生成 HPM 升级包，并成功升级 BMC 固件。虽然 CSR 和 PSR 功能正常生效，但在一键日志的 hwdiscovery 模块中无法看到 Connector_PSR_EEP_0101.sr 的内容，且该文件大小为 0 KB，同时 connectors.txt 显示其数据源为设备树对象（如 /bmc/kepler/Chip/Eeprom/Eeprom_3_10_0101）而非 BIN 文件。以下是对此现象的详细分析与解答。

---

问题总结

项目	信息
操作	使用 bingo build 将 .sr 文件编译为 HPM 包并升级
预期结果	在一键日志中 AppDump/hwdiscovery/ 能查看到完整的 .sr 配置数据
实际结果	.sr 文件存在但为空（0 KB），且数据源来自 EEPROM/设备树，而非本地 BIN 或 SR 文件
关键线索	connectors.txt 中 DataSource: EEPROM，SourcePath 指向设备树路径而非文件系统路径

---

核心结论

bingo build 生成的 HPM 包本身无缺陷，但 CSR/PSR 文件是否写入文件系统并被 hwdiscovery 正确保存，取决于构建时的配置逻辑和 CSR 加载策略，而不完全由 bingo build 决定。

因此，此问题不是 bingo build 的缺陷，而是 CSR 数据来源优先级与日志导出机制的匹配问题。

---

详细分析

1. 为什么 CSR/PSR 功能正常但日志看不到内容？

• CSR 已加载并生效：说明升级成功，hpm 包已正确应用，系统运行时使用了新的配置。
• connector_PSR_EEP_0101.sr 为空（0KB）：表明 hwdiscovery 组件并未将 EEPROM 中加载的 SR 数据反向写入到 dump 目录中。

原因：
hwdiscovery 仅在特定条件下将加载成功的 SR 数据备份到 /data/opt/bmc/sr/backup/ 目录，并在一键日志中导出。
若 SR 数据直接从 EEPROM 或设备树对象 加载（即 DataSource: EEPROM），默认行为不会生成对应 .sr 文件到文件系统中用于 dump，导致日志中该文件为空。

---

2. connectors.txt 中为何 SourcePath 是设备树路径？

-SourcePath : /bmc/kepler/Chip/Eeprom/Eeprom_3_10_0101
-DataSource : EEPROM

这表明：

• Connector_PSR_EEP_0101 的数据来源是 硬件 EEPROM 芯片或其模拟对象（设备树），而不是 /opt/bmc/sr/*.sr 下的本地文件。
• 这意味着系统优先加载了 EEPROM 中的 CSRs，而不是 HPM 包中内置的 .sr 文件。

hwdiscovery 的加载策略：
根据 《硬件自发现FAQ》 中的“CSR 版本比较”原则：

在格式版本兼容范围内，比较数据版本（DataVersion），选择较新的作为实际加载源。

因此，即使你用 HPM 包写入了一个 .sr 文件，如果 EEPROM 中的 DataVersion 更高，系统仍会优先加载 EEPROM 数据，并忽略 HPM 包中的版本，从而导致 dump 中无文件内容。

---

3. bingo build 是否应该负责生成可用于日志查看的 .sr 文件？

是的，但有前提条件。

• bingo build 会将 .sr 文件打包进 HPM 包，并在升级过程中写入文件系统（如 /opt/bmc/sr/）。
• 但 hwdiscovery 是否将其“识别为本地 SR 文件并用于 dump 输出”，取决于以下因素：

条件	是否影响 dump 输出
LoadStatus == 1	要求 connector 已启用
DataSource == LOCAL	必须为本地文件源才能触发 dump 写入
LocalDataVersion > EEPROM 版本	确保本地文件被真正加载
SourcePath 指向磁盘路径（如 /opt/bmc/sr/*.sr）	必须是文件系统路径

否则，即使 .sr 文件已被写入磁盘，只要未被 实际加载为 LOCAL 数据源，hwdiscovery 就不会将其输出到 connectors.txt 或 dump 中。

---

解决方案与建议

方案一：强制使用本地 .sr 文件作为数据源（推荐）

确保你的 PSR 配置满足以下条件：

1. 设置 DataSource 为 LOCAL
2. SourcePath 指向 /opt/bmc/sr/ 下的 .sr 文件
3. 确保 .sr 的 DataVersion 高于 EEPROM 中的版本

操作步骤：

1. 修改你的 .sr 文件中 DataVersion 字段，例如设为 "3.99"

   {
     "FormatVersion": "3.00",
     "DataVersion": "3.99",
     ...
   }
   

2. 确保 Connector_PSR_EEP_0101 在配置中：

   -DataSource: LOCAL
   -SourcePath: /opt/bmc/sr/14100513_000000010402315MYK.sr
   

3. 使用 bingo build 重新打包并升级。

4. 升级后检查：

   cat /var/log/framework.log | grep "start to process sr data"
   

   应显示加载路径为 /opt/bmc/sr/...，而非 EEPROM。

---

方案二：检查并清理旧的 EEPROM 数据（调试用）

如果你不确定 EEPROM 中的内容，请先清除或更新它。

注意：此操作需谨慎，可能影响板卡识别。

# 查看当前 EEPROM 加载情况（需有权访问 eeprom 接口）
cat /var/log/framework.log | grep -i eeprom

# （高级）若允许，可通过 i2c 工具擦除指定 EEPROM 区域
# 如：i2cset -y 8 0x50 0x00 0x00

---

方案三：确认 HPM 包中是否包含 .sr 文件

检查生成的 HPM 包是否真正包含了你的 .sr 文件：

# 解压 HPM 包（HPM 实质为 CPIO 包）
mkdir hpm_extract && cd hpm_extract
cp ../your_package.CSR.hpm .
uncompress_hpm.sh your_package.CSR.hpm  # 假设有工具支持
find . -name "*.sr" | xargs ls -l

如未包含，请检查 bingo build 构建时的工作目录结构是否符合规范：

/some_dir/
├── Connector_PSR_EEP_0101.sr
└── bingo build

---

是否 bingo build 存在缺陷？

不存在根本性缺陷。

• bingo build 成功将 .sr 文件编译进 HPM 包，这是它的核心功能之一。
• 但它 不控制运行时加载逻辑，也不保证 hwdiscovery 一定会将加载的 SR 内容导出到一键日志。
• 加载源的选择由 hwdiscovery 组件根据 LoadStatus、DataSource 和 DataVersion 决定。

因此，当前问题是 配置优先级设置不当 或 未理解 SR 加载机制 所致，而非构建工具的问题。

---

参考资料与建议

1. 阅读文档：

   • 《硬件自发现FAQ》 中的 “CSR 版本比较”原则
   • connectors.txt 文件格式说明

2. 查看运行日志验证加载源：

   grep "process sr data" /var/log/framework.log
   

   输出示例：

   start to process sr data, source: /opt/bmc/sr/14100513_xxxx.sr, data version: 3.99
   

   表示已从本地文件加载成功。

3. 建议开发实践中：

   • 对于调试和日志采集场景，显式设置 DataSource=LOCAL 并提高 DataVersion
   • 避免依赖默认的 EEPROM 自动优先策略
   • 使用 BMC Studio 批量导出时选择“包括文件系统 SR”选项（如有）

---

总结

项目	结论
bingo build 有缺陷吗？	否，构建过程正常
.sr 文件升上去了吗？	很可能已写入文件系统
为什么 dump 中为空？	因为系统从 EEPROM 加载，hwdiscovery 未将 EEPROM 数据回写到 dump 文件
如何解决？	提高 .sr 中 DataVersion，确保 DataSource=LOCAL，让系统真正加载本地文件

---

最终建议：

请修改 Connector_PSR_EEP_0101.sr 文件中的 DataVersion 至高于当前 EEPROM 的版本（如 "3.99"），并确保 connectors.txt 或 MDS 定义中指向正确的文件路径，再重新打包升级，即可在一键日志中看到完整内容。

如有进一步日志（如 framework.log 输出），可进一步定位加载路径选择逻辑。

[m0_64526648 (masiyu)]

你好，这个跟bingo build的hpm包无关，跟sr文件的加载逻辑有关。这个connector的数据来源是从eeprom里面读取的，麻烦确认下升级的csr版本和eeprom内置版本，确定文件是否生效

[weixin_41256007 (baixin_lipengbo)]

升级的sr hpm包是生效的，我理解升级hpm包是写入eeprom，然后bmc从eeprom中读取成功了，通常在一键日志中看到的sr bin文件应该就是eeprom内置版本吧，升级hpm包写入eeprom会覆盖天池组件eeprom中内置的sr吗？

[huangzhiyu]

同时有Eeprom的sr和内置sr，加载内置sr的场景下，Eeprom的版本会覆盖内置sr的版本，但内容还是使用内置的

[huangzhiyu]

看你截的图没有内置sr，可能是加载Eeprom 的 sr有报错，可以检查下framework.log或hw_stream.log内hwdiscovery的日志，可能有硬件访问失败导致没加载的问题

[ocy (wuzhou-ouchangyun)]

通过hpm包升级eeprom里面的sr，是会覆盖目标组件eeprom的内容的，eeprom目前也只能存放一份sr，升级完后，可以通过mdbctl直接在读取一下eeprom内容，就知道是不是真的刷新成功

[weixin_41256007 (baixin_lipengbo)]

检查了一键日志中framework.log和hw_stream.log文件内容，没有看到相关报错，硬件访问应该是正常的，因为我升级的hpm包都是正常生效的，看了下一键日志收集的过程，可以看到三种方式，我升级的PSR不是从backup目录下拷贝的bin文件，而是直接从设备树eeprom对象读取的（显然dump失败了，一键日志中没有内容）

[huangzhiyu]

有加载这个Connector相关的日志吗？以及试试能否从环境上直接读取Eeprom数据

[huangzhiyu]

你们bingo出包的时候有配置签名吗？

[weixin_41256007 (baixin_lipengbo)]

没有配置签名

[huangzhiyu]

没配签名，bingo出的包签名区域数据应该是全0，自发现加载的时候会加载，但不会备份文件，也不会将文件导出到一键收集日志里