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

关注

原创最新推荐文章于 2026-09-28 12:54:49 发布 399 阅读 AI 写同款· GEO 优化 ›

JetPack 7.2嵌入式AI部署实战：Yocto构建、TensorRT优化与Secure Boot全链路解析嵌入式AI开发正从单点模型推理迈向端到端可量产部署阶段。JetPack作为NVIDIA面向Jetson平台的系统级开发框架，其核心价值在于统一管理Linux内核（L4T）、CUDA、TensorRT、ROS2等组件的版本耦合与安全启动流程。尤其在AGX Orin等高性能边缘芯片上，Yocto构建体系已成为实现Secure Boot 2.0、eFUSE烧录和AOT编译引擎集成的事实标准。本文围绕JetPack 7.2展开，深入剖析内存子系统优化如何通过SRAM预加载提升1.3倍实时推理性能，并详解如何将YOL 阅读详情

📺 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 / SDK Manager 的优势
上手速度	快，适合第一次把板子跑起来
调试环境	Ubuntu 熟悉，apt、ssh、桌面都方便
AI 组件	CUDA、TensorRT、DeepStream 安装直接
Demo 验证	适合模型、相机、性能快速验证

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

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

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

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

开发阶段关注的是：

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

量产阶段关注的是：

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

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

维度	Ubuntu L4T / JetPack	Yocto / OE4T
主要目标	快速开发、完整体验	定制系统、量产维护
rootfs	偏通用、组件多	可裁剪、按需生成
构建方式	更偏刷机 + 包安装	从源码和 recipe 构建镜像
版本追踪	手工修改容易分散	layer、recipe、patch 可管理
OTA 集成	可以做，但需要额外整理	更适合工程化集成
适用阶段	开发、验证、Demo	产品化、批量部署、长期维护

一句话总结：

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 硬件	Orin / Thor 模块和开发套件
Jetson Linux	BSP、Kernel、Bootloader、驱动基础
JetPack 组件	CUDA、TensorRT、VPI、DeepStream 等 AI 能力
Ubuntu L4T	快速开发和验证
Yocto / OE4T	定制系统、量产镜像、长期维护

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