【问题求助】环境出现Tpcm相关告警

交流互助区
1

问题描述

openUBMC 2609版本使用1712芯片，环境出现Tpcm相关告警
3 |2026-10-22 06:51:50 |Minor |0x2C0000A5 |The security coprocessor heartbeat is lost, and the operational status is abnormal.

环境信息

  • 软件版本：[OpenUBMC2609]

  • 硬件配置：[Hi1712 KP950]

期望结果

无TPCM相关告警

实际结果

出现以下告警
3 |2026-10-22 06:51:50 |Minor |0x2C0000A5 |The security coprocessor heartbeat is lost, and the operational status is abnormal.

分析结论

第 1 步：建立核间通道（每次 BMC 启动都重做）

coprocessor_init(79): [TPMC][COPRO] linx enabled, start linx helpers ← 启动 Linx 收发 helper

log_handler_init(410): [Coprocessor] log sync task started ← 协处理器日志同步任务

linx_listener_start(134): [Linx] linx msg listener is start ← 消息监听

linx_recive_msg(85): linx_recive_msg: enter linx msg task ← 接收任务

第 2 步：与安全核握手（A55 ready）—— 这一步就失败了

notify_a55_ready(33): [TPCM][COPRO] waiting for a55 ready resp ← 向安全核（Cortex-A55）发 ready 询问

a55_send_msg_to_linx(61): Get data rsp failed: -1 ← 无应答（-1 = Linx 收发失败）

↑ 每 11 秒重试一次：07:18:28 / 39 / 50、07:19:01 / 12 / 23 / 34

notify_a55_ready(37): [TPCM][COPRO] waiting for a55 ready resp failed ← 重试耗尽（07:19:44.85）

安全核从未回过 ready（整份 dump 累计：发送失败 40 次、等待 44 次、成功 0 次）。但 tpcm 不会因此中止，继续起心跳任务。

第 3 步：心跳任务与「心跳丢失」判定

linx_heartbeat_start(185): [TPCM][COPRO] coprocessor heartbeat task started ← 07:19:44.85

heartbeat_process(134): heartbeat error, ret=-1, rsp=0, last:0, current:0 ← 07:19:45.87 首跳即失败

heartbeat_process(134): heartbeat error, ret=-1, rsp=0, last:0, current:2 ← 07:20:46.92 current 升到 2，判定丢失

heartbeat_loss(147): coprocessor heartbeat loss, save registers info, try reset coprocessor

  • 每跳间隔约 61 秒；ret=-1 = Linx 收发失败，rsp=0 = 没收到安全核响应
  • current 由 0 升到 2 的那一拍触发判定（首跳 current:0 只报错、不判定）
  • 判定后按设计做两件事：保存安全核寄存器转储（落到 LogDump/coprocessor/dfx.log，每次丢失新增一段）+ 尝试复位协处理器（日志未见复位成功，随后心跳依旧失败）
  • 进入丢失状态后，后续每跳固定打印 last:2, current:2（状态已锁存），不再重复判定，直到 BMC 下次启动

第 4 步：上报告警

do_add_event(138): [TPCM] Call add event success

add_event(150): [TPCM] is_repeat = 0, Add event the 1 time successfully.

add_event(159): [TPCM] Add Coprocessor event repeatly finished successfully.

2

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

四、结论与排查建议

  • 该告警是 openUBMC 新增的合法功能告警，出现告警的直接原因是 Hi1712 平台上安全协处理器（A55/Linx）未能建立有效通信与握手，而非告警本身有缺陷。
  • 期望「无 TPCM 相关告警」的前提是安全协处理器能够正常就绪并打通 Linx 核间通道；当前现象表明该通信链路未建立（A55 从未返回 ready、Linx 收发持续失败）。
  • 建议重点核查：
    1. Hi1712 对应 Linx（灵犀）协处理器固件 LiteOS_M.bin 是否正确构建并打包进 GPP 镜像的 linx 分区；
    2. 安全核（A55）侧的启动/就绪状态及其固件是否正常；
    3. TPCM 组件是否按正确名称与 deployConfig 完成配置（TPCM 对配置参数较为敏感，配置不当会导致运行异常）。

说明：关于该告警是否为「误报」以及具体的硬件/固件修复步骤，现有知识库未提供更进一步的官方处置方案，上述根因分析依据的是本次提供的 dump 日志逻辑与 Hi1712 芯片 Linx 协处理器构建特性。

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

openUBMC 2609（Hi1712）TPCM 安全协处理器心跳丢失告警分析

一、告警性质：这是「新增」的功能性告警，并非误报

根据知识库检索结果，你看到的这条告警属于 openUBMC 新增的安全协处理器心跳丢失告警，对应以下相关变更：

  • 【修改描述】新增安全协处理器心跳丢失告警：该告警是为「安全协处理器异常时提供告警，通知客户并提供恢复措施」这一需求新增的。
  • 【修改描述】补充安全协处理器心跳丢失告警 MIB 信息：已补充对应的 MIB 定义。
  • 根据评审结论调整安全协处理器心跳丢失告警级别：告警等级经过评审后调整，故日志中最终以 Minor 级别呈现。

告警码 0x2C0000A5、告警文本 “The security coprocessor heartbeat is lost, and the operational status is abnormal.” 即对应此新增告警。因此，从「告警是否按设计产生」的角度看，该告警是系统按设计上报的，并不属于错误告警。

二、根因定位：Linx 核间通道与 A55 安全核握手失败

结合 Hi1712 芯片的构建特性可以确认：Hi1712 平台配套使用灵犀（Linx）协处理器固件 LiteOS_M.bin，该固件仅在 1712 和 oee_3095 芯片上构建，并打包进 GPP 镜像的 linx 分区。TPCM 与安全核（Cortex-A55）之间的通信正是通过这一 Linx 核间通道完成的。

你提供的 dump 分析清晰地复现了故障链路：

阶段 日志现象 含义
第 1 步 建立核间通道 coprocessor_init / linx_listener_start / linx_recive_msg Linx 收发与监听任务正常启动
第 2 步 与安全核握手 notify_a55_ready → a55_send_msg_to_linx(61): Get data rsp failed: -1 向 A55 发送 ready 询问无应答，约每 11 秒重试，最终 waiting for a55 ready resp failed
第 3 步 心跳任务 linx_heartbeat_start → heartbeat_process: ret=-1, rsp=0 首跳即失败，current 由 0 升到 2 时触发丢失判定
第 4 步 上报 heartbeat_loss → do_add_event / add_event 保存寄存器转储并尝试复位，随后上报告警

关键点在于：安全核（A55）在整个 dump 中从未返回 ready（成功次数为 0），也就是说 ret=-1（Linx 收发失败）、rsp=0（无安全核响应）反映的是 安全核侧未就绪或通信链路不通，而非 TPCM 软件逻辑错误。tpcm 并不会因握手失败而中止，仍继续启动心跳任务，最终由心跳丢失判定逻辑上报了这条告警。

三、告警产生机制说明

按照日志所显示的判定逻辑：

  1. 心跳间隔约 61 秒，每跳返回 ret=-1、rsp=0；
  2. 首次心跳 current:0 仅报错、不判定；
  3. 当 current 由 0 升到 2 的那一拍才触发丢失判定；
  4. 判定后按设计执行两件事：
    • 保存安全核寄存器转储（写入 LogDump/coprocessor/dfx.log）；
    • 尝试复位协处理器（日志未见复位成功，随后心跳依旧失败）；
  5. 进入丢失状态后，后续每跳固定打印 last:2, current:2（状态已锁存），不再重复判定，直到 BMC 下次启动。

四、结论与排查建议

  • 该告警是 openUBMC 新增的合法功能告警，出现告警的直接原因是 Hi1712 平台上安全协处理器（A55/Linx）未能建立有效通信与握手，而非告警本身有缺陷。
  • 期望「无 TPCM 相关告警」的前提是安全协处理器能够正常就绪并打通 Linx 核间通道；当前现象表明该通信链路未建立（A55 从未返回 ready、Linx 收发持续失败）。
  • 建议重点核查：
    1. Hi1712 对应 Linx（灵犀）协处理器固件 LiteOS_M.bin 是否正确构建并打包进 GPP 镜像的 linx 分区；
    2. 安全核（A55）侧的启动/就绪状态及其固件是否正常；
    3. TPCM 组件是否按正确名称与 deployConfig 完成配置（TPCM 对配置参数较为敏感，配置不当会导致运行异常）。

说明：关于该告警是否为「误报」以及具体的硬件/固件修复步骤，现有知识库未提供更进一步的官方处置方案，上述根因分析依据的是本次提供的 dump 日志逻辑与 Hi1712 芯片 Linx 协处理器构建特性。