简介：海思HiTool烧写工具是一套面向海思芯片方案的硬件烧录与调试工具集合，适合嵌入式开发、电视机主板维修及固件升级场景。包内含HiDebugger调试信息抓取、HiBurn镜像烧写/上载、HiReg寄存器读写、HiFastplay开机画面与瞬播镜像制作等多个模块，覆盖从调试信息抓取到分区表烧写的完整链路，软硬件开发者均可借助它完成芯片级操作。资源打包为rar格式，共1220个文件，大小约166.47MB。主要文件类型包括jar、cfg、dll、xml、exe等，其中cfg用于配置连接与烧写参数，dll提供串口通信与底层驱动支持，exe为可运行的图形界面工具，另有svf、bin等固件相关文件，可适配多种海思型号的烧录需求。包内还包含大量芯片配置与调试脚本，便于按具体处理器型号快速查找对应参数。目前已有3220人学习下载，适合需要处理海思平台升级、救砖或调试的用户。借助HiTool，可完成固件升级、镜像烧写、寄存器调试与开机画面制作等任务，配合丰富的工具模块和清晰的目录结构，能有效缩短开发调试周期，是一套实用性较强的海思方案开发与维护工具集。

1. 海思HiTool烧写工具解决什么问题：先处理一个“卡在3%”的现场

拿到一块新板子，上电，打开海思HiTool烧写工具，点烧写，进度条停在3%，串口日志没有任何输出。这个场面在很多人的项目里都出现过，问题往往不在工具，而在对烧写链路的理解。海思HiTool烧写工具是海思芯片方案配套的PC端烧录软件，它解决的核心问题只有一个：把编译好的固件可靠地写入板载存储（eMMC、SPI NOR、NAND等），让目标设备能正常启动进入系统。它通过串口或网口与板端通信，下载、校验、写入一气呵成。适合的场景很明确：开发阶段频繁改固件、产线批量烧录、板子启动异常需要恢复最小系统的时刻。这篇笔记直接按“先懂原理→照着操作→避开常见坑”的顺序来讲，内容全部围绕海思平台的实际烧写流程展开，不管是刚接触的新手还是已经烧过几轮的老手，都能在对应环节找到自己能用的东西。

2. 前置概念：烧写通道、启动流程和文件角色

2.1 串口与网口两条路径如何取舍

海思平台的烧写路径有两条：一条走串口，一条走网口。它们在HiTool里对应两种烧写模式，选错一条会直接导致烧写失败或速度慢到无法忍受。

串口烧写走的是UART通道，板端在BootROM或uboot阶段接收PC发来的数据，再写入存储介质。优点是对硬件环境要求低——只要有一根USB转串口线、板子能进烧写模式就能干；缺点是慢。115200波特率下传输速率大约11KB/s，一个30MB的文件要烧接近一小时，产线基本没法用。debug阶段或者板子网络不通的时候，我一般只用串口烧最小系统：一个uboot或一个内核镜像，烧完能进uboot就行。

网口烧写走的是以太网通道，板端uboot起来后通过网络协议接收PC端数据。速率比串口高两到三个数量级，整包烧写（uboot+kernel+rootfs）在三五百兆的固件量级下，几分钟就能完成，是产线和日常开发的主力路径。代价是：必须保证PC端与板端网络能通，且板端uboot能正常启动到网口命令阶段。如果板端uboot本身坏了、DDR初始化不过，网口烧写无从谈起，这时候只能退回串口，先通过BootROM把uboot救回来。

两条路径在HiTool里的入口位置不同，串口烧写对应“串口烧写”标签页，网口烧写对应“网口烧写”标签页，界面里需要手动指定端口、波特率或IP地址。在开始之前明确当前板子处于什么状态，是选择通道的第一步。

2.2 从BootROM到文件系统：烧写动作发生在哪一步

要理解烧写过程，先要理清板端从断电到进系统的启动链。芯片内部有一段固化的BootROM，上电后先执行BootROM，它负责初始化最小硬件环境，然后从外部存储介质（eMMC的boot分区、SPI NOR头部或NAND起始块）加载bootloader，也就是常说的uboot。uboot初始化DDR、网卡等外设，再加载内核；内核挂载rootfs，系统起来。

烧写动作可以发生在两个阶段：一是BootROM阶段，芯片内部逻辑直接通过UART接收数据并写入存储；二是uboot阶段，uboot已经跑起来，通过网络或串口接收数据再写存储。HiTool对这两种情况都支持，差别体现在界面上：BootROM阶段烧写时，芯片型号和DDR配置必须选对，因为DDR还没初始化，配置错了整个烧写流程直接卡死；uboot阶段烧写时，DDR和网卡已经就绪，烧写任务只需要关注数据链路稳定。

文件角色是另一个容易混淆的维度。一块板子要能正常启动，至少需要三个角色：bootloader（负责引导）、内核镜像（负责启动操作系统）、根文件系统（提供用户空间环境）。在HiTool里它们对应不同的烧写分区，写在存储介质的不同位置。很多新手拿到一个烧写任务，把所有镜像文件一股脑挂上就点开始，结果分区错位、uboot找不到内核，板子起不来。搞清楚每个文件该写在哪个分区、分区在介质上的偏移多少，比点“开始烧写”按钮更重要，这块放到第4章详细展开。

3. 从连接检查到整包烧录：一步步操作与参数怎么填

3.1 最小硬件连接与串口环境准备

先做最基础的硬件连接检查。板端串口调试口一般是三根线：TX、RX、GND，通过USB转串口线接到PC。这里有两个容易翻车的地方：TX RX需要交叉连接，板端TX接转接板的RX，板端RX接转接板的TX，接反了日志没有、烧写也连不上；第二，必须共地，GND不接会出现电平基准不一致，串口通信时好时坏。

接线完成后在PC端安装USB转串口芯片的驱动，常见的芯片方案有CH340、FT232、CP2102等，对应驱动各不相同。装完后在设备管理器里确认串口端口号，记下来。然后打开一个串口终端（SecureCRT、MobaXterm这类均可），按板子的默认波特率（常见115200）连接，给板子上电，观察终端是否输出uboot启动日志。这一步能通，说明串口链路没问题。

# Linux下用minicom查看串口是否通
# -D 指定设备节点, /dev/ttyUSB0 根据实际情况改
# -b 指定波特率, 海思平台默认多是 115200
minicom -D /dev/ttyUSB0 -b 115200

这段命令的作用是快速验证串口链路是否可用。如果minicom窗口里没有任何输出，先查驱动有没有识别到USB转串口设备，再检查TX RX是否接反，最后确认板子是否在上电状态下有实际启动动作。注意，有些板子需要按住烧写按键或拨到烧写模式才会进入BootROM收数据，单纯上电并不一定走烧写流程。

3.2 创建烧写任务：选介质、导XML、配网口

串口链路确认后，打开HiTool工具。第一步是选择芯片型号，这一步决定后续所有协议和行为参数。选错型号，连接后通信协议对不上，日志会停在初始化阶段。芯片型号必须和板子实际使用的主控一致，参考原理图或物料清单确认。

第二步新建烧写任务。任务向导里会依次让选择烧写通道（串口/网口）、存储介质（eMMC/SPI NOR/SPI NAND等）和传输方式。存储介质选错是重大事故源头：板子上是eMMC，任务里选了SPI NOR，HiTool会按SPI NOR的分区布局去写，即使烧写成功，板端uboot按eMMC地址读数据也什么都读不到。

第三步导入分区表XML。HiTool里点“烧写eMMC”或“烧写SPI NOR”入口后，有一个导入分区表的功能。这个XML文件定义每个分区的名称、起始地址、大小、烧写入口和校验方式。官方发布的SDK包里一般自带对应方案的XML模板，优先用模板再按需增删。

第四步逐个分区绑定镜像文件。XML里每个分区对应一行，每行右边有一个浏览按钮，选择该分区要烧写的实际镜像文件。镜像文件名要能对应上分区角色，避免把kernel文件挂到uboot分区。

网口烧写模式下，还要配置网络IP。常见做法是PC端设一个固定IP（比如192.168.1.100），板端uboot里设置IP为同网段（比如192.168.1.10），并且把serverip指向PC地址。HiTool主界面里也有对应的IP填写框，两者需要一致。板端的IP可以在uboot命令行里临时设置：

# 在板端uboot命令行执行, 设置板端IP和PC端IP
setenv ipaddr 192.168.1.10
setenv serverip 192.168.1.100
saveenv

注意，saveenv不是必须的，临时调试可以不保存，重启后恢复原值；产线烧录建议确认环境变量正确后再保存，以免后续烧写端环境混乱。板端IP和PC端IP必须在同一网段，且不能被其他设备占用，否则网络握手成功但数据传输超时。

3.3 烧写过程的4个阶段和每阶段的日志看点

点“烧写”按钮后，HiTool日志窗口会滚动输出状态信息。整个过程可以拆成四个阶段，每个阶段关注的日志关键词不一样。

阶段一是连接与握手。串口模式下，板端BootROM或uboot会回传握手应答，日志里出现“Validating...”“Connection established”字样。网口模式下，uboot会反馈链接建立信息。如果日志一直停在“Waiting for connection”或者反复重试，先检查通道选择是否正确、板端是否真的跑到了对应阶段，再检查端口是否被其他软件占用。

阶段二是DDR初始化与准备。BootROM烧写模式下，HiTool会根据芯片型号下载一段初始化代码到板端DDR测试内存。日志里出现“DDR training”“DDR init”相关输出，说明正在做内存初始化。这个阶段最容易失败，日志卡住不动十有八九是DDR颗粒型号与代码里的配置不匹配。

阶段三是数据传输。日志按文件逐条显示发送进度，每个文件开始和结束都有记录。传输中断、进度条停在某个百分比不动，优先查网线、网络协商速率、串口数据线质量，其次查目标分区空间是否够用。

阶段四是分区写入与校验。HiTool每写完一个分区会做一次校验，校验方式在分区表里指定（常见为MD5或文件大小对比）。日志里出现“Success”“Verify OK”表示该分区已落地。全部完成后板子复位，能进系统就是成功，进不去就按第5章的排查套路逐个看。

4. 镜像文件与XML分区表：这层关系先理顺

4.1 分区表的每一项对应什么角色

HiTool的分区表XML是整个烧写流程的地图。它决定每个镜像文件写入存储介质的哪个偏移位置、占用多大空间。在eMMC方案里常见的分区角色如下：

分区名	镜像文件	作用	烧写入口	易错点
fastboot	u-boot.bin	引导程序，上电最先执行	BootROM阶段优先写入	必须写在介质起始位置
bootargs/param	bootenv.txt等	启动参数、环境变量	依赖前一分区	内容错误会导致kernel启动参数异常
kernel	uImage/Image	操作系统内核	需在fastboot之后	与rootfs版本不匹配时会反复重启
rootfs	rootfs.img	根文件系统	需内核匹配	分区大小不足会校验失败
userdata	app.img等	应用数据区	可最后写入	尺寸和实际镜像差异过大会浪费空间

XML里每条记录一般有这些属性：分区名、挂载分区类型（bootloader/kernel/rootfs等）、起始地址、分区大小、镜像路径、擦除标志、校验标志。以eMMC为例，fastboot分区典型起始地址是0x0，大小留8MB~16MB；kernel分区一般在几MB到几十MB之间；rootfs根据构建内容决定大小。地址和大小单位、字节序在XML里有严格约定，改错一个数字，后面所有分区的实际落点都会偏移。

新手常犯的一个错误：把烧写完的分区大小等同于镜像文件大小。实际上镜像文件往往比分区小，剩余空间是空的。分区大小是用来约束HiTool擦除和校验范围的，不是文件体积。如果分区大小填得比镜像还小，HiTool会直接报错或截断写入，起到的效果就是分区写入了但数据不完整。

4.2 手动改分区表的边界和风险

官方SDK自带的XML模板是经过验证的，改动它等于在动启动链路的基础坐标。实际开发中确实需要改分区的场景主要是两个：rootfs扩容（应用包太大、默认分区装不下）、新增业务分区（日志、缓存、OTA备份）。这两个改动本身合法，但要注意连带影响。

改rootfs分区大小，意味着它后面的所有分区地址都要顺延。如果你只把rootfs分区加大，后面userdata的起始地址还是旧的值，烧写的时候HiTool按旧的偏移写userdata，这部分数据会覆盖到rootfs区间或者落到错误位置。正确做法是：把rootfs和它后面的所有分区一起重新规划，保持连续性。

另一个风险点是分区对齐。eMMC和NAND的擦除块大小有对齐要求，分区起始地址如果不对齐，烧写时擦除操作会跨块，轻则性能下降，重则写到一半报错。模板里已有的地址一般是对齐好的，自己新增分区时最好沿用已有地址的步进规律。

<!-- 分区表XML片段示例: 仅展示字段含义 -->
<partition name="fastboot" type="bootloader" addr="0x0" size="0x800000" file="u-boot.bin" erase="true" verify="true"/>
<partition name="kernel" type="kernel" addr="0x800000" size="0x2000000" file="uImage" erase="true" verify="true"/>
<partition name="rootfs" type="rootfs" addr="0x2800000" size="0x10000000" file="rootfs.img" erase="true" verify="true"/>

这段XML模拟了三个分区的定义。addr是十六进制起始地址，size是十六进制空间大小，file指向本地镜像路径，erase决定烧写前是否擦除，verify决定是否校验。注意kernel的起始地址是0x800000，刚好接在fastboot的0x800000大小之后，rootfs又在kernel之后连续排布，顺序和连续性都保持严格一致。实际项目中直接把这三行粘进任务之前，务必确认芯片方案对应的地址位宽和页面大小，不同eMMC型号的boot分区布局也有差异。

改完分区表后的验证方式很简单：先烧一个最小系统（fastboot+kernel），确认板子能启动，再烧完整分区表。不要一上来就整包烧，否则报错时很难定位是地址错位还是文件本身的问题。

5. HiTool烧写避坑：5个常见失败现象与排查

5.1 现象：连接后卡在“Sending”，随后掉线

这个现象在项目里特别玄学：HiTool能识别到板子，日志也显示开始发文件，但发到一半断开，重试几次还是同一位置失败。原因排查后发现，多半不是HiTool本身的问题，而是板端串口被另一个终端软件占用了。PC上开着SecureCRT连了同一个串口，HiTool再连就出现句柄冲突；或者Windows驱动给USB转串口设备分配了中断优先级，占用后HiTool拿不到数据。

解决方法是先关掉所有正在占用该串口的软件，再重新打开HiTool连接。如果之前用过串口终端，可以先断开，但注意有些终端软件关闭后还会在后台持有句柄，需要到任务管理器里确认进程退出。另外检查一下驱动层的端口复用，在设备管理器里确认没有多个程序同时挂载该端口。

5.2 现象：网口烧写卡在DDR初始化失败

网口烧写模式下，进度条没起来就报DDR init错误，日志输出类似“ddr training fail”。这是BootROM网口烧写时最常见的一类失败。原因通常是两个：DDR配置参数和板子实际内存颗粒不匹配，或者DDR供电不稳导致训练过程失败。

第一个原因更常见。同一款主控可能搭配不同厂商、不同容量的DDR颗粒，烧写程序里的DDR初始化模板不可能覆盖全部兼容型号。排查时先确认板子物料清单里的DDR颗粒型号与选项是否一致，不一致就到uboot源码里修改ddr参数重新生成镜像。值得注意的一个细节：DDR频率设置过高也可能导致训练失败，适当降一档频率（比如从1800M降到1600M）会让训练过程更稳定。

5.3 现象：eMMC烧写极慢且校验失败

网口烧写大镜像时，速度远低于预期，每个分区都要烧很久，最后校验失败。排查网络协商状态：板端网口PHY可能协商成千兆，但网线是百兆线或者接触不良，导致实际链路不稳定，重传率高。另外PC端网卡的节能模式也会干扰大文件传输，出现周期性掉速。

解决路径是三步：换一根确认支持千兆的网线；在PC网卡属性里关闭节能以太网和绿色以太网选项；如果板端uboot支持，强制百兆模式烧写，传输速率虽降但稳定性提升。还要确认板端PHY芯片的驱动加载正常，有些方案在uboot下不自动初始化PHY，需要手动配置寄存器才能建立千兆链路，这种情况下保持百兆是更实用的选择。

5.4 现象：烧写成功但uboot起不来，启动串口打印乱码

这是最容易让人崩溃的场面：HiTool日志全部显示Success，分区校验也通过，断电重启后板子完全没有启动迹象，串口输出乱码或空白。原因多半在分区表地址与板端uboot期望的位置不一致。典型场景是：烧写任务里把fastboot写到eMMC boot1分区，但板端BootROM默认从boot0读取引导，写错boot分区导致找不到引导程序。

解决方法是打开uboot源码或对应芯片手册，确认BootROM的引导顺序和烧写任务里选择的boot分区一致，然后用HiTool重新指定正确入口再烧。另一个常被忽略的点是uboot镜像本身编译时选错了存储介质类型，NAND方案的uboot烧到eMMC上，即使地址正确也运行不起来。

5.5 现象：复位后反复重启，日志一直在uboot阶段循环

烧写完成能进uboot，但每次加载kernel都失败，板子反复重启。排查原因：内核镜像和rootfs不匹配，两者来自不同发布版本。比如kernel编译时开了新的文件系统特性，但rootfs还是旧版本，没有对应的支持模块，挂载时直接panic复位。另一种情况是kernel分区实际写入的地址与uboot的bootcmd环境变量不一致：uboot按bootcmd里的地址读内核，但烧写时内核落到了别的偏移。

处理方法分两种。如果是版本混搭，去拿同一发布版本号下的内核和rootfs重新整包烧写，不要交叉混用。如果是bootcmd错误，在uboot命令行里用printenv查看bootcmd和bootargs，改掉里面的内核加载地址和分区名，再saveenv保存。改完后重新烧写一次kernel分区。

6. 进阶技巧：从烧写进度反推板子硬件状态

6.1 分阶段进度百分比的经验判读法

烧写日志不仅告诉你烧到哪了，还暗示硬件状态到哪了。把我自己的经验整理成一套判断方法：串口烧写模式下，0%~10%都算握手和初始化阶段，此时大概率做DDR初始化，失败优先怀疑DDR配置；10%~40%是数据传输阶段，这个区间失败通常是链路不稳、波特率过高或文件太大导致超时；40%~75%进入分区写入阶段，慢是正常的，但如果长时间停滞不动，怀疑目标介质擦除失败或坏块；75%~100%是校验收尾，失败基本就是校验类型不匹配或分区大小与实际数据不一致。

网口模式下的分布略有不同：0%~5%是网络握手，5%~30%是DDR初始化，之后直接进入高速数据传输。网口烧写卡在5%以内时，多数不是板子问题，而是PC网卡、网线、IP配置的问题。这套判读法不是官方定义，是基于多次失败的日志总结出来的经验模型，但实操中很好用，能在几分钟内缩小排查范围。

6.2 烧写后的体检习惯：回读校验与版本确认

烧写完成不等于一切正常，我习惯在烧写后多做两个验证动作。第一是回读校验：用HiTool或uboot命令把关键分区读回来比对哈希值，确认写入的数据和源文件一致。第二是启动后检查系统版本，确认内核、rootfs版本号与预期一致。

在板端Linux系统起来后，通过串口或SSH登录执行检查：

# 查看内核版本和编译时间
uname -a

# 查看根文件系统版本信息文件
cat /etc/version

# 查看分区挂载情况, 确认rootfs挂载正常
df -h

uname -a输出内核版本和编译时间，cat /etc/version确认文件系统对应版本，df -h确认根分区挂载容量正常。如果版本号不匹配，回到第5章的版本混烧排查；挂载异常则检查分区表地址和rootfs大小。

我的一个习惯：每个项目固定一台烧写专用PC，IP、驱动、HiTool版本都保持稳定，不在多个环境之间频繁切换，会省掉大量“昨天还能烧今天就不行”的排查时间。烧写这种事，玄学往往藏在环境变更里。希望这篇笔记能帮你在下一次打开HiTool之前就把问题想清楚，少走几轮弯路。

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