---

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

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

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

---

---

Jetson边缘嵌入式实战课程第四讲：为什么 Jetson 产品化必须掌握 Yocto

大家好，我是 孙杰。

这些年一直在做嵌入式系统、边缘设备和 AI 应用相关工作，也持续分享一些技术学习和项目实践中的经验。这套课程的内容，主要也是基于这些年的系统开发和项目积累整理出来的。

最近我和 与非网、贸泽电子 合作，做了一套 Jetson 边缘嵌入式实战课程。这套课程不是单独讲某一个工具，也不是只讲某一个 demo，而是希望把 Jetson 平台相关内容按更清晰的脉络梳理出来，从硬件、系统到应用，尽量形成一个完整的学习路径。

这一篇，继续介绍第四讲的内容：Yocto 定制 Jetson 系统。

---

一、为什么第四讲要讲 Yocto

前面几讲已经把 Jetson 的基础脉络铺开了：

• 第一讲：Jetson 硬件平台怎么选
• 第二讲：JetPack 和 SDK Manager 是什么
• 第三讲：L4T 与 Jetson 系统架构

到了第四讲，课程开始进入一个更偏“产品化”的问题：
Jetson 如果真的要做成商业产品，为什么不能一直停留在 JetPack + Ubuntu 的开发模式，而要走向 Yocto？

这其实是很多做 Jetson 项目的人都会遇到的一道分水岭。

在开发阶段，JetPack 确实很好用。
刷机快、环境全、上手门槛低，拿来跑 demo、做原型验证、做算法联调，都非常方便。

但一旦项目开始往产品化推进，问题就会慢慢暴露出来：

• 系统组件太多，依赖链复杂
• 包管理不可控，升级可能破坏兼容性
• 系统内容难以精确裁剪
• 很难形成最小可信系统
• 长周期维护成本高

这也是第四讲要讲 Yocto 的根本原因。课程里明确指出，JetPack 发行版（Ubuntu）不适合量产环境，而 Yocto 提供的是完全可控的系统构建方式。【91†source】

---

二、JetPack 为什么不适合量产环境

这一点其实非常关键。

JetPack 使用 Ubuntu 作为根文件系统，这对开发者很友好，但 Ubuntu 本身带有典型桌面发行版的特点：

• 组件庞杂
• 依赖链复杂
• 包管理和升级不可完全控制
• 很难做到系统级最小化裁剪

从“开发机”的角度看，这些问题未必明显。
但从“产品”的角度看，它们都会变成风险：

• 升级后依赖漂移
• 软件版本不可冻结
• 长期维护中出现兼容性问题
• 系统内容无法严格审计
• 启动速度、镜像体积、安全性难以满足工业设备要求

所以，JetPack 更适合 开发环境，而不是 量产环境。【91†source】

---

三、什么是 Yocto，为什么它对 Jetson 特别重要

课程里对 Yocto 的定位非常明确：

Yocto 不是一个发行版，而是一个构建发行版的工具链。【91†source】

这句话非常重要。

很多人刚接触 Yocto 时，容易把它理解成“另一种 Linux 发行版”。
其实不是。Yocto 的核心价值在于：你可以从源代码和元数据层面，定义系统的每一个组成部分。

也就是说，你可以决定：

• 内核版本
• Bootloader 版本
• 驱动和补丁
• RootFS 里到底有哪些文件
• 启用哪些服务
• 系统要不要图形界面
• 需要哪些中间件和用户态组件

课程里总结的几个关键词其实很准确：

• 可控
• 可裁剪
• 可重现

这也是 Yocto 在工业设备、车规设备、边缘 AI 产品中被广泛使用的根本原因。【91†source】

为什么 Jetson 平台必须学 Yocto

这一讲里还有一个非常重要的判断：

Yocto 是 Jetson 平台上唯一可行的量产系统方案，因为 Buildroot 无法支持 Jetson 的闭源驱动生态，而 Ubuntu（JetPack）又不适合产品化。【91†source】

这句话实际上点明了 Jetson 平台的特殊性。

Jetson 和很多普通 ARM 平台不一样。它依赖 NVIDIA 的 GPU、DLA、ISP、视频编解码、多媒体等闭源驱动生态。如果没有一套能够兼容这些底层能力、又能实现系统定制和版本冻结的构建体系，产品化就会很难推进。

而这套体系，在 Jetson 上就是 Yocto + meta-tegra。

---

四、Yocto 在 Jetson 产品上的优势到底体现在哪

课程里专门列出了 Yocto 在 Jetson 产品化中的多维度优势，这部分非常适合从产品需求出发来理解。【91†source】

我这里把它按工程视角重新梳理一下。

1. BSP 可深度定制

如果项目里要接 MIPI 摄像头、工业相机、定制 I2C 设备、PCIe 外设，或者要改电源、时钟、设备树配置，那么系统层的 BSP 必须可控。

Yocto 的优势就在于：

• 内核、设备树、驱动都在同一套构建体系里
• 变更路径清晰
• 版本关系明确
• 系统可重建、可追溯

这对 Jetson 上的 Camera / ISP / I2C / PCIe 等定制尤其重要。【91†source】

2. 闭源驱动能力可以完整保留

Jetson 平台的价值，很大程度上来自 NVIDIA 的 GPU、ISP、编码器、解码器、多媒体加速链路。

如果系统构建方式不能把这些能力完整迁移进去，那“定制系统”就没有意义。

课程里指出，meta-tegra 深度集成 NVIDIA 全套闭源驱动，这意味着 Yocto 构建出来的系统可以保留 JetPack 的核心硬件能力。【91†source】

3. 系统可裁剪，适合真正的产品镜像

Ubuntu 做开发环境很方便，但真到产品里，很多组件根本不需要。

Yocto 可以做到：

• 文件级裁剪
• 服务级裁剪
• 图形栈自由选择
• 启动项和依赖精确控制
• 镜像体积压缩到几十 MB 级别

这对于无人机、机器人、边缘盒子、工业相机这类设备特别重要。【91†source】

4. 更适合 OTA、安全和生命周期管理

如果产品要支持：

• A/B 升级
• dm-verity
• OTA 回滚
• 长周期版本维护
• 版本冻结和审计

那么 Yocto 的优势会非常明显。课程里提到，它天然适合与 Mender、RAUC 等机制结合，用于构建更稳定的量产系统方案。【91†source】

5. 更适合长期维护

这是很多团队后面才会真正体会到的问题。

开发能跑，不代表三年后还能维护。
产品能交付，不代表五年后还能稳定复现同一套软件环境。

课程里明确提到，Yocto 支持：

• 可重现构建
• 版本冻结
• 可审计
• 长生命周期维护

这对医疗设备、交通设备、电力终端、工业控制类产品尤其重要。【91†source】

---

五、Jetson 上的 Yocto BSP：meta-tegra 到底是什么

这一讲的核心内容之一，就是 meta-tegra。

1. 什么是 BSP 层

在 Yocto 里，BSP（Board Support Package）层本质上是“让特定硬件平台能成功启动并运行 Linux 所需要的全部软件支持层”。课程里列出的组成包括：

• Bootloader
• Kernel
• Device Tree
• Drivers
• Firmware
• Board-level patches【91†source】

也就是说，BSP 层不是单一文件，而是一整套和硬件平台强相关的系统支持内容。

2. 什么是 meta-tegra

课程里对它的定义很清楚：

meta-tegra 是 NVIDIA Jetson 平台的官方 Yocto BSP 层，基于 L4T。它将 JetPack 使用的底层驱动与中间件全部迁移到 Yocto 中，使 Yocto 构建的系统具备 JetPack 的全部能力。【91†source】

这句话的意思可以理解成：

• 你不是“放弃 Jetson 能力去换可控系统”
• 而是通过 meta-tegra，把 JetPack 的底层能力迁移到 Yocto 的构建体系中

它集成的内容包括：

• L4T 定制内核
• GPU 与 DLA 加速
• ISP / CSI / VI 摄像头链路
• NVENC / NVDEC 编解码
• 多媒体与视觉库（如 VPI）
• UEFI 启动链
• 设备树配置
• OP-TEE 等安全机制【91†source】

也正因为如此，meta-tegra 才成为 Jetson 产品化系统构建的关键基础。

---

六、Yocto SDK 为什么比传统开发方式更适合产品开发

第四讲还专门讲了 Jetson Yocto SDK 的价值，这部分非常值得单独拎出来说。【91†source】

1. ABI 完全一致

这一点是做产品时特别重要、但经常被忽视的问题。

Yocto SDK 和目标系统镜像由同一次构建流程生成，因此：

• ABI 一致
• 库版本一致
• 编译选项一致

这样做最大的好处是：
应用在开发环境和目标设备上的行为更一致，能避免大量“本地能编译、设备上跑不起来”的问题。【91†source】

相比之下，如果直接依赖 Ubuntu / apt 的生态，版本变化很容易引入 ABI 漂移。

2. 系统组件会自动进入 SDK

课程里提到，只要系统镜像中启用了 Qt、Chromium、GStreamer、CUDA、TensorRT 等组件，对应开发库就会自动进入 Yocto SDK。【91†source】

这意味着：

• 不需要手动拼开发环境
• 不需要额外整理依赖包
• 系统和应用开发环境天然同步

对于大型应用的集成，尤其是 UI、大型多媒体应用或者 AI 推理应用，这个优势非常明显。

3. 适合长期冻结和自动化构建

Yocto 的另一大优势，是适合 CI/CD 和版本冻结。课程里提到，它特别适合 3–7 年生命周期的设备维护。【91†source】

这一点对以下场景非常关键：

• 工业相机
• 机器人
• 无人机
• 医疗设备
• 电力或交通终端

这类项目不是“先跑起来”就结束，而是需要长期持续维护的。

---

七、这一讲里的一个实践示例：在 Yocto 中加入 Chromium

为了说明 Yocto 的扩展能力，课程里给了一个很典型的例子：
通过 meta-browser Layer，把 Chromium 集成进 Jetson 的 Yocto 系统中。【91†source】

示例流程大致如下：

1. 拉取 Layer

git clone https://github.com/OSSystems/meta-browser.git

2. 加入到 bblayers

BBLAYERS += "${TOPDIR}/../meta-browser"

3. 将 Chromium 加入镜像

IMAGE_INSTALL += "chromium"

4. 构建镜像

bitbake core-image-weston

5. 在目标系统运行

chromium https://www.yocto.org

这个例子本身并不是为了讲 Chromium，而是为了说明一件事：

Yocto 不只是“做最小系统”，它同样可以扩展大型软件生态，而且这种扩展是可控、可重现、可维护的。【91†source】

这恰恰是很多产品真正需要的能力。

---

八、第四讲的重点和难点在哪里

课程最后总结得很准确，这一讲的重点主要包括：

• 掌握 Yocto 在 Jetson 平台上的实际使用方式
• 理解 meta-tegra BSP 的组成和系统构建流程
• 理解 SDK 的生成机制
• 掌握应用层组件扩展方式
• 理解 Layer / Recipe 的元数据体系和构建逻辑【91†source】

而难点主要在于两件事：

1. 理解 Yocto 的元数据体系

很多人第一次接触 Yocto，会被这些概念绕住：

• Layer
• Recipe
• Machine
• Distribution
• Image
• Class
• Append

它难的不是命令本身，而是背后的构建思想。

2. 正确处理依赖和配置

Jetson 平台本身就比普通板子复杂。
再叠加 Yocto 的构建体系，如果对依赖关系、版本关系和 BSP 结构不熟，很容易在配置和构建阶段踩坑。

所以第四讲并不是“上来就教你写复杂 recipe”，而是先把 Yocto 在 Jetson 上到底怎么用、为什么必须用 这件事讲清楚，这样后面继续往深处走才有意义。

---

九、这一讲适合哪些人看

如果你处在下面这些阶段，第四讲会很适合你：

• 正在从 JetPack 开发环境走向产品化系统
• 想做 Jetson 商用设备或工业设备
• 需要更可控的 BSP、镜像和应用环境
• 想理解 meta-tegra 在 Jetson 系统中的作用
• 后续准备做 Qt、Docker、GStreamer、CUDA、TensorRT 等系统级扩展
• 想建立一套可维护、可审计、可冻结的软件发布体系

简单说，这一讲更适合那些不满足于“开发板能跑起来”，而是开始认真考虑“产品怎么真正落地”的开发者。

---

十、课程入口

B站视频入口

第四讲：Yocto 定制 Jetson 系统

与非网课程入口

Jetson边缘嵌入式实战课程（贸泽电子）

---

十一、我想分享的内容

我一直觉得，边缘嵌入式开发真正有价值的部分，不只是把功能做出来，而是把系统真正做“稳”、做“可控”、做“可维护”。

如果前几讲更多是在帮大家建立 Jetson 的基础认识，那么第四讲开始，课程就正式进入了更靠近产品化、工程化的阶段。

为什么 Jetson 产品最终要走向 Yocto？
本质上不是因为它“更高级”，而是因为真正的产品需要：

• 可控
• 可裁剪
• 可复现
• 可长期维护

而这些能力，恰恰是 Yocto 最核心的价值。

如果你对 Jetson 和边缘嵌入式开发感兴趣，也欢迎继续关注我。后面我会把这个系列继续更新下去。

---