📚 课程目录第2章 IGX软件栈与版本构成

2. IGX软件栈与版本构成

在 NVIDIA IGX 平台上做 OTA 升级，最容易踩的坑不是“升级失败”，而是“升完之后某个组件跑不起来”。原因往往在于：IGX 并不是一个单一固件，而是一整套分层软件栈，各层之间通过明确的版本契约绑定。理解这些契约，是后续制定升级策略、判断兼容性、回滚决策的前提。

一、IGX 软件栈的分层结构

从最底层往上，IGX 软件栈大致可以分为五层：

硬件与固件层：IGX Orin 模组、载板、MCU、安全芯片等，固件包括 UEFI、MCU 固件、QSPI 中的引导组件。
BSP 层：Board Support Package，包含内核、设备树、驱动、引导链（Bootloader）、根文件系统基础组件。IGX 的 BSP 由 NVIDIA 发布，版本号通常与 JetPack 绑定。
IGX OS 层：基于 Ubuntu 的定制发行版，包含系统服务、安全启动、OTA 客户端（如 NVIDIA 提供的更新代理）、容器运行时（containerd / Docker）、以及 IGX 特有的管理组件。
CUDA / 加速库层：CUDA Toolkit、cuDNN、TensorRT、VPI、DeepStream 等，构成 AI 推理与多媒体处理的核心依赖。
应用与容器层：用户业务容器、模型文件、推理服务，通过容器运行时与底层解耦，但仍受 CUDA / TensorRT 版本约束。

这五层不是简单堆叠，而是“下层决定上层的可用版本范围”。例如，BSP 决定了内核版本与驱动 ABI，CUDA 驱动必须与内核匹配；TensorRT 又依赖特定版本的 CUDA 与 cuDNN。任何一层单独升级，都可能破坏整条依赖链。

二、JetPack 与 IGX OS 的关系

JetPack 是 NVIDIA 面向 Jetson / IGX 的 SDK 元包，它本身不是运行时组件，而是一组经过验证的版本组合清单。一个 JetPack 版本会明确指定：

L4T（Linux for Tegra）版本，即 BSP 版本；
CUDA、cuDNN、TensorRT、VPI、DeepStream 的版本；
对应的 Ubuntu 基础版本。

IGX OS 则是在 L4T 基础上，叠加 IGX 特有的安全、管理与 OTA 能力后形成的可部署镜像。因此可以这样理解：JetPack 定义“组件版本组合”，IGX OS 定义“可部署的系统镜像”。IGX OS 的版本号通常与某个 JetPack 版本对应，例如 IGX OS 1.0 对应 JetPack 6.x 系列。

在 OTA 场景中，升级包通常以 IGX OS 镜像为单位交付，而不是单独升级 CUDA 或 TensorRT。这意味着版本治理的对象是“镜像版本”，而不是“单个组件版本”。

三、依赖图谱：谁约束谁

下面这张图展示了 IGX 软件栈中各组件的版本依赖方向。箭头表示“被依赖方约束依赖方”，即箭头起点是约束来源，终点是受约束组件。

图中右侧的箭头方向说明：上层组件依赖下层提供的接口与 ABI。例如，TensorRT 依赖特定版本的 CUDA 运行时和 cuDNN；CUDA 驱动又依赖 BSP 中的内核模块。因此，当 OTA 升级只更新了 IGX OS 层而 BSP 未同步更新时，CUDA 驱动可能无法加载，表现为 nvidia-smi 报错或容器启动失败。

四、版本兼容性的实际判断方法

在实际项目中，判断一组版本是否兼容，可以按以下顺序检查：

确认 IGX OS 版本：通过 cat /etc/igx-release 或 cat /etc/nv_tegra_release 获取当前系统版本。
确认 JetPack 对应关系：查阅 NVIDIA 官方 JetPack 版本说明，找到该 IGX OS 版本对应的 JetPack 版本，从而确定 CUDA、TensorRT、cuDNN 的基准版本。
检查容器内版本：在业务容器中执行 nvcc --version、dpkg -l | grep tensorrt，确认实际使用的版本是否与基准一致。
验证驱动加载：执行 lsmod | grep nvidia 和 nvidia-smi，确认内核模块与用户态库版本匹配。

如果发现容器内 TensorRT 版本高于 IGX OS 基准版本，通常意味着容器镜像自带了较新的 TensorRT，但底层 CUDA 驱动未同步升级，此时推理可能失败或性能异常。正确的做法是：要么将容器镜像回退到与 IGX OS 匹配的版本，要么整体升级 IGX OS 到支持该 TensorRT 的版本。

五、OTA 升级中的版本治理要点

IGX OTA 升级通常以 A/B 分区方式切换系统镜像。升级包中会包含新的 BSP、IGX OS 以及配套的 CUDA / TensorRT 库。但容器层往往不在 OTA 包内，需要单独管理。因此版本治理需要关注三个层面：

系统镜像版本：由 OTA 包控制，升级后整体切换。
容器基础镜像版本：需要与系统镜像中的 CUDA / TensorRT 版本对齐，建议在 CI 中固定基础镜像 tag。
应用依赖版本：模型文件、推理框架版本，需在容器内锁定，避免运行时动态拉取不兼容版本。

不要在生产环境中单独使用 apt upgrade 升级 CUDA 或 TensorRT 组件。IGX 的驱动与库经过整体验证，单独升级可能破坏 ABI 兼容性，导致系统无法启动或推理服务崩溃。

一个实用的做法是维护一份“版本矩阵表”，记录每个 IGX OS 版本对应的 JetPack、CUDA、TensorRT、容器基础镜像 tag。每次 OTA 升级前，先查表确认目标版本，再决定容器镜像是否需要同步更新。这样可以把版本兼容性问题从“运行时排障”前移到“升级前检查”，显著降低现场故障率。

总结来说，IGX 软件栈的版本关系不是简单的“越新越好”，而是“整体匹配优先”。JetPack 提供经过验证的组合，IGX OS 提供可部署的镜像，BSP 提供底层约束，CUDA / TensorRT 提供加速能力，容器运行时提供隔离与交付方式。理解这条依赖链，才能在 OTA 升级中做出正确的版本决策。