手机烧录实战：MTK/高通/展锐三平台工具与避坑指南

简介：这是一份面向设备维修工程师、嵌入式开发者和有一定刷机经验玩家的多平台固件烧录工具集，聚焦 MTK、高通、展锐三家的系统版本升级、线刷与救砖场景。包内围绕 SP Flash Tool、QFIL、展锐专用刷机工具等常见刷机方案，整理了配套驱动、配置与关键下载代理文件，并包含 scatter 解析、固件校验所需组件，可支撑全量升级、增量更新、分区恢复与出厂级烧录操作。资源压缩包大小 181.59MB，共 1031 个文件，以 zip 固件包、hex/bin 镜像、dll 运行库、ini 配置、exe 工具程序为主，同时收录 SDK 头文件、cpp 源码、lib 库文件和 log 日志；这样的结构既能满足直接刷机需求，也为二次开发和故障分析留出了素材。压缩包内还包含 DA 下载代理、批处理脚本、帮助文档等细节，可辅助选择正确的下载模式、匹配固件分区，并降低操作失误带来的变砖风险。已有 1876 人浏览学习，适合具备一定动手能力、希望系统掌握多平台刷机与排障思路的读者参考。

1. 手机烧录为什么绕不开三个平台：不是一套工具能通吃的事

一个项目机从方案商那边回来，硬件上电能不能起来、版本能不能稳定写进去，往往比写 ROM 本身更折磨人。MTK、高通、展锐三个平台的启动引导逻辑完全不同：MTK 走 BROM 加 DA 下载，高通依赖 EDL 与 9008 端口，展锐则靠 FDL 引导后吃整个 PAC 包，任何一套文件的对应关系错了，轻则反复报错，重则整机变砖。这份工具包把三套烧录流程、驱动和封装脚本收在一起，专门给做产线量产、售后维修、方案定制的人复现使用，省的是到处找小工具的功夫。

2. MTK 平台版本升级：scatter 解析与 DA 选择的三个关键点

MTK 的烧录方式和另外两家有本质区别：芯片出厂自带一套 BROM 引导程序，上电后先运行 BROM，再由 BROM 接收 PC 端发送的 Download Agent（DA），DA 负责初始化存储介质并执行真正的镜像写入。烧录能不能一次通过，很大程度取决于 DA 与 scatter 是否匹配目标芯片。

2.1 scatter 文件里的分区粒度：看清 preloader、boot、userdata 的边界

scatter 是 MTK 烧录的核心配置文件。它把整颗 flash 划分成多个分区，每个分区记录起始地址、物理大小与对应的镜像文件名。以下是一份常见的 scatter 节选，里面每一行都对应一个独立分区：

# MT6580_Android_scatter.txt（节选，格式与工具包内文件一致） PRELOADER 0x0 preloader.bin BOOT 0x200000 boot.img SYSTEM 0x8000000 system.img USERDATA 0x30000000 userdata.img

第一列是分区名，第二列是十六进制起始地址，第三列是下载到该分区的镜像文件名。这里有个经常翻车的换算误区：0x8000000 换成十进制是 134217728，也就是 128MB。如果编译出来的 system.img 实际超过这个大小，DA 写到一半会直接报partition size exceeded，而且不会等你说完话。

我会在量产前把每个 img 的实际字节数都列出来，再用 python 或者计算器把 scatter 里的地址逐一比对，确保没有越界。特别要留意 preloader 分区：preloader 负责初始化 DDR 和引导后续装载，它的起始地址和大小写错任何一个字节，机器就直接黑屏，而且烧录工具不一定能发现异常，因为 DA 依然能进 BROM。

分区表还有一个坑藏在“起始地址”本身。多数新平台的 scatter 会把 preloader 放在 0x0，但如果 flash 的固定块大小不是 4K，地址偏移没有对齐，下载时 DA 会报 block alignment 错误。出现这个问题，我会先去查 flash 的 block size，再回去看 scatter 里的对齐规则，很少真去动镜像文件。

2.2 实操：从格式化到全量烧录的封装脚本与命令参数

产线烧录如果用 GUI 点点停停，效率太低，也容易漏选分区。工具包里的flash_mtk.sh把格式化、全量下载、校验三个动作拆开，方便单步观察失败位置：

#!/bin/bash # flash_mtk.sh —— 工具包内置 MTK 平台全量烧录脚本 SCATTER="./scatter/MT6580_Android_scatter.txt" DA_FILE="./da/MTK_AllInOne_DA.bin" # 第一步：格式化 userdata，清除用户数据分区残留 ./flash_tool format --scatter "$SCATTER" --partition userdata # 第二步：全量下载，DA 指定为 AllInOne 版本 ./flash_tool download --scatter "$SCATTER" --da "$DA_FILE" --all # 第三步：校验，确认每个分区哈希与镜像一致 ./flash_tool verify --scatter "$SCATTER" --all

这里三个参数最值得说明。--partition userdata把格式化任务限定在 userdata 分区，不会误伤 nvram 和 persist；--da MTK_AllInOne_DA.bin用的是全兼容 DA，适合不清楚芯片具体批次的维修场景；--all表示写入 scatter 里全部带镜像的分区。

第三步校验不是形式主义。我有一次遇到几十台板子 download 全部到 100%，verify 阶段却发现 system 分区哈希对不上，最后排查是镜像文件在拷贝到产测电脑时被杀毒软件拦截并做了改动。如果不校验，这种异常要等整机开机运行后才会暴露，损失完全不一样。

格式化分区也要按场景区分。全新量产机建议全盘格式化，确保上一批测试残留数据不会带进下一批；单纯版本升级则清 cache 和 userdata 就够，nvram 必须保留。判断标准很直白：凡是涉及串号、IMEI、校准数据的操作，都不要勾选 nvram 格式化。

2.3 参数速查：DA 版本、速率、存储类型与 Secure Boot

在 MTK 平台烧录，四个参数基本决定了成败。我把它们整理成一张速查表，开工前过一遍：

Secure Boot 是我提得最多的一个字段。现在新平台默认开启镜像签名校验，DA 接收镜像后会先验签，签不过直接拒绝下载。看到AUTH_ERR时先别怀疑镜像损坏，回去查 scatter 里的 SECURE_BOOT_EN 和 DA 版本是不是同一次发布，比反复重新下载要省时间。

最后说一个被反复问到的点：工具显示 100% 是不是代表成功？不是。很多版本显示 100% 只表示镜像全部传输到设备端，DA 还在做落盘动作，这个状态很快就会跳走。正确做法是等 verify 步骤通过，或者单独执行一次回读校验，确认分区内容与本地镜像哈希一致。

3. 高通平台版本烧录：EDL 模式与 firehose 协议的四道关卡

高通平台的烧录路径完全不是“打开软件刷镜像”那么简单，它的核心是设备进入 EDL 模式后暴露的 9008 端口。PC 端所有操作都要通过这个端口，把 loader 和镜像按协议传进去，任何一步错了，端口都会卡死或者直接消失。

3.1 EDL 与 9008 端口：Sahara 和 Firehose 协议的边界

高通平台的烧录分两个协议层：Sahara 和 Firehose。Sahara 负责把 firehose loader（通常是prog_firehose_ddr.elf）传进设备内存并执行；Firehose 负责后续所有镜像分区的传输和写入。设备开机后如果检测不到正常的 bootloader，会停在 EDL 模式，PC 端会看到一个名为“Qualcomm HS-USB QDLoader 9008”的端口。

我判断是哪一层出错，基本只看报错的时间点：卡在刚开始几秒就是 Sahara，loader 没有跑起来；进度条过了一半再掉，通常走 Firehose 阶段，问题多半出在 XML 配置或镜像路径上。

9008 端口本身并不会主动消失，它会一直等到 loader 执行完成或被替换。这也是为什么很多人拿高通救砖时，只要端口还在就能反复试错。如果端口直接消失，说明设备已经脱离 EDL，需要重新进一次 EDL 模式。

需要提醒的是，9008 端口显示正常，不代表驱动就是好的。Win10/Win11 下同名端口会被不同版本的驱动抢占，装错驱动时端口能看到，但 QFIL 连接不到。我会打开设备管理器确认端口名称后面有没有额外标记，再开始烧录。

3.2 实操：9008 救砖与全分区烧录的完整流程

进入 EDL 有三种常见方式：短接主板测试点、fastboot oem edl、或按住组合键插入 USB。短接测试点对黑砖最有效，因为不依赖系统；fastboot oem edl适合能进 fastboot 但起不来的情况。

组合键方式在量产机上不完全统一，有的项目是音量上加音量下，有的是单独的一个工程键。工具包里不写死某个按键方案，而是建议先用测试点方式验证端口能否枚举，再决定产线夹具怎么设计。

下面这段是工具包内flash_qcom.sh的参考实现，按高通平台命令行烧录的习惯整理：

#!/bin/bash # flash_qcom.sh —— 高通平台 9008 口救砖/量产烧录 LOADER="./loader/prog_firehose_ddr.elf" RAW_XML="./xml/rawprogram0.xml" PATCH_XML="./xml/patch0.xml" PORT="COM10" fh_loader --port="\\\\.\\$PORT" \ --sendxml="$RAW_XML" \ --patch="$PATCH_XML" \ --search_path="./images" \ --noprompt

参数里prog_firehose_ddr.elf是 Sahara 阶段设备端要执行的 loader，必须与目标芯片系列严格匹配；rawprogram0.xml定义分区布局和每个分区对应的镜像路径；patch0.xml记录分区起始地址修正和扇区对齐信息。--search_path指向镜像所在目录，路径里带空格时务必加引号。

烧录完成后的验证信号不只有“Download Success”：设备端 9008 端口会自动消失，回到正常 USB 枚举状态，这代表 loader 已经完成整个写过程并拉起系统。如果端口还在而工具报成功，我会认为结果是可疑的，需要重新检查 loader 是否被正确执行。

UFS 设备的 XML 与 eMMC 设备不同，rawprogram 里的physical_partition_number会指定 LU 编号，互用 XML 会让 UFS 设备的某个 LU 被错误写入，机器会直接不开机，并且很难回滚。

3.3 rawprogram/patch 的对应关系与常见配置错误

rawprogram0.xml 可以理解成高通平台的“总图纸”，它逐行定义了每个分区写在 flash 的哪个位置、对应哪个镜像文件。patch0.xml 则针对实际 flash 型号做修正，最典型的是扇区大小与不同 eMMC/UFS 的逻辑块对齐。

最常见的错误是跨项目串用 loader。A 项目的prog_firehose_ddr.elf拿到 B 项目上，Sahara 阶段也许能过，但后续镜像写入会乱套，因为里面编译时绑定了平台内存布局。真要救砖，最好找同平台同内存颗粒的官方发布包，通用 loader 是最后手段，能过的概率不高。

另一个隐蔽问题是rawprogram0.xml里的 filename 与实际镜像大小不一致。比如 XML 写死了system.img，目录里放的是同名文件但大小不同，firehose 不报错，写入后系统却起不来，因为分区里的内容已经被截断。我每次都会把 XML 里的<filename>和本地文件大小比对一次，防止这种“表面成功”的翻车。

4. 展锐平台版本升级：FDL 引导与 PAC 打包的完整链路

展锐平台的烧录逻辑和 MTK 有些像，但引导方式拆得更细。ResearchDownload 工具把整个下载过程分成两个明显阶段：先送 FDL1 初始化内存和最小外设，再送 FDL2 作为主下载代理，之后才真正开始写用户分区。

4.1 FDL1 与 FDL2 的分工：从初始化到主代理

FDL1 负责把 DDR 控制器和最小外设初始化好，它运行在非常精简的环境里，只做一件事：为 FDL2 准备好内存和执行环境。FDL2 跑起来后，才具备和 PC 端持续通信、接收大镜像的能力。

FDL1 与 FDL2 必须来自同一个平台发布包。混插不同版本的 FDL，最常见的报错是Load FDL fail，或者开始加载后进度条卡在 0%。我一般会先核对 PAC 包里两个 FDL 的校验值，再检查它们是否都是签名版本。展锐近几代平台对 FDL 的签名校验比老平台严格，手工改过的 FDL 文件基本不可能被接受。

还有一个细节：FDL 的加载顺序不能被跳过。有些工具支持直接选择某个镜像文件开始，但底层仍然会先加载 FDL1，再加载 FDL2。如果工具配置里把 FDL1 的加载项去掉，下载永远不会启动，设备端也没有任何反应。

4.2 实操：ResearchDownload 的升级模式与量产模式怎么选

ResearchDownload 界面里最需要理解的选项是“升级模式”和“量产下载”。量产下载会把整个 flash 按配置重新排布，适合产线首装；升级模式则保留部分用户数据分区，适合售后返修和版本迭代。

工具包里的展锐镜像列表通常以 XML 形式存在，核心内容如下：

<?xml version="1.0" encoding="UTF-8"?> <distribution> <image type="fdl1">fdl1-signle.bin</image> <image type="fdl2">fdl2-signle.bin</image> <image type="boot">boot.img</image> <image type="system">system.img</image> <image type="vendor">vendor.img</image> <image type="userdata">userdata.img</image> </distribution>

XML 里每个<image>的 type 必须与 PAC 包内文件实际名称一致，路径写错一个字母工具会直接 fail，不会自动跳过。system、vendor、userdata这类分区可以按需取舍，但 fdl1 和 fdl2 这两项必须保留，否则整个流程没有引导。

量产模式还要重点看“Format”开关。勾选 Format 会先做整盘低格，时间更长，但能彻底清掉上一版残留；升级模式下一般不勾，否则串号和校准数据都会丢失。部分版本的工具把 Format 选项藏在高级菜单里，第一次使用时要主动找一遍。

4.3 系统版本升级时最容易少配的三个分区

展锐项目升级时最容易漏配的是nvram、wcn和persist三个分区。nvram存串号与蓝牙/Wi-Fi 地址，wcn放无线校准参数，persist保存传感器校准和部分产品级信息。

一旦这三个分区被覆盖或清空，机器能开机但功能残废：电话打不出、Wi-Fi 连不上、摄像头拍照异常。这类问题很难在产测环节被系统性拦截，因为很多产测项目只检查开机和基本功能，不会逐台验证串号。

我的策略是在升级模式的白名单里强制保留这三个分区，只在整机返厂恢复或出厂重置时才放开。量产模式下也要在 XML 或工具的勾选界面里确认它们没有被标成格式化对象，否则几百台机器一次性丢串号的场面，售后那边会直接炸锅。

5. 烧录工具避坑：跨平台最容易翻车的五个现场

以下五条来自实际产线和个人维修台的经验，每一条都可以在十分钟内复现，也都花了我不少时间才定位到根因。

5.1 现象一：MTK 平台识别不到设备，工具一直停在“Download DA”

现象：设备插入 USB 后，SP Flash Tool 长时间停在 Download DA 阶段，进度条不动，端口不消失。原因：最常见的是 DA 版本与芯片不匹配，BROM 能正常枚举，但 DA 无法初始化 flash 控制器；其次是 USB 线只具备充电能力，数据链路根本没有建立。解决：先换一条确认过数据传输的线材，再把 DA 替换成平台对应版本；如果还卡在相同位置，拔掉设备重新插入并按住音量键让它再次进 BROM。

5.2 现象二：高通平台 QFIL 报错 “Sahara protocol fail”

现象：QFIL 连接 9008 端口后几秒内直接报 Sahara protocol fail，loader 没有成功执行。原因：firehose loader 与芯片不匹配是最主要因素；其次是一些老 9008 设备在 USB 3.0 口上的兼容性差。解决：先换 USB 2.0 接口，并给目标板单独供电；再确认prog_firehose_ddr.elf来自同平台发布包，不要跨项目挪用。

5.3 现象三：展锐平台下载到一半进度条卡死

现象：ResearchDownload 走到 40% 到 60% 时进度条停住，最终报告 Fail to download。原因：大部分是 PC 端 USB 睡眠导致通信中断，也有 USB 线材接触不良的情况。解决：在系统电源管理里把 USB 选择性暂停关闭，换一根短一些的线材，最好选带屏蔽层的工装线，而不是普通手机充电线。

5.4 现象四：版本升级后串号丢失、Wi-Fi MAC 全零

现象：开机后拨号盘输入*#06#没有串号，Wi-Fi 开关打不开，日志里 MAC 地址都是 00。原因：烧录过程中把 nvram 或 wcn 分区一起格式化，校准数据没有备份也没有回写。解决：升级前先对这两个分区做单独回读备份；量产模式必须勾选保留对应分区，售后维修机要在校准完成后重新写入。

5.5 现象五：换电脑之后工具无论如何都识别不到

现象：同一台设备在 A 电脑上烧录正常，换到 B 电脑后三个平台工具都认不出，设备管理器连感叹号都不带。原因：B 电脑之前装过冲突版本的驱动，VID/PID 被旧驱动注册信息占用；或者线材在搬运过程中被拉扯损坏。解决：先彻底卸载驱动残留，再打开设备管理器手动指定驱动路径，不要选自动搜索；线材直接换掉再试，避免浪费时间排查软故障。

6. 把三个平台的烧录收进同一个脚本：校验、日志与补救技巧

三套工具各管各的，最怕就是拿错了项目包。后来我把所有烧录动作统一收进一个入口脚本，按平台名分派，再补一道日志校验，产线上的人只需要记住./flash.sh mtk这种最简单的命令。

6.1 平台分派脚本的写法

入口脚本flash.sh只负责根据参数调用对应平台的封装脚本，代码如下：

#!/bin/bash # flash.sh —— 统一烧录入库脚本，按平台分派 case "$1" in mtk) echo "开始 MTK 平台烧录..." && ./flash_mtk.sh ;; qcom) echo "开始高通平台烧录..." && ./flash_qcom.sh ;; sprd) echo "开始展锐平台烧录..." && ./flash_sprd.sh ;; *) echo "用法: ./flash.sh [mtk|qcom|sprd]" && exit 1 ;; esac ./check_log.sh

check_log.sh是最后一道自动检查，作用是把烧录日志里的成功关键字捞出来，没有命中就红字提醒，避免“工具显示烧完，但日志里全是警告”的情况：

#!/bin/bash # check_log.sh —— 日志关键字校验 if grep -E "(PASS|Download Success|verify ok)" ./logs/latest.log; then echo "烧录校验通过" else echo "日志中未发现成功标记，请人工复核" fi

这套逻辑并不复杂，但能强制每个操作者都走一遍成功标记检查，而不是凭经验判断。

6.2 我看日志的习惯：只看 PASS 不够，还要看连续烧录耗时

单台机器 PASS 只能说明这一次下载没出错，产线更怕的是偶发失败。我会在几十台板子连续烧录后，把所有日志里的耗时和校验状态拉成一张表，观察有没有越烧越慢的趋势。曾经有一批板子前二十台全部 PASS，第二十五台开始偶发verify hash mismatch，查到最后是测试探针老化、接触电阻变大。如果只看单台 PASS，这个问题会等到客户那边退机才被发现。

从那以后，我每次支持产线都会强制走一遍“成功标记 + 连续烧录耗时”的双重检查，确认没有悄悄出现的偶发失败。这份工具包里的脚本和日志模板，就是按这个思路整理的，希望帮到你。

本文还有配套的精品资源，点击获取