2606构建1712版本升级，I2C_1不通

交流互助区
1

问题描述

使用社区2606分支构建1712版本，升级到环境之后发现BCU的SR未加载，定位发现I2C_1不通。

环境信息

  • RTOS：208.11.0.SPC0100

  • Linux kernel：5.10.0-60.18.0.50

  • hwproxy:1.120.11

  • hwdiscovery: 1.120.7

  • BMC SDK: 5.14.00.01

重现步骤

  1. 使用来料自带BMC版本，BCU的SR可以正常加载，I2C_1通信正常。

  2. 使用社区2606版本构建1712包，升级之后BCU的SR不能加载，I2C_1通信异常，I2C_1 总线后续持续出现 [I2C-01-RT<-11|-11>]

尝试过的解决方案

回退来料自带BMC版本没有问题，排除硬件I2C通信问题。

分析结论

怀疑hwproxy 1.120.11 与新 SDK/RTOS 的 I2C 访问接口兼容性问题。

S950X00_2102315RYU10S6100094_19700101-0800.tar (22.2 MB)

2

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

四、结论

根据现有上下文，无法直接给出唯一根因，但上述分析支持您对 hwproxy 与 SDK/RTOS 兼容性 的怀疑。同时，I2C 总线竞争、插件访问未释放、升级配置缺失（如 I2CUpgradeChip）也是需要重点排查的方向。建议结合完整日志和升级包内容，逐步确认到底是哪一层导致 I2C_1 通信失败。

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

根据您提供的问题描述和上下文中的知识库信息，以下是对**“2606构建1712版本升级后 I2C_1 不通”**问题的综合分析与排查建议。

一、问题定位

您的问题现象为：使用社区 2606 分支构建 1712 版本并升级后，BCU 的 SR 无法加载，定位发现 I2C_1 通信异常，且总线持续出现 [I2C-01-RT<-11|-11>] 错误。回退到原厂自带 BMC 版本后恢复正常，这已经排除了硬件层面的故障，基本可以确定问题与升级后的新软件版本（尤其是 hwproxy、SDK/RTOS 相关组件）存在关联。

二、结合知识库的可能原因分析

1. 总线被占用或竞争导致访问超时（可能性较高）

知识库中关于 hwproxy 插件访问的说明明确指出：

插件访问时会占据总线访问通道，此时其他的访问将无法发送，可能产生超时等情况。如果插件访问时间长，需评估对总线其他器件的影响。

在升级后的运行环境中，如果某些组件（如 storage 模块、power_mgmt 等）仍在持续占用 I2C_1 总线，就会导致其他设备（例如 BCU 的 SR 加载）无法正常通信。知识库中也有类似案例：在升级过程中，storage 模块大量占用 I2C 总线，导致升级失败。虽然您的问题是升级后持续不通，但总线占用未释放的机制是相似的。

此外，内核日志中出现的 -11 与知识库日志中 i2c.lua:120: response error, i2c read fail, ret: 11 高度相似，这可能意味着 I2C 访问被拒绝或超时，属于“总线无法让出”的典型表现。

2. hwproxy 与 SDK/RTOS 的 I2C 访问接口兼容性问题

您怀疑 hwproxy 1.120.11 与新 SDK/RTOS 的 I2C 访问接口存在兼容性问题，这与知识库中的信息并不矛盾。知识库提到 I2C Bus 本身容易受到瞬时干扰和信号竞争的影响，而在固件升级或高负载操作期间，这种问题更容易暴露。如果 hwproxy 在升级后对 I2C 底层接口的调用方式发生了变化，或者与 RTOS 版本不匹配，就可能出现 I2C_1 持续访问失败的情况。

3. 升级过程中缺少必要的 I2C 配置（如 I2CUpgradeChip）

知识库中有一条重要关系：

I2CUpgradeChip 是 I2C 升级所需的属性，但未配置。

如果本次升级涉及 I2C 链路上的设备（例如 CPLD 或其他芯片）更新，但新版本代码路径中缺少 I2CUpgradeChip 配置，则可能导致升级后 I2C 相关功能异常。这需要结合您的升级包是否包含 I2C 升级步骤来判断。

4. CSR 配置或拓扑数据不完整

知识库中提到，CSR 配置主要用于配置 topo 数据，不会直接控制底层 I2C 电平高低。但如果您的新版本构建中 CSR 配置或拓扑数据与 1712 硬件不匹配，可能导致 BCU 的 SR 无法被发现，间接表现为 I2C_1 通信异常。

三、进一步排查建议

  1. 检查升级后的系统日志
    重点查看 hwproxy 和内核日志中是否出现类似以下错误：

    • i2c.lua:120: response error, i2c read fail, ret: 11
    • PluginRequestEx 超时（例如 used time[102s]）
    • [I2C-01-RT<-11|-11>] 持续打印

  2. 确认是否有组件在持续占用 I2C_1 总线
    观察日志中请求来源（如 bmc.kepler.power_mgmt、storage 模块等），判断是否有后台任务长时间占用总线。可使用调试手段查看当前 I2C 总线的持有者。

  3. 检查 BCU SR 加载所依赖的拓扑配置
    确认新版本的 CSR 配置和拓扑数据是否完整覆盖 BCU 设备，必要时对比原厂 BMC 版本的配置差异。

  4. 验证 I2C 升级链路相关配置
    如果升级过程包含 I2C 固件更新，请确认代码路径中是否已正确配置 I2CUpgradeChip，避免因缺少该属性导致升级后功能异常。

  5. 尝试更换 hwproxy 版本或回退方案
    由于回退原厂版本即可恢复，说明软件兼容性是核心疑点。建议在测试环境中尝试不同版本的 hwproxy 或 SDK/RTOS 组合，以定位具体不兼容的组件。

四、结论

根据现有上下文，无法直接给出唯一根因，但上述分析支持您对 hwproxy 与 SDK/RTOS 兼容性 的怀疑。同时，I2C 总线竞争、插件访问未释放、升级配置缺失（如 I2CUpgradeChip）也是需要重点排查的方向。建议结合完整日志和升级包内容，逐步确认到底是哪一层导致 I2C_1 通信失败。

3

流日志和内核日志有报什么错吗