EDL Utility

The EDL Utility is a Win32 utility for accessing the Qualcomm Emergency Download interface on Qualcomm processors.

Usage: edl [flags] [output] [start-sector] [sector-count] /l loader file /p partition name or number /g print GPT partition table, sort: N(umber), A(lpha), D(isk order), S(ize) /r read /e erase /w write /t truncate reading of partitions to active size /z reboot /m eMMC memory (default) /n NAND memory /u UFS memory [lun] /s start block /c count of blocks /b block size override /v verbose

Note: The usage has changed and now requires an explicit /r to read blocks from the device.

Qualcomm processors support two different protocols, "Sahara" and "Firehose". Sahara is supported in ROM and is always present. Firehose is implemented in downloadable loaders in ELF format.

EDL Mode

The usual procedure is to first get your device in EDL mode, i.e. where it is presenting USB VID/PID 05c6/9008. This can be achieved by:

Windows Drivers

Everything under Windows needs some kind of driver. Zadig is a simple generic driver generator. Do NOT use any Windows drivers from Qualcomm. They will try to present your device as a serial port.

Loaders

Next, you must use the Sahara protocol to load a loader for the Firehose protocol. Loaders may be found (thank you!) at https://github.com/bkerler/Loaders/. These files often use .bin or .mbn as the extension despite it actually being a normal ELF file. As the filenames tend to be cumbersome, you might rename them something short and mnemonic.

The Onyx Poke3, Leaf and Note Air 2 all use this loader. ~~The Onyx Max Lumi 2 uses this loader.~~

C:\>edl.exe /lpoke3.bin Found EDL 9008 Sending poke3.bin 100% Ok Waiting for Firehose... Ok

From this point on the processor is using the Firehose protocol and you need not (can not) reload the loader unless you reboot.

A device might be using eMMC storage (older devices), NAND storage or UFS storage (newer devices). The /u flag must be used for all operation in Firehose on devices with UFS.

Specifying Blocks

The flags /u (LUN), /p (partition), /s (start block), /c (count of blocks) and /b (block size) are used to specify the area of operation. If the partition is specified then start block is relative to the start of the partition. Accidentally specifying a (large) device-relative start block and a partition will probably be flagged as an error. Specifying a (small) partition-relative start block and forgetting to specify a partition might cause unpleasantness! Zero is the default for both start block and count of blocks; there's no need to specify them.

Operations

Start	Count	Partition
Unspecified	Specified
0	0	error	Whole partition
0	+	Start of disk	Start of partition
+	+	Middle of disk	Middle of partition
+	0	error	End of partition
−	0	error	End of partition
−	+	error	Part of end of partition

The major operations are /r (read), /e (erase), /w (write). The erase and write operations can be combined which yields the non-optimized operations of full erase and (possibly) partial write (depending on the size of the input file).

Truncation

Partitions are sized for the maximum anticipated size of the contents. Often the fraction of a partition that is actively being used is as low as 20%. (There are often many partitons with all zeroes in them also.) There is no particular need to transfer a whole partition when 20% will do. Of course, if you still want to transfer another 50MB of zeroes, just don't use the /t flag.

Android images are naturally aligned to pagesize (normally 4096 bytes) but ELF files can be any size. Therefore, when they are read, even when truncated, they are rounded up to the current device blocksize (normally 512 or 4096 bytes). This simplifies matters when/if they are written back to the device.