Jetson Edge AI 实战03：L4T 到底是什么？Bootloader、Kernel、RootFS 一次讲清【视频讲解】

> 🎬 本文配套完整视频已发布：

👉 Jetson Edge AI 实战03：L4T 与 Jetson 系统架构｜点击进入 B站观看

前两讲，我们先认识了 Jetson 的硬件，又把 JetPack 和 SDK Manager 的关系理了一遍。

到了第三讲，我想开始真正往 Jetson 系统底层走。

只要后面准备做 Jetson 驱动、摄像头、载板适配、Yocto、Secure Boot，基本都会不断碰到一个词：

L4T。

很多人知道 JetPack，却不一定真正理解 L4T。还有一些刚从 Rockchip、i.MX、U-Boot 平台转过来的工程师，会发现 Jetson 的 Bootloader、设备树、Kernel 结构明显更复杂。

所以这一讲不急着做应用，而是先把：

L4T → Bootloader → Kernel → Device Tree → RootFS

这一整条 Jetson 系统链路串起来。

本节课程的主题就是 L4T 与 Jetson 系统架构，后续的驱动、Camera、BSP 和系统定制都会建立在这里。

---

L4T 到底是什么？和 JetPack 有什么关系？

这是最先要搞清楚的问题。

L4T 全称是：

Linux for Tegra

对于做嵌入式 Linux 的工程师来说，我觉得完全可以先把它理解成：

NVIDIA 为 Jetson 提供的一套官方 Linux BSP。

它负责 Jetson 最底层的系统运行环境，包括 Bootloader、Linux Kernel、硬件驱动，以及基于 Ubuntu LTS 构建的 RootFS。

而 JetPack 是建立在 L4T 之上的完整开发软件栈。

所以可以先简单记成：

L4T 负责把 Jetson 这台机器真正跑起来。

JetPack 负责在这个基础上继续提供 CUDA、TensorRT、多媒体和 AI 开发环境。

课程里对 L4T 的定位也很明确：它是 JetPack SDK 的核心基础，CUDA、TensorRT、多媒体加速以及系统功能都依赖下面的 L4T。

这个关系一旦理清，后面很多概念就不会混了。

---

L4T 版本为什么总和 JetPack 一起出现？

第二讲我们已经讲过 JetPack 4、5、6 等版本。

对应到底层，同样存在不同的 L4T 版本。

课程里整理了一条比较清楚的演进关系：

• L4T 32.x → JetPack 4.x
• L4T 34.x → JetPack 5.0 DP
• L4T 35.x → JetPack 5.1.x
• L4T 36.x → JetPack 6.x

不同版本还会同时改变：

Linux Kernel、Ubuntu、Bootloader，以及支持的 Jetson 设备。

所以实际项目里经常会看到：

JetPack 6.x
L4T 36.x
Kernel 5.15
Ubuntu 22.04

这不是四套独立的软件。

它们其实属于同一套 Jetson 软件平台版本。

这也是为什么 Jetson 上做 Kernel、驱动、CUDA、多媒体时，版本匹配非常重要。

不是随便拿一个 .ko 模块放进去就能用，也不是换个 Kernel 就一定能正常跑 NVIDIA 的 GPU、ISP 和多媒体组件。

---

L4T 里面到底包含什么？

真正进入 Jetson BSP 开发以后，我们经常会看到 NVIDIA 提供的：

Drivers、Sources、Docs、Tools。

这四部分其实很好理解。

Drivers：让系统真正跑起来

这一部分包含已经编译好的驱动和系统组件。

里面会涉及 Kernel、Bootloader、GPU、ISP、Camera、多媒体以及刷机工具。

它的核心作用就是：

让 Jetson 能启动，并且让硬件真正工作。

Sources：允许我们继续定制

包括 Kernel、设备树以及部分软件组件的源码。

这也是我们后面做：

• 驱动修改
• Device Tree 定制
• Carrier Board 适配
• Kernel 编译

真正要接触的部分。

Jetson 本身并不是所有底层内容都完全开放，课程里把这种方式概括成“半开源”：部分内容可以查看和修改，而更底层的一些初始化仍然由 NVIDIA 控制。

Docs：非常重要，但最容易被忽略

真做 Jetson 项目以后会发现，很多问题靠网上搜索不一定靠谱。

尤其是：

Pinmux、UPHY、Carrier Board、Bootloader、Camera

很多东西还是要回 NVIDIA 官方文档。

Tools：完成构建和调试

编译 Kernel、构建镜像、调试性能，都需要对应工具。

所以 L4T 并不是简单的一份 Linux 源码。

它实际上是一整套完整的 Jetson BSP 开发环境。

---

把 Jetson Linux 从底到顶拆开

我觉得学习 Jetson 系统最有效的方法，就是不要一开始看一大堆文件。

先分层。

大致可以拆成四个部分。

1. Boot 阶段

最先解决的是：

系统怎么起来。

这里涉及 BootROM、MB1、MB2、CBoot 或 UEFI。

这一阶段要先完成最基本的硬件准备，例如电源、DDR、时钟以及启动相关配置。

2. Kernel

Bootloader 准备完成后，Linux Kernel 开始接管系统。

Kernel 负责：

• 内存管理
• 任务调度
• PCIe
• GPU
• ISP
• NVENC / NVDEC
• 各种硬件驱动

Jetson 很多真正的硬件能力，都是从这一层开始建立起来。

3. Device Tree + Driver

这一层对嵌入式工程师应该非常熟悉。

设备树负责描述：

硬件在哪里、地址是什么、总线怎么连接、GPIO 怎么配。

Driver 则负责真正操作硬件。

所以以后遇到：

摄像头为什么没有 probe？

I²C 设备为什么看不到？

GPIO 为什么不工作？

很多时候都会回到：

DTB + Driver。

4. RootFS

最后才进入我们日常最熟悉的 Ubuntu 用户空间。

systemd、系统服务、CUDA、TensorRT、VPI 等内容都运行在这里。

所以整个 Jetson Linux 可以先简单理解为：

Boot → Kernel → DTB / Driver → RootFS → Application

把这条链记住，后面定位问题非常有帮助。

---

Jetson 开机时到底发生了什么？

换一个角度，如果按照时间顺序看，就是完整的启动流程。

大致可以理解成：

上电

↓

BootROM

↓

MB1

↓

MB2

↓

UEFI

↓

Kernel

↓

RootFS

↓

systemd

↓

用户应用

所以 Jetson 开机，并不是“直接启动 Linux”。

在 Kernel 之前其实已经做了很多事情。

Bootloader 阶段会负责底层硬件初始化，然后把 Kernel、DTB、initrd 等内容交给 Linux。

Kernel 启动以后继续初始化驱动和硬件。

RootFS 挂载以后，systemd 再启动用户空间服务。

理解这个顺序以后，排查问题会简单很多。

比如：

连 Kernel log 都没有。

那就不要先去检查 Ubuntu 服务，问题大概率发生在 Bootloader 或更早。

如果：

Kernel 已经启动，但是摄像头没有。

那重点就应该看：

设备树、驱动、模块、固件。

如果：

Ubuntu 已经正常启动，但 CUDA 不工作。

这时候再去看 NVIDIA 用户态组件和版本匹配。

所以真正重要的不是记启动命令，而是知道：

问题发生在哪一层。

---

Jetson Bootloader 为什么看起来比 U-Boot 复杂？

如果以前做过 Rockchip、i.MX 等平台，会比较习惯：

ROM → SPL / TF-A → U-Boot → Kernel

Jetson 明显不一样。

Jetson Orin 更接近：

BootROM → MB1 → MB2 → UEFI → Kernel

除了启动阶段更多之外，还有一个很重要的东西：

BCT，Boot Configuration Table。

BCT 里面会涉及很多非常底层的板级信息，例如：

• 电源
• Pinmux
• UPHY
• DDR
• 电压
• Clock
• Carveout
• 安全参数

这意味着有些硬件配置在进入 Kernel 之前就已经决定了。

这点对于以后做 Carrier Board 非常关键。

以前在某些 ARM 平台上，一个硬件问题可能首先想到：

改 DTS。

但 Jetson 上不一定。

有些配置发生在更早的 Bootloader / BCT 阶段。

所以只改 Kernel Device Tree，有时候根本解决不了问题。

---

Jetson Kernel 也不只是“一个 Linux Kernel”

继续往 Kernel 里面走，会发现 Jetson 还有几个比较明显的特点。

NVIDIA OOT 模块

Jetson 的 GPU、ISP、CSI、NVENC 等能力需要 NVIDIA 自己的模块配合。

这里的 OOT，就是：

Out-of-Tree Modules。

它们和 Linux Kernel 一起工作，但对版本匹配要求很高。

所以经常会遇到一个现象：

Kernel 能启动，并不代表 Jetson 的全部硬件能力都正常。

多层设备树

Jetson 的设备树通常不是单一的一份 DTS。

可以从几个层次理解：

SoC

↓

Module

↓

Carrier Board

芯片、模组、载板分别描述自己的硬件信息。

这对于 Jetson 模组化设计很合理，但第一次接触时确实比普通开发板复杂。

Kernel 并不是独立工作的

一个真正完整的 Jetson 系统需要：

Kernel + DTB + NVIDIA OOT Modules + Firmware + RootFS

一起配合。

任何一部分版本不一致，都可能出现奇怪问题。课程里也把 OOT 模块依赖、版本匹配和多层设备树列为了这一讲的重点。

---

为什么我觉得 L4T 是 Jetson 必须理解的一层？

如果只想跑一个 Demo，确实不用研究这么深。

SDK Manager 刷完系统，装好 JetPack，直接跑模型也可以。

但是一旦进入真实产品：

• 自己设计 Carrier Board
• 接 MIPI Camera
• 改 Device Tree
• 修改 Kernel Driver
• 定制 RootFS
• 做 Yocto
• Secure Boot
• A/B OTA
• 产品量产

最终都会回来碰 L4T。

这也是为什么第三讲开始，我不再只是讲“怎么使用 Jetson”，而是开始往下面拆：

Jetson 为什么能够工作？

理解 L4T，就是从“会用 Jetson”走向“真正理解 Jetson BSP”的第一步。

---

这一讲，其实记住这几条就够了

如果第一次看，没必要一下记住所有 Boot 阶段。

先记住下面几个关系：

JetPack 建立完整开发环境，L4T 是下面的 Linux BSP 基础。

L4T 包含 Bootloader、Kernel、Driver、RootFS 等核心系统内容。

Jetson 启动主线：Bootloader → Kernel → RootFS。

硬件能否工作，不只取决于 Kernel，还取决于 BCT、DTB、Driver、NVIDIA 模块和用户态库。

把这几个关系先建立起来，后面再看到 L4T 目录、Kernel Source、Device Tree、Bootloader 文件，就不会再是一堆毫无关系的东西。

---

完整视频讲解

本文对应：

《Jetson Edge AI 实战》第03讲：L4T 与 Jetson 系统架构

这一讲主要围绕：

L4T 与 JetPack → L4T版本 → BSP组成 → Jetson Linux架构 → Bootloader → Kernel → Device Tree → RootFS

完整串了一遍。

文章更适合快速建立系统结构，视频则可以跟着课程图把整个启动流程和系统架构一步步理清。

B站搜索：嵌入式孙老师

第三期视频发布后，我也会继续同步到 B站和 YouTube。

需要本节对应的 PPT、代码及详细学习资料，可以联系本人获取。

---

前两讲，我们解决的是：

Jetson 是什么？开发环境怎么装？

第三讲开始解决的是：

Jetson 为什么能够这样运行？

从这一讲继续往后，Camera、Driver、Yocto、载板适配和设备安全，其实都会不断回到今天这套系统架构。

把底层结构看懂以后，再去解决具体问题，很多事情会简单得多。

All in AI，不如走向边缘🌞

🎬 本文配套完整视频已发布：
👉 Jetson Edge AI 实战03：L4T 与 Jetson 系统架构｜点击进入 B站观看