2. JetPack与开发环境搭建

Jetson 平台的软件能力并不是零散安装的，而是通过 NVIDIA 的 JetPack SDK 以“整包”形式交付。理解 JetPack 的组成，是后续部署推理服务、编译 TensorRT 引擎、调试 CUDA 内核的前提。JetPack 本质上是一套面向 Jetson 模块的软件开发套件，它把操作系统、驱动、CUDA 工具链、加速库和示例工程打包在一起，保证各组件版本互相匹配。若自行拼装版本，很容易出现 CUDA 与驱动不匹配、TensorRT 无法加载、cuDNN 符号缺失等问题，因此“用 JetPack 统一版本”是 Jetson 开发的第一原则。

JetPack 的组成结构

JetPack 在逻辑上分为四层。最底层是 Jetson Linux（L4T），即基于 Ubuntu 的板级支持包，包含引导加载程序、Linux 内核、设备树、根文件系统以及 GPU/ISP/视频编解码等驱动。第二层是 CUDA 工具链，包括 nvcc 编译器、CUDA Runtime、cuBLAS、cuFFT、NPP 等，用于编写和运行 GPU 加速代码。第三层是 加速库，核心是 cuDNN（深度神经网络原语）和 TensorRT（推理优化与运行时）。第四层是 上层框架与工具，如 PyTorch、TensorFlow、DeepStream、VPI、Nsight 系列调试工具，以及 jetson-utils、示例工程等。

需要特别区分两个概念：JetPack 版本与 L4T 版本。JetPack 是面向开发者的整体发行版编号，L4T 是底层 BSP 编号。例如 JetPack 5.1.2 对应 L4T 35.4.1，JetPack 6.x 对应 L4T 36.x。刷机时真正写入设备的是 L4T，而 CUDA、TensorRT 等组件通过 SDK Manager 或 apt 源安装。查看当前系统版本可用：

cat /etc/nv_tegra_release
# 输出示例：R35 (release), REVISION: 4.1, GCID: 33912345
dpkg-query --showformat='${Version}\n' --show nvidia-l4t-core

刷机与系统配置

刷机有两种主流方式。第一种是 NVIDIA SDK Manager，运行在 Ubuntu 主机上，通过图形界面选择目标模块（如 Jetson Orin Nano、Xavier NX）、JetPack 版本和要安装的组件，自动完成下载、烧录和组件安装，适合首次搭建。第二种是 flash.sh 脚本，位于 L4T BSP 的 Linux_for_Tegra 目录，适合批量生产或需要自定义分区、设备树的场景。

刷机前需将 Jetson 置于恢复模式（Recovery Mode）：以 Orin Nano 为例，先断开电源，按住 Force Recovery 按钮，再接入 USB-C 到主机，松开按钮。主机执行 lsusb 应看到 NVIDIA 的 0955:7xxx 设备。随后在 SDK Manager 中选择“Jetson”目标，勾选 JetPack 组件，输入设备存储类型（NVMe 或 eMMC），开始烧录。烧录完成后设备首次启动会进入 Ubuntu 初始化向导，设置用户名、密码、时区和网络。

系统配置阶段建议完成几件事：一是扩展根分区，若使用 NVMe 需确认根文件系统已挂载到 SSD；二是配置国内 apt 镜像以加速后续安装；三是设置风扇策略与电源模式。Jetson 提供 nvpmodel 与 jetson_clocks 两个关键工具：nvpmodel 切换功耗模式（如 15W、MAXN），jetson_clocks 将 CPU/GPU/EMC 频率锁定到最高，用于性能测试时排除动态调频干扰。查看当前模式：

sudo nvpmodel -q
sudo jetson_clocks --show
# 性能测试前锁定最高频率
sudo nvpmodel -m 0 && sudo jetson_clocks

CUDA / cuDNN / TensorRT 环境验证

组件安装完成后必须逐项验证，否则问题会推迟到部署阶段才暴露。CUDA 验证使用 nvcc --version 查看编译器版本，并用 deviceQuery 示例确认 GPU 被识别。cuDNN 验证可检查头文件与库版本，TensorRT 则用 trtexec 做一次最小推理测试。以下命令可作为标准验证流程：

nvcc --version
# 查看 cuDNN 版本
cat /usr/include/cudnn_version.h | grep CUDNN_MAJOR -A 2
# TensorRT 版本与设备信息
dpkg -l | grep nvinfer
/usr/src/tensorrt/bin/trtexec --version
# 用随机输入跑一次最小引擎，确认运行时可用
/usr/src/tensorrt/bin/trtexec --onnx=/dev/null --shapes=input:1x3x224x224 2>/dev/null || true

更可靠的验证是编译并运行 CUDA 示例。进入 /usr/local/cuda/samples（或从 GitHub 获取 cuda-samples），执行 make 后运行 deviceQuery，若输出中显示 Result = PASS 且列出 GPU 名称、计算能力（如 Orin 为 8.7），说明 CUDA 驱动与运行时链路正常。TensorRT 验证则建议用 trtexec 加载一个真实 ONNX 模型，观察是否能成功构建引擎并输出吞吐量，这比只看版本号更有意义。

远程开发与调试工具链

Jetson 通常作为边缘设备部署，直接接显示器键鼠开发效率低，因此远程开发是常态。最基础的方式是 SSH：在 Jetson 上确认 sshd 已启动，主机通过 ssh nvidia@<设备IP> 登录。更高效的是 VS Code Remote-SSH，在主机 VS Code 中安装 Remote-SSH 插件，连接到 Jetson 后即可在远端直接编辑、运行和调试 Python/C++ 代码，终端与文件系统都指向设备本身。

性能调试依赖 NVIDIA 的 Nsight 系列。Nsight Systems 用于系统级时间线分析，能看清 CPU 线程、CUDA 流、内存拷贝和 TensorRT 执行的时间分布，常用命令为 nsys profile --stats=true ./app。Nsight Compute 用于单个 CUDA 内核的深入分析，如占用率、访存效率、指令吞吐，命令为 ncu --set full ./app。此外，tegrastats 是 Jetson 特有的轻量监控工具，可实时输出各模块功耗、温度、内存和 GPU 利用率，适合长时间运行推理服务时观察设备状态。

完成以上步骤后，一台 Jetson 设备应具备：可远程登录的开发环境、版本匹配的 CUDA/cuDNN/TensorRT、可用的性能剖析工具，以及锁定频率后的稳定性能基线。这套环境是后续模型转换、引擎构建和推理服务部署的基础，任何一项缺失都会在优化阶段放大为难以定位的问题。