CPLD的hpm升级包签名失败

交流互助区
1

问题描述

参考社区的cpld场外打包 CPLD场外打包疑问 - 交流互助区 - openUBMC 论坛
在进行到对文件进行签名这一步时报错

企业微信截图_1783934761902
企业微信截图_1783934761902825×136 22.4 KB

想问一下这是什么原因

2

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

总结建议

您遇到的问题很可能不是一个纯粹的“签名算法”或“密钥”问题，而是一个因HPM重签名导致 CSR配置 与 实际硬件 不匹配所引发的 升级执行 失败。

建议的解决方向：

  1. 审视您的CSR配置，确保其与您目标硬件平台的CPLD连接方式一致。
  2. 如果您的配置与文档片段5中的示例类似（同时存在 Jtag_1 和 JtagOverLocalBus_1），请确认 LogicFirmware_EXU_1 对象的 Routes 属性引用的是正确的总线（通常是 JtagOverLocalBus_1）。
  3. 如果问题依旧，您可能需要调整CSR配置文件，使其与实际硬件匹配，然后重新进行签名和升级流程。
点击此处查看详细分析解答

根据您提供的 Context（知识图谱与文档片段），您遇到的“CPLD的hpm升级包签名失败”问题，其根本原因极有可能与 HPM重签名后升级失败 的已知场景高度吻合。

以下是根据现有信息进行的详细分析：

核心原因分析

根据知识库中的关系描述：

  • BCU_CPLD 和 EXU_CPLD 组件在经历 HPM重签名 后，均报告了升级失败。错误根因被精确定位为：CSR（芯片配置寄存器）中定义的JTAG总线类型与实际硬件使用的总线类型不匹配。

    • 具体表现为：CSR中定义的是 JTAG 类型，但实际硬件使用的是 JtagOverLocalBus_1 类型。这种不匹配导致了升级过程中的总线访问权限错误。

    关键关系摘录:
    EXU_CPLD → HPM重签名: “HPM重签名 leads to EXU_CPLD upgrade failure due to bus type mismatch (JTAG vs JtagOverLocalBus_1).”
    BCU_CPLD → HPM重签名: “HPM重签名 results in BCU_CPLD upgrade failure due to bus type mismatch and access permissions.”

详细排查步骤

虽然您的问题提到了“签名失败”，但从已知的同类失败案例看，最终的日志错误并非签名字段无效，而是在写入阶段（如JTAG烧录）出错。建议您按照以下逻辑排查：

  1. 确认日志详情：

    • 不要仅停留在“签名失败”的提示。请检查更详细的系统日志（如 app.log 或 firmware_mgmt 的日志）。
    • 参考文档片段中的日志示例，查看是否出现了类似 cpld]block_write fail:kepler.hwproxy.RequestTimeout: 或 Upgrade Cpld process failed, ret=-1 的错误，这通常指向通信或访问问题，而非单纯的签名问题。

  2. 对比CSR配置与实际硬件：

    • 这是最关键的校验点。请检查您平台的CSR（配置状态寄存器） 中关于CPLD总线的定义。
    • 打开CSR数据（在文档片段5中，CSR配置包含 Jtag_1 和 JtagOverLocalBus_1 两种总线类型）。
    • 确认您的CSR中 EXU_CPLD 或 BCU_CPLD 对应的 Routes 或类似字段，其定义的总线是否与硬件实际连接的总线一致。

  3. 参考社区已知案例：

    • 您参考的 CPLD场外打包疑问 帖子中，其他用户最终通过排查 JTAG总线类型 解决了问题。这进一步印证了上述原因分析的有效性。

总结建议

您遇到的问题很可能不是一个纯粹的“签名算法”或“密钥”问题，而是一个因HPM重签名导致 CSR配置 与 实际硬件 不匹配所引发的 升级执行 失败。

建议的解决方向：

  1. 审视您的CSR配置，确保其与您目标硬件平台的CPLD连接方式一致。
  2. 如果您的配置与文档片段5中的示例类似（同时存在 Jtag_1 和 JtagOverLocalBus_1），请确认 LogicFirmware_EXU_1 对象的 Routes 属性引用的是正确的总线（通常是 JtagOverLocalBus_1）。
  3. 如果问题依旧，您可能需要调整CSR配置文件，使其与实际硬件匹配，然后重新进行签名和升级流程。
3

解决了，.enc文件要在指令里加上-p <密码>