=============================================================
Charger-type detection and the unreachable fedl/LED branch
=============================================================

The charger-type detection loop
===================================

``0x8074651c`` (PH13, DDR-resident SBL1/charger code, ``0x80735000``) is the
charger-type detection loop: it initializes the detected type to ``0xFF``,
polls a getter function ``0x80735700(2)`` up to 1000× (~1 s), classifies
the result (CDP = 2 D+ toggles), and on failure/timeout falls into
``chgr_type_det_err`` — one of the ``fedl`` failure reasons below. This
getter is itself reached only through the runtime GOT (next section), so it
cannot be followed further statically; the detection *loop* around it is
recovered in full from static disassembly.

Why the branch past it isn't
================================

XBL uses a runtime-populated GOT for cross-module calls (PLT-style stubs,
e.g. this same charger getter, ``0x80735700`` → GOT slot ``0x148b81f0``,
which sits in an unmapped gap not present in the file). Consequently, of
1643 ADRPs across the XBL image's executable-permission segments, **zero** reach the SBL1
``fedl``/charger/LED string band (``0x1481d000`` / ``0x1481f000``); those
strings also appear in no 64-bit literal. The exact ``fedl`` and blue-LED
branches are therefore not statically recoverable — the ``fedl`` failure
taxonomy itself (``pmi_not_detected``, ``vbus_det_err``, ``vbus_low``,
``chgr_type_det_err``, ``chgr_det_timeout``) and the blue-LED string
(``not power_key_press, blue led on!`` at vaddr ~``0x1481fb13``) *are*
recovered by string search; only the runtime GOT edge from getter to
branch resists static analysis. Full residual/read-procedure detail:
:doc:`/open-questions`.

:Source: ``_READONLY/lun1/xbl_a.bin`` — Capstone disassembly of
   ``0x8074651c``; whole-image ADRP/literal sweep for the ``fedl``/LED
   string band.
:Cross-refs: :doc:`/xbl/index` (PH9/PH13 in the segment layout),
   :doc:`/boot/keys`, :doc:`/edl/entry`, :doc:`/open-questions`.