RTM default recommendation: Fallback UART + USB bulk when available. | Mode | Data Generated | Bandwidth Requirement | Use Case | |-------|----------------|------------------------|------------| | PC-Only | 4 bytes per instruction | ~200 KB/s (at 100 MHz, 1:1000 sampling) | Locating infinite loops | | PC + Load/Store Address | 12–16 bytes per memory op | ~5 MB/s | Detecting wild pointers | | Register Delta | 2–8 bytes per taken branch | ~1 MB/s | Tracking boot state machine | | Full Execution Trace | All of above | ~50 MB/s (impractical for UART) | Post-mortem analysis with USB |
A automatically downgrades from Full to PC-Only when the host cannot keep up. 5. Implementation Example: Extending MTK (MediaTek) SP Flash Tool 5.1 Current Limitations MediaTek’s BootROM (Preloader v2) already includes a partial trace capability via SEND_DA_EX command with debug flag 0x80, but it only dumps a fixed 256-byte register file on crash. No continuous streaming. 5.2 RTM Modifications Step 1 – Custom Download Agent (DA): Patch the original DA binary ( MTK_AllInOne_DA.bin ) to include a background thread: smartphone flash tool -runtime trace mode-
Document Version: 1.0 Subject Area: Embedded Systems Debugging, Mobile Device Firmware Tooling Target Audience: Firmware Engineers, Security Researchers, Android OEM Developers 1. Abstract Traditional smartphone flash tools (e.g., SP Flash Tool, Qualcomm QFIL, Samsung Odin) operate in a black-box programming mode . They send pre-built firmware images (bootloader, kernel, system) to the device’s memory partitions with minimal runtime feedback. This paper introduces Runtime Trace Mode (RTM) — an extension to conventional flashing tools that enables real-time instruction execution tracing, memory access logging, and register state streaming from the device’s boot ROM and bootloader during the flashing process. RTM transforms the flash tool from a simple programmer into a low-level interactive debugger, crucial for diagnosing boot failures, verifying secure boot chains, and analyzing proprietary bootrom exploits. 2. Introduction Smartphone boot sequences involve multiple stages: BootROM → Preloader → Little Kernel (LK) / U-Boot → Kernel. A single corrupted partition or misconfigured security fuse often results in a dead device (hard brick). Conventional flash tools provide no insight into why the device halts. They only succeed or fail with opaque error codes (e.g., STATUS_BROM_CMD_SEND_DA_FAIL ). RTM default recommendation: Fallback UART + USB bulk
void trace_thread() uint32_t last_pc = 0; while (1) uint32_t pc = read_cp15_register(PROGRAM_COUNTER); if (pc != last_pc) uint8_t packet[8]; packet[0] = TRACE_PC_PKT; // 0xE1 *(uint32_t*)(packet+1) = pc; send_usb_trace_packet(packet, 5); last_pc = pc; for(int i=0;i<1000;i++) asm("nop"); // sampling rate ~100 kHz Abstract Traditional smartphone flash tools (e