Jetson 为什么既有 QSPI 又有 NVMe？从 SoM 与载板看懂存储结构

---

📺 B站 嵌入式孙老师：博主个人介绍
📘 博主书籍-京东购买链接：Yocto项目实战教程
📘 加博主微信，进技术交流群：jerrydev

---

Jetson 为什么既有 QSPI 又有 NVMe？从 SoM 与载板看懂存储结构

最近在排查 Jetson Thor 烧录问题时遇到：

Error: Error flashing qspi
Error: Flash failure.

这让我重新想了一个很基础的问题：

Linux 明明装在 NVMe，Jetson 为什么还必须有 QSPI？

顺着这个问题回到硬件，会发现 Jetson 的存储结构其实并不复杂。关键不是背 MB1、MB2、BCT、UEFI 这些名字，而是先理解：

SoM 和载板分别负责什么，又是怎样一起把 Linux 启动起来的。

---

---

1. 先看硬件：QSPI 在 SoM，NVMe 在载板

Jetson 并不是“一块 SoM 就等于一台完整电脑”。

SoM 提供核心计算和启动能力，真正的 SSD、USB、Ethernet、Display 等接口则通过 Carrier Board 扩展。

整体关系可以先压缩成：

                 Jetson SoM
┌────────────────────────────────┐
│                                │
│          Tegra SoC             │
│              │                 │
│          QSPI NOR              │
│              │                 │
│       Boot Firmware            │
│                                │
│          LPDDR RAM             │
│                                │
└──────────────┬─────────────────┘
               │ SoM Connector
               │
               │ PCIe
               ↓
             Carrier
┌────────────────────────────────┐
│                                │
│          M.2 M-Key             │
│              │                 │
│           NVMe SSD             │
│              │                 │
│      Linux / RootFS / Data     │
│                                │
└────────────────────────────────┘

在实际自定义载板中，NVMe 也是这种关系：SoM 提供 PCIe，Carrier 提供 M.2 M-Key Socket 和 SSD。

这就形成了 Jetson 最重要的两个持久化存储角色：

存储	在哪里	主要职责
QSPI NOR	SoM	Boot Firmware / 启动
NVMe SSD	Carrier	Linux / RootFS / 数据

一句话：

SoM 负责把平台启动起来，Carrier 上的 NVMe 负责提供真正的操作系统。

QSPI 为什么必须放在 SoM？

因为启动不能依赖 Carrier 上一定存在某一块 SSD。

QSPI 是 SoM 自己带着的 Boot Flash。

里面主要面对的是：

Boot Firmware
BCT
UEFI
Platform Firmware

实际 Thor BSP 镜像目录里也能看到：

mb1_t264_prod.bin
mb2_t264.bin
mb1_bct_*.bct
mb2_bct_*.bct
uefi_t26x_general.bin
bpmp_*.bin
xusb_*.bin
...

这些东西的共同特点是：

它们不是 Linux RootFS，而是 Linux 启动之前的平台软件。

所以我更习惯把 QSPI 理解成 Jetson SoM 上的 Boot Storage。

NVMe 为什么放在 Carrier？

因为 NVMe 是大容量系统存储，而且不同产品对容量、尺寸甚至存储方案的要求都可能不同。

SoM 只需要把 PCIe 引出来：

Tegra
  │
PCIe
  │
  ↓
Carrier
  │
M.2 M-Key
  │
  ↓
NVMe

这样产品可以自由选择：

256 GB
512 GB
1 TB
2 TB
...

Linux 的 RootFS、应用、模型和数据都可以放在这里。

这也是 SoM + Carrier 架构很典型的分工：

通用的启动能力留在 SoM，产品相关的大容量存储留给 Carrier。

---

2. 两块存储并不是独立工作的

理解 QSPI 和 NVMe 时，最容易产生另一个误区：

QSPI 是一套东西
NVMe 是另一套东西

实际上正常启动时，两边必须接力。

QSPI 先把机器带起来

可以先不纠结 Thor 内部每一级 Boot Firmware 的名字，把正常启动压缩成：

Power On
   ↓
SoC Early Boot
   ↓
QSPI
   ↓
Boot Firmware / BCT
   ↓
UEFI

QSPI 这一阶段负责解决：

平台怎么初始化
        ↓
Bootloader 怎么运行
        ↓
最终去哪里寻找 OS

到这里，机器还没有真正进入我们熟悉的 Linux。

然后才轮到 Carrier 上的 NVMe

UEFI 继续通过 SoM 的 PCIe Controller 找到载板上的 NVMe：

QSPI
  ↓
UEFI
  │
  │ PCIe
  ↓
NVMe
  ↓
Kernel
  ↓
RootFS
  ↓
Linux

于是 SoM 和 Carrier 真正合作起来：

               SoM
        ┌───────────────┐
        │ QSPI          │
        │ Boot Firmware │
        │ UEFI          │
        └───────┬───────┘
                │
             PCIe
                │
                ↓
              Carrier
        ┌───────────────┐
        │ NVMe          │
        │ Kernel        │
        │ RootFS        │
        └───────────────┘

所以更加准确的理解不是：

QSPI 和 NVMe 谁更重要？

而是：

QSPI 负责把启动流程送到 NVMe，NVMe 再接过来完成 Linux 启动。

这就是两者最核心的关系。

---

3. 再反过来看 Flash，很多东西就清楚了

硬件关系理解以后，再看 Jetson 烧录目录就不会那么乱。

实际生成的 Thor 镜像目录里同时存在：

internal-flash.idx
external-flash.idx

以及：

MB1 / MB2
BCT
UEFI

和：

boot.img
kernel_*.dtb
*.ext4.simg

这实际上就是硬件结构在软件上的映射：

硬件                          镜像

SoM QSPI                 Boot Firmware
   │                     BCT
   │                     UEFI
   │
   │
Carrier NVMe             Kernel
                         RootFS
                         OS Data

为什么一次完整烧录不只是写 NVMe？

因为只有 NVMe 上有 Linux，还不够。

假设：

NVMe
├── Kernel    ✓
└── RootFS    ✓

QSPI
└── Boot Firmware   ✗

机器仍然可能走不到加载 NVMe 的阶段。

反过来：

QSPI
└── Boot Firmware   ✓

NVMe
└── RootFS          ✗

则可能能够进入前面的 Boot/UEFI 阶段，但最终没有正常 Linux 可以启动。

所以完整 Flash 本质上是在准备：

           Jetson 完整系统

     SoM                   Carrier
      │                       │
    QSPI                    NVMe
      │                       │
Boot Environment          Linux OS

这也是为什么 Error flashing qspi 不能简单理解成：

“Ubuntu 没刷进去。”

它明确指向的是启动存储这一侧。

---

BCT 和 QSPI 又是什么关系？

看到：

tegra264-mb1-bct-qspi-common.dts

很容易误以为：

这是在定义 QSPI 里面存什么。

其实不是。

类似：

qspiflash@0 {
    interface-frequency = <...>;
    maximum-bus-width = <...>;
    fifo-access-mode = <...>;
};

描述的是：

Boot Firmware 怎么正确访问 QSPI 这个硬件。

所以我现在会把 Jetson BSP 中这两类东西明确分开：

BCT
│
└── Hardware Configuration
    QSPI 怎么访问？
    Pin 怎么配置？
    电源怎么初始化？

而：

Flash XML / Partition Layout
│
└── Storage Layout
    有哪些 Partition？
    哪个 Image 写到哪里？

简单说：

BCT 管“硬件怎么工作”，Flash Layout 管“镜像怎么放”。

这个区别理顺后，看 L4T BSP 会容易很多。

---

initrd flash 只是把两边“刷起来”

再看：

l4t_initrd_flash.sh

名字里虽然有 initrd，但它并不代表第三块存储。

脚本本身就说明它是使用 initrd 来完成目标设备 Flash 的工具。

原因也很直接：

一块正在生产或者恢复的设备，QSPI 和 NVMe 可能都还没有完整系统，那么必须先通过 Recovery/RCM 给目标板送进去一个临时执行环境。

于是：

Host PC
   │
USB Recovery
   ↓
RCM
   ↓
临时 initrd
   ↓
Target 获得 Flash 能力
   │
   ├─────────────┐
   ↓             ↓
 QSPI           NVMe

所以这三个东西最好一直分清：

initrd / RCM
→ 怎么刷

QSPI
→ 怎么启动

NVMe
→ Linux 在哪里

---

最后：先看物理位置，再看那些 .bin 和 .xml

以前看 Jetson BSP，目录里几百个：

*.bin
*.bct
*.dtb
*.img
*.xml

很容易一头扎进文件名。

现在我觉得更有效的方法反而是先回到硬件：

                SoM
                 │
              QSPI
                 │
         Boot Firmware
                 │
               UEFI
                 │
                 │ PCIe
                 ↓
              Carrier
                 │
               NVMe
                 │
          Kernel + RootFS

然后看到一个镜像时，只问三个问题：

它属于 SoM 还是 Carrier？

它最终进入 QSPI 还是 NVMe？

它负责 Boot，还是负责 Linux？

很多 Jetson 烧录和启动问题都能迅速归位。

对我来说，这次重新整理之后，Jetson 的存储结构最终可以压缩成一句话：

SoM 用 QSPI 保存启动能力，再通过 PCIe 把启动流程交给 Carrier 上的 NVMe；两者一起，才组成一套真正可以启动 Linux 的 Jetson 系统。

这比单独记“QSPI 是 Boot Flash、NVMe 是 SSD”更重要，因为真正做自定义载板时，我们面对的从来都不是单独的 SoM，而是 SoM 和 Carrier 共同组成的完整系统。