How Qualcomm Warm Resets Happen Below Android: OCP Protection and PMIC Key-Combo Triggers

In Android bring-up and debugging on Qualcomm-based devices, reboots can come from many places: watchdogs, user-requested restarts, kernel failures, or long-press key actions. Two cases are much lower-level and are often harder to trace because software may never get a chance to react:

a Warm Reset caused by PMIC OCP (Over Current Protection)
a Warm Reset triggered by a key combination plus a hardware timer

Both are driven by PMIC hardware, not by the normal Android or kernel reboot path. That difference is what makes them easy to misread during debugging.

OCP-triggered Warm Reset

What OCP does

OCP, or Over Current Protection, is a hardware protection feature built into the PMIC, such as the PM6375. Its job is to continuously monitor power rails like LDOs and SMPS regulators for overcurrent conditions, preventing damage or abnormal power behavior.

When an overcurrent event is detected, the PMIC can be configured to respond in different ways:

<table> <thead> <tr> <th>Response type</th> <th>Behavior</th> </tr> </thead> <tbody> <tr> <td>IRQ</td> <td>Report an interrupt only, no reboot</td> </tr> <tr> <td>Shutdown</td> <td>Pull PS_HOLD low and fully power off the SoC for a cold restart</td> </tr> <tr> <td>Warm Reset✅</td> <td>Restart the SoC without cutting power</td> </tr> </tbody> </table>

What the reset path looks like

If a rail hits an overcurrent condition and the OCP action is configured as Warm Reset, the sequence is roughly this:

PMIC hardware detects the OCP event.
Instead of notifying APSS through software interrupt handling, the PMIC directly drives the PON FSM to perform a Warm Reset.
The SoC receives the reset signal and immediately reboots back into XBL.
XBL may record the event like this:

   POWER OFF by OCP warm reset

The important part is which layers are involved, and which are completely bypassed:

<table> <thead> <tr> <th>Layer</th> <th>Participates in OCP Warm Reset?</th> </tr> </thead> <tbody> <tr> <td>Android userspace</td> <td>❌ No</td> </tr> <tr> <td>Linux kernel</td> <td>❌ No time to respond</td> </tr> <tr> <td>Before UEFI / XBL</td> <td>✅ Reset happens before software can handle it</td> </tr> <tr> <td>PMIC hardware logic</td> <td>✅ Direct trigger</td> </tr> </tbody> </table>

Can software intercept it?

No. An OCP-triggered reset is a PMIC-level hardware protection action. It does not follow the usual software reboot flow:

it does not go through kernel_restart() or similar reboot paths
it cannot be controlled or blocked from userspace
after reboot, last_kmsg is often missing, and reboot_reason may be empty or fall back to a default value

That is usually the first clue that the reset did not originate in Android or the kernel.

How to confirm OCP was the cause

Several signals can help identify this case:

check XBL logs for strings such as OCP warm reset
read PMIC PON or FAULT registers
see whether reboot_reason = 0 or no meaningful value is present
confirm that there is no last_kmsg or tombstone related to the reboot
check whether bit0 of PON_WARM_RESET_REASON1 is set to 1

How it differs from other reset types

<table> <thead> <tr> <th>Reset type</th> <th>Source</th> <th>Power cut?</th> <th>Through software?</th> <th>State retained?</th> </tr> </thead> <tbody> <tr> <td>user reboot</td> <td>software request from user space</td> <td>❌</td> <td>✅ Yes</td> <td>✅</td> </tr> <tr> <td>kernel panic</td> <td>kernel crash</td> <td>❌</td> <td>✅ Yes</td> <td>✅</td> </tr> <tr> <td>PMIC OCP warm</td> <td>✅ hardware-triggered</td> <td>❌</td> <td>❌ No</td> <td>✅</td> </tr> <tr> <td>PMIC OCP shutdown</td> <td>✅ hardware-triggered</td> <td>✅</td> <td>❌ No</td> <td>❌</td> </tr> </tbody> </table>

A Warm Reset caused by OCP still keeps power on, which is why it behaves differently from a full shutdown path.

Warm Reset triggered by key combination and timer

Why platforms use it

Some products configure a key combination in XBL or UEFI—such as Power + Volume Down—so that holding the keys for a defined duration will trigger a Warm Reset. This is commonly used to enter special debug or recovery paths, including crash dump, EDL, or recovery-related modes.

How it is implemented

During early boot, XBL programs the PMIC PON block over the SPMI bus. The configuration typically includes:

enabling S1 and S2 keys, for example Power as S1 and Volume Down as S2
defining the logic relationship between them, such as AND or OR
setting the required hold time, for example 7 seconds
choosing the response type as Warm Reset

After those registers are programmed, the PMIC monitors the key states by itself in hardware.

That means:

it does not depend on Android
it does not depend on the Linux kernel
the configuration remains active even after the system has fully booted

If the configured key combination is held long enough, the PMIC directly triggers a Warm Reset and the SoC reboots immediately.

PON key-combination logic inside the PMIC

At XBL or UEFI initialization time, the PMIC is configured through SPMI to define:

which keys are active, such as S1 and S2
whether the trigger condition is AND or OR
how long the timer should run, such as 7 seconds
what action to take, such as warm reset or shutdown

These settings are ultimately written into registers inside the PMIC PON module. Typical registers include:

S1_TIMER
S2_TIMER
S1_S2_ENABLE
RESET_TYPE
PON_REASON_CONFIG

Why the configuration still works after Android boots

This point matters a lot during debugging: once programmed, the PMIC behavior does not disappear just because Android is running.

Even after the device has entered the Android UI:

if S1 + S2 are pressed
and held longer than the configured timeout, such as 7 seconds
the PMIC timer determines that the condition has been satisfied
and it immediately performs a Warm Reset

Again, this bypasses Android, Linux, and the normal kernel reboot path entirely.

The actual reset path

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

This path does not call:

kernel_restart()
reboot() syscall
watchdog
qcom_restart()

Practical debugging perspective

These two Warm Reset mechanisms look similar at the system level because both restart the SoC without going through standard software-controlled reboot handling. But their trigger sources are different:

OCP Warm Reset comes from PMIC current monitoring on a power rail
key-combination Warm Reset comes from PMIC key detection plus timer logic

They also share several debugging characteristics:

both bypass Android and the kernel
neither requires kernel cooperation
both are initiated directly by PMIC hardware logic

There are still some useful differences:

<table> <thead> <tr> <th>Item</th> <th>OCP Warm Reset</th> <th>Key-combo Warm Reset</th> </tr> </thead> <tbody> <tr> <td>Trigger source</td> <td>PMIC current monitoring</td> <td>PMIC key combination + timer</td> </tr> <tr> <td>Passes through software</td> <td>❌ No</td> <td>❌ No</td> </tr> <tr> <td>Needs kernel support</td> <td>❌ No</td> <td>❌ No</td> </tr> <tr> <td>Configurable</td> <td>✅ Response type can be configured</td> <td>✅ Keys and timer can be configured</td> </tr> <tr> <td>reboot_reason visibility</td> <td>⚠️ May be empty or default</td> <td>✅ Usually can be designed for clearer identification</td> </tr> <tr> <td>Debug use</td> <td>✅ Useful for power-rail fault analysis</td> <td>✅ Useful for forcing debug or special boot modes</td> </tr> </tbody> </table>

For OCP cases, the most valuable clues are usually in XBL logs and PMIC FAULT or PON status registers, especially when the usual kernel-side artifacts are missing. For key-combination resets, the main thing to remember is that once XBL has programmed the PMIC, the hardware keeps watching for that combination on its own, regardless of whether Android is already up.

That is why both cases can look like "mysterious reboots" from the software side: the reset happens underneath the software stack.