3. IGX开发环境搭建

NVIDIA IGX平台的开发环境搭建，本质上是在一台x86_64 Ubuntu主机（Host）与IGX目标设备（Target，如IGX Orin Developer Kit）之间建立一条可重复、可恢复的工作链路。这条链路包含四个关键环节：物理连接与刷机通道、SDK Manager刷写系统镜像、目标设备网络与远程访问配置、以及容器运行时与GPU能力的验证。理解这条链路的顺序与依赖关系，比记住某一条命令更重要——因为刷机失败、网络不通、SSH拒绝连接这三类问题，几乎都源于对链路中某个环节的假设不成立。

主机与目标设备的物理连接

IGX Orin Developer Kit的刷机与调试依赖两类物理通道：USB-C/Type-C调试口用于串口控制台与部分刷机模式，而以太网口用于网络刷机与后续远程访问。典型连接方式是：主机通过USB-C线连接目标板的调试口（通常标记为Debug或UART），同时用网线将主机的第二个网口与目标板的RJ45口直连，或接入同一交换机。刷机时目标板需要进入恢复模式（Recovery Mode），常见操作是按住Force Recovery按钮后上电或复位，此时主机执行lsusb应能看到NVIDIA设备（如0955:7023这类VID:PID），这是判断目标板是否真正进入恢复模式的直接依据。

串口控制台是贯穿整个搭建过程的“生命线”。在主机上可用picocom或minicom连接，典型参数为115200波特率、8数据位、无校验、1停止位：

sudo picocom -b 115200 /dev/ttyUSB0
# 退出：Ctrl-A 然后 Ctrl-X

串口能看到UEFI/引导日志，意味着即使网络和SSH都不可用，你仍然可以观察启动过程、进入登录提示符并排查问题。因此建议在刷机前先确认串口可读，再开始SDK Manager流程。

使用SDK Manager刷写IGX系统镜像

NVIDIA SDK Manager是官方推荐的刷机与组件安装工具，运行在Ubuntu主机上。安装后启动，登录NVIDIA开发者账号，在Step 1中选择目标硬件为IGX Orin（或对应IGX型号），选择JetPack/IGX OS版本。Step 2中需要明确勾选两类内容：一是Flash OS（刷写目标板系统），二是Host Components与Target Components（主机侧与目标侧的SDK组件，如CUDA、TensorRT、容器运行时等）。若只需刷机，可取消部分组件以缩短时间。

刷机前SDK Manager会要求填写目标板的连接方式。若使用网络刷机，需要提供目标板在恢复模式下的IP或通过USB自动发现；若使用USB刷机，则确认恢复模式设备已出现。随后进入约20～40分钟的刷写过程，期间串口会输出分区写入与文件系统展开日志。刷写完成后目标板自动重启，首次启动会进行初始化，串口最终应出现登录提示符。

网络配置与远程访问

目标板首次启动后，需要配置网络以便SSH访问。若使用直连网线，可在串口登录后为目标板配置静态IP，例如主机侧网口设为192.168.100.1/24，目标板设为192.168.100.2/24。在目标板上编辑Netplan配置：

sudo nano /etc/netplan/01-igx-net.yaml
# 示例内容
network:
  version: 2
  ethernets:
    eth0:
      addresses: [192.168.100.2/24]
      dhcp4: false
sudo netplan apply

随后在主机上执行ping 192.168.100.2确认连通，再用ssh nvidia@192.168.100.2登录（默认用户名常见为nvidia，密码在首次启动时设置）。若SSH连接被拒绝，优先检查目标板是否已安装并启动openssh-server，以及防火墙是否放行22端口。串口此时仍是重要的回退通道：即使SSH不通，也可以通过串口登录后检查ip addr与systemctl status ssh。

基础容器环境验证

IGX平台的核心价值之一是支持容器化部署，因此刷机后必须验证容器运行时与GPU直通能力。目标板通常预装Docker或NVIDIA Container Toolkit。验证步骤建议按以下顺序进行：

1. 检查Docker服务：docker info，确认Server正常运行。
2. 检查NVIDIA运行时：docker run --rm --runtime nvidia nvcr.io/nvidia/l4t-base:r35.4.1 nvidia-smi，若能看到GPU型号与驱动版本，说明容器内GPU直通成功。
3. 检查CUDA可用性：在容器内执行nvcc --version或运行一个简单的CUDA样例。
4. 检查TensorRT：python3 -c "import tensorrt; print(tensorrt.__version__)"，确认推理栈可用。

若nvidia-smi在容器内报错，常见原因是未指定--runtime nvidia，或目标板未正确安装L4T基础镜像。此时应回到串口检查dmesg | grep -i nvidia，确认内核模块加载正常。

常见问题与判断依据

搭建过程中最值得记住的判断依据有三条。第一，lsusb是否出现NVIDIA恢复模式设备，决定刷机能否开始；第二，串口是否出现登录提示符，决定目标板系统是否真正启动成功；第三，容器内nvidia-smi是否输出GPU信息，决定容器化部署是否具备GPU基础。这三条分别对应“刷得进、起得来、跑得动”，任何一条不成立，都应先回到对应环节排查，而不是继续往下执行。

此外，建议在刷机完成后立即记录目标板的IP、用户名、SDK版本与L4T版本，形成一份简短的设备档案。后续部署容器镜像、配置远程运维时，这些信息会反复用到。对于需要批量部署的场景，可以把网络配置与容器验证脚本化，减少重复手工操作带来的不确定性。