1.2.7. Charger-type detection and the unreachable fedl/LED branch

1.2.7.1. 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.

1.2.7.2. 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: Open questions and limits of analysis.

Source:

_READONLY/lun1/xbl_a.bin — Capstone disassembly of 0x8074651c; whole-image ADRP/literal sweep for the fedl/LED string band.

Cross-refs:

XBL (PH9/PH13 in the segment layout), Physical keys: power, volume, and the boot-mode dispatcher, EDL / 9008 entry and the deep-flash cable, Open questions and limits of analysis.