简介面向海思芯片方案开发与硬件调试场景这份烧写工具集成了镜像烧录、调试信息抓取、升级包制作、寄存器读写与开机画面制作等常用功能覆盖海思电视、机顶盒、监控等主控芯片的产线烧录与固件维护环节适合嵌入式工程师、硬件调试人员及产线技术人员使用。资源包共包含1220个文件整体大小166.47MB核心包括jar工具模块、cfg与chip芯片及分区配置文件、dll动态库、svf边界扫描文件等其中jar文件承担各功能模块cfg/chip保存芯片与分区描述dll提供运行支持svf用于边界扫描另有xml、tcl脚本、exe可执行程序辅助配置与自动化操作压缩包可直接部署到Windows环境。已有3220人学习下载长期沉淀为海思方案调试中高频引用的工具集。借助包内的HiBurn烧写、HiDebugger调试、HiReg寄存器读写等组件使用者可完成镜像下载、码流抓取、内存查看、升级包制作与开机画面替换等任务同时附带串口连接、分区表选择等使用说明便于快速搭建烧录环境在主板调试、固件升级和批量产线烧录等场景中显著提升开发与维护效率。1. 海思HiTool烧写工具为什么调试台上那块板子总是卡在 0%一块好好的板子uboot 起来了串口 log 正常USB 线也插了结果你在 HiTool 里点下“烧写”进度条卡在 0% 整整十分钟。这种“玄学”我在调试台上见得太多了真去查十次里有八次不是工具的问题而是驱动没生效、板子没进烧写模式、或者分区表地址填错导致工具直接罢工。海思 HiTool 烧写工具本质上是一套 PC 端烧录方案负责把 uboot、kernel、dtb、rootfs 这些镜像按分区写进 NAND、eMMC 或 SPI NOR目标是把一块空片变成能启动的系统。适合谁做海思方案的嵌入式工程师、产线量产人员、维修返修人员以及刚拿到核心板想快速跑起系统的学习者。这篇文章我按自己实际用下来的思路把通道选型、分区表配置、烧写参数和常见翻车现场一次讲透。2. 烧写前先想清楚通道怎么选、驱动怎么装、板子怎么进烧写模式2.1 USB、串口、网口三种烧写通道边界和适用场景完全不同HiTool 的烧写页面会让你选传输方式常见是 USB、串口、网口三种。很多人第一次用默认选 USB然后卡住以为工具坏了其实是用错了场景。USB走的是 uboot 里的 fastboot 协议目标板 uboot 起来后把自身模拟成一个 USB 设备PC 通过 HiTool 往里灌镜像。优点是速度快、操作直观适合调试阶段和中小批量产线。缺点是要先把 uboot 烧进去而且是板子“活着”才能用。串口走的是串口协议速度慢百兆级别的镜像要等很久。但它有一个不可替代的价值uboot 完全没起来、NAND 里连引导都没有的时候部分海思芯片支持从 BootROM 引导串口下载这是救砖的最后手段。我一般把它当作“保命通道”预备着。网口目标板 uboot 起来后通过 TFTP 从 PC 拉镜像速度比串口快很多适合多块板子同时量产。前提是 uboot 网络环境变量配好PC 端 TFTP 服务正常网络是通的。产线批量场景我几乎不用 USB 一台台插拔太慢了。选型上没有绝对最优我自己的习惯是新板子第一次烧写用 USB因为交互直观、log 清晰uboot 起不来用串口救确认方案稳定后切网口做量产。2.2 装驱动不是双击下一步那么简单用一条命令确认设备是否被识别HiTool 在 Windows 上运行目标板通过 USB 连接到 PC 后需要安装对应的 USB 驱动。坑就在这里驱动文件通常在 HiTool 安装目录的 driver 子目录里而 Windows 的驱动签名策略经常会拦截旧版驱动导致设备管理器里出现一个带感叹号的未知设备HiTool 自然找不到目标板。我建议不要反复插拔线去碰运气直接用 PowerShell 查系统 PnP 设备状态:: 在 Windows 终端管理员权限里检查烧写设备是否被系统识别 powershell -Command Get-PnpDevice | Where-Object {$_.FriendlyName -match Hisilicon} | Format-Table Status,Class,FriendlyName -AutoSize这段命令的逻辑是Get-PnpDevice 读取系统所有即插即用设备通过 FriendlyName 过滤出包含 Hisilicon 字样的设备最后以表格展示三个关键字段。如果在 Status 列看到 OK说明驱动生效可以回 HiTool 继续如果列表为空说明设备没被正确枚举或者驱动没装上。手动安装时记得在设备管理器里选择“从磁盘安装”路径指向 HiTool 安装目录下的驱动文件夹而不是让 Windows 自动联网搜索。这里有个容易被忽略的细节某些开发板需要按住一个按键或者拨码开关才能进入烧写等待状态否则上电后直接正常启动了USB 永远不会枚举出来。所以驱动装不上时先查板子硬件设计上有没有烧写模式控制脚再看串口 log 确认 uboot 是否真的进入了烧写流程。2.3 判断板子是否“愿意”被烧写看串口 log别瞎等很多人在 HiTool 界面点了烧写之后就一直盯着进度条其实正确的做法是先开一个串口终端连接目标板的调试串口确认 uboot 阶段的输出。海思方案的调试串口波特率通常是 1152008 数据位、1 停止位、无校验即 115200-8-N-1。上电后在串口终端里看到类似下面的输出才说明板子进入了烧写等待# 串口终端里观察到的 uboot 启动输出示意 U-Boot 2016.05 (Hi3516EV200) DRAM: 512 MiB NAND: 256 MiB Burn mode: USB 关键行当前烧写通道是 USB Waiting for PC connect...看到 Burn mode: USB 这一行说明 uboot 已经根据烧写标志进入了等待 PC 连接的流程此时再去 HiTool 里点烧写才有意义。如果串口里直接跳到了正常启动内核的 log或者停在某个错误信息上说明板子根本没进烧写模式。常见原因是uboot 环境变量里烧写标志被清掉了或者板子启动时检测到的拨码状态不对。解决办法是先在 uboot 命令行里手动执行进入烧写模式的命令不同芯片的命令不一样常见做法是通过串口在 uboot 提示符下输入对应指令再重新上电。这条经验我在多块板子上验证过凡是烧写卡在 0% 的九成以上是没先看串口 log 就盲目开始烧。3. 分区表 XML烧写方案里最值得花时间研究的配置文件3.1 分区表在烧写里到底管什么不只是“把文件写进去”HiTool 的烧写不是简单地把一个镜像文件丢进 Flash而是按照一份分区表 XML 逐项执行擦除、写入和校验。分区表里定义了每个分区叫什么名字、从哪个地址开始、占多大空间、对应哪个镜像文件、这次烧写要不要更新它。正因为有“要不要更新”这个开关调试阶段的效率可以大幅提升比如 rootfs 没改动的时候可以把 rootfs 的更新项关掉只烧 kernel省掉整片擦写和等待的时间。但同一个开关也是坑。我见过有同事把某个分区的 Update 设成 false烧写完以为系统是新的结果上电发现还是旧内核在产线排查了半小时才发现是分区表没更新。所以分区表在烧写里的地位相当于做饭时的菜谱食材再新鲜步骤错了也是废的。海思不同芯片方案的默认分区表 XML 都是从 SDK 开发包里拿的字段名和结构在不同系列之间略有差异。我的建议是永远拿开发包自带的 XML 当模板只改地址、大小、镜像路径不要自己从零写一个 XML。3.2 一个可仿照的分区表 XML 结构与字段逐个拆解下面是一个简化的分区表示例字段名以你手上开发包实际文件为准但结构思路是一致的?xml version1.0 encodingUTF-8? !-- 简化示例仅供理解字段含义实际使用请以开发包 partition 文件为模板 -- Partition Item typeall PartNameuboot/PartName FlashAddr0x0/FlashAddr Size0x40000/Size File./images/uboot.bin/File Updatetrue/Update /Item Item PartNamekernel/PartName FlashAddr0x100000/FlashAddr Size0x800000/Size File./images/uImage/File Updatetrue/Update /Item Item PartNamedtb/PartName FlashAddr0x900000/FlashAddr Size0x100000/Size File./images/hi3516ev200.dtb/File Updatetrue/Update /Item Item PartNamerootfs/PartName FlashAddr0xA00000/FlashAddr Size0x1A00000/Size File./images/rootfs.squashfs/File Updatetrue/Update /Item /Partition逐项说明PartName 是分区名uboot、kernel、dtb、rootfs 这些名字会被内核 mtd 子系统或 eMMC 分区表引用名字写错可能导致内核启动时找不到对应分区FlashAddr 是起始地址十六进制单位是字节Size 是分区大小也是十六进制字节数File 是镜像文件路径相对于 HiTool 烧写时选择的本地目录也直接对应网口烧写时 TFTP 根目录下的相对路径Update 是这次烧写是否执行写入的关键开关。地址和大小是这整份文件里最需要小心的地方。这些十六进制数字没有换算好轻则烧写工具报错重则烧完起不来。比如 0x40000 等于 256KB0x800000 等于 8MB这些换算要在心里有数别只关心十进制。3.3 地址对齐与容量换算用 Python 脚本把边界算明白NAND Flash 有个特性擦除是按块Block进行的块大小常见 128KB 或 256KB。如果分区大小不是擦除块的整数倍烧写工具在擦除时会连邻居分区一起擦掉导致 uboot 还在kernel 没了。eMMC 虽然没有严格意义上的坏块管理问题但也有擦除组Erase Group的概念通常是 4KB 对齐。手动在计算器里按太容易出错我一般用一段小的 Python 脚本做检查# 检查分区是否重叠、是否按 Flash 擦除块对齐 partitions [ # (分区名, 起始地址, 大小) 单位均为字节 (uboot, 0x0000000, 0x040000), (kernel, 0x100000, 0x800000), (dtb, 0x900000, 0x100000), (rootfs, 0xA00000, 0x1A00000), ] block 0x20000 # 128KB常见 NAND 擦除块大小eMMC 可改成 0x1000(4KB) 再验一次 prev_end 0 ok True for name, addr, size in partitions: end addr size if addr % block ! 0: print(f[ERR] {name} 起始地址未按块对齐: 0x{addr:X}) ok False if size % block ! 0: print(f[ERR] {name} 大小未按块对齐: 0x{size:X}) ok False if addr prev_end: print(f[ERR] {name} 与前一分区重叠) ok False prev_end end if ok: print(分区表检查通过无重叠所有分区均按块对齐)这段脚本的逻辑很简单遍历每个分区做三项检查——起始地址是否是块的整数倍、大小是否是块的整数倍、起始地址是否小于上一个分区的结束地址。任何一项不满足烧写阶段都可能出现奇怪的问题。建议在修改完 XML 后先跑一遍这个脚本再进 HiTool 导入。实际量产中我把 block 分别设置成 128KB 和 4KB 各跑一次确保 NAND 和 eMMC 两种介质都能对齐。这块是踩坑重灾区后面第五章我会再展开说两个真实翻车案例。4. 把镜像真正写进 FlashHiTool 烧写步骤与参数设定4.1 最小可用的 USB 烧写流程照着做就能跑通先给一个我验证过多次的最小流程适用于多数海思芯片方案。步骤不复杂但每一步有讲究打开 HiTool选择芯片型号确保和你的目标芯片一致选错型号工具会直接拒绝连接或者连上后烧写报错。烧写方式选择“烧写”而不是“升级”。烧写直接灌裸镜像升级则要求镜像带升级包头两者不能混用。传输方式选 USB导入分区表 XML确认每个分区对应的镜像路径存在且文件名正确。接好串口线打开串口终端目标板上电并确认进入烧写等待状态。点击 HiTool 的烧写按钮然后给目标板复位或重新上电让 uboot 重新枚举 USB。观察烧写 log直到提示烧写成功再断开、复位目标板进入正常启动流程。这里常被忽略的是第 5 步的时序很多板子要求先点烧写、再给板上电顺序反了uboot 枚举 USB 的时候 PC 端还没有发起烧写会话就会出现等待超时。参数方面HiTool 里如果提供了超时时间设置我会把它调得稍微宽松一些比如 30 秒以上。USB 枚举和 DDR 初始化在第一次烧写时比较慢时间设短了会误报超时。4.2 串口和网口模式下的参数差异别把 USB 的思维带过去串口烧写和 USB 最大的不同在于速度。同样一个 32MB 的 rootfsUSB 可能几分钟完事串口能让你等到怀疑人生。它的适用场景只有一个uboot 已经被擦没了或者 Flash 里是乱数据需要通过 BootROM 串口下载把 uboot 先救回来。操作上只需要在 HiTool 里把传输方式改成串口选择正确的 COM 口号和波特率然后上电等待下载即可。救砖完成后我一般会立刻把分区表里 uboot 的 Update 设为 true用 USB 再完整烧一遍确保不是侥幸起来的。网口烧写的关注点完全在 uboot 网络环境变量上。目标板 uboot 需要知道 PC 的 IP、自己的 IP以及镜像所在路径。常见的环境变量组合如下# uboot 环境变量示例对应网口 TFTP 烧写场景 setenv ipaddr 192.168.1.50 setenv serverip 192.168.1.100 saveenvipaddr 是目标板自己的 IPserverip 是运行 TFTP 服务的 PC IP镜像路径在 HiTool 或 TFTP 服务配置里对应。网口烧写的关键是 PC 防火墙要放行 TFTP 端口否则目标板请求文件时直接超时。HiTool 里网口模式下同样导入 XMLFile 字段的相对路径是相对于 TFTP 根目录的这一点和 USB 模式略有不同我第一次用网口烧写时就栽在这里镜像路径配错目标板反复报 TFTP 超时。4.3 烧完不是终点三种验证手段让烧写结果可信任烧写成功的 log 只能说明“数据发完了”不能证明“Flash 里是对的”。我最依赖的验证手段有三个。第一个是烧写完成后在目标板系统里运行 md5sum和 PC 端原始镜像对比尤其是内核和 dtb 这种关键分区。第二个是检查 mtd 或 eMMC 分区表是否和 XML 里设计的一致。第三个是重启两次确认系统能稳定起来而不是第一次碰巧启动成功。在目标板 Linux shell 里我通常执行# 在目标板 Linux shell 里验证烧写结果 # 1) 查看当前 mtd 分区布局是否与烧写 XML 一致 cat /proc/mtd # 2) 对内核所在分区做 md5 校验mtd 序号以实际输出为准 dd if/dev/mtd3 bs2048 count1024 2/dev/null | md5sumcat /proc/mtd 的作用是列出所有 mtd 分区的名字和大小和 XML 里的 PartName、Size 对比名字或地址差一位说明 uboot 环境和内核 mtd 分区定义不匹配。dd 加 md5sum 的组合是提取 mtd 分区内容计算校验值然后和 PC 端原始镜像的 md5 对比一致才放心。很多人烧完直接断电跑路等到产线反馈整批起不来才回头查是不是镜像本身有问题这个习惯非常危险。5. HiTool 烧写避坑五个翻车现场与排查5.1 现象USB 枚举不到设备“Waiting for PC connect”永远在等串口 log 明明显示进入了烧写等待但 HiTool 界面始终提示未连接。这类问题我在调试中遇到最多。先排查 PC 端设备管理器里有没有出现海思 USB 设备用第二章那行 PowerShell 命令就能确认。如果设备列表为空大概率是 USB 线的问题很多 USB 线只有充电能力没有数据线芯换根线就好。如果设备有但带黄色感叹号是驱动签名问题需要在设备管理器里手动指定驱动目录安装。如果设备已经正常显示而 HiTool 仍连不上可以试试在 HiTool 里先点击烧写、再给目标板复位。USB 枚举发生在 uboot 启动阶段复位后枚举结果会被重新捕获这一招在我手头好几块板子上都奏效。这个问题的核心结论不要盲改 XML先确认物理链路和驱动。5.2 现象分区表导入报地址重叠或者烧完系统起不来HiTool 导入 XML 时如果提示地址重叠通常是把分区地址算错了。我之前有一次把 kernel 起始地址从 0x100000 改成了 0x10000少写了一个 0分区直接撞进 uboot 的范围。工具其实已经做了检查很多人不看报错直接点确认烧完才发现第二个分区把第一个分区覆盖了。更隐蔽的情况是工具不报错、系统起不来。原因往往是分区大小不是擦除块的整数倍导致擦写越界。这类问题用第三章那段 Python 脚本就能提前发现。我的习惯是每次改完分区表先跑脚本再导入 HiTool这个习惯帮我拦下了至少三次批量返工。5.3 现象NAND 烧写显示成功上电反复重启NAND 的坏块处理是单独的一道坎。HiTool 烧写 NAND 时通常有坏块跳过选项如果该选项没开写入过程中遇到坏块可能直接失败或写完后数据错误。另一个重点是 ECC 强度NAND 颗粒要求的 ECC 位数和烧写工具默认配置不一致会出现一种很折磨人的状况烧写时一切正常系统跑一会儿就崩。排查方式先看串口 log 里是否有 NAND ECC 错误或坏块提示再确认烧写选项里坏块处理策略是否打开最后检查 NAND 型号和 uboot 驱动配置是否匹配。NAND 这块确实有点像玄学但本质还是参数匹配问题颗粒手册和 SDK 默认配置对不上时以颗粒手册为准。5.4 现象烧到一半 USB 传输超时进度条卡住不动这个现象一般出现在烧大镜像的时候比如 rootfs 几百 MB烧到一半突然超时。先检查 PC 侧有没有开启 USB 节能模式Windows 的 USB 选择性挂起会在设备空闲时断掉连接把电源选项里的 USB 挂起关掉能解决大半问题。再检查目标板供电烧写大镜像时 Flash 写入电流比正常运行高供电不足会导致 USB 控制器复位。最后一个容易忽略的原因是复位按钮的位置。如果目标板在烧写过程中被误碰复位键uboot 会重启USB 连接当然中断。量产时我会把板子固定好、复位键朝内减少人为误触的可能。这个问题的排查顺序就是先软件后硬件先 PC 后板端。5.5 现象烧写全部成功但目标板启动后跑的还是旧系统所有镜像都显示烧写成功md5 也一致上电后却是旧系统这种矛盾一般指向两个地方。一是 uboot 环境变量里启动参数指定的分区地址和烧写 XML 不一致绕过了新写的 kernel二是板上有多个启动介质比如同时存在 SPI NOR 和 NAND板子实际从另一个介质启动了。先别急着怀疑 HiTool在 uboot 命令行执行 printenv 查看启动参数确认 bootcmd 指向的分区是否和 XML 一致。再查硬件设计上启动介质选择引脚确认上电时选中了你要烧写的介质。我印象最深的一次踩坑就是双介质板子烧写 NAND 成功但启动引脚默认选了 SPI NOR让我在 HiTool 和分区表之间排查了两个小时。6. 把 HiTool 用成量产工具黄金镜像备份与批量烧写习惯调试阶段的烧写是单板的量产阶段考验的是稳定性和可重复性。我强烈建议在做完功能验证之后不要急着格式化板子先通过 HiTool 的读回功能把整片 Flash 完整备份一份命名为黄金镜像。这一步很多人会省觉得开发包里有原始镜像就够了。实际量产中最大的风险不是镜像文件损坏而是某个人改过分区表、调过环境变量原始镜像根本复现不了实际出货配置。有了黄金镜像产线无论如何烧写、修复、返工都有一个绝对正确的参照物。量产批量烧写方面如果板子数量超过几十块我不建议一台台用 USB 烧写效率太低还容易漏按。常见做法是把镜像放到 TFTP 服务器上目标板 uboot 配置好环境变量后通过网口批量拉取。给产线的基本脚本逻辑可以简化成PC 端准备好 TFTP 根目录板子上电后 uboot 自动执行 tftp 下载并写入预设分区。这个流程不需要 HiTool 每一台都点一遍产线工人只需要负责上电和下板。我还有个个人习惯每次拿到一块新板子先把开发包默认的分区表 XML 复制一份到工程目录用日期和板卡型号命名保存所有后续改动都基于这份文件做 diff而不是直接改原文件。最多的一次为了省五分钟直接改了原文件结果两天后量产时发现 a 版和 b 板分区大小不一样整批返工。从那以后分区表的版本管理再没偷过懒。希望这些踩坑换来的习惯能帮到你。本文还有配套的精品资源点击获取