Skip to main content

Flashing Tools / EDL

Qualcomm chipsets such as the QCM6190 expose a powerful low-level flashing interface known as EDL (Emergency Download Mode). EDL provides a mechanism to read and write partition tables, individual partitions, and perform complete system provisioning even on devices that are otherwise unbootable.
This page introduces the underlying technologies (Sahara, Firehose, the bootloader), Qualcomm’s tooling, and how Particle uses EDL through Bundle Files, particle flash, and particle setup.

What is EDL?​

EDL (Emergency Download Mode) is Qualcomm’s proprietary low-level flashing interface implemented inside the primary boot chain of Qualcomm chipsets. EDL enables:

  • Reading/writing partition tables
  • Flashing individual partitions
  • Flashing entire system images
  • Recovering devices with corrupted bootloaders
  • Securely provisioning new boards in manufacturing

Because EDL operates below the normal boot chain, it is the mechanism of last resort and the mechanism used for initial factory programming.

Sahara Protocol​

When a Qualcomm device enters EDL mode, the earliest stage runs a protocol called Sahara.

Sahara is responsible for:

  • Enumerating over USB
  • Authenticating the host flashing tool
  • Transferring a loader (typically a Firehose binary) into RAM
  • Passing execution to this loader

You can think of Sahara as the handshake and bootstrapping layer. Once the loader is accepted and executed, the device shifts into a more fully featured flashing protocol.

Firehose Protocol​

Firehose is the second-stage flashing loader sent by Sahara. It is an ELF binary that runs in RAM and provides:

  • Partition table access
  • Read/Write of NAND/UFS/eMMC partitions
  • Bulk flashing operations
  • Erase commands
  • Provisioning controls

Firehose is what performs the real flashing work.
Every QCM6190 Particle bundle includes a Firehose loader (an .elf file) at the root of the zip file.

Boot Chain Overview​

On QCM6190 the general Qualcomm boot flow is:

  1. PBL (Primary Bootloader) - ROM, immutable. Implements Sahara and the transition into EDL.
  2. SBL (Secondary Bootloader) - Flash-resident, signed image. Performs early init.
  3. Aboot / LK / UEFI - Loads kernel, verifies images, handles secure boot chain.
  4. Kernel + RootFS - Full Linux boot.

EDL interacts directly with PBL, which is why EDL works even when every other part of the flash storage may be corrupt.

Qualcomm Tools​

Qualcomm provides several flashing utilities that interact with EDL, most commonly:

  • QFIL (Qualcomm Flash Image Loader) - Windows GUI tool, widely used for development and recovery.
  • QPST Suite - Additional Windows tools for diagnostics and service functions.
  • Qualcomm EDL Linux Tools - More recent; command line utilities for flashing and provisioning on Linux.

The ecosystem is large, and most documentation is found via public Qualcomm references and general online QDL/EDL resources.

Particle's Tachyon Bundles​

Particle distributes full OS images for QCM6190 devices in the form of Bundle Files (.zip).
A bundle contains:

  • A manifest (manifest.json) that defines the bundle contents
  • All OS partitions needed for a specific system release
  • The Firehose loader binary
  • Optional customer overlays or installed packages

What Bundles Do Not Contain​

There are four NVRAM partitions on Tachyon devices that store device-specific data:

  • Device ID
  • MAC addresses
  • Calibration blobs
  • Other device-unique keys and values

Particle never overwrites these in a bundle.
You can read/write them using particle tachyon backup, which is designed for safe handling of NVRAM data.

Why Bundle Files Exist​

Bundle files provide:

  • A complete, known-good OS image
  • A consistent and reproducible installation process
  • OTA compatibility between bundle versions
  • Manufacturing installation support
  • The ability to layer additional customer packages or configuration defaults

A bundle is basically a snapshot of the entire OS (minus NVRAM), suitable for flashing locally, remotely, or during manufacturing.

Creating and Modifying Bundles​

Particle provides a Bundle Tool that:

  • Reads bundle manifests
  • Filters or extracts partitions
  • Creates delta bundles or sub-updates
  • Allows OEMs to build custom OS forks
  • Enables adding additional packages
  • Supports configuration changes (defaults, overlays, etc.)

See the dedicated bundle-tool documentation page for specifics.

#link to tachyon/software/ubuntu_20_04/ubuntu-20.04-partial-flash

Customer Use of Bundle Files​

Customers typically use bundles for:

1. Initial On-Device Installation​

Used during early bring-up or recovery:

particle flash --tachyon bundle.zip
  1. Manufacturing Programming

The device can be flashed and configured on a factory line using a single bundle file.

  1. Pre-Installed Functionality

Bundles may include:

  • User overlays
  • Preloaded applications
  • Default configuration values
  • Custom forks of the OS

All based on modifying the base images via the bundle tool.

  1. OTA Updates

The cloud can OTA from one bundle version to another, including custom forks.

⸻

How Particle Tools Use EDL​

Particle CLI uses EDL under the hood when interacting with QCM6190-based devices.

Flashing a Bundle

particle flash --tachyon path/to/bundle.zip

This automatically:

  • Extracts the Firehose ELF
  • Boots the device into EDL (if needed)
  • Flashes all required partitions
  • Preserves NVRAM partitions

Setup Using a Bundle

particle setup --version=path/to/bundle.zip

If no version or file is supplied, the CLI downloads the latest known-good bundle from Particle’s release channels.

⸻

Using EDL Tools Directly​

Advanced users can use any Qualcomm-compatible EDL tool.

Requirements:

  • A Firehose ELF loader (always located in the root of any Particle bundle)
  • Appropriate XML/patch/partition definitions
  • Manual flashing commands

Direct use is supported but not recommended for normal workflows. It is intended for advanced debugging or extremely custom provisioning flows.

⸻

Secure Boot Images​

If a device is Secure Boot–enabled:

  • Every image must be signed with the device’s key
  • Unsigned or incorrectly signed partitions will be rejected
  • Firehose itself may also require authentication depending on device configuration
  • Bundles for secure-boot devices must be pre-signed before OTA or local flashing

Particle’s focus is to ensure secure boot workflows are fully supported in future releases, including secure bundle creation and signing.