=========================================
EDL / 9008 entry and the deep-flash cable
=========================================

The EDL entry target on this SM6350 unit is the Qualcomm HS-USB QDLoader 9008 /
Sahara interface, present from the first flash stage (``sbl1_sahara.c``,
``Sahara: Hello pkt sent/Response Received``, ``XBLRamDump``). PBL is on-die
ROM and is not present in the partition dump; PBL/BC1.2/Aleph statements are
architectural, the ``fedl``/Sahara/cookie strings and DT nodes are from the
images.

Deep-flash cable pin
====================

The deep-flash cable pin is D+ to GND, not D+ to D-.

- **D+ to D- short** = BC1.2 DCP (wall-charger) signature, producing charging,
  not EDL (``Charger SRC: DCP``, ``usb_dp_toggled_for_cdp``).
- **D+ to GND short** = the deep-flash cable (Aleph Security). It is an invalid
  BC1.2 signature, so XBL charger-type detection fails and forced EDL (``fedl``)
  results. This is the pin identified for the deep-flash-cable method on this
  SoC family.

Method matrix
=============

No case-opening and no button combinations are involved in any listed method.

.. list-table::
   :header-rows: 1

   * - Method
     - This SM6350
     - Universal vs device
     - Prerequisites
   * - D+→GND cable → XBL ``fedl``
     - Yes
     - SoC-family (835→8 Gen 3, Aleph)
     - USB power + D+ grounded during XBL charger-detect
   * - ``adb reboot edl`` (IMEM cookie)
     - Yes
     - universal mechanism
     - booted Android + adb
   * - ``reboot edl`` / direct cookie write
     - Yes
     - universal
     - shell/root/code-exec
   * - PBL image-load/auth failure → Sahara
     - Yes
     - SoC-universal
     - XBL unreadable/invalid (needs prior flash access or a UFS test-point =
       opening)
   * - Fastboot ``oem edl`` / ``reboot-edl``
     - No
     - device-specific
     - not implemented in this ABL
   * - Crash/panic/watchdog → EDL
     - Not by default
     - universal if enabled
     - ``download_mode`` must be enabled first (off by default)
   * - DDI / EUD debug interfaces → EDL
     - Present but gated
     - SoC-family
     - QC debug tooling + debug/secure-fuse policy
   * - Host-side Sahara / special VID-PID
     - No (cannot force)
     - universal
     - device must already be in 9008
   * - D+↔D- clean short
     - No → charger
     - —
     - (wrong pin; see method 1)

D+→GND → XBL ``fedl``
=====================

On USB power, XBL runs BC1.2 charger detection; on failure it logs
``"enter forced EDL"`` and drops to 9008. Reasons in ``xbl_a.bin``::

   fedl, chgr_type_det_err   ; charger TYPE unclassifiable
   fedl, chgr_det_timeout    ; detection never completes
   fedl, vbus_det_err / vbus_low / pmi_not_detected
   maybe bad usb cable! do bad usb config!   ; adjacent to chgr_type_det_err in the same routine

The ``0x807…`` charger module holds the type-detection loop at vaddr
``0x8074651c``: init type ``0xFF``, poll a charger-type getter up to 1000×
(~1 s window), classify (``CDP`` = 2 toggles D+), and on failure/timeout →
``chgr_type_det_err``. A hard D+→GND short prevents classification (VDP_SRC
cannot raise a grounded D+), so the type never resolves and ``fedl`` results.

Mechanism: BC1.2 DCD senses D+ (grounded → stuck low); Primary Detection applies
VDP_SRC to D+ and checks D- — with D+ clamped low the classifier's sanity check
fails → ``chgr_type_det_err``/``timeout`` → ``fedl``. A clean D+↔D- short instead
reads as a valid DCP → charging.

The exact ``fedl`` branch and the register-level BC1.2 read are not statically
recoverable — XBL SBL1 is section-stripped with a runtime-populated GOT (see
:doc:`/xbl/charger-detection` for why). The mechanism is established at
the string and detection-loop level; the precise comparator and the D+/GND→err
electrical mapping remain empirical (bench/live device required).

Software EDL (cookie)
=====================

``adb reboot edl`` / ``reboot edl`` write the EDL magic into shared IMEM;
PBL/XBL read it on the warm reset → 9008. DTB ``qcom,msm-imem@146aa000``
(``restart_reason@65c``, ``dload_type@1c``, ``diag_dload@c8``); XBL
``DloadCookieAddr = 0x01FD3000``, ``DloadCookieValue = 0x10``,
``EMERGENCY_DLOAD_TIMEOUT_COOKIE_SET``; ABL reboot-reason ``0x17``.

ABL's own path (``0x10708``) does this via UEFI variable ``RESET_PARAM="EDL"``
plus ``gRT->ResetSystem(EfiResetPlatformSpecific,"EDL")``; the platform reset
handler converts the "EDL" reset reason into the dload cookie. Prerequisite:
booted Android + adb.

PBL image-fail → EDL
====================

PBL falls to Sahara/9008 when it cannot read or authenticate XBL. This is
universal Snapdragon behavior; the Sahara receiver is present this early.
Triggering it without an OS requires a UFS storage test-point short at
power-on, which requires opening the device case (out of scope for the
no-open constraint above); otherwise it is a consequence of having already
corrupted or erased XBL.

Fastboot EDL — not available
============================

This ABL's static ``cmd_list`` has only ``reboot`` / ``reboot-bootloader`` /
``reboot-recovery`` / ``reboot-fastboot`` (plus the ``oem`` charger/panel/
device-info set) — no ``oem edl`` and no ``reboot-edl`` (see
:doc:`/abl/container`). This is an Onyx/OEM omission; entry must
bounce through Android (``adb reboot edl``).

Crash → EDL — off by default
============================

``# CONFIG_QCOM_SCM_DOWNLOAD_MODE_DEFAULT is not set``; only ``QCOM_MINIDUMP`` /
``MEMORY_DUMP_V2`` are on, so a crash yields a minidump/subsystem-restart, not
9008. XBL retains the dload/ramdump machinery (``boot_dload_check``,
``boot_error_handler: Ramdump allowed. Trying to enter DLOAD``,
``PBS_WATCHDOG_TO``) and can enter dload only if ``download_mode`` is enabled
first.

DDI / EUD — debug-gated routes
==============================

- **DDI** = XBL debug/DDR command interface (``boot_ddi_entry``,
  ``DDI: Eye Plot Test``, ``DDI: Frequency Switch``, ``ddi_param_count``);
  ``"DDI output present, go to EDL"`` — if a DDI debug connection is present, XBL
  diverts to EDL. Needs QC debug tooling.
- **EUD** (Embedded USB Debugger): ``qcom,msm-eud@88e0000`` +
  ``qcom,secure-eud-en``; XBL/DXE ``EUD_MODE_MANAGER``, ``usb_eud_is_active``,
  ``"wait 20s for EUD: enumerating t32"``. Reroutes USB2 D+/D- to a debug
  controller; secure/debug-fuse gated — usability on a production unit is not
  determinable from the dump (fuse state not present).

Host-side Sahara — cannot force EDL
===================================

The device enumerates ``05C6:9008`` only after it decides to enter EDL (methods
1–4/6). A host running Sahara "Hello" or probing for 9008 cannot pull a
normally-booting device into EDL.

Type-C: charger detection path
==============================

The USB-C stack: controller ``dwc3@a600000`` (drd/SS); HS PHY ``qusb@88e3000``
(qusb2phy-v2) = USB2 D+/D-; SS PHY ``ssphy@88e8000`` (QMP-DP combo); Type-C/CC
``qcom,typec@1500`` on PM7250B (attach/orientation/PD); charger
``qcom,qpnp-smb5`` with ``dpdm-supply`` → qusb2phy (APSD on D+/D-); EUD
``qcom,msm-eud@88e0000``.

- CC = attach/orientation/PD/legacy-cable-detect.
- D+/D- = BC1.2 charger-type detection, whose failure triggers ``fedl``.

Based on the DTB/architecture (not bench-verified): D+→GND appears not to be
bypassed by Type-C — with any normal cable CC attach succeeds, VBUS/data
enable, APSD runs on D+/D-, and grounding D+ would break the step that gates
``fedl``. The short would not need to touch CC (its one dependency is that
CC attach succeed).

Pinout (Type-C receptacle, not in a DTB): D+ = A6 & B6, D- = A7 & B7 (USB2 D+/D-
tied across orientations device-side); GND = A1/A12/B1/B12. Thus "short D+→GND" =
short A6 (or B6) to any GND pin, orientation-independent. Whether this board ties
A6≡B6 or inserts a D+/D- mux/ESD part needs the schematic.

Practical sequence (D+→GND cable)
=================================

Expected sequence, from the static mechanism above (not bench-verified on this
unit): device off → plug the D+→GND cable to the PC (VBUS + D+ grounded) →
VBUS/CBLPWR powers the SoC → XBL charger-detect sees the anomaly → 9008
enumerates → swap to a normal cable / remove the short → run Firehose. The
short must be live during XBL charger detection.

Device-specific state
=====================

XBL/ABL/TZ are test-key-signed and secure boot is empirically un-fused. A foreign
``lenovo_motorola`` Firehose programmer was accepted by PBL/Sahara and dumped
this unit — direct proof that a generic/test-signed programmer runs in EDL here
(see :doc:`/edl/firehose` and
:doc:`/boot/secure-boot`). The programmer ELF is an external file, never
part of a partition dump. EDL read is proven; the analysis here is
static-analysis only — no device write was performed.

Provenance
==========

:Source: XBL/ABL/boot-chain partition images; SM6350/BC1.2/Aleph architecture for
   PBL and charger-detection electrical behavior.
:Artifacts: ``../_READONLY/lun1/xbl_a.bin``, ``../artifacts/abl_a/abl_dxe_fv.bin``,
   ``../artifacts/boot_a/board.dts``, ``../artifacts/boot_a/kernel_config.txt``.
:Cross-refs: :doc:`/soc/pmic` (charger/PON),
   :doc:`/boot/keys` (reason ``0x17``),
   :doc:`/boot/secure-boot`, :doc:`/abl/container`,
   :doc:`/xbl/charger-detection`,
   :doc:`/edl/firehose`.