企业官网建设流程全解析

简介：海思HiTool烧写工具是一套面向海思芯片方案开发与维护的硬件烧录调试套件，适合嵌入式工程师、电视主板维修人员及机顶盒/电视方案调试者使用。它集中了HiBurn镜像烧写、HiDebugger调试信息抓取与码流录制、HiLoader升级包制作、HiReg图形化寄存器/内存读写、HiFastplay开机画面与瞬播镜像制作等模块，可覆盖从底层硬件调试到量产烧录的常见场景。压缩包内共1220个文件，以jar程序组件、cfg配置文件、chip芯片描述、dll动态库、svf烧写文件为主，还包含xml、tcl脚本、exe可执行程序及png界面资源等，整体约166MB，目录按功能划分清晰，便于按需取用。目前已有3220人学习下载。对于需要通过串口或网口烧写eMMC、配置分区表、上载镜像，或排查升级失败、制作自定义开机画面的用户，这套工具提供了完整的图形化操作入口和底层调试能力，是海思平台开发与维修中非常实用的辅助资源。

1. 海思HiTool烧写工具：第一块板子能不能亮，一半看它

海思HiTool烧写工具第一次出现在工程目录里时，多数人以为它不过是个“把文件拖进去、点开始”的小软件。真正上手你会发现，它决定的是板子上电后能不能在Flash里找到可执行的启动代码——uboot被刷坏、分区被清空、新板子空片启动无反应，这些场景全靠它把镜像按地址写进eMMC、NAND或Nor Flash。

它同时面向两类人：一是调试期的开发者，需要反复写入uboot、kernel和rootfs，烧写频率高且每次失败都要自己定位；二是产线侧的测试工程师，要让几十块板子用同一套分区配置稳定复制，参数一旦错就成批量返工。这篇文章按通道选型、网口全流程、分区表核对、高频翻车现场、回读备份的顺序展开，新手能照着完成第一次烧写，熟手也能借边界条件和排查链路省去一些玄学时间。

2. 烧写通道三选一：串口、网口、USB的取舍与边界

打开HiTool之前要先回答一个问题：板子和PC之间用什么物理链路传数据。串口、网口、USB都叫烧写，但它们的初始化依赖、速率和适用场景差别很大。选错通道，后面分区配置再准确，也只会得到一堆超时和枚举失败日志。

2.1 三条烧写通道的链路差异：从物理层看选型

三条通道的本质逻辑是相同的：板子先通过片内引导逻辑完成必要的初始化，再把PC发来的数据写入目标存储介质。差异在于“初始化到什么程度”以及“用什么协议收数据”。

串口是整个链路里最底层的存在。它只需要芯片内部那段固化引导逻辑正常工作，不依赖外部存储里的任何代码，所以当整块Flash被清空、uboot不复存在时，串口依然是唯一可能把板子拉回来的通道。

网口烧写则要求更高一些，它通常借助uboot里的网络协议栈或片内网口驱动完成数据接收，一旦uboot分区损坏，网口烧写往往无法进入正常连接流程。USB通道最快，但板子要先完成DDR初始化，且PC端驱动一旦没装好或者被其他设备抢占，枚举失败会比串口、网口更隐蔽。

2.2 为什么我默认用网口：速度、稳定性与救砖边界

开发期和高频调试场景，我一般会优先走网口。串口烧写一个几十MB的rootfs，用115200波特率大约要十几分钟，期间串口线只要有点接触不良就会中断，重来成本很高。USB虽然快，但板子没正常进入烧写状态时USB设备可能根本不出现，排查起来要同时看驱动、枚举顺序和设备状态。

网口的优势在于它的故障可观察性最好。连接不上时，ping一下就知道链路通不通；IP不在同一网段，提示也足够直接。只要板子uboot还活着，网口烧写几乎是最稳的方案。量产场景另说——大批量板子用网口逐台配置IP太慢，USB整包烧写更合适，但那是另一个话题。

网口烧写的基本条件很朴素：PC网口和板子网口之间能通。常见做法是把PC配置成固定IP，先确认板子的烧写地址，再把两者放在同一网段。我习惯在uboot命令行里先执行printenv ipaddr看板子IP，再据此设置PC的IP。顺序不能反过来，因为板子烧写地址在SDK里往往有默认值，PC去迁就它是成本最低的。

2.3 串口救砖操作：uboot被清后唯一还讲得通的退路

如果操作失误把uboot分区写坏，网口烧写会彻底失效，这时只能回到串口。串口烧写由芯片固化的引导逻辑承载，只要上电时序正常，不依赖Flash内容，所以它能对空片和坏引导分区的板子执行烧写。

串口救砖的步骤相对固定：

1. 用USB转串口连接板子调试串口，在设备管理器里确认识别到的COM口号，避免和其他设备混用。
2. HiTool里选择串口传输方式，波特率先选115200。有些方案支持更高波特率，但救砖时没必要冒险。
3. 导入镜像时分清楚优先级：如果只是uboot被破坏，只烧uboot分区即可，不要顺手把整个rootfs也挂上去。
4. 点击烧写前，确认板子处于可接收状态。部分方案需要按住复位键再上电，或者通过跳线强制进入升级模式，具体看方案手册。
5. 烧写过程中不要碰串口线，也不要断电，串口烧写没有断点续传。

串口速度慢是客观事实，所以量产流程里很少直接用串口烧完整包。常见做法是先用串口烧一个loader，再切换网口或USB烧其余大分区。这个组合流程既能享受串口的救砖能力，又能保住网口和USB的速度优势。

3. 网口烧写全流程：从IP配置到日志判读的可复现步骤

网口烧写看起来只是“选文件、点开始”，实际由四件事组成：PC网口配置、板子烧写模式的确认、HiTool任务装配、日志核对。任何一步被跳过，后面都会变成反复尝试的无效操作。

3.1 先把网口对齐：PC静态IP与板子IP的确认顺序

网口烧写最常见的第一道坎不是工具不会用，而是板子和PC根本不在同一个网络环境里。PC接了无线网卡、板子误插到路由器上、板子IP和PC IP在不同网段——这些情况在日志里通常只表现为卡在链路检测阶段。

Linux下把PC网口配成固定IP的命令很简单：

# 将eth0配为固定IP，实际网卡名以ip link查到的为准 sudo ifconfig eth0 192.168.1.100 netmask 255.255.255.0 up # 先ping一次板子烧写IP，例如192.168.1.10，确认二层链路可通 ping -c 3 192.168.1.10

Windows下用netsh也可以完成同样的事：

netsh interface ip set address name="以太网" static 192.168.1.100 255.255.255.0

这里的关键顺序是：先通过uboot的printenv ipaddr或方案文档确认板子IP，再据此设置PC IP。如果反过来，PC设了个地址但板子根本不在这段，烧写日志会一直停留在等待连接，看起来像工具坏了，实际是网段错了。

另外，这个阶段建议用网线直连，不要经过路由器或交换机。网口烧写协议依赖二层广播发现设备，中间隔了一层路由设备可能直接导致扫描不到目标板。信号干扰、网线断芯这类物理问题在此阶段也要一并排除。

3.2 HiTool烧写任务的核心是XML分区配置，不是拖文件

很多人第一次打开HiTool，会下意识去找“添加文件”按钮，然后逐个拖入镜像开始烧。这个思路本身没错，但它忽略了一个关键点：烧写不是把文件内容“放”进去，而是把数据写到指定的物理地址去。地址从哪来？从分区配置来。

HiTool里新建烧写任务时，通常会要求导入或选择分区配置文件，不少版本里是XML格式。不同SDK的XML字段名略有差异，但核心信息是一致的：

<!-- 某方案的eMMC分区示意，地址与大小均按绝对物理地址填写 --> <partition> <item name="fastboot" type="boot" addr="0x0" size="0x100000"/> <item name="kernel" type="kernel" addr="0x200000" size="0x1000000"/> <item name="rootfs" type="rootfs" addr="0x1200000" size="0x4000000"/> </partition>

每个item对应一个烧写分区：name是分区名，type是镜像类型，addr是烧写起始地址，size是分区大小。type字段很关键，HiTool会按类型决定是否对数据做特定处理，比如kernel镜像和rootfs镜像的处理方式就完全不同。addr必须是物理地址，不是相对偏移，直接对应方案手册里分区表列出的值。

这个阶段要养成的习惯是：导入XML后再把分区表打开对照一遍。XML检查地址是否和分区表完全一致；镜像文件路径是否真实存在；size是否和分区表长度匹配。任何一项不一致，烧写过程本身可能“成功”，但板子起不来。

3.3 从扫描设备到烧写完成：界面点的每一个按钮都有顺序

完成IP配置和分区配置后，真正的烧写操作可以按固定顺序进行：

1. 在HiTool主界面选择对应的方案类型或芯片系列，选错会导致协议栈不匹配，扫描不到设备。
2. 传输方式选网口，填入板子的固定IP地址。
3. 点击设备扫描或类似按钮，观察日志窗口出现连接成功的提示，有些版本会显示设备型号。
4. 导入或加载分区配置，逐项确认镜像文件路径有效，文件没有被其他程序锁定。
5. 勾选需要烧写的分区，首次调试不建议全选，先烧uboot和kernel，跑通后再补rootfs。
6. 点击开始烧写，之后不要断电、不要断开网线、不要动PC的休眠设置。

最后的等待阶段最容易出问题。烧写大镜像时，日志看起来可能暂时停滞，不要急着打断它。大多数HiTool版本在写完一个分区后会有明确提示，再进入下一个分区。如果某个分区长时间不结束且无任何输出，需要按第5章的排查思路处理，而不是盲目重来。

3.4 烧写完成后的验证动作：改启动模式与串口日志确认

烧写完成不等于板子能启动。eMMC方案尤其要注意一个容易被忽略的点：烧写的目标可能是user area，也可能是boot1/boot2分区。部分方案要求uboot烧在user area的固定偏移上，另一部分方案则要求先烧到boot1，再通过eMMC的ext_csd配置切换启动源。

验证动作一般分两步。第一步，复位板子，串口终端里观察是否有uboot版本信息打印出来。如果没有打印，先不要急着认定镜像烧坏，检查串口连接是否松动、波特率是否和uboot输出一致。第二步，进入uboot后执行：

# 查看当前启动命令是否正确指向kernel所在分区 printenv bootcmd

确认bootcmd指向的地址和分区表里kernel的地址一致，再执行reset复位，正常可以看到kernel解压和rootfs挂载日志。走到这一步，才真正算一次完整的网口烧写闭环。

4. 分区表与地址映射：烧写参数为什么必须逐项核对

高频问题里有一个很典型：烧写过程全部通过，日志也显示成功，但板子就是找不到kernel，或者rootfs挂载失败。这类问题十有八九出在分区表与HiTool参数的对应关系上。烧写工具不会校验你的地址是否符合方案设计，它只负责把数据写到你指定的位置。

4.1 一张典型分区表长这样：地址、大小、镜像类型三列定生死

海思方案的分区表通常由SDK提供，可能出现在文档里、uboot环境变量里或者专门的配置文件中。一张典型的示意分区表如下：

注意这里的地址全部是绝对物理地址，不是从0开始逐个累加的偏移量。不同方案之间起始地址差异很大，上一块板子的分区表直接拿到新板子上大概率是错的。这也是为什么“照着之前项目抄一遍HiTool配置”的做法在换方案时特别危险。

4.2 地址换算不是“算”而是“核对”：用一个Python脚本检查重叠

很多人在分区地址上花费大量时间做十六进制加法，其实HiTool填的就是分区表里写明的地址，不需要额外换算。真正需要做的是交叉核对——地址没有重叠、最后一个分区没有越过Flash或eMMC容量。

这类检查用简单脚本比肉眼快得多：

# 分区重叠检查脚本：输入为(名称, 起始地址, 大小)，单位字节 parts = [ ("fastboot", 0x0, 0x100000), ("kernel", 0x200000, 0x1000000), ("rootfs", 0x1200000, 0x4000000), ] parts.sort(key=lambda p: p[1]) # 按起始地址排序 for i in range(1, len(parts)): prev_end = parts[i-1][1] + parts[i-1][2] if prev_end > parts[i][1]: print(f"冲突: {parts[i-1][0]} 结束地址 {hex(prev_end)} 越界进入 {parts[i][0]}") else: print(f"OK: {parts[i-1][0]} -> {parts[i][0]}")

脚本的思路是把十六进制地址转成整数，逐个分区比较前一个分区的终点是否压到后一个分区的起点。真实项目里，我会把每个分区末尾地址打印出来，再和存储介质总容量对比一次，防止最后一个分区越界。脚本只是辅助，人工对照SDK文档仍然不可省略。

4.3 镜像类型选错的现场：启动成功但起不来的典型差异

分区表解决的是“写在哪”，镜像类型解决的是“怎么处理数据”。HiTool里每个分区都要指定类型，常见的有boot、kernel、rootfs、data等几类。

镜像类型选错的现象往往很有迷惑性。比如把rootfs镜像标成kernel类型，烧写过程完全正常，日志也提示成功，但uboot跳转后kernel打印一段信息就停住了，或者rootfs挂载时报出文件系统格式错误。原因是HiTool对不同类型做了不同的数据处理和校验路径，类型不匹配时数据写入顺序、对齐方式都可能和你实际镜像格式对不上。

分配表里每一项的size也必须准确。size填的比镜像实际大小小，文件系统尾部被截掉，启动时大概率报错；size填得比实际大，则可能覆盖相邻分区，让另一个分区莫名损坏。这里没有玄学，长度、地址、类型三个值只要能跟分区表逐字对上，启动问题基本能消除大半。

5. 海思HiTool烧写避坑指南：5个典型翻车现场与排查链路

烧写工具用久了，遇到的失败场景其实高度重复。下面五条是从实际调试中沉淀下来的高频踩坑记录，每条按“现象、原因、解决”展开，可以直接对照排查。

5.1 网口烧写卡在获取IP超时：先查网段再查网线

现象：HiTool点击扫描设备后长时间停留在链路检测阶段，日志反复打印类似获取IP超时的信息，板子完全没有响应。

原因：最常见的是板子和PC不在同一网段。PC可能开着Wi-Fi自动获取地址，板子的固定地址在另一端；也有情况是网线接到了路由器或交换机上，而HiTool的网口发现机制依赖二层广播，跨设备后无法找到目标板。

解决：用一根网线直接连接板子和PC，关闭PC其他网络接口。进入uboot执行printenv ipaddr或从方案手册查到板子烧写IP，然后把PC网口设置成同网段固定地址，最后用ping验证互通。这一步做完，九成以上的连接超时问题会消失。

5.2 烧写到中途报错：镜像损坏、坏块和供电，三条线一起排

现象：烧写进度走到中途突然报写入失败或CRC错误，重试几次后在不同位置反复失败。

原因：三个方向可能性最大。镜像文件在拷贝过程中损坏，PC端保存的文件和原始文件不一致；NAND Flash本身存在坏块，而烧写配置没有开启坏块处理；板子供电不足，写入瞬间电压跌落导致Flash操作失败。

解决：先对镜像做MD5校验，确认PC上的文件和SDK发布包一致。再看烧写配置里是否勾选了NAND坏块相关的处理选项。最后换一个功率足够的电源适配器，不要用USB口给板子供电。经验法则是：同一位置反复失败的，优先怀疑镜像；随机位置失败的，优先怀疑供电。

5.3 烧完引导分区后板子失联：救砖只能回到串口

现象：第一次烧写时网口还能正常连接，烧完某个分区后板子复位，HiTool再也扫描不到设备，ping也完全不通。

原因：烧写地址覆盖了引导分区，uboot被写入错误数据或全部清空。网口烧写依赖uboot里的网络栈，uboot本身坏了，网口自然失效，板子处于“假砖”状态。

解决：只能走串口救砖流程，重新烧写引导分区。这个情况最好的处理方式是预防：新板子第一次烧写时，先只烧kernel和rootfs，把系统跑起来确认无误后，再单独烧写boot分区。不要一上来就全选烧写，给自己留一条呼救通道。

5.4 串口打开失败：别让COM口被占用还找不到原因

现象：选择串口通道后HiTool提示打开失败，设备管理器里能看到COM口，但工具就是无法占用。

原因：最常见的是其他串口调试软件已经占用了同一个COM口。另一个情况是USB转串口芯片的驱动装错版本，设备管理器显示正常，底层收发却有问题。

解决：关闭所有串口终端和调试工具，在设备管理器里确认COM口号，重新插拔USB转串口模块。如果换了USB口导致COM号漂移，到HiTool里手动重新选择。驱动层面，确认转串口芯片型号，安装对应的原生驱动，不要用系统自带的通用驱动凑合。

5.5 rootfs烧完挂载不上：类型、长度与启动参数要三处一致

现象：uboot正常启动，kernel也能解压，但打印找不到根文件系统，或者挂载时报文件系统格式错误。

原因：三个点最容易出错。HiTool里rootfs分区的镜像类型选成了其他类型，导致数据处理方式不匹配；烧写长度和文件系统实际大小不符，截断或越界；kernel启动参数里的root分区指定和分区表不一致，比如rootfs实际在mtdblock2，参数里却写成了mtdblock3。

解决：到HiTool里核对该分区的类型和长度，确保和镜像特征相符；进入uboot执行printenv bootargs检查root参数。这里有一个容易忽略的点：eMMC和NAND的分区设备号规则不同，不要想当然沿用上一块板子的启动参数。

6. 进阶技巧：量产前用HiTool回读固件，少走半天弯路

HiTool不仅能烧写，还能把Flash里的内容完整读出来保存成镜像文件。这个功能在量产准备阶段的作用，比很多人预期的要大得多。

我在调通一块样板后，做的第一件事不是继续调功能，而是用HiTool的回读功能把uboot分区和rootfs分区完整备份一份。操作上和烧写方向相反：选择目标分区，指定保存路径，工具把数据从Flash读取到PC。回读完成后，执行一次完整性对比：

# 对原始镜像和回读镜像分别计算MD5 md5sum original_rootfs.img backup_rootfs.img

两个文件哈希一致，说明回读链路和数据保存都没有问题。备份文件命名时带上日期和板子批次信息，方便后续追溯。

这个习惯帮我解决过不止一次现实问题。有一回在某个模拟项目X上，需要调整文件系统参数，我改完启动参数后板子彻底起不来，又找不回当初那份调试通过的rootfs，只能凭记忆一点一点恢复配置，花了小半天时间。那个下午的教训就一句话：凡是调通的固件，必须留一份完整的回读镜像作为后悔药。先回读、再改动，谁做谁受益。希望帮到你。

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