B站 嵌入式孙老师博主个人介绍博主书籍-京东购买链接*Yocto项目实战教程加博主微信进技术交流群jerrydevNVIDIA JetPack 7.2 官宣支持 YoctoJetson 从开发板系统走向量产系统最近看 JetPack 7.2 下载页面时一个变化很值得注意除了传统的JetPack ISO Image和SDK Manager页面里又出现了一个新的入口Yocto Images。虽然当前页面上还是 Coming Soon但这个信号已经很明确NVIDIA 开始把 Yocto 放进 Jetson 官方软件路线里。这件事的重点不是“多了一个构建方式”而是说明 Jetson 的定位正在变化Jetson 不再只是方便开发者验证 AI Demo 的开发板系统而是在向可裁剪、可复现、可长期维护的量产系统靠拢。1. 过去 Jetson 的典型开发方式以前我们使用 Jetson最常见的方式是Jetson DevKitRecovery ModeSDK Manager / flash.shUbuntu L4T RootfsCUDA / TensorRT / DeepStreamAI Demo / Camera / Application这条路线的优点很明显项目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 / JetPackYocto / 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而是要部署到现场长期运行远程升级批量维护。这时系统工程问题会变得非常重要算法 Demo硬件 Bring-up驱动和设备树固化系统服务固化OTA 和安全策略批量生产和长期维护到了后半段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 可以把它们整理成自己的产品 layermeta-product/ ├── recipes-kernel/ ├── recipes-bsp/ ├── recipes-core/ ├── recipes-app/ └── images/这样硬件改动、内核补丁、系统服务、应用程序都进入同一个构建体系。4.4 适合 OTA 和长期维护Jetson 设备一旦部署到客户现场就不能总靠手工刷机。Yocto 更容易和 OTA 系统结合把系统镜像、版本号、分区策略、升级包都纳入自动化流程。这对机器人、工业设备、边缘 AI 网关非常关键。5. NVIDIA 支持 Yocto不是替代 JetPack这里容易有一个误解是不是以后 Jetson 就不用 Ubuntu L4T 了不是。更合理的理解是Jetson 软件路线Ubuntu L4T / JetPackYocto / OE4T快速开发算法验证Demo 和调试定制镜像量产部署长期维护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 LinuxBSP、Kernel、Bootloader、驱动基础JetPack 组件CUDA、TensorRT、VPI、DeepStream 等 AI 能力Ubuntu L4T快速开发和验证Yocto / OE4T定制系统、量产镜像、长期维护这个结构说明 Jetson 正在从“开发者友好的 AI 开发板”进一步走向“工程化的边缘 AI 产品平台”。7. 总结NVIDIA 在 JetPack 7.2 官宣支持 Yocto核心原因可以概括成一句话Jetson 的应用场景已经从开发板验证走向了批量部署和长期维护。Ubuntu L4T 解决的是开发效率问题Yocto 解决的是产品工程问题。对于开发者来说JetPack 仍然是最容易上手的方式对于产品团队来说Yocto 可以把 BSP、内核、设备树、rootfs、应用、OTA、安全策略统一管理起来。所以这次 Yocto 支持的意义不只是“多了一个系统构建方式”而是 NVIDIA 在释放一个信号Jetson 正在从开发板系统走向量产系统。