做嵌入式开发的人听到“烧录”两个字第一反应多半是单片机那一套Keil里点一下DownloadST-Link/J-Link往STM32里写个固件。放在Jetson Orin NX Super这种级别的边缘AI开发板上烧录的含义完全不一样——你要做的不是往芯片里写一段程序而是给整块板子装上一套完整的Ubuntu系统包括内核、GPU驱动、CUDA、cuDNN、TensorRT这些底层组件。简单说这是“刷机”不是“下程序”。我这块板子来回折腾过好几轮踩过不少坑这篇文章把整个流程从下载镜像到最终把CUDA环境跑通按实操顺序完整盘一遍给准备入手Jetson Orin NX Super的朋友省点时间。1. 动手烧录前先弄清这些底层逻辑1.1 这块板子的定位与“烧录”的真实含义Jetson Orin NX Super是NVIDIA Jetson家族里面向边缘AI计算的中高端模组常用于机器人、智能相机、视觉检测、无人机等场景。它最大的特点是把桌面级GPU的AI推理能力压缩到一个很小的模组里功耗可根据场景调整算力释放比前代产品明显提升。很多人第一次拿到手就懵这个模块上没有硬盘也没有传统意义上的系统盘那系统装哪这正是“烧录”这个词在Jetson圈子里和单片机圈子里含义不同的原因。单片机的烧录是把编译好的固件写到芯片Flash里而Jetson的烧录是把NVIDIA定制好的完整Linux镜像写进你的启动盘。这个镜像叫JetPack里面不只是Ubuntu系统还包括与硬件深度绑定的L4T内核、GPU驱动、CUDA运行库、cuDNN、TensorRT等。换句话说你烧录的是一整套AI开发环境。还有一个关键点Orin NX Super模组本身没有板载eMMC存储启动存储需要你自己配最常见的是M.2 NVMe SSD或SD卡。这一点一定要在买配件之前搞清楚否则板子到手才发现没有存储介质一整天都白等。1.2 烧录方式的选型为什么我推荐SDK Manager直刷NVMe给Jetson装系统社区里常见的方式有这么几种使用NVIDIA官方SDK Manager图形化工具烧录全称NVIDIA SDK Manager支持自动下载镜像、组件勾选、一键刷入。去NVIDIA官网手动下载JetPack镜像然后用Etcher等工具把镜像写入SD卡再插卡启动。高级玩法是使用命令行工具比如基于nvmflash或自写脚本对NVMe/eMMC执行烧录适合量产和定制镜像。如果你只有一块板子、一套系统我强烈建议直接用SDK Manager而且直刷NVMe。理由很实际NVMe顺序读写普遍在1GB/s以上而SD卡通常只有几十到一百多MB/s跑深度学习模型时要频繁加载权重文件NVMe带来的差距非常明显。另外SD卡长期高频读写容易掉盘、坏块用NVMe做启动盘系统稳定性会高很多。SDK Manager另一个优势是组件分离你可以在烧录时选择是否安装CUDA、cuDNN、TensorRT、OpenCV等组件后续也可以单独补装。这个工具目前只提供Linux版本没有Windows原生客户端。如果你手里只有Windows电脑别指望在Windows下双击就能刷老老实实准备一台Ubuntu物理机或者用支持USB直通的虚拟机但虚拟机方案需要额外折腾USB控制器透传建议有条件直接用Linux实体机。1.3 物料与环境清单照着准备别到了现场抓瞎我第一刷的时候就是缺东缺西弄到一半发现USB线只支持充电不支持数据心态直接崩了。按下面这份清单准备基本不会有遗漏一台x86_64架构的Ubuntu主机建议Ubuntu 22.04用于运行SDK Manager。Jetson Orin NX Super开发板以及配套的原厂电源适配器。一根支持数据传输的USB-C线用来连接开发板烧录口和主机。手机快充线不一定能用劣质线更是坑。M.2 NVMe SSD建议2280规格容量越大越好至少128GB起步。HDMI显示器、USB键盘鼠标用于首次开机后的系统初始化。网络环境开发板烧录完成后需要联网更新软件源和安装PyTorch等依赖。主机上建议提前装好基础环境比如Python3、pip、ssh等SDK Manager运行时会依赖一些库缺了会自动提示安装。注意主机磁盘空间要留够JetPack镜像和解压后临时文件占地很大20GB以上空闲空间比较稳妥。2. SDK Manager 全流程实操从下载镜像到完成烧录2.1 安装SDK Manager并让主机认识开发板SDK Manager在NVIDIA开发者官网注册账号后即可下载下载下来是个deb安装包。安装没什么难度sudo apt install ./sdkmanager_2.x.x.deb安装完成后直接在终端执行sdkmanager首次启动会让你登录NVIDIA开发者账号并接受许可协议。登录后主界面很简洁左边是产品与版本选择右边是已连接的设备信息。如果你之前没有给开发板上电界面通常会提示未检测到设备。这时候我们需要把开发板以刷机模式连上主机。SDK Manager能识别的前提是主机USB口能看到一个名为NVIDIA Corp. APX的设备。在终端执行lsusb输出中出现类似ID 0955:7e19 NVIDIA Corp. APX这样的行说明设备已经被主机识别。如果你的设备还是显示为其他NVIDIA设备可能是系统已正常运行、没有进入Recovery模式或者USB线有问题。2.2 进入Recovery模式这一步失败后面全是坑把开发板切到Recovery模式是整套烧录流程里最容易翻车的环节。操作本身不复杂但顺序很重要。我的标准做法是这样断开开发板电源确保完全断电。用USB-C线把开发板的烧录口一般来说是靠近电源接口的那个USB-C口连接到Ubuntu主机。按住开发板上的Force Recovery按钮不要松手。插上DC电源给开发板上电保持按钮按住1到2秒后松开。回到主机终端执行lsusb确认出现APX设备。为什么要用这个顺序因为Recovery模式本质上是让芯片进入USB下载固件的小系统它在没有系统盘或系统损坏时也能被主机访问。如果先上电再按Recovery有时候芯片已经正常启动到系统了就不会枚举出APX设备。这个阶段我踩过的最深的坑是USB线。有些type-C线只能充电插上去之后lsusb一点反应都没有。排查时先换线再换USB口别一上来就怀疑开发板坏了。另外如果主机上有多个NVIDIA设备lsusb输出里可能有好几行需要仔细确认APX那一行。2.3 关键烧录配置JetPack版本、组件和存储盘SDK Manager识别到设备后进入配置界面。你需要选择产品型号、JetPack版本、烧录的组件以及目标存储介质。这里每一步都要仔细看尤其是存储介质很多人默认烧到了SD卡结果后续发现启动速度很慢还以为是板子性能问题。产品型号选择里找Jetson Orin NX Super版本建议选JetPack 6.0或更新版本。Orin NX Super模组相对较新太老的JetPack不一定完整支持可能烧录时直接报错也可能烧完系统不稳定。JetPack版本本身决定了CUDA版本和内核版本官方推荐就选当前最新稳定版。组件勾选页面里我建议直接全选Jetson SDK Components也就是包含CUDA、cuDNN、TensorRT、OpenCV这些。虽然全选会让下载体积变大但后面编译一些AI项目时会发现缺一个组件就得从头折腾非常花时间。最关键的一步是存储介质选择。SDK Manager的烧录界面会问你要把镜像写到哪个存储设备这个选项只有在目标设备连上后才会出现。如果你想用NVMe就明确选择NVMe而不是SD Card。这一步选错后面就得重新刷机。2.4 烧录过程中的“翻车”点和抢救方法点击烧录后SDK Manager会做几件事下载JetPack镜像、校验文件完整性、把镜像写入开发板的启动盘、初始化系统分区。整个过程下载量大耗时很长和网速关系很大。如果网络不稳定Progress条可能长时间卡住看起来很吓人但很多情况下并没有死掉。遇到烧录“卡死”先别急着拔线去看日志。SDK Manager的日志默认存放在~/.nvsdkm/logs下最新的刷机记录以时间戳命名。打开日志搜索关键字error或fail基本能定位是网络下载问题、文件校验问题还是USB连接问题。如果是下载失败重试一般能续传如果是USB连接闪断重新进Recovery模式再刷一遍最稳妥。烧录过程中绝对不要拔USB线、不要断电、不要让主机进入休眠否则NVMe分区很可能被写坏那就只能重新来。烧录完成的标志是SDK Manager提示Device has been successfully flashed开发板会自动重启。如果你接了显示器应该能看到启动画面。到了这一步烧录阶段就算完成了。3. 首次开机与系统初始化让开发板进入可用状态3.1 首次启动配置账号、联网、驱动确认烧录完成重启后第一次进入的是一个全新的Ubuntu系统。系统会引导你完成初始设置包括选择语言、时区、创建用户名和密码、配置Wi-Fi等。这个初始化和普通Ubuntu电脑几乎一样按提示操作即可。这里我有个建议联网时尽量用有线网络。有线网络在首次apt update和安装驱动时的稳定性和速度都更好。Wi-Fi虽然能用但有时候固件版本和路由器兼容性问题会让人怀疑人生。系统进入桌面后先别急着装软件花两分钟确认硬件驱动是否正常。终端里执行uname -a如果内核版本里带tegra字样说明L4T内核已正确加载。再执行dpkg -l | grep nvidia能看到一大堆nvidia开头的包说明GPU驱动和CUDA相关包都已安装。还可以用tegrastats查看SoC温度、频率、内存占用能正常输出就说明硬件基本健康。3.2 确认系统版本和启动存储是否正常很多人烧录完第一个动作是看系统版本号执行lsb_release -a如果显示Ubuntu 22.04 LTS说明JetPack 6.x对应的基础系统已经就位。接下来还需要确认当前系统是从NVMe启动的而不是SD卡。执行lsblk查看根分区的挂载点。如果根目录挂在/dev/nvme0n1p1上说明是NVMe启动一切正常如果挂在/dev/mmcblk0p1上说明系统其实在SD卡里需要回头重新烧录。另一个高频问题就是根分区大小。SDK Manager默认烧录镜像时分区表通常只分配了一个固定大小给根分区即使你的NVMe有1TB系统也可能只显示几百GB甚至更少。这时需要手动扩展根分区。在Ubuntu 22.04上根文件系统一般是ext4操作方式如下sudo growpart /dev/nvme0n1 1 sudo resize2fs /dev/nvme0n1p1执行完后用df -h /确认根分区大小。这一步很多人不知道我在社区里见过有人因为“存储空间只有几十G”而误以为板子坏掉的。3.3 换软件源、扩容与基础优化Jetson上的Ubuntu软件源默认指向国外服务器国内访问速度很不稳定。建议把ports.ubuntu.com替换成国内镜像源比如清华源、阿里源。注意Jetson是ARM架构软件源地址必须使用ports.ubuntu.com对应的镜像路径不要照搬x86电脑的源。编辑软件源文件sudo nano /etc/apt/sources.list把.cn或国内镜像的地址替换掉原来的ports.ubuntu.com。编辑时务必小心不要把repo.download.nvidia.com开头的NVIDIA L4T源删掉。这个源负责Jetson专属内核和驱动更新删了之后后续apt upgrade可能出现内核和驱动版本不一致的问题。换完源后执行sudo apt update sudo apt upgrade让系统完成初始更新。首次更新包数量很大耗时较长建议连接电源适配器不要只靠USB-C供电否则大负载更新时可能出现供电不足。额外的基础优化包括在设置里把屏幕休眠调成Never避免长时间跑训练任务时屏幕关闭影响调试如果有需要可以编辑/etc/nvpmodel.conf选择不同的功耗模式默认的MAXN模式下性能和功耗最高适合跑重负载推理任务。4. 配置CUDA环境不只是“装上”那么简单4.1 JetPack默认带什么CUDA、cuDNN、TensorRT对照很多人第一次在Jetson上跑深度学习第一反应是“我要去NVIDIA官网下载CUDA Toolkit”。在Jetson上完全不需要。JetPack烧录后CUDA Toolkit、cuDNN、TensorRT其实都已经预装了只不过它们的位置和普通PC上不太一样。可以查一下系统里这些组件是否齐全组件常见路径验证方式CUDA Toolkit/usr/local/cuda/usr/local/cuda/bin/nvcc -VcuDNN/usr/lib/aarch64-linux-gnu/libcudnn*dpkg -l | grep cudnnTensorRT/usr/lib/aarch64-linux-gnu/libnvinfer*dpkg -l | grep tensorrtOpenCV/usr/lib/aarch64-linux-gnu/libopencv*python3 -c import cv2; print(cv2.version)注意/usr/local/cuda其实是一个软链接真实版本目录可能是/usr/local/cuda-12.x。这样设计的好处是如果官方后续升级CUDA版本软链会自动指向新版本目录你的环境变量不需要频繁修改。4.2 配置PATH与验证nvcc这一步很多人漏掉刚烧录完的Jetson你在终端敲nvcc -V很可能会报command not found。原因不是没有安装CUDA而是系统的PATH环境变量里没有包含/usr/local/cuda/bin。这个环节最容易被忽略因为你安装普通软件时通常会自动配置好环境变量但Jetson上的CUDA更多面向编译工具链需要自己手动配。编辑~/.bashrc文件在末尾追加两行export PATH/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda/lib64:$LD_LIBRARY_PATH然后执行source ~/.bashrc nvcc -V如果能看到CUDA版本信息说明环境变量配置成功。LD_LIBRARY_PATH同样重要编译CUDA程序时链接器需要找到libcudart.so等运行库不加这个路径会报cannot find -lcudart。建议同时把这两行写入/etc/profile.d/cuda.sh这样所有用户登录时都能自动加载避免以后切换用户后又要再配一次。验证CUDA真正可用可以用官方自带的一个小工具。进入/usr/local/cuda/samples/1_Utilities/deviceQuery目录执行make编译当前目录下的示例程序然后运行./deviceQuery。如果输出Detected 1 CUDA Capable device(s)说明CUDA编译和运行链路都没问题。4.3 让PyTorch跑在CUDA上安装与验证全过程在Jetson上配置PyTorch是很多新手崩溃的重灾区。最大的坑在于直接使用pip3 install torch从普通PyPI源安装大概率会遇到两个问题。一是下载的wheel可能不适用于ARM架构二是即使装上了导入时也可能提示CUDA相关动态库缺失比如找不到libcudnn.so.8这是因为官方PyPI上的torch默认捆绑的CUDA依赖和Jetson的L4T驱动版本不匹配。正确做法是安装NVIDIA为Jetson平台专门编译的PyTorch预编译包。流程如下确认当前JetPack版本可以执行dpkg-query -W -f${Version} nvidia-l4t-core去NVIDIA官方开发者网站找到PyTorch for Jetson的下载页面选择与自身JetPack版本匹配的torch和torchvision的wheel文件。下载后安装pip3 install --no-cache-dir torch-xxx.whl pip3 install --no-cache-dir torchvision-xxx.whl验证是否可用python3 -c import torch; print(torch.__version__, torch.cuda.is_available())如果输出True说明PyTorch已经正确识别到了Jetson的CUDA设备。还可以继续确认设备名称python3 -c import torch; print(torch.cuda.get_device_name(0))能看到类似“NVIDIA Orin”的设备名说明CUDA环境完全可用。这里多说一句如果你习惯用conda管理Python环境也可以把上面的wheel安装在conda环境里但建议不要在conda里再安装conda-forge提供的cuda-toolkit、cudnn等包。Jetson上的CUDA应该跟着JetPack走conda里的CUDA工具链很可能会覆盖系统动态库版本导致整个环境变得混乱。4.4 CUDA环境出问题的排查思路CUDA环境报错大部分都可以归因到三类环境变量没配好、组件没装完整、版本不匹配。我把自己遇到过的典型问题整理成了排查思路。比如gzip: stdin: invalid compressed>