[Android稳定性] 第032篇 [原理篇] 高通平台 OCP & 组合键 Warm Reset 机制详解

一、引言

在基于 Qualcomm 平台的 Android 系统开发与调试过程中，常见的系统重启场景包括 Watchdog 重启、用户触发 reboot、按键长按重启等。而其中较为底层且难以捕捉的两种重启方式是：

• OCP（Over Current Protection）触发的 Warm Reset
• 通过组合键 + Timer 配置触发的 Warm Reset

本文将深入剖析这两种 Warm Reset 的触发原理、执行路径与调试手段。

二、OCP（过电流保护）Warm Reset 机制

1.1 什么是 OCP？

OCP（Over Current Protection）是 PMIC（如 PM6375）内置的一种硬件保护机制，实时监测各个供电轨（如 LDO/SMPS）是否出现过电流现象，以防止烧毁或异常功耗。

一旦检测到 OCP，PMIC 可以根据配置执行不同级别的响应操作：

响应类型	行为
IRQ	仅上报中断，不重启
Shutdown	拉低 PS_HOLD，SoC 完全断电冷重启
Warm Reset✅	触发 SoC 重启，供电不断电

1.2 Warm Reset 的执行路径

当某电源轨发生过流，且 OCP 响应设置为 Warm Reset：

1. PMIC 硬件逻辑检测到 OCP

2. PMIC 不通过软件中断或通知 APSS，而是 直接触发 PON FSM 执行 Warm Reset

3. SoC 收到 Reset 信号，立即重启进入 XBL

4. XBL 可记录此类事件为：

   POWER OFF by OCP warm reset
   

这个重启路径的关键点

层级	是否参与 OCP Warm Reset
Android 用户空间	❌ 完全绕过
Linux Kernel	❌ 没来得及响应
UEFI / XBL 前	✅ 被直接重启
PMIC 硬件逻辑	✅ 直接触发

1.3 软件端是否能拦截？

不能。OCP 触发属于 PMIC 硬件级保护，执行路径不经过 kernel 或 Android：

• 不会走 kernel_restart() 等软件 reboot 路径
• 无法通过用户空间控制或拦截
• 重启后通常 last_kmsg 不存在，reboot_reason 可能为默认值或缺失

1.4 如何确认是 OCP？

• 查看 XBL Log：有“OCP warm reset”字样
• 读取 PMIC PON/FAULT 寄存器
• 检查 reboot_reason = 0 或无值
• 没有 last_kmsg / tombstone 记录
• PON_WARM_RESET_REASON1的bit0为1

1.5 和其他类型 reset 对比

Reset 类型	来源	是否断电	是否走软件	是否保留状态
user reboot	用户软件调用	❌	✅ 是	✅
kernel panic	kernel 崩溃	❌	✅ 是	✅
PMIC OCP warm	✅ 硬件触发	❌	❌ 否	✅
PMIC OCP shutdown	✅ 硬件触发	✅	❌ 否	❌

二、组合键 + Timer 配置触发的 Warm Reset

2.1 背景说明

在某些平台需求下，会通过 XBL（或 UEFI）配置组合键（如 Power + Volume Down）在用户长按达到特定时间后触发 Warm Reset，用于进入某些调试模式（如 crash dump、EDL、recovery 等）。

2.2 实现机制

1. 在 XBL 中通过 SPMI 写入 PMIC 的 PON 模块寄存器：

   • 启用 S1/S2 键（如 Power = S1, Volume Down = S2）
   • 配置逻辑关系（AND/OR）
   • 设置触发时间（如 7 秒）
   • 设置响应类型为 Warm Reset

2. 配置后，PMIC 会独立硬件监控这些按键状态

   • 无需依赖 Kernel 或 Android
   • 即使系统已经启动，PMIC 配置仍然生效

3. 当组合键按住达到设定时长：

   • PMIC 触发 Warm Reset → SoC 直接重启

2.3 PON 按键组合逻辑

XBL/UEFI 初始化时会通过 SPMI 总线和 PMIC 通信，配置：

• 哪些按键（S1、S2）生效
• 什么组合方式（AND/OR）
• 定时器时间（比如 7s）
• 响应类型（如 warm reset / shutdown）

📍 这些配置最终会写入 PMIC PON 模块的寄存器，常见寄存器包括：

• S1_TIMER
• S2_TIMER
• S1_S2_ENABLE
• RESET_TYPE
• PON_REASON_CONFIG

2.4 Android 启动后，这套 PMIC 配置仍然生效

重要的是：这些配置不因 Android 启动而失效。

即使你已经进入 Android 系统：

• 如果你按下 S1 + S2 并持续超过设定的时间（比如 7 秒）
• PMIC 的内部定时器判断为 组合触发条件满足
• 就会立即触发一个 Warm Reset
• 这不会经过 Android、Linux、Kernel —— 完全绕开软件

2.5 这个触发时的 reset 路径

[用户按下 S1 + S2] ──► [PMIC 计时器检测条件成立] ──► [PMIC 硬件触发 Warm Reset]
         ↓
   [SoC 收到 Reset 信号，直接重启到 XBL]

不会调用：

• kernel_restart()
• reboot() syscall
• watchdog
• qcom_restart()

三、总结

3.1 OCP

项目	你的现象
Reset 类型	✅ Warm Reset
触发源	✅ PMIC OCP（过电流）
是否断电	❌ 没有断电（所以是 warm）
重启后是否有 XBL 日志	✅ 有，证明不是 cold reset
是否可能查到具体电源轨	✅ 可通过 FAULT_REASON 查看

3.2 组合键warm reset

你的配置行为	描述
配置了 S1+S2 + timer	写入 PMIC 的寄存器
Android 启动后仍然生效	是的，PMIC 独立于 APSS 继续判断按键组合
是否由软件触发	❌ 否，完全由 PMIC 硬件判断和控制
触发后是否走 kernel reboot	❌ 不会，直接硬件重启 SoC

3.3 OCP和组合键warm reset对比

项目	OCP Warm Reset	按键组合 Warm Reset
触发源	PMIC 电流监控	PMIC 按键组合 + timer
是否经过软件	❌ 否	❌ 否
是否需要内核配合	❌ 否	❌ 否
是否可配置	✅ 可配置响应类型	✅ 可配置组合键和定时
是否可抓 reboot_reason	⚠️ 有可能为空/默认	✅ 通常可配置
是否适合 debug 使用	✅ 是，用于异常电源轨排查	✅ 是，用作调试/强制进入特殊模式