===============================================
PMIC reset timers, charging and reachability
===============================================

The PMIC power-on (PON) reset timers set the hard ceiling on how long a button
can be held before the SoC power-cycles, and thereby determine which ABL boot
modes are reachable by button. The reset-config table is written only by XBL.
Because cable/VBUS is itself a PON wake source, the SoC always boots on USB
insertion; the charger-screen path decides only what runs after the wake.

The charger IC is PM7250B (``qcom,qpnp-smb5``, Type-C, smb5-vbus). PMICs:
pm6350 (SoC) + pm6150l + pm7250b (charger).

Where PON reset timers are configured
=====================================

.. list-table::
   :header-rows: 1
   :widths: 30 20 50

   * - Component
     - Sets PON reset timers?
     - Evidence
   * - Kernel DTB (``qcom,power-on@800``)
     - No
     - only ``pon-dbc-delay=0x3d09`` (~15.6 ms debounce),
       ``kpdpwr-sw-debounce``, ``system-reset``; keys
       KPDPWR→KEY_POWER(``0x74``), RESIN→KEY_VOLUMEDOWN(``0x72``);
       no s1/s2/s3-timer
   * - ABL
     - No
     - reads PON reason only (``GetPonReason``)
   * - XBL
     - Yes
     - loads ``/pmic_settings.bin``; PON register table in
       ``xbl_config_a.bin`` at ~``0x37c8``

The XBL PON reset-config table
==============================

From ``xbl_config_a.bin`` at ~``0x37c8``. Record: ``selector = byte[0]``,
``value = byte[1]``, ``addr = byte[2:4]`` (SID0 PON base ``0x800``).

This is not one flat, unconditional table: the records fall into repeated
write groups keyed by that leading selector byte, and at least three distinct
selector values (``0x00``, ``0x02``, ``0x04``) appear, with different groups
writing different values to the *same* register. The KPDPWR/RESIN/PS_HOLD
rows below are all from the ``byte0=0x00`` group. The cited "gen2 S3" row
(``0x862=0x05`` / ``0x863=0x80``) is from the ``byte0=0x04`` group. A separate
``byte0=0x02`` group later in the same table writes different values to those
same two registers: ``0x862=0x04``, and ``0x863`` written twice — first
``0x00``, then ``0x80``. So each row below should be read as "from the group
noted", not as the register's single unconditional value:

.. list-table::
   :header-rows: 1
   :widths: 30 15 55

   * - Register
     - Value
     - Meaning
   * - ``0x842`` KPDPWR_S2_CNTL
     - ``0x08``
     - KPDPWR S2 reset type
   * - ``0x843`` KPDPWR_S2_CNTL2
     - ``0x80``
     - KPDPWR (power-only) S2 reset ENABLED (bit7)
   * - ``0x84A`` RESIN_S2_CNTL
     - ``0x08``
     - RESIN S2 reset type
   * - ``0x849`` RESIN_S2_TIMER
     - ``0x06``
     - RESIN S2 "bite" delay (~0.8–1.0 s)
   * - ``0x84B`` RESIN_S2_CNTL2
     - ``0x80``
     - RESIN (Vol-Down) S2 reset ENABLED (bit7)
   * - ``0x85A`` PS_HOLD_RST_CTL
     - ``0x08``
     - PS_HOLD reset
   * - ``0x862/0x863``
     - ``0x05/0x80``
     - gen2 S3 (combo) reset config (``byte0=0x04`` group)

- KPDPWR and RESIN S2 resets are both enabled; combo regs ``0x84C–0x84F`` are
  not written (so RESIN is an independent reset, not just the two-key combo).
- The S1 timers and the KPDPWR S2 timer (``0x840``/``0x841``/``0x848``) are not
  written, so they take the PMIC OTP default (OTP not in the dump). The RESIN S2
  timer (``0x849``) *is* written = ``0x06``. Reset-type field ``0x08`` is
  **``DVDD_HARD_RESET``** — deterministic: the 4-bit QPNP S2 reset-type field
  admits only ``1=WARM_RESET, 4=SHUTDOWN, 5=DVDD_SHUTDOWN, 7=HARD_RESET,
  8=DVDD_HARD_RESET`` (only the ASCII name is absent from the binary, not the
  meaning).

Hardware hold-to-reset timeout
==============================

``hardware reset = S1_TIMER (OTP default) + S2_TIMER``. KPDPWR total (both OTP
default) ≈ **8 s** — approximate, timed by holding the power button rather than
read from a static register (the S1 timer takes the PMIC OTP default, which is
not present in this dump). RESIN = OTP S1 (same class, dominant ~6–7 s) plus
explicit S2 ``0x06`` (~1 s) ≈ ~7–8 s ≤ KPDPWR. Exact ms not in dump; use
T_hw ≈ 8 s (approximate throughout).

Boot-mode reachability
======================

T_hw ≈ 8 s (approximate — timed by holding the button, not read from a static
register); ABL cycle ≈ 100 ms (see :doc:`/boot/keys`). The reachability
verdicts below follow from this approximate figure, not an exact one.

.. list-table::
   :header-rows: 1
   :widths: 30 35 35

   * - Mode
     - ABL requirement
     - Reachable?
   * - Normal boot
     - default
     - Yes
   * - EDL (software ``reboot edl``)
     - none
     - Yes (see :doc:`/edl/entry`)
   * - EDL (hardware D+→GND)
     - anomalous USB at boot
     - Yes (see :doc:`/edl/entry`)
   * - Recovery — 5-tap (Power)
     - hold 3–10 s + release + 5 taps
     - Yes — fits under T_hw
   * - Download-hold (BootIntoMode)
     - hold ≥50 cyc (~5 s) then release + charger gate
     - Narrow (release 5–~8 s + charger)
   * - Fastboot (BootIntoMode)
     - continuous ~10 s
     - No — PMIC resets at ~8 s first
   * - Recovery-hold (BootIntoMode)
     - continuous ~10 s
     - No — same
   * - Hold-recovery via Vol-Down alone
     - continuous ~10 s
     - No — RESIN S2 (~7–8 s) resets first; also gated by CBLPWR/ChgPresent

Any mode needing a continuous ≥10 s hold appears unreachable by button, given
the ~8 s (approximate) PMIC power-cut point above. Only "hold-then-release"
designs work under that constraint, which plausibly explains why the
documented 5-tap Power recovery sequence is shaped the way it is (see
:doc:`/boot/keys`) — that link between the timing math and the 5-tap design
choice is this analysis's own inference, not confirmed from any Onyx design
rationale.

Power-off and charging behavior
===============================

USB-in-while-off
----------------

PBL→XBL→ABL always runs on plug-in (cable/VBUS is itself a PON source, above).
``GetPonReason`` logs
``PON Reason … KPDPWR CBLPWR USB DC ChgPresent``. ABL's off-mode-charge decision
(RVA ~``0x1c2c0``, log ``"PON Reason is %d cold_boot:%d charger path:%d"``) sets
off-mode-charge iff ``(PON&0x81)==0`` (not KPDPWR/hard-reset) AND ``(PON&0x30)!=0``
(CBLPWR/PON1) AND charger present AND battery present — it does distinguish
"cable woke it" from "power key". It can only pick charger-mode vs boot vs
shutdown, not stay off.

Charger-only mode
-----------------

There is no ABL-native battery UI. ABL appends ``androidboot.mode=charger``
(RVA ~``0x1cd2c``) and boots the Android ``healthd``/charger UI. Gate =
``charger_screen_enabled`` (device_info +``0x0f``; getter ``0x24d88``, setter
``0x24de8`` "Enabling/Disabling Charger Screen"; fastboot
``oem enable/disable-charger-screen``; ``getvar charger-screen-enabled``).

``charger_screen_enabled`` = ``devinfo.bin`` byte 15 = ``0x01`` → ENABLED. A
cable-insert wake with charger present boots the Android charger UI, not a normal
full boot.

Low-battery: DTB ``qcom,qpnp-smb5`` ``vbatt-cutoff-mv=0xC80(3200)``,
``vbatt-low-mv=0xCE4(3300)``, ``vbatt-empty-mv=0xBB8(3000)``; ABL compares vs
``#0xC80`` → ``"capacity very low"`` (at ``0x30324``) /
``"Your device will shutdown in 30s"`` → power off (a dead-battery insert can
end powered-off). fstab is not involved — charger mode is cmdline plus Android
init.

"Off, USB attached, only a button triggers PBL" — not achievable
----------------------------------------------------------------

``charger_screen_enabled`` only changes the post-wake choice, not whether the
SoC wakes (cable insertion is itself a PON source, above). To wake by button
only: unplug USB (then only KPDPWR). To stop at the
bootloader with USB attached: hold Vol-Down (→BootIntoMode) or Power 5-tap, or
``reboot edl``. For EDL, the CBLPWR auto-wake helps (9008 over the same cable —
see :doc:`/edl/entry`). A dead-battery insert can look like
"stays off" but is battery-gated.

Regulator and PMIC tree
=======================

Beyond the charger, this board carries a multi-PMIC power tree (five
``qcom,qpnp-revid`` peripherals — one per PMIC die). Rails are driven through
**two control planes**:

RPMh-managed rails (primary + companion)
----------------------------------------

The SoC core/memory/IO rails live on **PM6350** (primary) and **PM6150L**
(companion) and are **not** written over SPMI directly — they are voted through
``rpmh-rsc`` and applied by the **AOP** (:doc:`/soc/aop`). ~40 regulator
instances:

- **ARC "level" rails** (``rpmh-arc-regulator``): ``cxlvl`` (Cx), ``gfxlvl``
  (GPU Gfx), ``lcxlvl`` (LCx), ``bobe1`` — the voltage-corner resources the AOP
  arbitrates (the Cx/Gfx side of the retention/DVFS story in
  :doc:`/soc/aop`, :doc:`/soc/thermal`).
- **VRM rails** (``rpmh-vrm-regulator``): **PM6350** ``s1``, ``s2``, ``s3``,
  ``s5`` SMPS + ``l1``–``l22`` LDOs; **PM6150L** ``bob`` (buck-boost), ``s1``/
  ``s6``/``s8`` SMPS + ``l1``–``l11`` LDOs. (``_ao`` suffixes = always-on
  variants; ``_level`` = corner-voted.)

SPMI-direct PMIC functions
--------------------------

Functions RPMh does not manage are driven straight over SPMI
(``spmi-pmic-arb``, :doc:`/boot/base-dtb`) on four PMICs:

.. list-table::
   :header-rows: 1
   :widths: 20 80

   * - PMIC
     - SPMI functions
   * - **PM6350** (USID0)
     - the SoC primary and the **master PON / reset source** —
       ``qcom,power-on@800`` at USID0 is the *only* PON node carrying a real
       keymap (``pon_1`` KPDPWR→``0x74``, ``pon_2`` RESIN→``0x72``),
       ``qcom,system-reset`` and ``qcom,store-hard-reset-reason``. This is the
       PON the XBL reset-config table (SID0 base ``0x800``, timers above) writes.
   * - **PM7250B**
     - the charger complex — ``qpnp-smb5`` (charger), ``qpnp-qg`` (fuel gauge),
       ``qpnp-pdphy`` (USB-PD PHY), a bare (unconfigured) ``qcom,power-on@800``,
       and the ``adc-tm5`` skin-thermistor channels
       (:doc:`/soc/thermal`, :doc:`/boot/usb-transport`)
   * - **PMK8350** (USID6)
     - the always-on **measurement** PMIC — ``pmk8350-rtc`` (RTC),
       ``spmi-adc7`` + ``adc-tm7`` (the always-on ADC / thermal front-end,
       :doc:`/soc/thermal`) and GPIO. It has **no** ``qpnp-power-on`` node —
       it is *not* the PON/reset source.
   * - **PM6150L**
     - a companion — ``qpnp-lcdb-regulator`` / ``pm6150l-spmi-wled`` (display bias
       + WLED), ``qpnp-vibrator-ldo`` (haptics), and a bare ``qcom,power-on@800``
   * - **PM8008**
     - a satellite PMIC (``pm8008-chip`` + ``pm8008-regulator``) — extra LDOs

``qcom,power-on@800`` appears on **3** PMICs — **PM6350@USID0** (the master, with
keymap + ``system-reset``), **PM7250B@USID2** and **PM6150L@USID4** (both bare,
phandle only). ``spmi-temp-alarm`` (per-die over-temperature) is on the same
three dies and feeds the thermal subsystem (:doc:`/soc/thermal`). (The
keymapped, system-reset PON sits on PM6350@USID0; PMK8350 carries no
``qpnp-power-on`` node.)

Reference-base leftovers
------------------------

Several PMIC functions are **display/camera power for hardware this e-reader does
not have** — the same reference-base pattern as the AMOLED display naming
(:doc:`/display/panel`): ``qpnp-amoled-regulator`` and ``qpnp-lcdb-regulator``
(AMOLED/LCD bias — not these; on this device the Lattice FPGA is the runtime
EPD power/timing controller, with the FP9931/MAX17135 EPD PMIC drivers
present but only bound to XBL's boot splash and sibling PCB variants, see
:doc:`/display/tcon`), ``pm6150l-spmi-wled`` (LCD/LED backlight — the e-ink front-light is the
``LM3630A`` pair on QUP SE10 instead, :doc:`/boot/qup-buses`), and
``qpnp-flash-led-v2`` (camera flash — no camera). They are populated in the stock
SM6350 PMIC configuration but unused here.

Caveats
=======

- ~100 ms/cycle assumes standard EFI Stall µs.

Provenance
==========

:Source: ``../_READONLY/lun1/xbl_config_a.bin``, ``../_READONLY/lun1/xbl_a.bin``,
   ``../artifacts/abl_a/abl_dxe_fv.bin``, ``../artifacts/boot_a/board.dts``,
   ``../_READONLY/lun4/devinfo.bin``.
:Method: register values and enable/type bits read from ``xbl_config_a.bin``;
   reset-timer magnitude inferred from PMIC OTP defaults plus the observed ~8 s
   hold-to-reset; charging logic read from ABL DXE strings and the kernel DTB.
:Cross-refs: :doc:`/boot/keys`,
   :doc:`/edl/entry`,
   :doc:`/xbl/xbl-config`.