NVIDIA JetPack 7.2 官宣支持 Yocto：Jetson 从开发板系统走向量产系统

📺 B站 嵌入式孙老师：博主个人介绍

📘 博主书籍-京东购买链接*：Yocto项目实战教程

📘 加博主微信，进技术交流群： jerrydev

NVIDIA JetPack 7.2 官宣支持 Yocto：Jetson 从开发板系统走向量产系统

最近看 JetPack 7.2 下载页面时，一个变化很值得注意：除了传统的 JetPack ISO Image 和 SDK Manager，页面里又出现了一个新的入口：Yocto Images。

虽然当前页面上还是 Coming Soon，但这个信号已经很明确：NVIDIA 开始把 Yocto 放进 Jetson 官方软件路线里。

这件事的重点不是“多了一个构建方式”，而是说明 Jetson 的定位正在变化：

Jetson 不再只是方便开发者验证 AI Demo 的开发板系统，而是在向可裁剪、可复现、可长期维护的量产系统靠拢。

1. 过去 Jetson 的典型开发方式

以前我们使用 Jetson，最常见的方式是：

这条路线的优点很明显：

所以在开发阶段，Ubuntu L4T 非常好用。

比如我们做 camera bring-up、TensorRT 模型验证、GStreamer pipeline 调试，Ubuntu 环境的确更直接。

但是，当项目从“开发板验证”进入“产品量产”时，问题就变了。

2. 开发板系统和量产系统的关注点不同

开发阶段关注的是：

能不能跑起来？
驱动能不能工作？
相机有没有图？
模型推理性能够不够？

量产阶段关注的是：

系统能不能稳定复现？
rootfs 能不能裁剪？
版本能不能锁定？
OTA 怎么做？
安全面能不能缩小？
100 台设备的软件是否完全一致？

这就是 Ubuntu L4T 和 Yocto 的核心区别。

一句话总结：

JetPack / Ubuntu L4T 解决“怎么快速跑起来”
Yocto 解决“怎么稳定量产和长期维护”

3. 为什么 NVIDIA 现在要正式支持 Yocto？

核心原因其实不是技术新鲜，而是产品需求变了。

过去很多 Jetson 项目停留在开发板验证阶段，SDK Manager + Ubuntu L4T 已经足够。但现在 Jetson Orin、Jetson Thor 面向的场景越来越复杂：

工业相机
机器人
边缘 AI 网关
医疗设备
车载边缘计算
多传感器 AI 设备

这些场景不只是跑一个 demo，而是要部署到现场，长期运行，远程升级，批量维护。

这时系统工程问题会变得非常重要：

到了后半段，Yocto 的价值就明显了。

它可以把这些内容统一纳入构建系统：

Bootloader
Kernel
Device Tree
Pinmux
驱动 patch
系统服务
应用程序
rootfs 配置
OTA 配置
安全策略

最终输出的不是“手工配置过的一台机器”，而是“可以重复构建出来的产品镜像”。

4. Yocto 对 Jetson 产品化最大的价值

我理解 Yocto 对 Jetson 的价值主要有四个。

4.1 可裁剪

量产设备不一定需要完整 Ubuntu 桌面，也不一定需要大量开发工具。

比如一个边缘 AI 相机，可能只需要：

Kernel
Device Tree
Camera Driver
CUDA Runtime
TensorRT Runtime
GStreamer
自己的应用
日志服务
OTA 服务

Yocto 可以从镜像构建阶段就决定系统里放什么、不放什么。这样 rootfs 更小，启动服务更少，攻击面也更小。

4.2 可复现

量产系统最怕“这台机器和那台机器不一样”。

Yocto 的优势是把软件版本固定在 layer、recipe、commit、patch 里。以后追问题时，可以清楚知道：

用了哪个 kernel？
用了哪个 device tree？
用了哪个 JetPack 组件版本？
应用是哪次提交？
rootfs 里包含哪些包？

这比在 Ubuntu 系统里手动 apt install、手动改配置更适合长期维护。

4.3 适合自定义载板

真正做产品时，很少完全照搬 DevKit。自定义载板通常会涉及：

Pinmux
GPIO
I2C / SPI / UART
USB / PCIe
Camera
Display
Power Sequence
Kernel Config
Device Tree

如果这些修改散落在 Linux_for_Tegra 目录和各种脚本里，后期很难维护。

而 Yocto 可以把它们整理成自己的产品 layer：

meta-product/
  ├── recipes-kernel/
  ├── recipes-bsp/
  ├── recipes-core/
  ├── recipes-app/
  └── images/

这样硬件改动、内核补丁、系统服务、应用程序都进入同一个构建体系。

4.4 适合 OTA 和长期维护

Jetson 设备一旦部署到客户现场，就不能总靠手工刷机。

Yocto 更容易和 OTA 系统结合，把系统镜像、版本号、分区策略、升级包都纳入自动化流程。

这对机器人、工业设备、边缘 AI 网关非常关键。

5. NVIDIA 支持 Yocto，不是替代 JetPack

这里容易有一个误解：是不是以后 Jetson 就不用 Ubuntu L4T 了？

不是。

更合理的理解是：

Ubuntu L4T 仍然是最方便的开发入口；Yocto 则是更适合产品化的工程入口。

实际项目里，比较合理的路线是：

前期：SDK Manager + Ubuntu L4T 快速验证
中期：固化 kernel / DT / driver / service
后期：迁移到 Yocto，形成可重复构建的产品镜像

所以 NVIDIA 支持 Yocto，不是要替代 JetPack，而是补齐 Jetson 的量产路径。

6. 这次变化的真正意义

JetPack 7.2 支持 Yocto，表面看只是下载页面多了一个入口，实际代表的是 Jetson 软件栈的分层越来越清晰：

这个结构说明 Jetson 正在从“开发者友好的 AI 开发板”，进一步走向“工程化的边缘 AI 产品平台”。

7. 总结

NVIDIA 在 JetPack 7.2 官宣支持 Yocto，核心原因可以概括成一句话：

Jetson 的应用场景已经从开发板验证，走向了批量部署和长期维护。

Ubuntu L4T 解决的是开发效率问题，Yocto 解决的是产品工程问题。

对于开发者来说，JetPack 仍然是最容易上手的方式；对于产品团队来说，Yocto 可以把 BSP、内核、设备树、rootfs、应用、OTA、安全策略统一管理起来。

所以这次 Yocto 支持的意义不只是“多了一个系统构建方式”，而是 NVIDIA 在释放一个信号：

Jetson 正在从开发板系统，走向量产系统。