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

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

4.1.2. Method matrix

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

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)

4.1.3. 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 Charger-type detection and the unreachable fedl/LED branch 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).

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

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

4.1.6. 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 ABL overview, key handling, fastboot). This is an Onyx/OEM omission; entry must bounce through Android (adb reboot edl).

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

4.1.8. 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).

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

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

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

4.1.12. 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 Firehose fuse read and secure-boot confirmation and Secure boot and image signing). 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.

4.1.13. 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:

PMIC reset timers, charging and reachability (charger/PON), Physical keys: power, volume, and the boot-mode dispatcher (reason 0x17), Secure boot and image signing, ABL overview, key handling, fastboot, Charger-type detection and the unreachable fedl/LED branch, Firehose fuse read and secure-boot confirmation.