qualcomm/qdlrs

Purpose and workspace shape

This Rust workspace implements Qualcomm EDL (“9008”) host tooling: Sahara bootrom communication, Firehose programmer operations, storage flashing, and crash RAM-dump collection. Workspace/package composition is defined in Cargo.toml, with the reusable protocol library in qdl/ and two binaries in cli/ and qramdump/.

Executable entry points

cli/src/main.rs is the qdl-rs command entry point. It parses transport, loader, storage, reset, and command options, then drives device initialization and operations such as dump, GPT inspection, partition write/erase, reset, and flashing. qramdump/src/main.rs is a separate recovery-oriented executable that connects to a crashed EDL device and receives selected memory regions.

Protocol core: Sahara bootstrap

The library API begins in qdl/src/lib.rs. Sahara protocol state and message exchange live in qdl/src/sahara.rs, while protocol data structures are centralized in qdl/src/types.rs. This stage communicates with the boot ROM, handles the initial handshake, and transfers the supplied programmer/loader so the device can transition to Firehose-capable operation.

Transport boundary

Host/device I/O is abstracted behind serial and USB implementations: qdl/src/serial.rs and qdl/src/usb.rs. CLI tools select a backend and device path or USB serial number; platform driver availability determines whether serial or direct USB is usable. Above this boundary, Sahara and Firehose logic should operate independently of the physical transport.

Firehose operations and data parsing

The library’s Firehose-facing operations and XML/response handling are exposed through qdl/src/lib.rs and parsing support in qdl/src/parsers.rs. The operational boundary is the device-resident Firehose programmer loaded by Sahara: host commands become Firehose requests for storage initialization, raw reads/writes, erase, GPT access, memory peek, reset, and device logging. Storage behavior is parameterized by media type (eMMC/UFS/NVMe/NAND), physical partition/LUN, slot, and sector size.

Flashing pipeline

The high-level flash workflow is implemented in cli/src/flasher.rs. It consumes Qualcomm rawprogram*.xml and optional patch*.xml manifests, resolves referenced image files, and applies their programming/patch instructions through the initialized Firehose session. cli/src/programfile.rs models or processes program-file input used by this workflow. Manifest-provided LUN information is an important distinction from direct storage commands, which require an explicit physical-partition index.

Safety and lifecycle controls

cli/src/main.rs exposes destructive direct operations separately from manifest flashing, with options for bypassing storage writes, packet hashing, read-back verification, and storage-init control. Loader upload and Flash operations occur before reset; reset mode controls whether the target returns to EDL, powers off, or boots the system. Shared CLI-side support is in cli/src/util.rs.

Runtime and external dependencies

All components are native Rust executables built with Cargo; CI workflows are under .github/workflows/build.yml and .github/workflows/qcom-preflight-checks.yml. The only runtime service is a physically connected Qualcomm device in EDL mode, accessed via a USB/serial driver and requiring a device/platform-specific Firehose programmer binary supplied by the operator.