QFIL, edl or a box tool: choosing what to flash with
People pick a flash tool by whichever one a YouTube video used, then assume any failure is their device’s fault. But the tools genuinely differ in how they negotiate the connection, and a device that stalls in one often completes in another.
That is not a minor detail. It is the thing that eventually recovered my own tablet after weeks of failures — the full story is in the hard brick guide.
The three options
| Tool | Character |
|---|---|
| QFIL (Qualcomm) | The reference implementation, free, from the vendor. Predictable and well documented. Relies entirely on your own Windows driver setup, which is where it most often stalls. |
| edl (open source) | Python, cross-platform, transparent. Reads partition tables, dumps individual partitions, works well on Linux. More capable for diagnosis than QFIL. On Windows it fights libusb. |
| Box tools (paid) | Bundle their own drivers and loader handling. Frequently complete handshakes the others cannot. Cost money, and the exact mechanism is opaque. |
Why the tool changes the outcome
Before anything is flashed, your PC has to complete the Sahara handshake and upload a firehose loader to the device. Only then does firmware become relevant at all.
Each tool implements that handshake with its own timing, its own retry behaviour and its own driver stack. So a device that drops off mid-handshake with one tool can complete with another, without a single byte of your firmware changing.
This is the practical takeaway and it is worth more than any tool recommendation: if you are failing at Sahara, change the tool before you change the firmware. A Sahara failure happens before your firmware is read. Buying a different firmware package cannot fix it — I know because I tried.
What I would reach for, and when
- Starting out on Windows — QFIL. Free, standard, and every guide assumes it.
- Diagnosis and dumping —
edlon Linux. Reading the partition table, pulling individual partitions and seeing exactly what the device reports are all easier here. - Windows refuses to cooperate — a Linux live USB with
edl, which sidesteps driver signing entirely. - Everything free has failed at the handshake — a box tool becomes a reasonable purchase. Not as a first resort.
Before you spend money
A box tool is a legitimate purchase for someone doing repair work regularly. It is a poor purchase for someone trying to rescue one device, made in frustration at 2am.
Work through this first:
- A known-good data cable, and a USB 2.0 port directly on the machine
- Correct Qualcomm drivers, installed with signature enforcement disabled
- The right firehose file for your chipset
- A Linux live USB attempt with
edl, with ModemManager removed
If all four are done and the handshake still fails, a box tool is now an informed decision rather than a hopeful one.
Frequently asked questions
- Is a paid tool more capable than QFIL?
- Not in what it can write. The difference is in drivers, loader handling and handshake behaviour — convenience and reliability rather than raw capability.
- Can I use the same firmware package across tools?
- Generally yes. The loader and the XML files are standard; the tools differ in how they get to the device, not what they send.
- Why does edl fail on Windows but work on Linux?
- libusb behaves differently on Windows, and driver signing complicates it further. The tool is the same; the platform is not.
- Do box tools work on newer devices?
- Increasingly less. Modern verified boot and hardware-backed protection apply regardless of which tool is sending the bytes.
- Which should a beginner learn first?
- QFIL, because most documentation assumes it. Then
edl, because it teaches you what is actually happening.
Failing on one tool and unsure whether to try another? Send me the error text and which tool produced it. Where in the process it fails tells you whether switching will help.