Boot Modes & Debug Modes

Advanced10 min read

Assumes: 5.2 The Boot Chain, 10.1 Debug Bench

TL;DR

A Qualcomm automotive SoC has at least 6 distinct modes: EDL, fastboot, recovery, normal (HLOS), QNX shell, and crashdump/ramdump. Each mode has different entry methods, available tools, and visibility into the system. Knowing which mode you’re in — and how to get to the right one — is the first step of any debug session. This page is the single reference that unifies what is otherwise scattered across QFIL, fastboot, and crash-analysis docs.

You have seen EDL on the QFIL page, fastboot on its own page, and recovery mentioned in passing. In practice, every debug session starts with the same question: what mode is the board in, and how do I get to the mode I need? On SA8155P/SA8295P cockpit platforms running QNX + AAOS under QHEE, the answer depends on boot stage, fuse state, and which USB port you plugged into. This page maps the full ladder from PBL ROM to running HLOS, including the crash branches that fire when something goes wrong. Every engineer has a “board won’t boot and demo is in 30 minutes” story. These modes are how it ends well.

The Mode Ladder

Boot modes are not arbitrary labels — they mirror the boot chain stages (Page 5.2). Each rung on the ladder corresponds to how far up the chain execution reached before stopping. Higher rungs have more software running and more debug tools available. Lower rungs are more primitive but more recoverable.

flowchart BT
    subgraph branches ["Crash / Debug Branches"]
        CD["Crashdump / Ramdump<br/>SCM → download_mode register<br/>adb reboot dumpmode"]
        SDI["SDI (System Debug Image)<br/>CPU halted, JTAG exposed<br/>fuse-open boards only"]
    end

    HLOS["Normal HLOS<br/>QNX microkernel + AAOS Linux<br/>Standard power-on boot"]
    REC["Recovery<br/>ABL + recovery ramdisk<br/>adb reboot recovery<br/>vol-up + power combo"]
    FB["Fastboot<br/>XBL fastboot interface<br/>adb reboot bootloader<br/>vol-down + power combo"]
    EDL["PBL / EDL<br/>ROM Firehose loader<br/>test point short<br/>adb reboot edl<br/>dead boot fallback"]

    EDL --> FB
    FB --> REC
    REC --> HLOS

    EDL -.->|"crash trigger from any stage"| CD
    FB -.-> CD
    REC -.-> CD
    HLOS -.-> CD

    HLOS -.->|"SDI enabled + fatal exception"| SDI
    FB -.-> SDI

Read the ladder bottom-up for recovery, top-down for normal operation. When both A/B slots are bricked, you drop to EDL. When the kernel panics, a branch fires to crashdump or SDI instead of continuing up the ladder.

Mental Model

Think of boot modes as floors in a building. EDL is the basement — no OS, no partitions mounted, but you can rebuild the foundation (QFIL). Fastboot is the ground floor — structural work (partition flash). Recovery is the maintenance floor — system repair without full demolition. Normal HLOS is where people live and work (QNX + AAOS). Crashdump and SDI are the security camera freeze-frames — triggered when something breaks on any floor, capturing evidence before cleanup.

Unified Mode Matrix

This table is the centerpiece of this page. Bookmark it. When a colleague says “the board is in some weird USB mode,” start here.

Mode	Entry Method	What’s Running	Available Tools	Network Available?	Persists Across Reboot?	Use When
EDL (Emergency Download)	Test point short to GND during power-on; adb reboot edl; dead boot (PBL finds no valid XBL)	PBL ROM + Firehose programmer loaded into RAM	QFIL only (Qualcomm Flash Image Loader); QPST as alternative	No	N/A — mode is entered per session	Both A/B slots bricked; XBL corrupt; first factory flash; partition table rebuild
Fastboot	adb reboot bootloader; vol-down + power key combo; DIP switch on ADP	XBL presenting fastboot USB gadget	fastboot CLI — flash, erase, getvar, fastboot oem *	No	No — reboot returns to normal or EDL	Flash individual partitions (boot, vendor_boot, modem, vbmeta); unlock/lock; slot switch; dev iteration
Recovery	adb reboot recovery; vol-up + power combo; fastboot reboot recovery	ABL + recovery ramdisk (minimal Linux)	adb sideload, wipe data/cache, factory reset UI, update.zip sideload	No	No	System update sideload when OTA agent fails; factory reset; cache wipe without full QFIL
Normal — QNX	Standard boot (successful chain through QHEE → QNX IFS load)	QNX Neutrino microkernel + resource managers + your safety/cluster processes	slog2info, pidin, dumper, qconn, slay, UART console, QNX Momentics remote debug	Yes (Automotive Ethernet)	Yes — survives warm reboot; cold boot reloads IFS	QNX-side development; safety-critical debug; cluster/HMI bring-up; SOME/IP and gRPC OTA agent on QNX host
Normal — AAOS	Standard boot (ABL loads boot.img into AAOS vCPU guest)	Linux kernel + Android framework + HALs	adb, logcat, dumpsys, pm, am, bugreport, systrace	Yes (USB gadget + Ethernet passthrough)	Yes	App development; framework/HAL debug; VHAL testing; infotainment feature work
Crashdump / Ramdump	Kernel panic with dump policy enabled; adb reboot dumpmode; SCM call sets download_mode register; watchdog-triggered reset after crash	Minimal SBL dump agent — CPUs partially held, RAM contents streamed	USB dump collection to host; QCAP (Qualcomm Crash Analysis Portal); RAMParser / vendor minidump tools	No	Dump collected once via USB; register cleared on cold power cycle	Post-crash analysis; kernel panic investigation; watchdog timeout forensics; field returns with no reproducible UART log
SDI (System Debug Image)	Fatal exception with SDI fuse + BSP policy enabled; CPU halt instead of reset on crash	CPU cores halted (not reset); on-chip debug agent exposes JTAG	Lauterbach TRACE32, OpenOCD, on-chip debugger — live register and memory inspect	No	State held until power cycle or debugger resume	Live post-crash register/memory inspection; low-level driver debug; when you have JTAG hardware and need the exact faulting instruction pointer

Quick Mode Identification on USB

USB Enumeration	Likely Mode	Host Tool
Qualcomm HS-USB QDLoader 9008	EDL	QFIL / QPST
Android Bootloader or fastboot device ID	Fastboot	fastboot devices
Android with recovery UI or sideload	Recovery	adb devices (may show “recovery”)
Android with normal product ID	Normal AAOS HLOS	adb devices
Unknown bulk device during crash	Crashdump collection	QCAP / vendor dump tool

On hypervisor ADP boards, the physical USB port and boot stage together determine what enumerates. ADB in normal HLOS may appear on a different port than EDL (Page 10.1).

Think About It

Your board is stuck in a boot loop. You can’t reach fastboot or ADB. What mode do you force?

Reveal Answer

Force EDL — short the EDL test point to GND during power-on, or set the DIP switch boot strap before applying 12V. Software entry (adb reboot edl, vol-down combo) is unavailable when the chain never reaches ABL, so hardware strap is the reliable path. USB should enumerate as QDLoader 9008 — recover with QFIL and a signed Firehose programmer matched to your SoC variant.

EDL: The Escape Hatch

EDL (Emergency Download Mode) is the lowest-level software-accessible mode. PBL ROM code runs, initializes a minimal USB stack, and waits for a Firehose programmer. No XBL, no hypervisor, no guest OS — just ROM and RAM.

When and Why

Scenario	Why EDL
Both A/B boot slots corrupt or unsigned	ABL and fastboot never start
XBL partition wiped or bad signature	PBL cannot chain-load; falls to EDL automatically
First factory provision of blank UFS	No boot chain exists yet
fastboot flash wrote wrong image to wrong LUN	Partition table or GPT damaged beyond fastboot repair

Firehose Programmer Requirement

EDL alone does nothing useful. The host must send a signed Firehose programmer (.elf, .mbn, or .melf) matched to your SoC variant (SA8155P vs SA8295P). The programmer runs in RAM and executes rawprogram*.xml / patch*.xml commands to write UFS.

Board Type	Programmer Requirement
Fuse-open debug ADP	Often accepts engineering-signed or test-signed programmers
Production-fused automotive board	Must use OEM-authorized signed programmer — unsigned loaders rejected
Tier-1 bench with fixture	Fixture may inject authorized programmer automatically

Cross-reference: Page 8.2 (QFIL) covers the full EDL + Firehose flash flow, XML structure, and common QFIL errors.

sequenceDiagram
    participant Host as Host PC (QFIL)
    participant PBL as PBL ROM (EDL)
    participant FH as Firehose in RAM
    participant UFS as UFS Storage

    Host->>PBL: USB connect (QDLoader 9008)
    Host->>PBL: Send signed programmer
    PBL->>FH: Load and execute programmer
    Host->>FH: Configure (UFS LUN, sector size)
    Host->>FH: Program commands from rawprogram.xml
    FH->>UFS: Sector-level writes
    Host->>FH: Reset
    PBL->>PBL: Reboot → attempt normal chain

Fastboot: The Flash Workshop

Fastboot is XBL’s partition-level USB interface. ABL is not running; the Android kernel is not running. You get direct read/write to GPT-named partitions on the current or specified slot.

What Fastboot Can Do

Category	Examples
Partition flash	fastboot flash boot boot.img, fastboot flash modem NON-HLOS.bin
Slot management	fastboot set_active a, fastboot flash boot_b ...
Wipe	fastboot erase userdata, fastboot -w
OEM extensions	fastboot oem device-info, fastboot oem unlock (if policy allows)
Reboot routing	fastboot reboot, fastboot reboot recovery, fastboot reboot bootloader

Unlock Status

fastboot oem device-info (or fastboot getvar unlocked) reports whether the bootloader accepts unsigned or user-keyed images. On production automotive units, unlock is typically permanently disabled by fuse — fastboot still works for signed partition updates but rejects unlock requests.

Cross-reference: Page 8.3 (Fastboot & ADB) for the full command cheat sheet, slot-aware flashing patterns, and vCPU USB routing gotchas.

Where You'll See This

Typical dev loop: iterate on boot.img or vendor_boot.img → adb reboot bootloader → fastboot flash boot boot.img → fastboot reboot → verify on UART + adb shell. Reserve QFIL/EDL for when this loop cannot start because XBL or ABL is broken.

Crashdump / Ramdump Mode

When the kernel (QNX or Linux) hits an unrecoverable fault, you need post-mortem data — not another reboot loop. Qualcomm platforms implement this through a download mode mechanism that PBL reads on the next reset.

How the SoC Enters Dump Mode

1. Running HLOS detects fatal error (kernel panic, watchdog bark, explicit trigger)
2. Kernel or TZ firmware makes an SCM (Secure Channel Manager) call to set the download_mode value in a TCSR register
3. SoC resets (warm reset)
4. PBL reads the register on boot
5. Instead of loading XBL → normal boot, PBL enters dump collection mode
6. A minimal dump agent streams RAM contents (full or partial) over USB to the host

flowchart TD
    PANIC["Kernel panic / watchdog / adb reboot dumpmode"]
    SCM["SCM call: write download_mode to TCSR"]
    RESET["Warm reset"]
    PBL["PBL reads TCSR on boot"]
    DECIDE{"download_mode value?"}
    NORMAL["Normal boot → XBL → HLOS"]
    FULL["Full ramdump: entire RAM → USB"]
    MINI["Minidump: vendor-registered regions only"]

    PANIC --> SCM --> RESET --> PBL --> DECIDE
    DECIDE -->|"0"| NORMAL
    DECIDE -->|"1"| FULL
    DECIDE -->|"2"| MINI

Full Dump vs Minidump

Type	download_mode	What’s Captured	Speed	Use Case
Full ramdump	1	Entire physical RAM	Slow (minutes); large file	Deep kernel/driver analysis; unknown fault location
Minidump	2	Vendor-registered regions only (stacks, ring buffers, known structures)	Fast (seconds); smaller file	Field returns; fleet triage; known subsystem failures
Disabled	0	Normal reboot only	N/A	Production builds where dumps are policy-blocked

Kernel Parameter: qcom_scm.download_mode

On AAOS/Linux builds, the dump policy is often exposed as a kernel command-line parameter:

qcom_scm.download_mode=full    # full ramdump on panic
qcom_scm.download_mode=mini    # minidump only
qcom_scm.download_mode=0       # disable dump mode; reboot normally

QNX-side dump policy is configured in the BSP startup script and dumper service configuration — not via the same kernel parameter, but the underlying TCSR mechanism is the same at the PBL level.

Collection Workflow

1. Board crashes or you trigger adb reboot dumpmode
2. USB enumerates as a Qualcomm dump device (not ADB, not fastboot)
3. Host tool (QCAP, vendor script, or QCEDL utilities) receives the dump file
4. Analyze offline with RAMParser, crash debug symbols, and vendor minidump decoders

Cross-reference: Page 10.4 (Software Debug Toolkit) covers RAMParser, minidump analysis, and correlating dump regions with subsystem owners.

SDI (System Debug Image)

SDI is Qualcomm’s on-chip debug agent for a different post-crash strategy: halt instead of reset. When SDI is enabled and a fatal exception occurs, CPU cores freeze in place. Register files, program counters, and memory contents remain intact — like pausing a video at the exact frame of the crash.

SDI vs Crashdump

Aspect	Crashdump / Ramdump	SDI
CPU state after crash	Reset; cores restart in dump agent	Halted — exact PC, LR, SP preserved
Memory	Copied to host over USB	Inspected in place via JTAG
Hardware required	USB cable + host collection tool	JTAG probe (Lauterbach TRACE32, etc.)
Fuse requirement	Dump policy in BSP (may work on fused production with minidump)	Fuse-open board + debug BSP
Remote analysis	Yes — ship dump file to vendor	No — debugger must attach at bench
Best for	Fleet triage, no JTAG on hand	Register-level debug, stepping from faulting instruction

When SDI Is Worth the Setup

SDI shines when the crash is non-deterministic and the act of resetting destroys evidence — heap corruption, race conditions, or failures where the dump agent itself overwrites the faulting region. Attach TRACE32, inspect the exact instruction, read surrounding registers, and single-step backward through the call chain.

When you lack JTAG hardware, fuse-open access, or Lauterbach licenses, minidump is the practical choice — it captures enough for 80% of kernel panic investigations without halting the silicon.

Common Gotcha

If you try SDI on a production-fused board, it won’t work regardless of BSP settings. SDI requires a fuse-open board and a JTAG connection. Plan your bench accordingly (Page 10.1). Also: SDI halts the system — the vehicle is not driving safely with SDI triggered. Bench and HIL only.

QNX Shell vs Android Shell

On a multi-OS cockpit, your UART console may show output from both QNX and AAOS interleaved on a muxed debug port. Before you type commands, identify which OS owns the prompt.

QNX Console Signatures

Indicator	QNX	AAOS (Linux)
Prompt	# (root) — often no hostname prefix on embedded	$ (shell user) or # (root/adb root)
Typical commands	pidin, slay, use, slog2info, dumper	logcat, pm, am, dumpsys, getprop
Boot log prefix	startup-*, procnto, qnx banner, slog timestamps	[ 0.000000] kernel timestamp format, init messages
Process listing	pidin ar	ps -A or adb shell ps
Kill a process	slay <pid>	kill <pid>

Boot Log Timeline on UART

A successful boot on a QNX + AAOS ADP typically shows:

1. PBL/XBL messages — DDR training, slot selection (no Linux timestamps)
2. ABL/UEFI — partition load messages
3. QNX IFS — procnto startup, driver attach, slog output
4. Linux kernel — [ 0.000000] lines, init first stage
5. Android — init second stage, logd, zygote

If output stops after step 2, you have a hypervisor or guest load failure — not a “shell confusion” problem.

Filtering Interleaved Output

On muxed UART, both guests print concurrently. Practical filters:

# On host terminal — grep for Linux kernel only
grep '^\[' serial.log

# Grep for QNX slog lines (pattern varies by BSP)
grep -E 'slog|procnto|qnx' serial.log

For dedicated access: use ADB for AAOS (adb shell) and qconn/Momentics or a second UART (if routed) for QNX — rather than relying on a single interleaved serial stream.

Mode Transition Flowchart

System stuck? Work this flowchart before random cable swaps.

flowchart TD
    START["System is stuck — what do I do?"]
    UART{"Any UART output\nafter power-on?"}
    PREFIX{"What prefix / banner\n do you see?"}

    PBL_BRANCH["PBL/XBL stage\n(DDR train, no OS)"]
    QNX_BRANCH["QNX boot messages\n(procnto, slog)"]
    LINUX_BRANCH["Linux timestamps\n[    0.000000]"]
    ANDROID_BRANCH["Android init / logd"]

    NO_UART["No UART output"]
    USB_TRY["Try different USB port\nand cable"]
    EDL_FORCE["Force EDL:\ntest point short or DIP switch"]
    QFIL["QFIL recovery\nPage 8.2"]

    TOOLS_PBL["Tools: UART only.\nIf dead → EDL → QFIL"]
    TOOLS_QNX["Tools: UART console,\nslog2info, pidin, qconn,\nEthernet SOME/IP/gRPC"]
    TOOLS_LINUX["Tools: UART + adb\n(if USB routed to AAOS guest)"]
    TOOLS_AAOS["Tools: adb, logcat,\ndumpsys, bugreport"]

    USB_CHECK{"USB device\nenumerates?"}
    USB_EDL["QDLoader 9008 → EDL → QFIL"]
    USB_FB["Fastboot device → fastboot CLI"]
    USB_ADB["ADB device → adb shell / logcat"]
    USB_DUMP["Dump device → QCAP/RAMParser"]

    START --> UART
    UART -->|Yes| PREFIX
    UART -->|No| NO_UART

    PREFIX -->|"PBL/XBL messages"| PBL_BRANCH --> TOOLS_PBL
    PREFIX -->|"procnto / slog"| QNX_BRANCH --> TOOLS_QNX
    PREFIX -->|"Kernel timestamps"| LINUX_BRANCH --> TOOLS_LINUX
    PREFIX -->|"init / zygote"| ANDROID_BRANCH --> TOOLS_AAOS

    NO_UART --> USB_TRY
    USB_TRY --> EDL_FORCE --> QFIL

    TOOLS_PBL --> USB_CHECK
    TOOLS_QNX --> USB_CHECK
    TOOLS_LINUX --> USB_CHECK
    TOOLS_AAOS --> USB_CHECK

    USB_CHECK --> USB_EDL
    USB_CHECK --> USB_FB
    USB_CHECK --> USB_ADB
    USB_CHECK --> USB_DUMP
    USB_CHECK -->|"Nothing"| EDL_FORCE

Memorization Trick

Each mode maps to a one-word purpose. Read them in boot order from bottom to top:

Letter	Mode	One-Word Purpose
E	EDL	Emergency — lowest level, QFIL only
F	Fastboot	Flash — partition-level read/write
R	Recovery	Repair — system fix, sideload, wipe
N	Normal	Native — production state, full toolset
C	Crashdump	Capture — post-mortem RAM to USB

Mnemonic: “Every Fallen Robot Needs Care.” (E-F-R-N-C — add “Care” for the crash branch that catches fallen robots.)

For SDI, remember “Stop, Don’t Ship” — SDI stops the CPU for live inspect; crashdump ships RAM to the host for offline analysis.

What to Remember

1. Identify the mode first — USB enumeration and UART prefix tell you where you are.
2. EDL is the unbrick path — when fastboot and ADB are unreachable.
3. Fastboot is partition surgery — signed images, slot-aware, no running OS.
4. Crashdump captures; SDI freezes — different hardware, different analysis workflow.
5. Fuse state gates everything — production boards may block EDL programmers, fastboot unlock, and SDI.

Common Gotcha

If you assume fastboot or EDL are available without checking fuse state, you’ll hit locked-out debug modes on production boards. On production-fused boards, EDL requires a signed Firehose programmer. Fastboot may be locked — partition flash only accepts OEM-signed images. Crashdump mode may be disabled entirely (download_mode=0). Check debug policy (Page 8.4) before assuming a mode is available.

Deep Dive

The download_mode register mechanism bridges the running OS world and PBL’s boot decision on the next reset.

When the kernel (or TZ via SMC) decides a crash dump is needed, it writes a mode value to a TCSR (Top-Level Control and Status Register) at a fixed SoC-specific address. The write goes through the SCM (Secure Channel Manager) — a TrustZone gatekeeper that prevents arbitrary guest OS code from setting dump mode on every panic spoof.

On the next reset, PBL reads TCSR before chain-loading XBL. The value determines the branch:

Value	Behavior
0x0	Normal boot — load XBL, continue chain
0x1	Full ramdump — stream entire RAM over USB
0x2	Minidump — stream vendor-registered regions only

The register survives warm reset (watchdog reboot, adb reboot dumpmode) so PBL sees the request. It does not survive cold power cycle — yanking 12V clears TCSR, and the next boot goes normal. This is why field instructions say “do not power-cycle after a crash if you need the dump” — cold boot loses the download_mode flag.

On AAOS, expose policy via qcom_scm.download_mode= on the kernel command line. On QNX, the equivalent policy lives in BSP startup and the dumper configuration. Both paths converge on the same SCM → TCSR → PBL handshake.

Connect the Dots

Page 5.2 (boot chain) explains the stage progression that maps directly to the mode ladder — PBL → XBL → ABL → HLOS. Page 8.2 (QFIL) is the operational guide for EDL, the bottom rung. Page 8.3 (fastboot & ADB) covers the fastboot and recovery commands referenced in the matrix. Page 8.4 (secure boot) explains fuse state and why production boards restrict mode access. Page 10.1 (debug bench) maps physical connectors to the entry methods listed here. Page 10.3 (debug interfaces) details UART wiring, JTAG setup, and which tools work in each mode.

Check Your Understanding

1. USB enumerates as `Qualcomm HS-USB QDLoader 9008`. Which boot mode is the board in?

Recall

A. Normal AAOS HLOS with ADB activeB. EDL — PBL ROM waiting for a signed Firehose programmerC. Recovery ramdisk with sideload enabledD. Fastboot (XBL partition flash mode)

2. The board is completely unresponsive: no UART output, no USB device enumeration. Which mode and entry method should you try first?

Applied

A. EDL via test point short to GND during power-onB. Fastboot via adb reboot bootloaderC. Normal boot with a different SD cardD. Recovery via vol-up + power combo

3. You need to flash a single `boot.img` partition without reflashing the entire UFS via QFIL. Which mode and tool?

Applied

A. Crashdump mode + RAMParserB. Recovery + `adb sideload` with a full OTA zipC. Fastboot — `fastboot flash boot boot.img` then `fastboot reboot`D. EDL + QFIL with rawprogram.xml

4. What is the key difference between crashdump mode and SDI?

Applied

A. SDI runs before PBL ROM executes; crashdump runs after AAOS fully boots upB. Crashdump collects RAM to USB for offline analysis; SDI halts CPUs for JTAGC. Crashdump requires JTAG probe connection; SDI works over ADB USB link onlyD. They are the same mode with different names on QNX versus AAOS terminology

5. The download_mode register is set to 0x2 before a watchdog reset. What happens on the next boot?

Synthesis

Connects to: Module 5 — Boot Chain

A. Minidump — only vendor-registered memory regions are collectedB. Normal boot — register value 0x2 is ignoredC. SDI mode — CPUs halt for JTAG attachD. Full ramdump — entire physical RAM is streamed over USB

6. After a kernel panic, field instructions say 'do not power-cycle.' A colleague cold-boots the board by yanking 12V. Why does this destroy the crash collection opportunity?

Synthesis

Connects to: Module 8 — Build, Flash & Update

A. Cold cycle clears TCSR download_mode register — PBL boots normally insteadB. Cold boot permanently blows JTAG_DISABLE fusesC. The Firehose programmer image is erased from SRAM on every cold boot cycleD. UFS A/B slots swap automatically on cold boot

Further Reading

• Android Bootloader Architecture — Google’s overview of the bootloader stack (PBL analog through ABL) that maps directly to the mode ladder on Qualcomm automotive platforms.
• Android Fastboot Protocol — Official fastboot command reference for partition flash, slot management, and reboot routing used in XBL fastboot mode.
• Android Recovery Mode and OTA — Recovery ramdisk design, sideload workflow, and factory reset paths referenced in the recovery row of the mode matrix.
• Android Debug Bridge (adb) — ADB documentation covering adb reboot bootloader, adb reboot recovery, adb reboot edl, and adb reboot dumpmode entry methods from normal HLOS.
• Qualcomm Developer Network — Portal for QFIL, Firehose programmer, and EDL/QDLoader 9008 tooling required for the lowest rung of the mode ladder.
• Android Verified Boot — Explains AVB verification failures that block boot at ABL and why production boards restrict fastboot unlock and unsigned flash.
• QNX Neutrino System Architecture — QNX boot and process model context for distinguishing QNX shell mode from AAOS HLOS in the unified mode matrix.
• Lauterbach TRACE32 — Debugger used for SDI post-crash CPU inspection when download_mode crashdump collection is insufficient or unavailable on fuse-open benches.