简介这是一份面向设备维修工程师、嵌入式开发者和有一定刷机经验玩家的多平台固件烧录工具集聚焦 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 AgentDADA 负责初始化存储介质并执行真正的镜像写入。烧录能不能一次通过很大程度取决于 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 平台烧录四个参数基本决定了成败。我把它们整理成一张速查表开工前过一遍参数推荐值说明DA 文件优先 AllInOne DA新老平台兼容性好老平台再备旧 DA串口速率921600 bps再高容易丢字节产线稳字优先存储类型autoeMMC/UFS 自动识别失败再手动指定Secure Boot与发布包一致不一致会报 auth fail分区粒度整包全量维修场景可单分区写入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”的端口。我判断是哪一层出错基本只看报错的时间点卡在刚开始几秒就是 Saharaloader 没有跑起来进度条过了一半再掉通常走 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 PORTCOM10 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 version1.0 encodingUTF-8? distribution image typefdl1fdl1-signle.bin/image image typefdl2fdl2-signle.bin/image image typebootboot.img/image image typesystemsystem.img/image image typevendorvendor.img/image image typeuserdatauserdata.img/image /distributionXML 里每个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 failloader 没有成功执行。原因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.shcheck_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这个问题会等到客户那边退机才被发现。从那以后我每次支持产线都会强制走一遍“成功标记 连续烧录耗时”的双重检查确认没有悄悄出现的偶发失败。这份工具包里的脚本和日志模板就是按这个思路整理的希望帮到你。本文还有配套的精品资源点击获取