1. 从“一键还原”的幻想说起Jetson 刷机到底难在哪很多人第一次给 Jetson 刷系统脑子里想的都是 Ghost 那个年代的事——插上 U 盘点一下“还原”进度条走完重启收工。我当初也是这么想的。结果第一次给 Jetson Orin Nano 刷机从晚上八点折腾到凌晨两点中间经历了设备管理器里找不到 APX 设备、bct_mem 报错、Recovery 模式进不去、刷完起不来等一连串问题才真正意识到给 Jetson 刷系统本质上不是“重装”而是“心脏搭桥”——你要在主机和板子之间建立一条极其脆弱的生命通道任何一个环节断了板子就是一块砖。这篇文章面向的是所有手里有 Jetson 系列设备Nano、Orin Nano、Orin NX、AGX Orin 等、需要重装系统或者恢复变砖设备的开发者。不管你是刚拿到开发套件的新手还是已经部署过 YOLOv5、Ollama、Qwen 这类模型但系统崩了要重刷的老手这篇实录都能帮你少走几个小时的弯路。我会把整个刷机流程拆开从底层原理讲到实操细节把那些官方文档里一笔带过、但实际会卡死你的坑一个个标出来。核心关键词就几个Jetson、Recovery 模式、APX 设备、bct_mem、刷机。这几个词贯穿整个流程理解了它们之间的关系你就理解了 Jetson 刷机的本质。先说一个基本认知Jetson 不是普通 PC它没有 BIOS没有传统意义上的引导扇区可以随便写。它的启动链条是固化在芯片里的一段 BootROM 代码上电后先跑 BootROM然后根据配置去加载引导程序。当系统正常时它从 eMMC 或 NVMe 启动当系统损坏或者你主动进入 Recovery 模式时BootROM 会进入一种特殊的等待状态通过 USB 接口等待主机把完整的系统镜像“灌”进去。这个等待状态就是 APX 模式。APX 是 NVIDIA 定义的一种 USB 设备模式全称是 Advanced Protocol eXtension。当 Jetson 处于 Recovery 模式时它在主机上会以一个特定的 USB 设备 ID 出现通常是 0955:7xxx 系列而不是普通的存储设备。主机端的刷机工具flash.sh 或 SDK Manager通过这个通道把引导程序、内核、根文件系统、设备树等一整套东西按顺序写进去。这个过程不像 Ghost 那样“整块覆盖”而是分阶段、分区域、有严格时序要求的写入。为什么说像心脏搭桥因为整个过程中主机和板子之间的连接必须保持绝对稳定。USB 线松一下、主机休眠一下、虚拟机抢一下 USB 设备都可能导致写入中断。而一旦在关键区域比如 BCT 分区写入中断板子就真的起不来了。BCT 是 Boot Configuration Table 的缩写存储的是内存时序、启动设备配置等最底层的参数。bct_mem 相关的报错基本都出在这个环节。所以在动手之前先把心态摆正这不是一键还原这是一次需要耐心、需要理解原理、需要做好环境准备的操作。下面我按实际操作的顺序把整个流程拆成几个阶段来讲。2. 刷机前的环境准备主机、线材、镜像一个都不能马虎2.1 主机环境的选择与配置刷 Jetson 对主机环境有硬性要求这不是矫情是 USB 通信时序决定的。官方推荐 Ubuntu 18.04 或 20.04原因很简单NVIDIA 的刷机工具链L4T 里的 flash.sh、tegraflash 等是在 Linux 下开发和测试的USB 驱动、权限管理、脚本依赖都是针对 Linux 调的。你用 Windows 跑 SDK Manager 的虚拟机方案或者用 WSL2大概率会在 USB 透传环节卡住。我实测下来最稳的方案是一台原生 Ubuntu 20.04 的物理机内核版本 5.4 或 5.15 都行不要用太新的内核有些新内核的 USB 驱动反而对 APX 设备支持不好。如果你只有 Windows 主机那就装一个 Ubuntu 双系统或者用一台旧笔记本专门装 Ubuntu 来刷机。虚拟机方案我不推荐VMware 和 VirtualBox 的 USB 控制器在 APX 设备枚举阶段经常出问题表现为设备管理器里能看到设备但刷机工具找不到或者刷到一半设备掉线。主机上需要装的软件包不多但缺一不可sudo apt-get update sudo apt-get install -y build-essential cmake git libusb-1.0-0-dev sudo apt-get install -y python3 python3-pip sudo apt-get install -y device-tree-compilerlibusb是刷机工具和 APX 设备通信的基础库device-tree-compiler是编译设备树用的。这些包在后续编译和刷写过程中都会被调用到。还有一个容易被忽略的点主机的 USB 端口。优先用主板后置的 USB 3.0 端口不要用前面板或者 USB Hub。前面板的线材质量参差不齐USB Hub 更是灾难APX 设备对 USB 信号完整性很敏感。我踩过一次坑用了一个便宜的 USB 3.0 HubRecovery 模式能进但刷到 bct_mem 阶段就报错换直连后置端口后一次通过。2.2 线材与供电的细节Jetson 开发套件通常附带一根 USB-C 线或者 Micro-USB 线这根线就是刷机线。但要注意不是所有 USB 线都能用来刷机。有些线只有充电功能没有数据线芯有些线虽然能传数据但线径太细压降大在高速写入时容易出错。我建议用设备原装线或者找一根确认支持 USB 3.0 数据传输的优质线。供电方面Jetson Orin 系列在 Recovery 模式下功耗不低尤其是 AGX Orin。如果你用的是开发套件自带的电源适配器直接插上就行。但如果你是通过 USB-C 给板子供电同时刷机要注意主机的 USB 端口能不能提供足够的电流。有些主机的 USB 3.0 端口只能给到 900mA而 Orin Nano 在 Recovery 模式下可能需要更多。供电不足的表现是设备能进 Recovery但刷机过程中随机断开或者刷完后启动不稳定。提示刷机时最好给 Jetson 接上官方电源适配器不要只靠 USB 供电。USB 线只负责数据传输供电走独立电源这样最稳。2.3 镜像与工具链的获取Jetson 的系统镜像和工具链都打包在 NVIDIA 的 JetPack SDK 里。你需要根据板子型号下载对应的版本。比如 Jetson Orin Nano 8GB 对应 JetPack 5.1.x 或 6.xJetson Nano 对应 JetPack 4.6.x。版本选错了刷进去也起不来。下载方式有两种一是用 SDK Manager 图形化工具它会自动下载镜像和工具链二是手动下载 BSP 包和根文件系统包。我推荐手动下载因为 SDK Manager 在下载过程中经常因为网络问题中断而且它会把东西散落在多个目录里不好管理。手动下载的话你需要两个包BSP 包包含引导程序、内核、设备树、刷机脚本文件名类似Jetson_Linux_R35.x.x_aarch64.tbz2根文件系统包包含 Ubuntu 根文件系统文件名类似Tegra_Linux_Sample-Root-Filesystem_R35.x.x_aarch64.tbz2这两个包的版本号必须完全一致不能混用。下载完后解压tar xf Jetson_Linux_R35.x.x_aarch64.tbz2 cd Linux_for_Tegra/rootfs/ sudo tar xpf ../../Tegra_Linux_Sample-Root-Filesystem_R35.x.x_aarch64.tbz2 cd .. sudo ./apply_binaries.shapply_binaries.sh这一步会把 NVIDIA 的专有驱动、固件、库文件复制到根文件系统里。这一步必须用 sudo否则权限不够。执行完后Linux_for_Tegra目录就是你的刷机工作目录。3. 进入 Recovery 模式APX 设备识别的关键一步3.1 Recovery 模式的硬件操作让 Jetson 进入 Recovery 模式不同型号的操作方式略有不同但核心逻辑是一样的在按住 Recovery 按钮或短接 Recovery 引脚的同时给板子上电或者按复位键。以 Jetson Orin Nano 开发套件为例确保板子完全断电拔掉电源线找到板子上的 Recovery 按钮通常标注为 REC 或 Recovery按住 Recovery 按钮不放插上电源线或者按一下电源键保持按住 Recovery 按钮约 2 秒然后松开此时板子就进入了 Recovery 模式。如果你用的是没有 Recovery 按钮的模组比如某些 Orin NX 模组需要短接载板上的 Recovery 引脚操作类似。对于 Jetson Nano 老款操作是先短接 Recovery 跳线然后插电再断开跳线。具体引脚位置参考对应型号的载板手册。注意进入 Recovery 模式的时机很关键。必须在通电之前就按住 Recovery 按钮如果先通电再按BootROM 已经走完启动流程了不会进入 Recovery。这个顺序不能反。3.2 主机端确认 APX 设备板子进入 Recovery 模式后在 Ubuntu 主机上执行lsusb你应该能看到类似这样的输出Bus 001 Device 005: ID 0955:7xxx NVIDIA Corp. APX0955是 NVIDIA 的 USB 厂商 ID7xxx根据型号不同而变化。比如 Orin Nano 可能是0955:7523AGX Orin 可能是0955:7023。只要看到NVIDIA Corp. APX就说明主机已经识别到了 Recovery 模式下的设备。如果lsusb里没有出现 APX 设备排查顺序如下检查 USB 线是否插紧换一个 USB 端口试试检查板子是否真的进入了 Recovery 模式有些板子有 Recovery 指示灯检查主机 USB 驱动是否正常dmesg | tail看看有没有 USB 枚举失败的日志如果是虚拟机检查 USB 设备是否透传到了虚拟机里我遇到过一种情况lsusb能看到 APX 设备但刷机脚本报cannot open USB device。这是因为普通用户没有 USB 设备访问权限。解决办法是加 udev 规则sudo bash -c echo SUBSYSTEM\usb\, ATTR{idVendor}\0955\, MODE\0666\ /etc/udev/rules.d/99-nvidia.rules sudo udevadm control --reload-rules sudo udevadm trigger加完规则后重新插拔 USB 线权限问题就解决了。3.3 bct_mem 报错的本质与应对bct_mem是刷机过程中最容易出问题的环节之一。BCT 是 Boot Configuration Table存储的是内存控制器配置、启动设备顺序、安全配置等底层参数。刷机工具在写入 BCT 分区时需要先读取板子上的内存信息然后生成对应的 BCT 文件再写回去。bct_mem报错通常表现为Error: Return value 8 Command tegradevflash_v2 --write BCT ... Failed to flash bct_mem这个错误的根本原因多数情况下是主机和板子之间的 USB 通信不稳定导致 BCT 数据写入不完整或者校验失败。少数情况下是 BCT 文件本身和板子不匹配比如用错了型号的配置文件。应对策略换 USB 端口换线确保直连后置端口关闭主机上可能占用 USB 带宽的程序比如虚拟机、Docker 的 USB 透传检查Linux_for_Tegra目录下的配置文件是否对应你的板子型号比如jetson-orin-nano-devkit.conf如果反复失败尝试降低 USB 速度在主机 BIOS 里把对应 USB 端口强制设为 USB 2.0虽然慢但更稳我实测下来bct_mem报错九成以上是 USB 连接问题换线换端口基本能解决。剩下的一成是配置文件选错了比如把 Orin NX 的配置用在了 Orin Nano 上。4. 刷机实操全流程从命令行到系统启动4.1 选择正确的配置文件在Linux_for_Tegra目录下有一堆.conf文件对应不同的板子型号和载板组合。你需要根据你的硬件选择正确的那个。常见的对应关系板子型号配置文件Jetson Nano 开发套件jetson-nano-devkit.confJetson Orin Nano 开发套件jetson-orin-nano-devkit.confJetson Orin NX 模组 官方载板jetson-orin-nx-devkit.confJetson AGX Orin 开发套件jetson-agx-orin-devkit.conf选错配置文件的后果是刷机过程可能能走完但刷完后系统起不来或者外设不工作。因为配置文件里定义了设备树、GPIO 映射、电源管理参数等和硬件强相关的东西。如果你不确定该用哪个可以看板子上的丝印型号或者查 NVIDIA 官方文档里的对应表。实在拿不准就把Linux_for_Tegra目录下所有.conf文件列出来找名字最匹配的那个。4.2 执行刷机命令确认板子处于 Recovery 模式、APX 设备已识别、配置文件已选对之后就可以执行刷机了。最基础的命令是sudo ./flash.sh jetson-orin-nano-devkit mmcblk0p1这里的mmcblk0p1表示刷到 eMMC 的第一个分区。如果你要刷到 NVMe SSD需要先确认 NVMe 的设备节点通常是nvme0n1p1。但注意不是所有 Jetson 型号都支持直接从 NVMe 启动Orin 系列支持Nano 系列需要额外配置。刷机过程会输出大量日志你会看到它依次写入 BCT、BCT backup、bootloader、kernel、kernel-dtb、rootfs 等分区。整个过程根据镜像大小和 USB 速度通常需要 10 到 30 分钟。Orin Nano 的镜像大概 8GB 左右USB 3.0 下大约 15 分钟。刷机完成后工具会提示Flash complete然后板子会自动重启。第一次启动会比较慢因为要初始化文件系统、生成 SSH 密钥、扩展分区等。耐心等几分钟看到 Ubuntu 的登录提示或者桌面就说明刷机成功了。4.3 刷机后的首次配置首次启动进入系统后默认用户名和密码都是nvidia。登录后建议立刻做几件事修改密码passwd更新软件源sudo apt-get update检查磁盘空间df -h确认根分区已经扩展到整个存储设备检查网络ip addr确认有线或无线网络正常安装常用工具sudo apt-get install -y vim htop tmux如果你要部署 AI 模型比如 YOLOv5、Ollama、Qwen 等还需要安装 CUDA、cuDNN、TensorRT 等组件。这些组件在 JetPack 里已经预装了但可能需要配置环境变量。检查/usr/local/cuda是否存在以及nvcc --version是否能正常输出。提示刷完机后建议先做一个完整的系统备份。可以用dd命令把 eMMC 或 NVMe 的内容镜像出来存到外部存储。这样下次系统崩了可以直接恢复不用再走一遍刷机流程。5. 常见问题与排查技巧实录5.1 设备识别类问题问题一lsusb 看不到 APX 设备这是最常见的问题排查思路按优先级排列确认 Recovery 按钮操作顺序正确先按住再上电保持 2 秒后松开换 USB 线和 USB 端口优先用后置 USB 3.0检查主机dmesg日志看是否有 USB 枚举失败或设备描述符读取错误如果是虚拟机确认 USB 设备已透传到虚拟机且虚拟机 USB 控制器设置为 USB 3.0尝试在 Windows 主机上用设备管理器查看如果 Windows 能识别到 APX 设备说明板子和线没问题是 Linux 主机环境的问题问题二设备识别到了但刷机工具报权限错误这个前面提过加 udev 规则即可。如果加了规则还不行检查当前用户是否在plugdev组里或者直接用sudo运行刷机脚本。5.2 刷机过程类问题问题三bct_mem 写入失败前面详细分析过核心是 USB 通信稳定性。补充一个技巧在刷机前先执行一次sudo ./flash.sh --no-flash ...这个命令只生成刷机所需的文件不实际写入。如果生成过程就报错说明是配置文件或工具链的问题如果生成成功但写入失败那就是 USB 通信问题。问题四刷机到一半卡住不动观察日志最后一行停在哪个分区。如果是rootfs阶段卡住可能是镜像文件损坏重新下载解压。如果是kernel或dtb阶段卡住可能是 USB 掉线检查线材和端口。如果日志完全不动超过 5 分钟可以尝试 CtrlC 终止重新进入 Recovery 模式再刷。问题五刷机完成但系统起不来现象是板子通电后黑屏或者串口输出停在某个阶段。常见原因配置文件选错了设备树不匹配根文件系统没有正确解压或apply_binaries.sh没有执行存储设备有问题比如 eMMC 坏块排查方法接串口调试线看启动日志停在哪里。如果是Kernel panic多半是根文件系统问题如果是No bootable device多半是 BCT 或引导程序问题。5.3 刷机后的系统问题问题六刷完机后网络不工作Orin 系列的网卡驱动在 JetPack 里是预装的但有时候需要手动加载。检查dmesg | grep eth看网卡是否被识别。如果没识别可能是设备树里网卡节点配置不对需要换一个配置文件重刷。问题七CUDA 或 TensorRT 不可用检查环境变量export PATH/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda/lib64:$LD_LIBRARY_PATH把这些加到~/.bashrc里。然后验证nvcc --version python3 -c import tensorrt; print(tensorrt.__version__)如果 Python 里导入失败可能是 Python 版本不对。JetPack 5.x 默认用 Python 3.8JetPack 6.x 用 Python 3.10。用python3 --version确认。5.4 常见问题速查表问题现象可能原因解决方向lsusb 无 APX 设备Recovery 操作顺序错、线材问题、USB 端口问题重做 Recovery、换线换端口刷机工具报权限错误udev 规则缺失、用户权限不足加 udev 规则、用 sudobct_mem 写入失败USB 通信不稳定、配置文件错误换端口、检查配置文件刷机卡在 rootfs镜像损坏、USB 掉线重新下载镜像、检查连接刷完起不来配置文件错、根文件系统不完整接串口看日志、重刷网络不工作设备树不匹配、驱动未加载换配置文件重刷CUDA 不可用环境变量未配置配置 PATH 和 LD_LIBRARY_PATH6. 一些踩坑之后的个人体会刷 Jetson 这件事第一次做的时候觉得处处是坑做多了之后发现坑就那么几个只是每个坑都足够深。我现在的习惯是刷机前先把所有准备工作做足线材、端口、镜像、配置文件全部确认一遍然后一次性走完流程。最怕的就是刷到一半发现配置文件选错了那种感觉就像手术做到一半发现拿错了器械。还有一个体会是不要迷信图形化工具。SDK Manager 看起来方便但它把很多底层细节隐藏了出了问题你根本不知道是哪一步错了。命令行刷机虽然看起来原始但每一步都透明日志清晰出了问题容易定位。我现在基本只用命令行。最后说一个实用技巧如果你有多台 Jetson 需要批量刷机可以把Linux_for_Tegra目录整个复制多份每份对应一个板子型号这样配置文件不会混。刷机时用不同的终端窗口分别操作互不干扰。这个做法在实验室或者小批量部署场景下很省时间。至于那些热词里提到的“一键还原”“Ghost”之类的期待我只能说Jetson 刷机确实没有捷径。但理解了原理之后你会发现它也没那么可怕。无非就是让板子进 Recovery让主机认出 APX让工具把镜像写进去然后等它启动。每一步都有明确的成功标志和失败排查方向按部就班来基本都能搞定。
Jetson刷机实战：从Recovery模式到APX设备，彻底解决bct_mem报错
1. 从“一键还原”的幻想说起Jetson 刷机到底难在哪很多人第一次给 Jetson 刷系统脑子里想的都是 Ghost 那个年代的事——插上 U 盘点一下“还原”进度条走完重启收工。我当初也是这么想的。结果第一次给 Jetson Orin Nano 刷机从晚上八点折腾到凌晨两点中间经历了设备管理器里找不到 APX 设备、bct_mem 报错、Recovery 模式进不去、刷完起不来等一连串问题才真正意识到给 Jetson 刷系统本质上不是“重装”而是“心脏搭桥”——你要在主机和板子之间建立一条极其脆弱的生命通道任何一个环节断了板子就是一块砖。这篇文章面向的是所有手里有 Jetson 系列设备Nano、Orin Nano、Orin NX、AGX Orin 等、需要重装系统或者恢复变砖设备的开发者。不管你是刚拿到开发套件的新手还是已经部署过 YOLOv5、Ollama、Qwen 这类模型但系统崩了要重刷的老手这篇实录都能帮你少走几个小时的弯路。我会把整个刷机流程拆开从底层原理讲到实操细节把那些官方文档里一笔带过、但实际会卡死你的坑一个个标出来。核心关键词就几个Jetson、Recovery 模式、APX 设备、bct_mem、刷机。这几个词贯穿整个流程理解了它们之间的关系你就理解了 Jetson 刷机的本质。先说一个基本认知Jetson 不是普通 PC它没有 BIOS没有传统意义上的引导扇区可以随便写。它的启动链条是固化在芯片里的一段 BootROM 代码上电后先跑 BootROM然后根据配置去加载引导程序。当系统正常时它从 eMMC 或 NVMe 启动当系统损坏或者你主动进入 Recovery 模式时BootROM 会进入一种特殊的等待状态通过 USB 接口等待主机把完整的系统镜像“灌”进去。这个等待状态就是 APX 模式。APX 是 NVIDIA 定义的一种 USB 设备模式全称是 Advanced Protocol eXtension。当 Jetson 处于 Recovery 模式时它在主机上会以一个特定的 USB 设备 ID 出现通常是 0955:7xxx 系列而不是普通的存储设备。主机端的刷机工具flash.sh 或 SDK Manager通过这个通道把引导程序、内核、根文件系统、设备树等一整套东西按顺序写进去。这个过程不像 Ghost 那样“整块覆盖”而是分阶段、分区域、有严格时序要求的写入。为什么说像心脏搭桥因为整个过程中主机和板子之间的连接必须保持绝对稳定。USB 线松一下、主机休眠一下、虚拟机抢一下 USB 设备都可能导致写入中断。而一旦在关键区域比如 BCT 分区写入中断板子就真的起不来了。BCT 是 Boot Configuration Table 的缩写存储的是内存时序、启动设备配置等最底层的参数。bct_mem 相关的报错基本都出在这个环节。所以在动手之前先把心态摆正这不是一键还原这是一次需要耐心、需要理解原理、需要做好环境准备的操作。下面我按实际操作的顺序把整个流程拆成几个阶段来讲。2. 刷机前的环境准备主机、线材、镜像一个都不能马虎2.1 主机环境的选择与配置刷 Jetson 对主机环境有硬性要求这不是矫情是 USB 通信时序决定的。官方推荐 Ubuntu 18.04 或 20.04原因很简单NVIDIA 的刷机工具链L4T 里的 flash.sh、tegraflash 等是在 Linux 下开发和测试的USB 驱动、权限管理、脚本依赖都是针对 Linux 调的。你用 Windows 跑 SDK Manager 的虚拟机方案或者用 WSL2大概率会在 USB 透传环节卡住。我实测下来最稳的方案是一台原生 Ubuntu 20.04 的物理机内核版本 5.4 或 5.15 都行不要用太新的内核有些新内核的 USB 驱动反而对 APX 设备支持不好。如果你只有 Windows 主机那就装一个 Ubuntu 双系统或者用一台旧笔记本专门装 Ubuntu 来刷机。虚拟机方案我不推荐VMware 和 VirtualBox 的 USB 控制器在 APX 设备枚举阶段经常出问题表现为设备管理器里能看到设备但刷机工具找不到或者刷到一半设备掉线。主机上需要装的软件包不多但缺一不可sudo apt-get update sudo apt-get install -y build-essential cmake git libusb-1.0-0-dev sudo apt-get install -y python3 python3-pip sudo apt-get install -y device-tree-compilerlibusb是刷机工具和 APX 设备通信的基础库device-tree-compiler是编译设备树用的。这些包在后续编译和刷写过程中都会被调用到。还有一个容易被忽略的点主机的 USB 端口。优先用主板后置的 USB 3.0 端口不要用前面板或者 USB Hub。前面板的线材质量参差不齐USB Hub 更是灾难APX 设备对 USB 信号完整性很敏感。我踩过一次坑用了一个便宜的 USB 3.0 HubRecovery 模式能进但刷到 bct_mem 阶段就报错换直连后置端口后一次通过。2.2 线材与供电的细节Jetson 开发套件通常附带一根 USB-C 线或者 Micro-USB 线这根线就是刷机线。但要注意不是所有 USB 线都能用来刷机。有些线只有充电功能没有数据线芯有些线虽然能传数据但线径太细压降大在高速写入时容易出错。我建议用设备原装线或者找一根确认支持 USB 3.0 数据传输的优质线。供电方面Jetson Orin 系列在 Recovery 模式下功耗不低尤其是 AGX Orin。如果你用的是开发套件自带的电源适配器直接插上就行。但如果你是通过 USB-C 给板子供电同时刷机要注意主机的 USB 端口能不能提供足够的电流。有些主机的 USB 3.0 端口只能给到 900mA而 Orin Nano 在 Recovery 模式下可能需要更多。供电不足的表现是设备能进 Recovery但刷机过程中随机断开或者刷完后启动不稳定。提示刷机时最好给 Jetson 接上官方电源适配器不要只靠 USB 供电。USB 线只负责数据传输供电走独立电源这样最稳。2.3 镜像与工具链的获取Jetson 的系统镜像和工具链都打包在 NVIDIA 的 JetPack SDK 里。你需要根据板子型号下载对应的版本。比如 Jetson Orin Nano 8GB 对应 JetPack 5.1.x 或 6.xJetson Nano 对应 JetPack 4.6.x。版本选错了刷进去也起不来。下载方式有两种一是用 SDK Manager 图形化工具它会自动下载镜像和工具链二是手动下载 BSP 包和根文件系统包。我推荐手动下载因为 SDK Manager 在下载过程中经常因为网络问题中断而且它会把东西散落在多个目录里不好管理。手动下载的话你需要两个包BSP 包包含引导程序、内核、设备树、刷机脚本文件名类似Jetson_Linux_R35.x.x_aarch64.tbz2根文件系统包包含 Ubuntu 根文件系统文件名类似Tegra_Linux_Sample-Root-Filesystem_R35.x.x_aarch64.tbz2这两个包的版本号必须完全一致不能混用。下载完后解压tar xf Jetson_Linux_R35.x.x_aarch64.tbz2 cd Linux_for_Tegra/rootfs/ sudo tar xpf ../../Tegra_Linux_Sample-Root-Filesystem_R35.x.x_aarch64.tbz2 cd .. sudo ./apply_binaries.shapply_binaries.sh这一步会把 NVIDIA 的专有驱动、固件、库文件复制到根文件系统里。这一步必须用 sudo否则权限不够。执行完后Linux_for_Tegra目录就是你的刷机工作目录。3. 进入 Recovery 模式APX 设备识别的关键一步3.1 Recovery 模式的硬件操作让 Jetson 进入 Recovery 模式不同型号的操作方式略有不同但核心逻辑是一样的在按住 Recovery 按钮或短接 Recovery 引脚的同时给板子上电或者按复位键。以 Jetson Orin Nano 开发套件为例确保板子完全断电拔掉电源线找到板子上的 Recovery 按钮通常标注为 REC 或 Recovery按住 Recovery 按钮不放插上电源线或者按一下电源键保持按住 Recovery 按钮约 2 秒然后松开此时板子就进入了 Recovery 模式。如果你用的是没有 Recovery 按钮的模组比如某些 Orin NX 模组需要短接载板上的 Recovery 引脚操作类似。对于 Jetson Nano 老款操作是先短接 Recovery 跳线然后插电再断开跳线。具体引脚位置参考对应型号的载板手册。注意进入 Recovery 模式的时机很关键。必须在通电之前就按住 Recovery 按钮如果先通电再按BootROM 已经走完启动流程了不会进入 Recovery。这个顺序不能反。3.2 主机端确认 APX 设备板子进入 Recovery 模式后在 Ubuntu 主机上执行lsusb你应该能看到类似这样的输出Bus 001 Device 005: ID 0955:7xxx NVIDIA Corp. APX0955是 NVIDIA 的 USB 厂商 ID7xxx根据型号不同而变化。比如 Orin Nano 可能是0955:7523AGX Orin 可能是0955:7023。只要看到NVIDIA Corp. APX就说明主机已经识别到了 Recovery 模式下的设备。如果lsusb里没有出现 APX 设备排查顺序如下检查 USB 线是否插紧换一个 USB 端口试试检查板子是否真的进入了 Recovery 模式有些板子有 Recovery 指示灯检查主机 USB 驱动是否正常dmesg | tail看看有没有 USB 枚举失败的日志如果是虚拟机检查 USB 设备是否透传到了虚拟机里我遇到过一种情况lsusb能看到 APX 设备但刷机脚本报cannot open USB device。这是因为普通用户没有 USB 设备访问权限。解决办法是加 udev 规则sudo bash -c echo SUBSYSTEM\usb\, ATTR{idVendor}\0955\, MODE\0666\ /etc/udev/rules.d/99-nvidia.rules sudo udevadm control --reload-rules sudo udevadm trigger加完规则后重新插拔 USB 线权限问题就解决了。3.3 bct_mem 报错的本质与应对bct_mem是刷机过程中最容易出问题的环节之一。BCT 是 Boot Configuration Table存储的是内存控制器配置、启动设备顺序、安全配置等底层参数。刷机工具在写入 BCT 分区时需要先读取板子上的内存信息然后生成对应的 BCT 文件再写回去。bct_mem报错通常表现为Error: Return value 8 Command tegradevflash_v2 --write BCT ... Failed to flash bct_mem这个错误的根本原因多数情况下是主机和板子之间的 USB 通信不稳定导致 BCT 数据写入不完整或者校验失败。少数情况下是 BCT 文件本身和板子不匹配比如用错了型号的配置文件。应对策略换 USB 端口换线确保直连后置端口关闭主机上可能占用 USB 带宽的程序比如虚拟机、Docker 的 USB 透传检查Linux_for_Tegra目录下的配置文件是否对应你的板子型号比如jetson-orin-nano-devkit.conf如果反复失败尝试降低 USB 速度在主机 BIOS 里把对应 USB 端口强制设为 USB 2.0虽然慢但更稳我实测下来bct_mem报错九成以上是 USB 连接问题换线换端口基本能解决。剩下的一成是配置文件选错了比如把 Orin NX 的配置用在了 Orin Nano 上。4. 刷机实操全流程从命令行到系统启动4.1 选择正确的配置文件在Linux_for_Tegra目录下有一堆.conf文件对应不同的板子型号和载板组合。你需要根据你的硬件选择正确的那个。常见的对应关系板子型号配置文件Jetson Nano 开发套件jetson-nano-devkit.confJetson Orin Nano 开发套件jetson-orin-nano-devkit.confJetson Orin NX 模组 官方载板jetson-orin-nx-devkit.confJetson AGX Orin 开发套件jetson-agx-orin-devkit.conf选错配置文件的后果是刷机过程可能能走完但刷完后系统起不来或者外设不工作。因为配置文件里定义了设备树、GPIO 映射、电源管理参数等和硬件强相关的东西。如果你不确定该用哪个可以看板子上的丝印型号或者查 NVIDIA 官方文档里的对应表。实在拿不准就把Linux_for_Tegra目录下所有.conf文件列出来找名字最匹配的那个。4.2 执行刷机命令确认板子处于 Recovery 模式、APX 设备已识别、配置文件已选对之后就可以执行刷机了。最基础的命令是sudo ./flash.sh jetson-orin-nano-devkit mmcblk0p1这里的mmcblk0p1表示刷到 eMMC 的第一个分区。如果你要刷到 NVMe SSD需要先确认 NVMe 的设备节点通常是nvme0n1p1。但注意不是所有 Jetson 型号都支持直接从 NVMe 启动Orin 系列支持Nano 系列需要额外配置。刷机过程会输出大量日志你会看到它依次写入 BCT、BCT backup、bootloader、kernel、kernel-dtb、rootfs 等分区。整个过程根据镜像大小和 USB 速度通常需要 10 到 30 分钟。Orin Nano 的镜像大概 8GB 左右USB 3.0 下大约 15 分钟。刷机完成后工具会提示Flash complete然后板子会自动重启。第一次启动会比较慢因为要初始化文件系统、生成 SSH 密钥、扩展分区等。耐心等几分钟看到 Ubuntu 的登录提示或者桌面就说明刷机成功了。4.3 刷机后的首次配置首次启动进入系统后默认用户名和密码都是nvidia。登录后建议立刻做几件事修改密码passwd更新软件源sudo apt-get update检查磁盘空间df -h确认根分区已经扩展到整个存储设备检查网络ip addr确认有线或无线网络正常安装常用工具sudo apt-get install -y vim htop tmux如果你要部署 AI 模型比如 YOLOv5、Ollama、Qwen 等还需要安装 CUDA、cuDNN、TensorRT 等组件。这些组件在 JetPack 里已经预装了但可能需要配置环境变量。检查/usr/local/cuda是否存在以及nvcc --version是否能正常输出。提示刷完机后建议先做一个完整的系统备份。可以用dd命令把 eMMC 或 NVMe 的内容镜像出来存到外部存储。这样下次系统崩了可以直接恢复不用再走一遍刷机流程。5. 常见问题与排查技巧实录5.1 设备识别类问题问题一lsusb 看不到 APX 设备这是最常见的问题排查思路按优先级排列确认 Recovery 按钮操作顺序正确先按住再上电保持 2 秒后松开换 USB 线和 USB 端口优先用后置 USB 3.0检查主机dmesg日志看是否有 USB 枚举失败或设备描述符读取错误如果是虚拟机确认 USB 设备已透传到虚拟机且虚拟机 USB 控制器设置为 USB 3.0尝试在 Windows 主机上用设备管理器查看如果 Windows 能识别到 APX 设备说明板子和线没问题是 Linux 主机环境的问题问题二设备识别到了但刷机工具报权限错误这个前面提过加 udev 规则即可。如果加了规则还不行检查当前用户是否在plugdev组里或者直接用sudo运行刷机脚本。5.2 刷机过程类问题问题三bct_mem 写入失败前面详细分析过核心是 USB 通信稳定性。补充一个技巧在刷机前先执行一次sudo ./flash.sh --no-flash ...这个命令只生成刷机所需的文件不实际写入。如果生成过程就报错说明是配置文件或工具链的问题如果生成成功但写入失败那就是 USB 通信问题。问题四刷机到一半卡住不动观察日志最后一行停在哪个分区。如果是rootfs阶段卡住可能是镜像文件损坏重新下载解压。如果是kernel或dtb阶段卡住可能是 USB 掉线检查线材和端口。如果日志完全不动超过 5 分钟可以尝试 CtrlC 终止重新进入 Recovery 模式再刷。问题五刷机完成但系统起不来现象是板子通电后黑屏或者串口输出停在某个阶段。常见原因配置文件选错了设备树不匹配根文件系统没有正确解压或apply_binaries.sh没有执行存储设备有问题比如 eMMC 坏块排查方法接串口调试线看启动日志停在哪里。如果是Kernel panic多半是根文件系统问题如果是No bootable device多半是 BCT 或引导程序问题。5.3 刷机后的系统问题问题六刷完机后网络不工作Orin 系列的网卡驱动在 JetPack 里是预装的但有时候需要手动加载。检查dmesg | grep eth看网卡是否被识别。如果没识别可能是设备树里网卡节点配置不对需要换一个配置文件重刷。问题七CUDA 或 TensorRT 不可用检查环境变量export PATH/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda/lib64:$LD_LIBRARY_PATH把这些加到~/.bashrc里。然后验证nvcc --version python3 -c import tensorrt; print(tensorrt.__version__)如果 Python 里导入失败可能是 Python 版本不对。JetPack 5.x 默认用 Python 3.8JetPack 6.x 用 Python 3.10。用python3 --version确认。5.4 常见问题速查表问题现象可能原因解决方向lsusb 无 APX 设备Recovery 操作顺序错、线材问题、USB 端口问题重做 Recovery、换线换端口刷机工具报权限错误udev 规则缺失、用户权限不足加 udev 规则、用 sudobct_mem 写入失败USB 通信不稳定、配置文件错误换端口、检查配置文件刷机卡在 rootfs镜像损坏、USB 掉线重新下载镜像、检查连接刷完起不来配置文件错、根文件系统不完整接串口看日志、重刷网络不工作设备树不匹配、驱动未加载换配置文件重刷CUDA 不可用环境变量未配置配置 PATH 和 LD_LIBRARY_PATH6. 一些踩坑之后的个人体会刷 Jetson 这件事第一次做的时候觉得处处是坑做多了之后发现坑就那么几个只是每个坑都足够深。我现在的习惯是刷机前先把所有准备工作做足线材、端口、镜像、配置文件全部确认一遍然后一次性走完流程。最怕的就是刷到一半发现配置文件选错了那种感觉就像手术做到一半发现拿错了器械。还有一个体会是不要迷信图形化工具。SDK Manager 看起来方便但它把很多底层细节隐藏了出了问题你根本不知道是哪一步错了。命令行刷机虽然看起来原始但每一步都透明日志清晰出了问题容易定位。我现在基本只用命令行。最后说一个实用技巧如果你有多台 Jetson 需要批量刷机可以把Linux_for_Tegra目录整个复制多份每份对应一个板子型号这样配置文件不会混。刷机时用不同的终端窗口分别操作互不干扰。这个做法在实验室或者小批量部署场景下很省时间。至于那些热词里提到的“一键还原”“Ghost”之类的期待我只能说Jetson 刷机确实没有捷径。但理解了原理之后你会发现它也没那么可怕。无非就是让板子进 Recovery让主机认出 APX让工具把镜像写进去然后等它启动。每一步都有明确的成功标志和失败排查方向按部就班来基本都能搞定。
