4. 开发环境搭建与工具链配置

IGX开发者套件的软件栈与普通x86工作站差异很大：它基于NVIDIA Jetson系列SoC（如IGX Orin搭载的AGX Orin模块），采用ARM64架构，GPU与CPU共享统一内存，系统镜像、内核、引导固件和CUDA运行时都由NVIDIA的JetPack/L4T（Linux for Tegra）体系统一提供。因此，开发环境搭建不是"装个驱动再装个CUDA"那么简单，而是从系统烧录开始，逐层向上构建：L4T基础系统 → CUDA/cuDNN → TensorRT → 容器化运行时 → 远程调试通道。任何一层版本错配，都会在TensorRT引擎构建或推理时以"找不到libnvinfer"或"cudaErrorNoDevice"的形式暴露出来。

4.1 系统烧录：从BSP到可启动的IGX

IGX开发者套件的烧录通常使用NVIDIA SDK Manager，或在无图形界面的产线场景下使用flash.sh脚本。烧录前需要确认三件事：目标模块型号（如Orin AGX 64GB）、L4T版本（如35.4.1对应JetPack 5.1.2）、以及存储介质（eMMC或NVMe）。SDK Manager会自动下载BSP、根文件系统和目标组件，但下载量大，建议提前配置好代理或使用离线包。

以命令行烧录为例，进入Linux_for_Tegra目录后，将设备置于恢复模式（按住Force Recovery键再上电），执行：

sudo ./flash.sh jetson-agx-orin-devkit mmcblk0p1

烧录完成后首次启动会进入OEM配置流程，设置用户名、密码、时区。此时应立刻验证基础环境：

cat /etc/nv_tegra_release
uname -m          # 应输出 aarch64
nvidia-smi        # 查看GPU与驱动版本

如果nvidia-smi能正确显示Orin的GPU信息，说明L4T与驱动层已就绪。这一步是整个工具链的地基，若此处异常，后续CUDA和TensorRT都无法正常工作。

4.2 CUDA、cuDNN与TensorRT的安装

在IGX上，CUDA、cuDNN和TensorRT通常通过JetPack的apt源安装，而不是从NVIDIA官网下载.run文件。JetPack 5.x对应的源中，CUDA版本为11.4，cuDNN为8.6，TensorRT为8.5。安装命令如下：

sudo apt update
sudo apt install cuda-toolkit-11-4
sudo apt install libcudnn8 libcudnn8-dev
sudo apt install tensorrt tensorrt-dev

安装后需要把CUDA路径加入环境变量。编辑~/.bashrc，追加：

export CUDA_HOME=/usr/local/cuda-11.4
export PATH=$CUDA_HOME/bin:$PATH
export LD_LIBRARY_PATH=$CUDA_HOME/lib64:/usr/lib/aarch64-linux-gnu:$LD_LIBRARY_PATH

验证安装是否成功，可以用三个命令分别检查：

nvcc --version
python3 -c "import tensorrt; print(tensorrt.__version__)"
dpkg -l | grep cudnn

这里有一个常见陷阱：TensorRT的Python包名在不同版本中可能是tensorrt或tensorrt_libs，且必须与CUDA版本严格对应。如果import tensorrt报libnvinfer.so.8: cannot open shared object file，说明LD_LIBRARY_PATH没有包含TensorRT的库目录，通常位于/usr/lib/aarch64-linux-gnu/。

4.3 容器化开发环境

IGX上直接安装的CUDA/TensorRT会污染系统环境，且难以在多项目间切换版本。NVIDIA提供了l4t-tensorrt和l4t-cuda系列容器镜像，配合nvidia-container-runtime，可以在容器内直接访问GPU。配置步骤如下：

sudo apt install nvidia-container-toolkit
sudo systemctl restart docker
docker run --rm --runtime nvidia --network host \
  nvcr.io/nvidia/l4t-tensorrt:r8.5.2-runtime \
  nvidia-smi

如果容器内能看到GPU，说明容器化GPU直通已打通。实际开发中更推荐使用l4t-tensorrt:devel镜像，因为它包含trtexec、polygraphy等调试工具。一个典型的开发容器启动命令如下：

docker run -it --rm --runtime nvidia --network host \
  -v /home/nvidia/workspace:/workspace \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  -e DISPLAY=$DISPLAY \
  nvcr.io/nvidia/l4t-tensorrt:r8.5.2-devel

这样宿主机的工作目录挂载到容器内，代码修改即时可见，同时容器内可以直接运行TensorRT的Python API和trtexec。

4.4 远程调试配置

IGX开发者套件通常作为边缘设备部署，开发者通过SSH或VS Code Remote进行远程调试。基础SSH配置只需在IGX上启用sshd，然后在开发机上配置~/.ssh/config：

Host igx-dev
    HostName 192.168.1.100
    User nvidia
    ForwardAgent yes

对于TensorRT推理程序的调试，更高效的方式是使用VS Code的Remote-SSH插件，在IGX上直接打开工作区，配合launch.json进行断点调试。一个针对Python推理脚本的调试配置示例如下：

{
  "name": "TensorRT Infer Debug",
  "type": "python",
  "request": "launch",
  "program": "${workspaceFolder}/infer.py",
  "console": "integratedTerminal",
  "env": {
    "LD_LIBRARY_PATH": "/usr/lib/aarch64-linux-gnu:${env:LD_LIBRARY_PATH}"
  }
}

如果需要在容器内调试，可以在容器中启动sshd并映射端口，或者直接使用VS Code的Dev Containers功能，将l4t-tensorrt:devel镜像作为开发容器。这样既保留了容器化的环境隔离，又获得了完整的IDE调试能力。

4.5 工具链版本对应关系

整个工具链的版本必须严格对齐。下表给出JetPack 5.1.2（L4T 35.4.1）下的推荐组合，可作为环境检查的基准：

下图展示了从系统烧录到远程调试的完整工具链层次关系，以及各层之间的依赖方向。图中标注了每层的关键验证点，便于在搭建过程中逐层确认。

搭建完成后，建议用一段最小TensorRT推理代码做端到端验证：加载一个ONNX模型，用trtexec构建引擎，再在Python中执行一次推理，确认输出张量形状和数值范围符合预期。如果这一步通过，说明从系统烧录到远程调试的整条工具链已经贯通，可以进入后续的模型部署与性能调优环节。