新适配PCIeSwitch，使用i2c升级PCIeSwitch CPLD，firmware_mgmt提示报错Waiting for reply，应该是尝试调用general hardware里的on prepare超时。
在新机型上使用调试的BMC软件包升级CPLD，必现。升级进度卡在5%（prepare)半小时后timeout。
正常升级，或者到后面process流程。
一直停留在Waiting for reply阶段
MobaXterm_70.183.12.116_20260720_225352.txt (859.5 KB)
general_hardware组件是具体升级的逻辑执行的地方，你要看这里为什么没正常完成on_prepare的执行
答案内容由AI生成，仅供参考：
您遇到的核心问题是新适配的PCIeSwitch CPLD在I2C升级时，general_hardware 组件无法正常完成 prepare 阶段，进而导致 firmware_mgmt 组件通信超时。这很可能是因为硬件属性配置不完整或升级配置文件不正确。
建议您按以下步骤排查：
general_hardware 日志：查看 /var/log/app.log 中与 general_hardware 相关的日志，查找 [cpld] 相关的 prepare 阶段错误信息。这可以提供最直接的失败原因。I2CUpgradeChip 和 I2CUpgradeLockChip 是否已正确定义并与实际的硬件芯片对应。update.cfg文件，确认 update_link=’1’ 已正确配置，以指示系统走I2C升级流程。Routes 和 FirmwareRoute 属性，需要与实际的I2C升级通道相匹配。不匹配的路由配置也可能导致通信失败。综上所述，您需要关注的点不在于 general_hardware 组件本身是否缺失代码，而在于为新硬件适配所需的配置是否正确和完整。正确配置CSR和升级包是确保 general_hardware 组件能成功调用I2C升级功能的前提。
好的，根据您提供的问题描述和上下文信息，我将为您分析I2C升级PCIeSwitch CPLD时遇到的组件通信超时问题。
根据上下文信息，firmware_mgmt 组件负责广播升级阶段信号，而 general_hardware 组件则需要监听这些信号并执行相应的处理（如 prepare、process、finish）。您遇到的“升级进度卡在5%（prepare)半小时后timeout”和“Waiting for reply”报错，明确指向了 general_hardware 组件在 prepare 阶段未能及时响应 firmware_mgmt 的信号。
以下是可能导致此问题的几个关键点：
I2C升级CPLD需要特定的硬件属性来定义通信路径。在所提供的上下文中，明确指出 I2CUpgradeChip 是一个关键的配置属性，用于指定I2C升级时使用的芯片对象。该属性属于“硬件属性”类别。
general_hardware需要加什么东西？”，这很可能就是问题所在。如果新适配的PCIeSwitch的CSR（Configuration and Status Register）文件中没有正确配置 I2CUpgradeChip 属性，general_hardware 在 prepare 阶段就无法找到正确的硬件接口来执行I2C通信，从而导致信号响应超时。从上下文中关于“配置示例”的部分来看，一个标准的CPLD配置通常包含 UpgradeChip、Routes、FirmwareRoute 等属性。而对于I2C升级，必须额外配置 I2CUpgradeChip 和 I2CUpgradeLockChip。
I2CUpgradeChip 和 I2CUpgradeLockChip 作为I2C升级所需的属性。I2CUpgradeChip 属性，general_hardware 在 prepare 阶段可能无法初始化I2C通信或无法获取正确的芯片地址，从而无法完成准备工作，最终导致 firmware_mgmt 等待超时。general_hardware 组件根据升级包中的 update.cfg 配置文件来判断升级链路。
update.cfg 中的 update_link 参数决定了是走 JTAG 还是 I2C 升级。
update_link='1' 表示使用 I2C 升级。update_link='0' 或未配置则默认为 JTAG 升级。update.cfg 文件中，update_link 已正确设置为 '1'。您遇到的核心问题是新适配的PCIeSwitch CPLD在I2C升级时，general_hardware 组件无法正常完成 prepare 阶段，进而导致 firmware_mgmt 组件通信超时。这很可能是因为硬件属性配置不完整或升级配置文件不正确。
建议您按以下步骤排查：
general_hardware 日志：查看 /var/log/app.log 中与 general_hardware 相关的日志，查找 [cpld] 相关的 prepare 阶段错误信息。这可以提供最直接的失败原因。I2CUpgradeChip 和 I2CUpgradeLockChip 是否已正确定义并与实际的硬件芯片对应。update.cfg文件，确认 update_link=’1’ 已正确配置，以指示系统走I2C升级流程。Routes 和 FirmwareRoute 属性，需要与实际的I2C升级通道相匹配。不匹配的路由配置也可能导致通信失败。综上所述，您需要关注的点不在于 general_hardware 组件本身是否缺失代码，而在于为新硬件适配所需的配置是否正确和完整。正确配置CSR和升级包是确保 general_hardware 组件能成功调用I2C升级功能的前提。
firmware_mgmt解析完升级包之后，会给各个组件发升级包的信号，信号中包含当前升级固件的类型（PCIe_Switch）。general_hardware收到信号后会在upgrade_subject.lua文件中进行处理。这个组件预先在一个表中注册了各种固件升级操作的回调，收到信号后，会在这个表中查找相同名称的固件，然后执行对应的回调。当前由于这个表中没有注册PCIe_Switch这种固件，所以无法往下执行。
你可以参考cpld_register_observer这个函数，向表中注册上你自己定义的固件类型，就可以走进去升级流程了
