
简介面向系统维护与硬件调试人员的 NOVATEK 升级指导 V1.0 文档专门解决 NOVATEK 系统在 XP/WIN7 32 位环境下的固件升级问题并注明可支持整机不拆机直接升级适合需要维护老平台的运维人员。文档覆盖完整升级链路从工具准备到最终烧录完成均有说明包含串口工具、EasyWriter V2011.1019 软件、VGA 线及升级板卡等装备清单和用途解释同时对 EasyWriter V2010 的驱动自动侦测、升级文件加载、Option 选项调整与自动烧录等环节给出逐步图文说明和参数要点提示便于边看边操作。针对升级中可能出现的连接失败、反复无法写入等情况文档还给出了检查接线与 12V 供电、擦除 MCU 后重试等排查思路并说明了烧录完成时的提示信息判断方法有助于技术人员快速定位问题。整个资源为 1 个 doc 文档压缩包大小 1.61MB内容集中可直接查阅。截至目前已有 1958 人学习下载适合需要独立完成 NOVATEK 系统升级或处理升级异常的技术人员参考。1. 一份《升级指导 V1.0》文档值不值得你花一下午很多同行拿到《升级指导 V1.0》这类文件时第一反应是直接翻到“升级步骤”那一页然后找一根USB线开始操作。但真实产线和售后场景里真正让设备变砖的往往不是升级动作本身而是步骤之前被跳过的设备识别和固件校验。在返修设备中常能看到有人把同系列但不同触控IC方案的固件刷进去两个文件名的前缀几乎一样连校验值都写在同一个表格里不仔细看分页就错了结果开机黑屏。这类升级指导文档核心价值是告诉你怎么把一个固件包安全地写到设备里并且确保下一次还能正常启动。它通常适用于显示类、触控类设备比如带屏幕的工控面板、智能家电控制板、自助终端。这类设备的主控方案不像PC主板有完善的BIOS恢复机制一旦升级中途断电或写入错误可能连系统引导都进不去。所以这篇文章的读者应该是需要亲自执行升级的硬件工程师、产线测试人员以及负责售后维修的工程师。你不需要是嵌入式专家但得愿意花10分钟理解版本、校验和文件结构这远比盲目重刷几十次更有用。2. 动手前先读懂升级指导设备识别与版本匹配2.1 确认主控方案与当前固件版本在打开升级包之前先回答三个问题这块板子用的是哪颗主控板卡硬件版本是多少当前固件版本是多少如果答不上来后面的升级大概率是盲操作。常见的一种情形是某开发者把A型主控的固件刷到了B型主控的板子上原因是两块板子外观几乎一样只是电源指示灯颜色略有差异而升级指导文档里明确注明了这两者不兼容但他没有看前几页。先看硬件版本。板子上通常有白色丝印比如HW VER: 1.0或REV: B。这个信息决定固件里的设备树和驱动是否匹配。尤其是触控IC同一块板子可能在不同批次换用了不同型号丝印不一定准确所以最好再通过串口日志确认。下面是我常用的确认脚本# 串口连接设备波特率 1152008N1 # 注意先连接串口再上电否则错过启动打印 stty -F /dev/ttyUSB0 115200 cs8 -cstopb -parenb raw cat /dev/ttyUSB0 echo power on now上电后启动日志会打印主控芯片厂商编号、芯片版本号、构建日期等信息例如CHIP[0x01:0x2345]这样的输出。把日志里所有以CHIP、HW_VER、FW_VER开头的行记录下来这些比丝印更可靠。有些设备会故意在打印里隐藏芯片信息但至少能判断主控方案的大类。再看当前固件版本。如果设备能正常进入系统在命令行下执行# 查看内核版本 cat /proc/version # 查看系统构建信息 cat /etc/os-release | grep BUILD_ID两个命令不一定都存在但能提供一个参考。注意有些方案会把版本号写在启动参数里导致系统界面显示的和实际引导的不一致。我见过一台返修机系统里显示1.2.0但实际引导的是1.1.9的启动环境因为上次升级重启时环境变量没更新。所以不要只信一个来源最终以串口bootloader中version命令的输出为准。确认好这些信息后再打开升级指导文档对照里面的“适用型号”和“版本要求”表。通常文档会有一页列出支持的硬件版本和固件版本要求比如要求当前版本不能高于某个值。如果当前版本高于目标版本大部分升级会被跳过。这个后面会专门讲。2.2 升级包的获取与完整性校验升级包的来源直接决定成功率。官方渠道是最稳的但有些设备厂商不公开下载只能从代理商或论坛获取。这时你需要做几件事第一核对包内文件的生成时间第二比对文档中给出的校验值第三检查包内是否有package.md5文件。三者缺一个都要警惕。完整性校验是防止升级“翻车”的第一道保险。网络传输过程中固件包可能因为FTP的二进制模式设置错误而损坏也可能被第三方工具重新压缩时丢了数据。MD5在十年前够用现在建议用SHA256。Linux下执行# 计算整个升级包压缩文件的 SHA256 sha256sum update_pkg.zipWindows下用命令行certutil -hashfile update_pkg.zip SHA256把输出和官方文档或网站公布的值逐字符比对。注意不要只对比前8位我曾经在帮人排查时发现有同行对比到第16位看到一致就跳过结果后面一位不同刷机后无线模块无法识别。对比时把两个值放到两个文本文件里用diff命令echo 官方哈希值 official.txt echo 本地计算值 local.txt diff official.txt local.txt echo MATCH升级包解压后还要对内部每个文件再校验一次。因为zip包整体完整不代表内部文件没被工具篡改过。很多升级指导文档会在最后一页附一个表列出每个文件的哈希值按它逐一校验。如果文档里没有就看package.md5在解压目录里执行cd extracted_dir md5sum -c package.md5查看输出中是否有FAILED字样。只要有任何一个文件失败就不要继续。因为升级过程通常分阶段写入前面文件写坏了还能恢复后面bootloader写坏了就只能拆机。这一步做足了后面省下的时间以小时计。另外升级前建议保留一份当前正在运行的固件包不管它是不是官方最新版。新版升级包不一定支持旧版回退特别是当新版改了分区大小时强行降级会让文件系统错乱。保留旧包至少给你留一条后悔药。3. 升级包内部结构那些文件名后缀代表什么3.1 典型文件清单与作用第一次打开某主控方案的升级包里面往往是一堆后缀名各不相同的文件。新手容易困惑为什么不能直接把一个文件发给设备其实这些文件分别管理不同的分区分别写入可以避免全量擦除带来的风险。理解它们的作用你才能在升级失败时判断是哪一个环节出了问题。下面是一份典型的升级包文件清单我用通用名字代替具体型号避免对号入座文件名后缀作用bootloader.bin.bin负责启动引导和升级入口通常不允许随意降级env.conf.conf环境变量包含启动参数、升级模式标志和MAC地址firmware.img.img主固件镜像包含系统内核和用户态程序touch.fw.fw触控IC的独立固件校准参数常在其中package.md5.md5记录上述文件校验值的清单表格里的文件不一定都出现但前三类几乎是必备。有些升级包还会带一个upgrade.ini告诉设备哪些文件需要升级、哪些文件必须保留。比如设备MAC地址存在env.conf里而升级包里的env.conf可能只是默认模板如果操作失误就会把设备原本的MAC覆盖掉导致网络冲突。这就是后面避坑章节要展开的。在动手刷机前我建议先把package.md5打开看看。它里面每一行对应一个文件的校验值如果某个文件不在列表里说明这个包可能被裁剪过。很多第三方精简包为了缩小体积把bootloader或touch固件拿掉了表面看升级没问题但后续设备偶发性死机往往就是因为这些缺失文件。另一个值得关注的是文件时间戳同一个版本号的文件如果生成时间相差半年以上说明包是被攒出来的不是一次官方构建遇到这种包最好直接放弃。3.2 用二进制查看工具快速识别固件类型当你拿到一个没有扩展名的文件比如upgrade或fw_2025怎么看它属于哪一类靠文件大小猜不靠谱因为固件镜像和文件系统镜像大小可能相近。最常见的方法是查看文件头部的魔数magic number。Linux下用file命令最省事# 直接识别文件类型 file upgrade # 如果 file 识别不出来用 hexdump 看前 16 字节 hexdump -C -n 16 upgradefile命令会读取二进制头部并与已知模式匹配。比如有些固件以EB 3C引导扇区标记开头有些以厂商自定义的ASCII字符串开头。如果识别结果说它是data那多半不是正常的固件镜像可能是加密后的包。现在不少主控方案对固件做了签名和加密升级指导里会特别强调升级包不允许修改任何字节否则设备会丢弃这个包。有时候同一个包里既有加密的A型固件也有明文的B型固件。file命令可能返回不同的结果但设备上电时的引导日志会打印加载地址和长度。比如日志显示loading from offset 0x4000, size 0x200000对应到文件里偏移0x4000处就是真正的镜像起点。我一般会用dd按偏移切出来再识别避免整包文件头干扰判断# 从 offset 0x4000 开始切 2MB 出来查看 # 0x4000 转十进制是 163840x200000 转十进制是 2097152 dd ifupgrade ofpart.bin bs1 skip16384 count2097152 file part.bin切出来后再用file或反汇编工具看就能确认它到底是什么。如果切出来仍然是data可以再用strings搜索内部可读字符串strings -n 8 part.bin | head -20如果能看到buildroot、initramfs、gzip等关键字就能大致猜测是Linux内核还是文件系统镜像。这个方法对逆向分析或做兼容升级很有用。4. 按文档执行升级U盘、串口与网络三种落地路径4.1 U盘升级最小可用的目录与按键时机U盘升级是工厂和售后用得最多的一种方式因为它不依赖操作系统只要bootloader正常就能执行。但很多人失败在目录结构不对或者按键时机没对上。我先给出一个经过多次验证的目录结构# 在 U 盘上建立如下结构根目录只有一个升级文件夹 /UDISK/ ├── upgrade/ │ ├── bootloader.bin │ ├── firmware.img │ ├── touch.fw │ └── package.md5 └── start_upgrade.sh注意U盘必须是FAT32格式且只有一个分区。很多新U盘出厂是exFAT或NTFSbootloader的USB驱动不一定支持。我通常会先用mkfs.fat重新格式化再建目录。start_upgrade.sh不是必须的但某些方案需要它来触发升级脚本如果你手里的升级指导文档里没提这个文件就不用创建它。按键时机方面常见做法是设备断电后插入U盘同时按住设备上的某个功能键通常是音量或Reset旁的小按钮再上电。bootloader检测到按键按下后会在约3秒内扫描U盘中的upgrade目录。如果你观察到LED闪烁或串口打印find upgrade package说明扫描成功此时松开按键升级自动进行。整个过程可能持续3到10分钟期间断电必砖所以一定接好稳定电源不要用电池或劣质电源适配器。如果按键时机没掌握好可以观察串口日志。下面是一个简单的循环脚本用来等bootloader进入升级模式# 等待设备串口输出升级标志超时 15 秒 for i in $(seq 1 15); do sleep 1 if timeout 1 cat /dev/ttyUSB0 | grep -q UPGRADE_MODE; then echo enter upgrade mode at $i sec break fi done这段脚本本身不执行升级只是帮你确认设备有没有进入升级模式。如果15秒内没有抓到标志说明按键没被识别或U盘文件系统有问题这时不要继续等直接断电重试。否则可能在不稳定的状态下写入半包这种半包状态是最难救的。4.2 串口升级用命令脚本把固件刷进去当设备完全没有系统bootloader也进不了U盘升级时串口往往是最后一道门。串口升级的原理是bootloader通过串口接收固件数据写入Flash速度比U盘慢但兼容性最好。这里提供一个串口升级的bash脚本框架重点在参数配置#!/bin/bash # 串口升级脚本适用于某主控方案的交互式升级 PORT/dev/ttyUSB0 BAUD115200 UPGRADE_FILEfirmware.img # 初始化串口8N1、无流控、raw 模式 stty -F $PORT $BAUD cs8 -cstopb -parenb -crtscts raw # 发送进入升级模式的命令 printf upgrade\r $PORT echo sent upgrade command # 等待设备回复最多 3 秒 timeout 3 cat $PORT | head -1 # 用 zmode 协议发送固件文件 sz -Z $UPGRADE_FILE $PORT $PORT注意第4行的stty参数cs8代表8数据位-cstopb代表1停止位减号代表取消2停止位-parenb代表无校验-crtscts关闭硬件流控。有些USB转串口芯片还需要raw模式配合-F指定设备节点。sz -Z用的是zmodem的Z模式如果bootloader不支持zmodem可以用sx -X走xmodem。xmodem更老但支持率更高缺点是每块128字节速度慢不少。发送过程中终端会显示传输百分比和错误重传次数。如果重传次数很高说明波特率不匹配或者USB转串口线质量差。有一种常见现象是劣质转接线在115200下每传输100KB就错几位换一根短一点的线或者降波特率到57600就好了。另外串口升级时不能有任何程序占用串口比如ModemManager会自动探测设备把/dev/ttyUSB0抢掉发命令没反应。排查时执行lsof /dev/ttyUSB0就能看到是谁占用了。4.3 网络批量升级升级服务器的配置要点产线几十台设备同时升级时U盘一个个插太慢串口更不现实这时候网络批量升级是正确选择。原理是设备在bootloader阶段从网络下载固件包下载完成后本地校验并写入Flash。服务器只要提供一个HTTP或TFTP服务就行。我更倾向于HTTP协议因为TFTP用UDP传输跨网段时容易丢包而且没有校验和重传。设备端只要支持HTTP可以用Python快速起一个服务# 在固件包所在目录启动 HTTP 服务 cd /srv/fw python3 -m http.server 8080设备端通常通过DHCP获取服务器地址和文件名对应DHCP Option 66和67。Option 66是服务器IP地址或主机名Option 67是启动文件名。在常见路由器的DHCP配置里可以这样设置Option值作用66192.168.1.100升级服务器IP地址67/srv/fw/firmware.img升级文件路径如果路由器不支持自定义DHCP选项可以让设备在启动时通过短按按键进入网络升级模式然后手动输入服务器IP和文件名。批量升级前先用一台设备走通全流程再用Wireshark抓包确认HTTP请求正常。python -m http.server是单线程的并发一高就卡死生产环境建议用nginx或lighttpd并限制同时连接数。我一般会在服务器上做一个简单的目录索引页方便直接点击文件名下载也方便从日志里看哪些设备拉取了固件。5. 升级避坑5个容易翻车的细节5.1 现象升级进度条卡在99%后设备变砖这个场景在现场反复出现过U盘升级显示99%然后界面卡死断电重启后设备没反应串口也进不了bootloader。原因是固件写入的最后一步是更新bootloader环境变量此时如果文件校验值不对bootloader会拒绝写入新环境块但旧的环境块已经部分擦除导致系统无法启动。解决方法是不要寄希望于断电重试而是把U盘里的升级包换成官方原始的bootloader镜像最好用串口进入强制恢复模式重新刷一次bootloader。如果串口都不响应只能拆Flash用编程器离线刷写。所以升级前一定要核对package.md5尤其是bootloader文件。99%这个数字并不是设备在撒谎它只是卡在最后100个扇区而这100个扇区的数据恰恰决定了你能不能再次启动。5.2 现象U盘插上没反应日志报USB枚举失败表现为设备上电后没有任何升级提示串口日志里出现usb_device_attach_fail或cannot set address。原因通常是U盘文件系统不是FAT32或者U盘兼容性差。有人用过2.5寸移动硬盘FAT32格式但bootloader枚举失败换成普通U盘立刻就好。解决方法是先把U盘格式化为FAT32。注意Windows下右键格式化只有FAT32选项但如果是64GB以上U盘Windows默认不提供FAT32选项需要借助工具。另一个坑是U盘不能有多个分区很多U盘自带加密分区或安全CDROMbootloader会被迷惑每次枚举都挂上一个无法识别的设备。用parted把整个盘做成一个分区最稳妥parted /dev/sdb mklabel msdos parted /dev/sdb mkpart primary fat32 1MiB 100% mkfs.fat -F32 /dev/sdb15.3 现象串口刷机后MAC地址丢失串口刷机成功后设备能开机但网络中找不到设备检查发现MAC地址是空的或变成00:00:00:00:00:00。原因在于升级包里的env.conf覆盖了设备原有的环境变量而MAC地址就存在环境变量里。大多数批量固件包里env.conf是默认模板没有你的设备实际MAC。解决方法是刷机前先用命令备份环境变量比如在串口bootloader中执行env export把输出保存下来刷机后再用env import恢复。如果是产线建议把MAC烧录独立于固件升级在升级完成后通过一个专门的小工具写入不要依赖升级包。这个坑最麻烦的地方在于设备能正常开机系统不报错只有找到网络中才发现异常排查时容易误以为是路由器问题。5.4 现象版本号回退升级被跳过有时候你明明执行了升级日志显示current version is higher, skip升级包根本没被写入。这是因为升级脚本会自动比较版本号如果目标版本低于或等于当前版本就跳过。常见于返修机已经被刷过更高版本但你不知道。解决方法是检查当前版本并确认是否真的需要降级如果确实需要使用强制升级参数。比如在upgrade.ini里写force1或按特定按键组合进入强制刷机模式。但强制降级有风险如果新版本调整了分区布局降级后可能文件系统不认建议先确认文档里是否明确支持降级。我见过最极端的情况是强制降级后Wi-Fi校准数据丢失机器虽然能开机但无线信号极差最后只能返厂重新校准。5.5 现象升级后触控反向或无响应升级完成后系统正常但触控方向左右颠倒或完全没有反应。原因通常是触控IC的固件与主控固件版本不配套或者升级过程擦除了触控校准参数。某主控方案在升级主固件时可能不会自动烧录触控固件而旧的触控固件与新内核驱动不兼容导致通信异常。解决方法是把升级包里的touch.fw也单独刷一遍然后在设备界面上执行触控校准。如果系统没有校准程序可以通过串口发校准指令。这个坑在换屏维修场景特别常见给设备换了一块触摸屏升级主控固件后触控失效实际要刷的是对应屏幕型号的触控固件而不是主固件。所以升级前一定要确认屏幕型号与触控IC是否匹配。6. 升级后的动作验证、备份与恢复砖机的心得6.1 用串口日志验证升级是否真正生效升级完成不是看到“SUCCESS”就够了我习惯再通过串口确认三个状态版本号、关键分区校验值、校准数据。版本号可以直接看开机日志中的build_variant或者进入系统后执行cat /etc/build_info。关键分区校验值用一个小命令对比# 假设设备系统里有读取分区的工具 dd if/dev/mtdblock3 bs1024 count2048 | sha256sum # 和升级包中对应文件的 sha256 对比 sha256sum firmware.img设备路径可能不同但思路是升级后Flash中的内容应该和升级包完全一致。如果对比不一致说明写入过程中有错误但设备可能没报错这时需要重新升级。6.2 备份当前可用固件的习惯每次升级前我先备份当前版本的整分区镜像特别是bootloader和env分区。这个习惯能救人很多次有开发者拿到一台定制固件的返修机官方升级包刷完功能缺失用备份镜像直接恢复了原状。备份命令通常这样# 通过串口 bootloader 读取 flash 分区 flash read bootloader bootloader.bin 0x0 0x80000 flash read env env.bin 0x80000 0x80000不同方案命令不同但原理一样。备份出来的文件放在项目目录下和固件包一起归档。这样即使后续升级失败也能快速回到可用状态而不是花半天重新配置设备。6.3 砖机恢复的最后手段如果bootloader完全损坏串口没有输出那只能拆机用编程器刷写Flash。操作之前先用酒精清理Flash引脚用夹子或热风枪拆芯片读取原始内容然后找到同一主控方案的官方bootloader写入。这里最宝贵的经验是不要直接写入从别的设备读取的完整Flash镜像因为其中包含那台设备的MAC和校准信息写进来后你的设备将拥有一模一样的MAC网络冲突不可避免。正确做法是只恢复bootloader和env模板然后再通过升级包刷一遍完整固件。这一套流程虽然麻烦但几乎能救回所有变砖设备前提是你提前做过备份没有备份时至少想办法找到官方原始bootloader文件。说到底升级指导文档只是起点真正让设备稳定运行的是你对备份、校验、验证这三件事的坚持。这几年我养成的习惯是任何设备升级前先写一条备份命令升级后写一条验证命令两张纸贴在工位旁边。这样即使过了半年再遇到同样型号也能快速复现整个流程。希望帮到你。本文还有配套的精品资源点击获取