最本质的区别在于它们运行的对象不同：

1. QEMU（软件仿真）：运行的是“行为模型”。

   • 原理： QEMU 是一个纯软件程序，运行在通用的服务器（x86 架构）上。它不关心芯片内部具体的电路是怎么连的，它只关心功能。
   • 比喻： 就像你在电脑上玩“超级马里奥”模拟器。电脑并不含有任天堂的游戏机电路，它只是用软件模拟了“按 A 键跳跃”这个行为。
   • 关键词： 功能级（Functional）。它知道“CPU 写了这个寄存器，灯就会亮”，但它不在乎电流是怎么流过去的。

2. Palladium / ZeBu / HAPS（硬件仿真/原型）：运行的是“RTL 电路”。

   • 原理： 这些机器内部塞满了大量的专用芯片（FPGA 或 定制处理器）。我们将芯片设计的源代码（RTL） 综合成电路网表，真刀真枪地烧录或者映射到这些机器里运行。
   • 比喻： 这就像是用乐高积木（FPGA/专用芯片）按照设计图纸，1:1 搭建了一个巨大的、虽然跑得慢但结构完全真实的“游戏机”。
   • 关键词： 周期级（Cycle-accurate）。它精确地模拟了每一个时钟周期内，信号在电线上的翻转。

三大维度深度对比

为了方便理解，我将对比分为三个维度：速度、真实度（精度）、可观测性。

速度 (Speed)

• QEMU： 极快。
  • 因为它跳过了复杂的电路细节，直接用主机 CPU 指令模拟目标指令，速度可以达到数百 MIPS（每秒百万条指令）。
  • 用途：适合你们软件团队开发上层应用、操作系统（Linux/Android）启动、UI 交互。
• HAPS (FPGA Prototyping)： 较快。
  • 它通常能跑到 5MHz - 100MHz。虽然比真实芯片（几 GHz）慢，但比下面的 Emulation 快。
  • 用途：适合驱动开发、长时间的压力测试、视频编解码测试。
• Palladium / ZeBu (Emulation)： 较慢。
  • 通常在 500kHz - 2MHz 左右。启动一个 Android 可能需要几小时（虽然现在有混合模式加速，但纯硬件部分依然慢）。
  • 用途：芯片逻辑除错、极早期的驱动验证。

真实度/精度 (Accuracy) —— 这是最关键的区别

• QEMU： 时序是假的。
  • 在 QEMU 里，你写一个指令 Delay(1ms)，它可能并不真的精确对应硬件的多少个时钟周期。它往往假设总线交互是瞬间完成的。
  • 风险：它测不出竞争冒险（Race Condition）或者带宽瓶颈。
• 硬件平台 (Palladium/ZeBu/HAPS)： 时序是真的。
  • 它严格遵守电路设计的时序。如果你的代码需要等待硬件模块响应，而那个模块需要耗费 100 个时钟周期才能把数据准备好，硬件平台就会真的让你等 100 个周期。

可观测性 (Visibility) —— 也就是 Debug 的难度

• QEMU： 你只能看到 CPU 寄存器、内存和你在代码里打印的 Log。你看不到芯片内部的一根“电线”是高电平还是低电平。
• Palladium / ZeBu： 上帝视角。
  • 我可以随时“暂停”时间，查看芯片内部几十亿个晶体管中任意一个的状态，甚至可以回放（Waveform dumping）。这对于查硬件 Bug 是救命的。
• HAPS： 比较难查。因为它为了追求速度，牺牲了可观测性。通常需要预埋一些探针才能看波形。

实战拆解：一个“简单”的 DMA 搬运，在不同平台的表现

光讲理论太枯燥，我们用一个经典的 “CPU 指挥 DMA 搬数据” 的例子，来看看 QEMU 是怎么“欺骗”你的，而硬件仿真平台又是如何工作的。

DMA 搬运一搬可以分为下面几步：

1. CPU 往内存写一段数据。
2. CPU 配置 DMA，把这段数据搬到另一个地方。
3. DMA 搬完后，发一个中断告诉 CPU：“我干完了”。

在 QEMU 里的美好世界

在 QEMU 的代码里，DMA 设备通常是一个 C++ 类。当你写入“开始”寄存器时，QEMU 内部可能就直接调用了一个 memcpy() 函数。

• 总线拥堵？ 不存在的，QEMU 里内存读写瞬间完成。
• 缓存同步？ 没关系的，QEMU 往往默认 CPU 和 DMA 看到的是同一块内存，不需要你操心 Cache 一致性。
• 结果： 代码逻辑通顺，中断准时到达，数据完美无缺。你觉得你的驱动无懈可击。

在硬件仿真平台（真实电路）里的残酷真相

当你把同一段代码放到 Palladium 上（这里跑的是真实的芯片电路设计图），情况完全变了。

总线上的“堵车”事故（AXI 背压）

• QEMU: 一路畅通。
• 硬件真相： DMA 发出写请求，但此时内存控制器正忙着处理 GPU 的请求，于是回了一个 Wait 信号。如果你的 DMA 硬件设计在处理这个 Wait 信号时状态机写得有问题，它可能就卡死在这里，傻等着永远不会来的“通行证”。
• 后果： 死锁。软件一直在等中断，但中断永远不会来。

缓存里的“谎言” (Cache Coherency)

• QEMU: CPU 写完数据，DMA 立刻就能读到最新的。
• 硬件真相： CPU 写的数据还在 CPU 的 L1 Cache 里，还没来得及写到 DDR 内存条上。此时 DMA 去读内存，读到的是旧数据（全是 0）。
• 后果： 数据校验错误。这是最坑的，因为系统没挂，但数据是错的，且极难复现。

中断的“生死时速” (Race Condition)

• QEMU: 逻辑上的先后顺序，先发中断，再处理。
• 硬件真相： DMA 拉高中断线需要 1 个时钟周期，信号经过总线传到 CPU 需要 10 个周期。就在这几纳秒的时间差里，如果你的驱动程序刚好去操作了清除中断的寄存器，或者总线出现了乱序。
• 后果： 丢中断。DMA 觉得我发了，CPU 觉得我没收到，两人面面相觑。

既然 QEMU 这么多坑，为什么还要用？

硬件仿真平台（Palladium/ZeBu）虽然真实，但也有致命缺点：贵、慢、难伺候。

• 它启动一次 Linux 可能要几个小时（QEMU 只要几秒）。
• 想加个断点调试？流程极其繁琐。
• 机器非常昂贵，通常全公司也没几台，得排队用。

最佳实践：软硬结合的“三步走”

作为一名聪明的开发者，你应该清楚每种工具的定位：

1. 早期开发 (QEMU): 这里的目的是跑通软件逻辑。验证任务调度、UI 交互、驱动的基本状态机。只要 QEMU 跑通了，说明你的代码逻辑大体是对的。
2. 中期验证 (硬件仿真/FPGA): 代码逻辑没问题了，现在要验证时序和硬件交互。把代码放到 Palladium 或 FPGA 上跑。这时候你会遇到上面说的死锁、数据错、超时。别慌，这正是硬件仿真平台的价值所在——帮你在流片前把这些深层 Bug 挖出来。
3. 最终回流: 当你在硬件平台上修复了 Bug（比如加了内存屏障指令），记得把这些改动同步回 QEMU 仓库，虽然 QEMU 不需要它也能跑，但保持代码一致性很重要。

硬件三巨头

同样作为硬件仿真平台，Palladium、ZeBu、HAPS 之间也有一些区别：

1. Palladium (Cadence 公司) / ZeBu (Synopsys 公司)：
   • 学名： 硬件仿真器 (Emulator)。
   • 特点： 极贵（一台机器几千万甚至上亿人民币）。编译代码很快，Debug 能力最强。
   • 你的用法： 芯片设计早期（RTL 刚写好），如果你的固件跑挂了，你需要找硬件设计人员看波形，这时候用这个。
2. HAPS (Synopsys 公司)：
   • 学名： FPGA 原型验证系统 (FPGA Prototyping)。
   • 特点： 也就是很多块高性能 FPGA 连在一起。跑得比 Emulator 快很多。
   • 你的用法： 芯片设计中后期。主要用来给你做驱动开发、跑真实的操作系统。因为它跑得够快，你能感觉到系统的流畅度。

附录：术语表

• RTL (Register Transfer Level)： 寄存器传输级代码。这是硬件工程师写的代码（通常用 Verilog 或 VHDL 语言）。它是芯片设计的“源代码”。QEMU 不跑这个，硬件仿真平台跑这个。
• 流片 (Tape-out)： 指芯片设计完成，把设计数据发送给晶圆厂（如台积电）进行制造的过程。流片极其昂贵，一旦失败损失巨大，所以必须在流片前用仿真平台测准。
• FPGA (Field-Programmable Gate Array)： 现场可编程门阵列。一种“万能芯片”。你可以通过编程改变它内部的电路连接。我们用它来模拟还没造出来的 ASIC 芯片。
• 时钟周期 (Clock Cycle)： 芯片心脏跳动一次的时间。2GHz 的 CPU，一个周期就是 0.5 纳秒。硬件仿真就是精确模拟每一次跳动发生了什么。
• 网表 (Netlist)： 类似于软件编译后的“汇编语言”或二进制。RTL 代码经过“综合（Synthesis）”工具处理后，就变成了由门电路（与门、非门、触发器）组成的网表。
• 时钟域 (Clock Domain)： 芯片里不同模块跑的速度不一样（比如 CPU 跑 2G，USB 模块跑 100M）。信号从 2G 传到 100M 的区域，需要特殊的同步处理，这往往是 Bug 的高发区。

本文翻译自：PCIe 第 2 部分 - 关于内存：MMIO、DMA、TLP 等！– 灵魂的逆向工程 — PCIe Part 2 - All About Memory: MMIO, DMA, TLPs, and more! – Reversing Engineering for the Soul

在这个系列文章的第一部分中，我们讨论了 ECAM 以及软件和硬件数据包网络中的配置空间访问。在讨论中，引入了 TLP（Transaction Layer Packets）的概念，这是所有 PCIe 数据在层次结构中移动的通用数据包结构。我们还讨论了这些数据包如何像以太网一样传输，即路由设备使用一个地址（在这种情况下是 BDF）来发送配置空间数据包穿过网络。

配置空间读取和写入只是可以直接使用设备执行 I/O 的几种方式之一。通过“configuration”这个名称，我们可以知道很明显它的意图不是为了执行大量数据传输。主要缺点是它的速度，因为配置空间数据包最多只能包含双向读取或写入的 64 位数据（通常只有 32 位）。对于如此少量的可用数据，数据包和其他链路标头的开销非常大，因此浪费了带宽。

正如第 1 部分所讨论的，理解内存和地址将继续是理解 PCIe 的关键。在这篇文章中，我们将更深入地研究更快的设备 I/O 事务形式，并开始了解软件设备驱动程序如何实际与 PCIe 设备连接以完成有用的工作。

注意：您无需成为计算机体系结构或 TCP/IP 网络方面的专家即可从这篇文章中获得一些信息。但是，了解 TCP/IP 和虚拟内存的基础知识对于掌握本文的一些核心概念是必要的。这篇文章也以 第 1 部分 中的信息为基础。如果您需要查看这些内容，请立即查看！

PCIe 中的数据传输方法简介

配置空间是一种在枚举时间内通过其 BDF 与设备通信的一种简单而有效的方式。这是一种简单的传输模式是有原因的 - 它必须是配置和可用的所有其他数据传输方法的基础。枚举设备后，配置空间已设置设备与主机一起执行实际工作所需的所有信息。配置空间仍用于允许主机监控和响应设备及其链接状态的变化，但它不会用于执行设备的实际高速传输或功能。

配置空间是在枚举时间通过设备的 BDF 进行通信的一种简单有效的方式。它是一种简单的传输模式，是所有数据传输方法的基础。一旦设备被枚举，配置空间就已经设置了设备执行实际工作所需的所有信息，与主机机器一起。配置空间仍用于允许主机计算机监视和响应设备及其链接的变化，但不会用于执行设备的实际高速传输或功能。

我们现在需要的是数据传输方法，让我们真正开始利用 PCIe 设计的高速传输吞吐量。吞吐量是对给定时间段内传输的字节数的度量。这意味着为了最大限度地提高吞吐量，我们必须最小化每个数据包的开销，以传输每个数据包的最大字节数。如果我们每个数据包只发送几个 DWORD（每个 4 字节），就像在配置空间的情况下一样，PCIe 高速传输能力就浪费了。

废话不多说，先介绍一下 PCIe 中高速 I/O 的两种主要形式：

• 内存映射输入/输出（简称 MMIO）- 与主机 CPU 读取和写入内存到 ECAM 以执行配置空间访问类似，MMIO 可以用来映射设备的地址空间，以执行内存传输。主机机器在其物理地址空间中配置“内存窗口”，使 CPU 拥有一个内存地址窗口，这些内存地址神奇地转换为直接读取和写入设备。内存窗口在 RC 中解码，将 CPU 的读取和写入转换为传输到设备的数据 TLPs。硬件优化使得这种方法可以实现比配置空间访问快得多的吞吐量。然而，其速度仍然远远落后于 DMA 的批量传输速度。
• 直接内存访问（简称 DMA）- DMA 是迄今为止最常见的数据传输形式，因为它具有原始传输速度和低延迟。每当驱动程序需要在主机和设备之间沿任一方向进行任何重要大小的传输时，它肯定会是 DMA。但与 MMIO 不同的是，DMA 是由设备本身启动的，而不是由主机 CPU 启动的。主机 CPU 将通过 MMIO 告诉设备 DMA 应该去哪里，设备本身负责开始和完成 DMA 传输。这允许设备在没有 CPU 参与的情况下执行 DMA 事务，与设备必须等待主机 CPU 告诉它每次传输做什么相比，这节省了大量的 CPU 周期。由于 DMA 的普遍性和重要性，从硬件实现和软件层面了解 DMA 非常有价值。

MMIO 简介

什么是 BAR？

由于配置空间限制为 4096 字节，因此之后没有太多可用空间用于特定于设备的功能。如果设备想要映射 1GB 的 MMIO 空间来访问其内部 RAM，该怎么办？没有办法将其放入 4096 字节的配置空间。因此，它将需要请求一个被称为 BAR（基地址寄存器）的东西。这是通过配置空间公开的一个寄存器，允许主机机器配置其内存的一个区域，直接映射到设备上。然后主机机器上的软件通过对 BAR 的物理地址的内存读/写指令来访问 BAR，就像我们在 ECAM 的第一部分中看到的 MMIO 一样。对设备内存映射进行读取或写入的操作将直接转换为发送到层次结构上的设备的数据包。当设备需要响应时，它将通过层次结构向主机机器发送一个新的数据包。

当 CPU 指令读取器件 MMIO 区域的内存时，会生成一个内存读取请求事务层数据包（MemRd TLP），该数据包从主机的 RC 向下传输到器件。这个 TLP 包的目的是通知设备希望读取设备，然后设备需要尽快响应请求地址上的内容。

在 PCIe 中发送和接收的所有数据传输数据包都将采用 TLP 形式。回想一下第 1 部分，这些数据包是设备之间的所有通信都在 PCIe 中发生的中心抽象。这些数据包在出现数据传输错误（类似于网络中的 TCP）的情况下是可靠的，并且可以根据需要重试/重新发送。这确保了数据传输免受 PCIe 可以达到的极高速度下发生的恶劣电气干扰。我们很快就会仔细研究 TLP 的结构，但现在只需将这些视为您在 TCP 中看到的常规网络数据包。

当设备收到请求者数据包时，设备会使用 MemRd TLP 响应内存请求。此 TLP 包含从设备内存空间读取的结果，给定原始请求者数据包中的地址和大小。设备将它正在响应的特定请求数据包和发送方标记到响应数据包中，交换层次结构知道如何将响应数据包返回给请求者。然后，请求者将使用数据包中的数据来更新发起请求的 CPU 寄存器。

同时，当 TLP 正在传输时，CPU 必须等待内存请求完成，并且它不能被中断或执行许多有用的工作。正如你可能看到的，如果需要执行大量这样的请求，CPU 将需要花费大量时间等待设备响应每个请求。虽然在硬件级别进行了优化，使此过程更加简化，但使用 CPU 周期等待数据传输完成仍然不是最佳选择。希望您能看到我们需要第二种类型的传输，即 DMA，来解决 BAR 访问的这些缺点。

这里的另一个重点是，设备内存并不严格需要用于设备的 RAM。虽然通常会看到具有板载 RAM 的设备通过 BAR 公开其内部 RAM 的映射，但这不是必需的。例如，访问设备的 BAR 可能会访问设备的内部寄存器，也可能导致设备执行某些操作。例如，写入 BAR 是设备开始执行 DMA 的主要方式。一个核心要点是，设备 BAR 非常灵活，可用于控制设备或执行与设备之间的数据传输。

如何枚举 BAR？

设备使用其配置空间从软件请求内存区域。在枚举时，由主机确定该区域将放置在物理内存中的位置。每个器件在其配置空间（称为“寄存器”，因此称为基址寄存器）中都有 6 个 32 位值，当枚举器件时，软件将读取和写入这些值。这些寄存器描述了器件希望分配的每个 MMIO 区域的长度和对齐要求，每个可能的 BAR 一个，总共 6 个不同的区域。如果设备希望能够将其 BAR 映射到 4GB 空间（64 位 BAR）以上，它可以将两个 32 位寄存器组合在一起，形成一个 64 位 BAR，最多只留下三个 64 位 BAR。

PCIe

术语注释：尽管首字母缩略词 BAR 表示基址寄存器，但你会看到上面的文本也将 MMIO 的内存窗口称为 BAR。不幸的是，这意味着配置空间中的寄存器名称也与给 device 的 MMIO 区域相同（两者都称为 BAR）。你可能需要根据上下文，以确定它们是指内存窗口，还是配置空间本身的实际寄存器。

BARs 是配置空间中另一个示例，它不是常量寄存器。在第一部分中，我们看了一些常量寄存器，比如 VendorID 和 DeviceID。但是 BARs 不是常量寄存器，它们应该由软件写入和读取。实际上，由软件写入寄存器的值是特殊的，因为将某些类型的值写入寄存器将导致读取时功能不同。如果你没有牢记设备内存并非总是 RAM，读取回来的值可能与写入的不同，那么现在正是时候这么做了。

设备内存可以是 RAM，但它并不总是 RAM，也不需要像 RAM 那样工作！

什么是 DMA？引言和理论

到目前为止，我们已经看到了两种形式的 I/O，配置空间访问和通过 BAR 的 MMIO 访问。我们将讨论的最后一种也是最后一种访问形式是直接内存访问（DMA）。DMA 是迄今为止最快的 PCIe 批量传输方法，因为它的传输开销最小。也就是说，通过链路传输最大字节数所需的资源最少。这使得 DMA 对于真正利用 PCIe 提供的高速链路至关重要。

但是，强大的力量会带来巨大的混乱。对于软件开发人员来说，DMA 是一个非常陌生的概念，因为我们在软件中没有类似的东西可以比较。对于 MMIO，我们可以将内存访问概念化为从设备内存中读取和写入的指令。但 DMA 与此非常不同。这是因为 DMA 是异步的，它不利用 CPU 来执行传输。相反，顾名思义，读取和写入的内存直接来自系统 RAM。一旦 DMA 开始，唯一涉及的各方是系统主内存的内存控制器和设备本身。因此，CPU 不会花费周期等待单个内存访问。相反，它只是启动转移，并让平台在后台自行完成 DMA。然后，平台将在传输完成时通知 CPU，通常是通过中断。

让我们想一想，为什么异步执行 DMA 如此重要。考虑 CPU 从计算机上的 NVMe SSD 解密大量文件的情况。一旦主机上的 NVMe 驱动程序启动 DMA，设备就会不断以最快的速度将文件数据从 SSD 的内部存储传输到 CPU 可以访问的系统 RAM 中的位置。然后，CPU 可以使用其 100% 的处理能力来执行解密数学运算，以便在从系统内存中读取数据时解密文件块。CPU 不会花时间等待对设备进行单个内存读取，而是简单地连接数据，并允许设备尽可能快地传输，而 CPU 会尽可能快地处理它。在此期间，任何额外的数据都会在系统 RAM 中缓冲，直到 CPU 可以访问它。这样，任何过程的任何部分都不会等待其他事情发生。所有这些都以尽可能快的速度同时发生。

由于 DMA 的复杂性和涉及的部件数量，我将尝试以最直接的方式解释 DMA，并用大量图表来显示该过程。更令人困惑的是，每个设备都有不同的 DMA 接口。没有用于执行 DMA 的通用软件接口，只有器件的设计人员知道如何告诉该器件执行 DMA。值得庆幸的是，某些设备类别使用普遍认可的接口，例如大多数 SSD 使用的 NVMe 接口或 USB 3.0 的 XHCI 接口。如果没有标准接口，则只有硬件设计人员知道设备如何执行 DMA，因此生产设备的公司或个人需要是编写设备驱动程序的人，而不是依赖与操作系统捆绑的通用驱动程序与设备通信。

一个简单的 DMA 传输 - Step by Step

我们 DMA 旅程的第一步是查看传输的初始设置。这涉及几个步骤，为即将到来的 DMA 传输准备系统内存、内核和设备。在这种情况下，我们将设置 DMA，以便读取系统 RAM 中存在的 DMA 缓冲区中的内存内容，并将其放入 Target Memory 的器件板载 RAM 中。此时我们已经选择将此内存从 DMA Buffer 读取到器件上地址为 0x8000 中。目标是尽快将此内存从系统内存传输到设备，以便它可以开始处理它。假设在这种情况下，内存量几 M 字节，MMIO 会太慢，但为简单起见，我们将仅显示 32 字节的内存。这种传输将是最简单的 DMA 传输类型：将内存块的已知大小和地址从系统 RAM 复制到设备 RAM。

第 1 步 - 从操作系统分配 DMA 内存

此过程的第一步是从 OS 分配 DMA 内存。这意味着设备驱动程序必须进行 OS API 调用，以请求 OS 为设备分配一个内存区域以将数据写入。这一点很重要，因为操作系统可能需要执行特殊的内存管理操作才能使数据对设备可用，例如删除保护或重新组织现有分配以促进请求。

传统上，DMA（直接内存访问）存储器必须是连续的物理存储器，这意味着设备从某个地址和长度的起始处开始，并线性地从缓冲区的起始位置读取/写入数据直到结束。因此，操作系统必须负责组织其物理内存，以创建足够大的连续范围，以满足驱动程序请求的 DMA 缓冲区。有时，对于长时间运行或物理内存有限的系统来说，这可能非常困难。因此，这一领域的增强功能允许更现代的设备使用 Scatter-Gather 和 IOMMU Remapping 等功能传输到非连续的存储器区域。稍后，我们将看一些这些功能。但现在，我们只专注于更简单的连续内存情况。

一旦请求的分配成功，API 将返回内存地址，并指向系统 RAM 中的缓冲区。这将是设备通过 DMA 访问内存的地址。DMA 意图为 API 返回的地址将被赋予一个特殊的名称; 设备逻辑地址或逻辑地址。对于我们的示例，逻辑地址等同于物理地址。设备看到的是操作系统看到的物理内存的完全相同视图，没有额外的转换。然而，在更高级的传输形式中，情况可能并非总是如此。因此最好意识到，设备给出的地址可能并非总是与其在 RAM 中实际的物理地址相同。

分配缓冲区后，由于目的是将数据从此缓冲区移动到设备，因此设备驱动程序将提前使用写入设备所需的信息填充缓冲区。在此示例中，由重复 01 02 03 04 模式组成的数据正在传输到设备的 RAM。

第 2 步 - 将 DMA 地址写入设备并开始传输

传输的下一步是准备设备执行事务所需的信息。这通常是了解器件的特定 DMA 接口最重要的地方。每个设备都以自己的方式进行编程，了解驱动程序应该如何对设备进行编程的唯一方法是参考其通用标准（如 NVMe 规范）或简单地与硬件设计人员合作。

在这个例子中，我将为一个只有执行传输所需的最基本功能的设备构建一个简化的 DMA 接口。在下面的图表中，我们可以看到这个设备通过向 BAR0 MMIO 区域写入数值来进行编程。这意味着为了为这个设备编程 DMA，驱动程序必须将内存写入由 BAR0 指定的 MMIO 区域。每个寄存器在 BAR0 区域内的位置是由驱动程序编写者提前知道的，并且被集成到设备驱动程序的代码中。

对于此示例、我在 BAR0 中创建了四个器件寄存器：

• Destination Address（目标地址） - 设备内部 RAM 中用于写入从系统 RAM 读取的数据的地址。这是我们将对已经确定的目标地址 0x8000 进行编程的地方。
• Source Address（源地址） - 设备将从中读取数据的系统 RAM 的逻辑地址。这将对我们希望设备读取的 DMA Buffer 的逻辑地址进行编程。
• Transfer Size（传输大小） - 我们要传输的大小（以字节为单位）。
• Initiate Transfer（启动传输标志位）- 一旦次寄存器写入 1，器件将开始在上面给出的地址之间进行传输。通过这种方式，驱动程序可以判断设备已完成填充缓冲区并准备好开始传输。这通常被称为门铃（Door Bell）寄存器。

在上图中，驱动程序需要使用器件的 BAR0 的映射内存将必要的值写入寄存器（它如何映射此内存取决于 OS）。此图中的值如下所示：

• Target Memory - 我们要从器件复制的内存将为 0x00008000，它映射到器件板载 RAM 中的内存区域。这将是我们的目标地址。
• DMA 缓冲区 - 操作系统在 0x001FF000 分配内存块，因此这将是我们的源地址。

有了这些信息，驱动程序现在可以将值编程到设备中，如下所示：

现在，驱动程序已经配置了执行传输所需的所有寄存器。最后一步是向启动传输寄存器写入一个值，该寄存器充当开始传输的 Door bell 寄存器。一旦写入此值，设备将驱动 DMA 传输，并独立于驱动程序或 CPU 的参与执行它。驱动程序已完成启动传输的工作，此时 CPU 可在等待设备通知系统 DMA 完成的同时，自由进行其他工作。

第 3 步 - 设备执行 DMA 事务

现在，驱动程序已写入 Door bell 寄存器，设备现在将接管处理实际传输。在设备本身上，存在一个名为 DMA 引擎的模块，负责处理和维护事务的所有方面。当器件被编程时，对 BAR0 的寄存器写入正在对 DMA 引擎进行编程，其中包含开始在 PCIe 链路上发送必要的 TLP 以执行内存事务所需的信息。

如上一节所述，PCIe 链路上的所有内存操作都是通过 Memory Write/Read TLP 完成的。在这里，我们将深入研究在交易发生时设备的 DMA 引擎发送和接收的 TLP。请记住，更容易将 TLP 视为在单个可靠连接上发送和接收数据的网络数据包。

如在前文部分讨论过的，PCIe 链接上的所有内存操作都是通过内存写入/读取 TLPs 来完成的。在这里，我们将深入探讨设备的 DMA 引擎在传输过程中发送和接收的 TLPs。要牢记的是，将 TLPs 视为在一个单一、可靠的连接上发送和接收数据的网络数据包更易于理解。

插曲：快速了解 TLP

在查看链路上的 TLP 之前，让我们仔细了解一下数据包结构本身的概览。

以下是内存读取请求和响应的两个 TLP。如前所述，用于内存操作的 TLP 利用请求和响应系统。执行读取的设备将生成特定地址和长度（以 4 字节 DWORD 为单位）的读取请求 TLP，然后坐下来等待完成数据包到达包含响应数据的链路。

我们可以看到，有与生成请求的设备、Requester 以及唯一的 Tag 值相关的元数据。此 Tag 值用于将请求与其完成匹配。当设备生成请求时，它会使用唯一值标记 TLP 以跟踪待处理的请求。该值由请求的发送者选择，并且由发送者来跟踪其分配的 Tags。

随着完成的数据通过链路到达，完成的 Tag 让设备能够将接入的数据正确地移至特定传输所需的位置。该系统允许单一设备有多个独特的未完成传输任务，尽管它们接收的数据包相互交错，但仍能保持作为独立传输任务的有序性。

数据包内部还包含了必要的信息，使得 PCIe 切换层次结构能够确定请求和完成需要去向的位置。例如，内存地址被用来确定正在请求访问的设备是哪一个。在枚举期间，层次结构中的每一个设备都被编程以拥有各自独特的地址范围。切换结构根据数据包中的内存地址，确定数据包需要去向哪里以访问那个地址。

设备收到并处理请求后，响应数据将以 Completion TLP 的形式发送回去。完成或“响应”数据包可以而且通常会被分段为许多较小的 TLP，这些 TLP 发送整体响应的一部分。这是因为在枚举期间，已确定设备和总线可以处理最大有效载荷大小（MPS）。MPS 可根据平台和设备功能进行配置，从 128 开始，最高可达 4096 的 2 次方大小。通常，此值约为 256 字节，这意味着需要将大型读取请求拆分为许多较小的 TLP。这些数据包中的每一个都有一个字段，该字段指示完成响应的原始请求的偏移量，有效负载中是返回的数据块。

有一个常见的误解，即内存 TLP 使用 BDF 来寻址数据包需要去往的位置。其实请求仅使用内存地址来指示数据包的目的地，并且设备和目标之间的桥接设备负责将该数据包发送到其正确的位置。。然而，完成数据包确实利用请求者的 BDF 将数据返回给发起请求的设备。

以下是一个展示内存读取和响应过程的图表，图中展示出请求会使用一个地址来发起请求，而完成的操作会使用请求中 Request 字段的 BDF 来发送相应应答：

现在回到实际的传输

让我们看看 DMA 引擎为了执行我们的请求而发送和接收的所有内容。由于我们请求了 32 字节的数据，因此只有一个单一的 Memory Read Request 和一个带有响应的单一 Memory Read Completion 数据包。为了便于您理解，请停止向前阅读，并考虑一下在此事务中哪个设备将发送和接收哪个 TLP。如果您需要再次查看第 2 步的图表，请向上滚动。

现在，让我们深入研究一下传输的实际数据包。虽然我将继续绘制这个模拟示例，但我认为对于这个练习，当执行真实传输时，实际看到其中一些 TLP 是什么样子可能会很有趣。

在实验中，我使用真实设备配置了如上文所示的同类通用参数，并启动了 DMA。这个设备会发送真实的 TLPs，将系统 RAM 中的内存读取到设备里。因此，你将有机会罕见地查看在执行这种 DMA 时发送的实际 TLPs 的例子，除非有分析器，否则这些在传输过程中几乎无法看到。

要查看此实验，请点击此链接至配套文章：Experiment - Packet Dumping PCIe DMA TLPs with a Protocol Analyzer and Pcileech – Reversing Engineering for the Soul

以下是器件生成的内存读取请求以及请求如何遍历层次结构的框图。

勘误表：0x32 应该是 32

此图中概述的步骤如下：

• DMA 引擎创建 TLP - DMA 引擎识别出它必须从 0x001FF000 读取 32 字节。它生成一个包含此请求的 TLP，并通过其本地 PCIe 链路将其发送出去。
• TLP 遍历层次结构 - PCIe 的交换层次结构通过桥接设备移动此请求，直到它到达其目的地，即 RC。回想一下，RC 负责处理所有用于访问系统 RAM 的传入数据包。
• 通知 DRAM 控制器 - RC 在内部与 DRAM 控制器通信，该控制器负责实际访问系统 DRAM 的内存。
• 从 DRAM 读取内存 - 从地址 0x001FF000 的 DRAM 请求给定长度的 32 字节，并将其返回到值为 01 02 03 04…

尽量不要被这些信息淹没，因为我确实知道仅针对单个内存请求 TLP 就有很多事情要做。所有这些在高层次上归结为仅从 RAM 中的地址 0x001FF000 读取 32 字节的内存。平台如何通过与 DRAM 控制器通信来实际读取系统 DRAM，仅供您参考。设备本身不知道 Root Complex 实际上是如何读取此内存的，它只是使用 TLP 启动传输。

注意：此处未显示更复杂的 RAM 缓存过程。在 x86-64 上，来自设备的所有内存访问都是缓存一致的，这意味着平台会自动将 CPU 缓存与设备正在访问的值同步。在其他平台（如 ARM 平台）上，由于其缓存架构，这是一个更复杂的过程。现在，我们只假设缓存一致性正在自动为我们处理，我们对此没有任何特别的担忧。

当 RC 收到此 TLP 时，它会在内部标记 Requester 和 Tag 的读取内容。当它等待 DRAM 响应该值时，此请求的信息将在 RC 中等待。要概念化这一点，可以将其视为网络套接字中的“open connection”。RC 知道它需要响应什么，因此会等到响应数据可用后，再通过套接字将数据发送回去。

最后，将 Completion 从 Root Complex 发送回设备。请注意，Destination 与 Requester 相同：

以下是响应数据包概述的步骤，如上所示：

• 从 DRAM 读取内存 - DRAM 控制器从系统 DRAM 中 0x001FF000 的 DMA 缓冲区地址读取 32 字节。
• DRAM 控制器响应根复合体 - DRAM 控制器在内部响应从 DRAM 向 RC 请求的内存
• RC 生成完成 - RC 跟踪传输并为从 DRAM 读取的值创建完成 TLP。在此 TLP 中，元数据值是根据 RC 对待处理传输的了解来设置的，例如发送的字节数、传输的标记以及从原始请求的 Requester 字段复制的目标 BDF。
• DMA 引擎接收 TLP - DMA 引擎通过 PCIe 链路接收 TLP，并查看标签是否与原始请求的相同标签匹配。它还会在内部跟踪此值，并知道有效负载中的内存应写入 Target Memory，该内存在设备内部 RAM 中处于 0x8000。
• Target Memory is Written（目标内存已写入） - 设备内存中的值将更新为从数据包的 Payload 中复制的值。
• 系统中断 - 虽然这是可选的，但大多数 DMA 引擎将配置为在 DMA 完成时中断主机 CPU。这会在设备成功完成 DMA 时向设备驱动程序发出通知。

同样，仅处理这个 complete 数据包就涉及很多步骤。但是，同样，您可以将整个过程简单地视为“从设备的请求中收到 32 字节的响应”。这些步骤的其余部分只是为了向您展示此响应处理的完整端到端是什么样子。

从这里，设备驱动程序会收到 DMA 已完成的通知，设备驱动程序的代码负责清理 DMA 缓冲区或将其存储起来以供下次使用。

在我们的艰苦努力后，我们终于完成了一次单一的 DMA 传输事务！想到这就是我能提供的最“简单”的传输方式，真是让人惊讶。有了 IOMMU 重映射和 Scatter-Gather 能力的加入，这些事务甚至可能变得更复杂。但就现在而言，你应该对 DMA 的全部内容以及它如何在真实设备中运作有了深入的理解。

尾声 - 关于复杂性的小说明

如果您读完这篇文章并觉得自己没有完全掌握所有抛给您的概念，或者对复杂性感到不知所措，您不必担心。这些帖子如此复杂的原因是它不仅涵盖广泛的主题，而且还涵盖广泛的专业。通常，整个系统的每个部分在行业中都有不同的团队，他们只关注他们在这个复杂机器中的“齿轮”。通常，硬件开发人员专注于设备，驱动程序开发人员专注于驱动程序代码，而操作系统开发人员专注于资源管理。这些团队之间很少有太多重叠，除非在他们的边界交接，以便另一支团队可以连接到它。

这些帖子有点独特，因为它们试图将系统作为一个整体进行记录，以便于概念理解，而不是实现。这意味着，在通常划定团队边界的地方，这些帖子根本不关心。我鼓励觉得这个话题有趣的读者在自己的时间里继续深入研究。也许您可以了解一些 FPGA 并开始制作自己的设备，或者您可以购买一个设备并开始尝试对其进行逆向工程，并通过您自己的定制软件与它进行通信。

总结

希望您喜欢这篇深入探讨 PCIe 内存传输的文章！虽然我在这篇文章中涵盖了大量信息，但兔子洞总是更深。值得庆幸的是，通过学习配置空间访问、MMIO（BAR）和 DMA，您现在已经涵盖了 PCIe 中可用的各种形式的数据通信！对于连接到 PCIe 总线的每个设备，主机系统和设备之间的通信将通过这三种方法中的一种进行。设备的链接、资源和驱动程序软件的所有设置和配置最终都是为了促进这三种形式的通信。

这篇文章花了这么长时间才发布的一个重要原因是，为了理解这一切，我必须向读者展示大量信息。很难决定什么值得写，什么太深以至于理解变得模糊。这个决定瘫痪使博客写作过程花费的时间比我预期的要长得多。再加上全职工作，很难找到时间来撰写这些帖子。

在即将发布的帖子中，我期待着讨论以下一些或所有的话题：

• 层次结构的 PCIe 交换/桥接和枚举
• 更高级的 DMA 主题，例如 DMA 重新映射
• 电源管理;设备如何“睡眠”和“唤醒”
• 平台/OS 的中断及其分配和处理
• 设备的简单驱动程序开发示例

与往常一样，如果你有任何问题或想评论或讨论这个系列的某个方面，你最好在我的 discord 的 #hardware 频道中通过“@gbps”找到我，逆向工程 discord

请期待未来的帖子！

本文翻译自：面向 Windows 初学者的 PCIe 实用教程（第 1 部分）– 灵魂的逆向工程 — A Practical Tutorial on PCIe for Total Beginners on Windows (Part 1) – Reversing Engineering for the Soul

Hello！我最近一直在与一些朋友和同事交谈，他们有兴趣了解更多关于 PCIe 的信息，但对复杂性或缺乏适合初学者的简单资源感到害怕。我最近经常使用 PCIe，觉得可能值得以博客文章的形式分享我的一些经验。

本文主要供具有计算机系统背景并且喜欢亲身实践的人员使用。它也适用于 PCIe 的初学者，或者是对通用概念有所理解但却无法将它们联系在一起的人。

第一件事是第一件事：不要被吓倒。有很多首字母缩略词和令人困惑的概念，当你"明白"时，它们就会变得简单。当时要迈出一步，不要害怕提出问题！（如果你想问我问题，可以考虑在 Reverse Engineering Discord 的 #hardware 频道@Gbps ping 我）

我打算在这个系列中做几件事：

• 从软件方面将 PCIe 分解为我认为最重要的内容，以学习和为现代 PC/服务器系统构建一个良好的基线思想模型。
• 展示使用各种工具（通常是 WinDbg）在 Windows 上调查 PCIe 层次结构和设备的实际示例。
• 为避免造成混淆，我会有意识地简化或略过一些具体的细节。在这里，可能会有一些术语的使用不准确，甚至信息本身也可能在技术上有所出入。但是，这样做的目的是为了学习整个系统，而不是规范的具体细节。PCIe 是复杂的，当我们处于初学阶段时，陷入过多的细节和特殊情况是没有意义的。
• 我们希望通过将这项技术与你已经熟悉的概念相联系，来揭开其神秘面纱。PCIe 并未重新发明轮子，通过理解与它类似的技术，你可能已经比你自己意识到的了解得更多。

我不打算用这个系列做以下事情：

• 详细了解传统 PCI 或 PCI-X。一般来说，这项技术除了历史价值之外并不重要。
• 演示如何为 PCIe 设备编写设备驱动程序。这是非常特定于操作系统的，并且比这里要讨论的要高得多。
• 详细介绍 PCIe 的链路层。该规范的一半以上都花在了这个主题上，并包含了一些世界上最前沿的高速数据传输技术。我不处理这边的事情，但是将来我可能会谈论使用 FPGA 构建 PCIe 设备（我以前做过）。
• 帮助你使用 PCIe 在视频游戏中作弊。是的，它存在。不，我不会帮忙。

这并不是对技术或协议的全面研究。要获得真正详尽的了解，你应该参考永远难以捉摸的 PCI-SIG PCI Express 基本规范。这是实现所有 PCIe 代码所依据的规范。目前，在撰写本文时，我们使用的是该规范的 6.0 版，但 3.0 及更高版本的版本都与现代 PCIe 完全相关。如何获得这种昂贵的规格对读者来说是一项练习。

注意：我有时会在“PCI”和“PCIe”之间来回切换，将技术描述为一种习惯的力量。除非另有说明，否则本系列中的所有内容都是关于 PCIe 的。

什么是 PCIe，我为什么要关注？

PCIe 代表 Peripheral Component Interconnect Express，外围设备组件互联传输。它于 2003 年首次推出，是从早期 PC 时代越来越流行的旧 PCI 和 PCI-X 规范演变而来的（为 Express 添加了“e”以区分它）。

大多数使用计算机的人都认为它是主板上插入显卡或适配器卡的 PCIe 插槽，但 PCIe 不仅仅是这几个扩展 Port。PCIe 是现代 CPU 与连接到系统的几乎所有设备通信的基础。

自推出以来，PCIe 的受欢迎程度飙升，成为短距离高速数据传输的近乎通用的标准。几乎所有的 M.2 SSD 都使用 NVMe over PCIe 作为其传输协议。Thunderbolt 3 能够使用外部线将 PCIe 设备直接动态热插拔到系统（支持扩展坞和 eGPU 等技术）。在此基础上，USB4 正在扩展 Thunderbolt 3，以使这种 PCIe 路由技术能够达到开放的 USB 规范。CXL 等新型传输协议，用于数据中心服务器，以 PCIe 为基础规范并在其上扩展他们的特别功能。

即使与之通信的设备本身不使用 PCIe 作为其物理层协议，系统仍必须使用 PCI 的软件接口进行通信。这是因为系统使用适配器（通常称为主机控制器），这些适配器是 PCI 设备，有助于将来自 CPU 的 PCI 请求转换为主机控制器支持的任何协议或总线。例如，此测试计算机上的所有 USB 3.1 都使用 USB XHCI 协议，该协议是一种通信协议，通过与 USB 主机控制器通信的 PCI 驱动程序将 PCIe 桥接到 USB。

毋庸置疑，PCI 如今无处不在，并且已被计算机世界的各个部分完全采用。因此，我们必须对这项技术有很好的理解，以更好地理解现代计算。

研究 PCIe 层次结构 - 一种分组交换网络

从传统的 PCI 转变到 PCIe 最重要的变化是从真正的总线拓扑结构转变为点对点链接。你可以将这看作是以太网集线器向今天的以太网交换机的演变。每个链接都是一个单独的点对点链接，其路由方式就像在一个分组交换的以太网网络上的以太网线一样。这意味着 PCIe 实际上并不是一个“总线协议”，尽管在各种文献和技术规范中让人困惑的频繁使用“总线”这个词。人们必须仔细理解，这个词“总线”并不意味着多个 PCIe 设备在同一个物理链接上进行通信。数据包（也被称为 TLPs）经过每个单独的链接，层次结构中的交换设备使用数据包内的路由信息将数据包传送到正确的 Port。

在我们进入 PCIe 的技术细节之前，首先我们需要谈谈整个系统的布局。我们研究 PCIe 层次结构的第一种方法是通过 Windows 设备管理器。大多数熟悉 Windows 的人以前都用过它，但没有多少人知道 View > Devices by Connection 中发现的非常方便的功能。

通过选择此视图，我们可以从根 PNP（Plug-N-Play）节点看到系统的完整拓扑。PNP 根节点是 Windows 上所有设备树的根，无论它们使用什么总线或协议。每个设备（无论是虚拟设备还是物理设备）都被枚举并放置在此 PNP 树上。我们可以利用 Device Manager 的这个视图来查看这个树的布局。

特别是，我们希望在系统上找到 PCI 设备的布局。这样，我们就可以开始构建 PCI 树在这台机器上的外观的可视化模型。为此，我们需要找到 PCI 树的根：RC。RC（缩写为 RC）是系统上所有 PCIe 的所有者。它物理上位于 CPU 芯片上，负责充当所有 PCIe 设备接收和发送数据包的主机。它可以被认为是软件（在你的机器上执行的指令）和硬件（PCIe 和 RAM 的外部世界）之间的桥梁。

在这个系统中，它位于这里的 PNP 层次结构中：

注意：你现在可能会问：“如果 PCI 主导了一切，为什么 PCI 根复合物不在树的顶部？答案是由于 PCIe 总线不是启动期间固件提供的系统初始布局。相反，ACPI（高级配置和电源接口）是描述 PCIe 到操作系统存在的东西。虽然你永远不会在 PC 中看到它，但可以描述一个没有 PCI 总线的系统，所有内容都完全由 ACPI 提供。我们稍后会详细讨论 ACPI，但现在不要太担心这个，只要知道 ACPI 是固件告诉我们RC在哪里的方式，然后帮助操作系统枚举树中的 PCI 设备。

所以现在我们知道 RC 是 PCIe 树的顶部，现在让我们看一下它下面的所有内容：

不出所料，此 PCI 总线上有许多设备。在这里，我们可以看到负责音频、集成显卡、USB、串行和 SATA 的各种控制器。此外，我们还看到其中一些设备称为 PCI Express Root Port。Root Port 是RC上的一个 Port，另一个 PCIe 端点（又名物理“设备”）或交换机（又名“路由器”）可以连接到该 Port。出于 PCI 规范的考虑，你将听到 Endpoint 称为 Type 0 设备，而 Switch（或网桥）称为 Type 1 设备，因为一个被配置为用于通信的设备，另一个被配置为用于路由数据包的设备。RC 将具有与其物理支持的一样多的 Root Port。也就是说，可以连接到 CPU 芯片的次数越多。CPU 上的一些 Root Port 可能直接路由到物理 PCIe 插槽，而其他 Root Port 可能路由到其他类型的插槽，如 NVMe 插槽。它也可能被路由到另一个 PCIe 交换设备，该设备可以将数据包路由到多个 Port，从而一次路由到多个端点。

我会继续提出这个比较，但我觉得这很重要——如果你已经了解以太网交换机，你就已经了解 PCIe 交换机。你可以想象这些 Root Port 就像台式计算机上的以太网 Port。你可以将这些直接连接到其他设备（例如摄像头），也可以将它们连接到像家用路由器/调制解调器这样的交换机，这将交换数据包以公开更多连接，以便与更多设备和机器通信。在这种情况下，以太网线是将一个 PCIe Port 连接到另一个 PCIe Port 的铜线，从而使其成为“点对点”。

考虑到这一点，让我们开始绘制这个层次结构（部分）图表，以便我们直观地看到它的全部布局：

在 PCI 中，系统上的所有“总线”都用 0 到 255（含）之间的数字标识。此外，所有设备都使用“设备 ID”和“功能 ID”进行标识。这通常被描述为 Bus/Device/Function，或简称为 BDF。在更正确的规范术语中，这称为 RID（请求者 ID）。为了减少混淆，我将它称为 BDF。BDF 很重要，因为它专门告诉我们设备在 PCIe 层次结构中的位置，以便我们可以与之通信。

因为这些都位于层级结构的顶层，所以我们将为这个“bus”提供一个数字标识符，即“Bus 0”或 Root Bus。我们可以通过右键单击顶级设备并选择 Properties 并查看 Location 来验证所有这些设备是否都是 Bus 0 设备：

对于此集成图形设备，它的 BDF 为 0:2.0。它位于总线 0（根总线）上，设备 ID 为 2，功能 ID 为 0。在这种情况下，“设备”表示物理设备，例如显卡。“功能”是物理设备向系统公开的独特功能。无论出于何种意图和目的，都可以将其视为一个单独的实体。公开多个功能的设备被恰当地称为多功能设备（MFD）。这意味着它向系统公开两个或多个 PCI 连接，而实际上只有一个设备。我们很快就会看到一个真正的 MFD 示例。

敏锐的读者会注意到，我们已经打破了我之前提到的“规则”：与这个独特的总线 0 相连的设备有很多。这是 PCIe 中“点对点”规则的第一个例外，只有在因为总线 0 物理上位于 CPU 的硅片上的情况下才允许这样做。也就是说，这些设备之间没有电气路径，这是一个想象中的连接。所有这些设备都存在于 CPU 封装内，并使用极高速电气互连进行路由。这些处理器互连使用的是特定于 CPU 供应商的内部协议，尽管这些协议并未公开文档，但我们仍然以 PCIe 的“语言”与它进行通信。这些端点（标记为绿色），由于其特殊性质，将被赋予一个特殊的名称：根复合集成端点（RC Integrated Endpoints，简称 RCIE），因为它们直接集成在 RC 上。

这并不奇怪，你会期望集成 UHD 图形等设备将物理位于 CPU 上（因为它是 CPU 规格的一部分）。但是，我们可以通过观察其他 RCIE 来了解系统的一些更有趣的拓扑结构，例如这里也存在 RAM 控制器（与内存的 DRAM DIMM 通信的硅）和 USB 控制器（与外部 USB 设备通信的硅）。这就是为什么某些 CPU 仅支持某些类型的 RAM 和 USB 规范的原因——因为通信的设备在物理上位于 CPU 上，并且仅支持它们在物理上创建时要支持的规范。

更新：这种说法是不正确的。一些 IO 控制器仍然可以在称为 PCH（Intel）或也称为芯片组（AMD）的分立芯片上找到，该芯片位于 CPU 附近，并且具有高速链路，使其看起来像是集成到 CPU 芯片中。上面这句话错误地说你可以在物理 CPU 上找到 USB 控制器，而它更有可能在“芯片组”上。但是，为了提高速度，与 RAM 通信的内存控制器位于 CPU 芯片上。

此图是层次结构第一级的最小化版本，但现在让我们通过在设备管理器中展开其余的 Root Ports 来构建层次结构的其余部分。

这是填充的图表的样子：

注意：我已经标记了 UHD Graphics 设备和总线 0 的 BDF。

这些 Root Port 物理上位于 CPU 上，但连接到它的设备并不在其中。这台机器的外部 PCIe 插槽上连接了 3 个设备：一块 NVIDIA Quadro P400 图形卡和两个 NVMe 驱动器。通过进入设备管理器中每个设备的属性，我们可以获取并更新它们在视觉上的 BDF(总线、设备、功能) 信息。

在每个 Root Port 下，我们可以看到一个设备已物理连接。但是，我们还可以看到，我们在每个 Bus 下都公开了一个新的 Bus。Root Port 充当了桥，它将我们从总线 0 桥接到新的总线，因此必须为新总线分配一个新的数字 ID，并且该 Port 下的所有设备/功能都将继承该新总线编号。这与 OS/固件在引导期间的总线枚举期间使用的逻辑相同：所有网桥和交换机都公开一条新总线，必须为其分配新的总线 ID 号。

在这种情况下，我们还可以看到一个多功能设备的好例子。Quadro P400 显卡充当具有两种功能的 MFD。第一个函数是 0（BDF 01:00.0），是显卡设备本身。第二个功能是 1（BDF 01:00.1），它是音频控制器，允许从 HDMI 等 Port 播放音频。这两个功能是不同的——它们用于完全不同的目的，并且具有与之关联的单独驱动程序和配置，但它们仍然由相同的物理设备（即设备 0）实现，并且位于同一总线（即总线 1）上。这与 PCIe 的点对点规则是一致的，一个链路上只能连接一个物理设备，因此总线上只能存在一个物理设备（除了例外，总线 0）。

从 WinDbg 探索 PCIe 层次结构和设备

到目前为止，我们已经通过使用 Device Manager 的“View by Connection”功能看到了标准的 PCI 总线层次结构。还有另一种更详细的方法来调查 PCIe 层次结构：使用 WinDbg 提供的可靠内核调试扩展。

注意：我们假设你了解如何在一台机器上设置内核调试器来继续下面的操作。你也可以用 LiveKD 来完成大部分练习。如果你并不了解如何设置，可以参考微软提供的指南：设置 KDNET。

我已经连接到了一台与上述使用的机器不同的新测试机。我们将通过调试器的输出，来演练如何绘制这台机器的层次结构图。我们也将学习如何通过其配置内存来查找设备的信息。

放入调试器后，我们将使用！pcitree 命令开始。这将转储系统上列举的 PCI 设备的文本树形图。

8: kd> !pcitree
Bus 0x0 (FDO Ext ffffdc89b9f75920)
  (d=0,  f=0) 80866f00 devext 0xffffdc89b0759270 devstack 0xffffdc89b0759120 0600 Bridge/HOST to PCI
  (d=1,  f=0) 80866f02 devext 0xffffdc89ba0c74c0 devstack 0xffffdc89ba0c7370 0604 Bridge/PCI to PCI
  Bus 0x1 (FDO Ext ffffdc89ba0aa190)
    No devices have been enumerated on this bus.
  (d=2,  f=0) 80866f04 devext 0xffffdc89ba0c94c0 devstack 0xffffdc89ba0c9370 0604 Bridge/PCI to PCI
  Bus 0x2 (FDO Ext ffffdc89ba0a8190)
    (d=0,  f=0) 10de13bb devext 0xffffdc89ba04f270 devstack 0xffffdc89ba04f120 0300 Display Controller/VGA
    (d=0,  f=1) 10de0fbc devext 0xffffdc89ba051270 devstack 0xffffdc89ba051120 0403 Multimedia Device/Unknown Sub Class
  (d=3,  f=0) 80866f08 devext 0xffffdc89ba0cb4c0 devstack 0xffffdc89ba0cb370 0604 Bridge/PCI to PCI
  Bus 0x3 (FDO Ext ffffdc89ba08f190)
    No devices have been enumerated on this bus.
  (d=5,  f=0) 80866f28 devext 0xffffdc89ba0cd4c0 devstack 0xffffdc89ba0cd370 0880 Base System Device/'Other' base system device
  (d=5,  f=1) 80866f29 devext 0xffffdc89ba0cf4c0 devstack 0xffffdc89ba0cf370 0880 Base System Device/'Other' base system device
  (d=5,  f=2) 80866f2a devext 0xffffdc89ba0d14c0 devstack 0xffffdc89ba0d1370 0880 Base System Device/'Other' base system device
  (d=5,  f=4) 80866f2c devext 0xffffdc89ba0d34c0 devstack 0xffffdc89ba0d3370 0800 Base System Device/Interrupt Controller
  (d=11, f=0) 80868d7c devext 0xffffdc89ba0d84c0 devstack 0xffffdc89ba0d8370 ff00 (Explicitly) Undefined/Unknown Sub Class
  (d=11, f=4) 80868d62 devext 0xffffdc89ba0da4c0 devstack 0xffffdc89ba0da370 0106 Mass Storage Controller/Unknown Sub Class
  (d=14, f=0) 80868d31 devext 0xffffdc89ba0dc4c0 devstack 0xffffdc89ba0dc370 0c03 Serial Bus Controller/USB
  (d=16, f=0) 80868d3a devext 0xffffdc89ba0de4c0 devstack 0xffffdc89ba0de370 0780 Simple Serial Communications Controller/'Other'
  (d=16, f=3) 80868d3d devext 0xffffdc89ba0e04c0 devstack 0xffffdc89ba0e0370 0700 Simple Serial Communications Controller/Serial Port
  (d=19, f=0) 808615a0 devext 0xffffdc89ba0e24c0 devstack 0xffffdc89ba0e2370 0200 Network Controller/Ethernet
  (d=1a, f=0) 80868d2d devext 0xffffdc89ba0e44c0 devstack 0xffffdc89ba0e4370 0c03 Serial Bus Controller/USB
  (d=1b, f=0) 80868d20 devext 0xffffdc89ba0254c0 devstack 0xffffdc89ba025370 0403 Multimedia Device/Unknown Sub Class
  (d=1c, f=0) 80868d10 devext 0xffffdc89ba0274c0 devstack 0xffffdc89ba027370 0604 Bridge/PCI to PCI
  Bus 0x4 (FDO Ext ffffdc89ba0a9190)
    No devices have been enumerated on this bus.
  (d=1c, f=1) 80868d12 devext 0xffffdc89ba02c4c0 devstack 0xffffdc89ba02c370 0604 Bridge/PCI to PCI
  Bus 0x5 (FDO Ext ffffdc89b9fe6190)
    No devices have been enumerated on this bus.
  (d=1c, f=3) 80868d16 devext 0xffffdc89ba02e4c0 devstack 0xffffdc89ba02e370 0604 Bridge/PCI to PCI
  Bus 0x6 (FDO Ext ffffdc89ba0a7190)
    (d=0,  f=0) 12838893 devext 0xffffdc89ba062270 devstack 0xffffdc89ba062120 0604 Bridge/PCI to PCI
    Bus 0x7 (FDO Ext ffffdc89ba064250)
      No devices have been enumerated on this bus.
  (d=1c, f=4) 80868d18 devext 0xffffdc89ba0304c0 devstack 0xffffdc89ba030370 0604 Bridge/PCI to PCI
  Bus 0x8 (FDO Ext ffffdc89ba0b2190)
    No devices have been enumerated on this bus.
  (d=1d, f=0) 80868d26 devext 0xffffdc89ba0364c0 devstack 0xffffdc89ba036370 0c03 Serial Bus Controller/USB
  (d=1f, f=0) 80868d44 devext 0xffffdc89ba0384c0 devstack 0xffffdc89ba038370 0601 Bridge/PCI to ISA
  (d=1f, f=2) 80868d02 devext 0xffffdc89ba03a4c0 devstack 0xffffdc89ba03a370 0106 Mass Storage Controller/Unknown Sub Class
  (d=1f, f=3) 80868d22 devext 0xffffdc89ba03c4c0 devstack 0xffffdc89ba03c370 0c05 Serial Bus Controller/Unknown Sub Class

注意：如果你遇到“无法获取 PciFdoExtensionListHead 地址”的错误，确保你的符号设置正确，并执行.reload pci.sys 操作来重新加载 PCI 的符号。

当显示此输出时，由于空格的格式设置方式，可能很难直观地看到“tree”。解释此输出的方法是查看 Bus 0x 文本的缩进。任何比 Bus 0x 行进一步缩进一组空格的东西都是该总线上的设备。我们可以看到，在器件的正下方还有其他 Bus 0x 线路。这意味着 Bus 0x 线上方的器件正在向我们公开一条新总线，并且总线编号在那里给出。

让我们看一下此输出的特定部分：

Bus 0x0 (FDO Ext ffffdc89b9f75920)
  (d=0,  f=0) 80866f00 devext 0xffffdc89b0759270 devstack 0xffffdc89b0759120 0600 Bridge/HOST to PCI
  (d=1,  f=0) 80866f02 devext 0xffffdc89ba0c74c0 devstack 0xffffdc89ba0c7370 0604 Bridge/PCI to PCI
  Bus 0x1 (FDO Ext ffffdc89ba0aa190)
    No devices have been enumerated on this bus.
  (d=2,  f=0) 80866f04 devext 0xffffdc89ba0c94c0 devstack 0xffffdc89ba0c9370 0604 Bridge/PCI to PCI
  Bus 0x2 (FDO Ext ffffdc89ba0a8190)
    (d=0,  f=0) 10de13bb devext 0xffffdc89ba04f270 devstack 0xffffdc89ba04f120 0300 Display Controller/VGA
    (d=0,  f=1) 10de0fbc devext 0xffffdc89ba051270 devstack 0xffffdc89ba051120 0403 Multimedia Device/Unknown Sub Class
  (d=3,  f=0) 80866f08 devext 0xffffdc89ba0cb4c0 devstack 0xffffdc89ba0cb370 0604 Bridge/PCI to PCI
  Bus 0x3 (FDO Ext ffffdc89ba08f190)
    No devices have been enumerated on this bus.

在此输出中，我们可以看到每个设备显示的 BDF。我们还可以看到总线 0 上存在的一组 Root Port，这些 Port 下面没有列举任何设备，这意味着插槽尚未连接到任何设备。

在这里看到树结构应该更容易，但无论如何，让我们把它画出来：

注意：这只是一个巧合，即公交号恰好与桥梁/PCI 的设备编号匹配到 PCI 端口。

如你现在所知，标记为 Bridge/PCI to PCI 的设备实际上是 Root Port，而总线 2 上的设备实际上是一个多功能设备。与设备管理器不同，我们看不到！pcitree 中的设备真实名称。相反，我们只得到了一个通用的 PCI 名称，用于设备“类型”将自己宣传为什么。这是因为设备管理器 从驱动程序读取设备名称，而不是直接从 PCI 读取设备名称。

要了解更多关于这个显示控制器设备的信息，我们可以使用命令 ！devext [pointer]，其中 [pointer] 是布局中单词 devext 后面的值。在本例中，它是：

(d=0,  f=0) 10de13bb devext 0xffffdc89ba04f270 devstack 0xffffdc89ba04f120 0300 Display Controller/VGA

!devext 0xffffdc89ba04f270

从这里，我们将从 Windows 中的 PCI 总线驱动程序获得此 PCI 设备的摘要的打印输出，pci.sys：

8: kd> !devext 0xffffdc89ba04f270
PDO Extension, Bus 0x2, Device 0, Function 0.
  DevObj 0xffffdc89ba04f120  Parent FDO DevExt 0xffffdc89ba0a8190
  Device State = PciStarted
  Vendor ID 10de (NVIDIA CORPORATION)  Device ID 13BB
  Subsystem Vendor ID 103c (HEWLETT-PACKARD COMPANY)  Subsystem ID 1098
  Header Type 0, Class Base/Sub 03/00  (Display Controller/VGA)
  Programming Interface: 00, Revision: a2, IntPin: 01, RawLine 00
  Possible Decodes ((cmd & 7) = 7): BMI
  Capabilities: Ptr=60, power msi express 
  Express capabilities: (BIOS controlled) 
  Logical Device Power State: D0
  Device Wake Level:          Unspecified
  WaitWakeIrp:                <none>
  Requirements:     Alignment Length    Minimum          Maximum
    BAR0    Mem:    01000000  01000000  0000000000000000 00000000ffffffff
    BAR1    Mem:    10000000  10000000  0000000000000000 ffffffffffffffff
    BAR3    Mem:    02000000  02000000  0000000000000000 ffffffffffffffff
    BAR5     Io:    00000080  00000080  0000000000000000 00000000ffffffff
      ROM BAR:      00080000  00080000  0000000000000000 00000000ffffffff
    VF BAR0 Mem:    00080000  00080000  0000000000000000 00000000ffffffff
  Resources:        Start            Length
    BAR0    Mem:    00000000f2000000 01000000
    BAR1    Mem:    00000000e0000000 10000000
    BAR3    Mem:    00000000f0000000 02000000
    BAR5     Io:    0000000000001000 00000080
  Interrupt Requirement:
    Line Based - Min Vector = 0x0, Max Vector = 0xffffffff
    Message Based: Type - Msi, 0x1 messages requested
  Interrupt Resource:    Type - MSI, 0x1 Messages Granted

这里有很多内核知道的关于这个设备的信息。此信息是通过 配置空间（缩写为“config space”）检索的，配置空间 是系统上的内存部分，允许内核以标准化的方式枚举、查询信息和设置 PCI 设备。软件从设备读取内存以查询供应商 ID 等信息，设备（如果已打开电源）使用该信息进行响应。在下一节中，我将更多地讨论这实际上是如何发生的，但要知道这里查询的信息是从配置空间生成的。

因此，让我们分解一些重要的东西：

• DevObj：指向 nt！_DEVICE_OBJECT 结构的指针，该结构表示内核中的物理设备。
• Vendor ID：注册给特定设备制造商的 16 位 ID 号。此值是标准化的，PCI-SIG 必须为新供应商分配一个唯一 ID，以便它们不会重叠。在本例中，我们看到这是 NVIDIA 显卡。
• Device ID：执行 PCIe 的特定芯片的 16 位 ID 号。类似的想法是，公司必须为其芯片请求一个唯一的 ID，这样它就不会与任何其他芯片冲突。
• Subsystem Vendor ID：芯片所在电路板的供应商 ID。在这种情况下，“HP”是显卡的生产商，而“NVIDIA”设计了图形芯片。
• Subsystem Device ID：芯片所在电路板的设备 ID。
• Logical Device Power State：此设备的电源状态。PCI 中有两种主要的电源状态，D0 = 设备已通电，D3 = 设备处于低功耗状态或完全关闭。
• Requirements：设备要求 OS 为其分配的内存要求。稍后会详细介绍。
• Resources：操作系统分配给此设备的内存资源。此设备已打开电源并启动，因此已为其分配了资源。
• Interrupt Requirement/Resource：与上述相同，但是对于中断则不同。

要实际获取有关此设备的完整信息，我们可以使用 PCI Lookup 中的出色工具来查询有关在 PCI-SIG 中注册的 PCI 设备的公共信息。让我们将有关设备和 Vendor ID 的信息放入框中：

当我们搜索时，我们得到这个：

这告诉我们该设备是 NVIDIA 创建的 Quadro K620 显卡。子系统 ID 告诉我们，这个特定的卡 PCB 是由 HP 生产的，该公司已获得 NVIDIA 的许可。

我们在 ！devext 中看到的很好地概述了 pci.sys 在摘要中特别关心向我们展示的内容，但它只触及了配置空间中所有信息的皮毛。要将所有信息转储到配置空间中，我们可以使用扩展名 ！pci 100 B D F，其中 BDF 是我们相关设备的 BDF。100 是一组标志，指定我们要转储有关设备的所有信息。显示的信息将按照它在设备的 config space 中存在的顺序进行布局。每个部分的前缀是一个偏移量，例如 02 表示 Device ID。这指定了从中读取此值的 config 空间的偏移量。这些偏移量在 PCI 规范中进行了详细说明，并且不会出于向后兼容性目的在 PCI 版本之间更改。

8: kd> !pci 100 2 0 0

PCI Configuration Space (Segment:0000 Bus:02 Device:00 Function:00)
Common Header:
    00: VendorID       10de Nvidia Corporation
    02: DeviceID       13bb
    04: Command        0507 IOSpaceEn MemSpaceEn BusInitiate SERREn InterruptDis 
    06: Status         0010 CapList 
    08: RevisionID     a2
    09: ProgIF         00 VGA
    0a: SubClass       00 VGA Compatible Controller
    0b: BaseClass      03 Display Controller
    0c: CacheLineSize  0000
    0d: LatencyTimer   00
    0e: HeaderType     80
    0f: BIST           00
    10: BAR0           f2000000
    14: BAR1           e000000c
    18: BAR2           00000000
    1c: BAR3           f000000c
    20: BAR4           00000000
    24: BAR5           00001001
    28: CBCISPtr       00000000
    2c: SubSysVenID    103c
    2e: SubSysID       1098
    30: ROMBAR         00000000
    34: CapPtr         60
    3c: IntLine        00
    3d: IntPin         01
    3e: MinGnt         00
    3f: MaxLat         00
Device Private:
    40: 1098103c 00000000 00000000 00000000
    50: 00000000 00000001 0023d6ce 00000000
    60: 00036801 00000008 00817805 fee001f8
    70: 00000000 00000000 00120010 012c8de1
    80: 00003930 00453d02 11010140 00000000
    90: 00000000 00000000 00000000 00040013
    a0: 00000000 00000006 00000002 00000000
    b0: 00000000 01140009 00000000 00000000
    c0: 00000000 00000000 00000000 00000000
    d0: 00000000 00000000 00000000 00000000
    e0: 00000000 00000000 00000000 00000000
    f0: 00000000 00000000 00000000 00000000
Capabilities:
    60: CapID          01 PwrMgmt Capability
    61: NextPtr        68
    62: PwrMgmtCap     0003 Version=3
    64: PwrMgmtCtrl    0008 DataScale:0 DataSel:0 D0 

    68: CapID          05 MSI Capability
    69: NextPtr        78
    6a: MsgCtrl        64BitCapable MSIEnable MultipleMsgEnable:0 (0x1) MultipleMsgCapable:0 (0x1)
    6c: MsgAddrLow     fee001f8
    70: MsgAddrHi      0
    74: MsgData        0

    78: CapID          10 PCI Express Capability
    79: NextPtr        00
    7a: Express Caps   0012 (ver. 2) Type:LegacyEP
    7c: Device Caps    012c8de1
    80: Device Control 3930 bcre/flr MRR:1K NS ap pf ET MP:256 RO ur fe nf ce
    82: Device Status  0000 tp ap ur fe nf ce
    84: Link Caps      00453d02
    88: Link Control   0140 es CC rl ld RCB:64 ASPM:None 
    8a: Link Status    1101 SCC lt lte NLW:x16 LS:2.5 
    9c: DeviceCaps2    00040013 CTR:3 CTDIS arifwd aor aoc32 aoc64 cas128 noro ltr TPH:0 OBFF:1 extfmt eetlp EETLPMax:0
    a0: DeviceControl2 0000 CTVal:0 ctdis arifwd aor aoeb idoreq idocom ltr OBFF:0 eetlp

Enhanced Capabilities:
    100: CapID         0002 Virtual Channel Capability
         Version       1
         NextPtr       258
    0104: Port VC Capability 1        00000000
    0108: Port VC Capability 2        00000000
    010c: Port VC Control             0000
    010e: Port VC Status              0000
    0110: VC Resource[0] Cap          00000000
    0114: VC Resource[0] Control      800000ff
    011a: VC Resource[0] Status       0000

    258: CapID         001e L1 PM SS Capability
         Version       1
         NextPtr       128
    25c: Capabilities  0028ff1f  PTPOV:5 PTPOS:0 PCMRT:255 L1PMS ASPML11 ASPML12 PCIPML11 PCIPML12
    260: Control1      00000000  LTRL12TS:0 LTRL12TV:0 CMRT:0 aspml11 aspml12 pcipml11 pcipml12
    264: Control2      00000028  TPOV:5 TPOS:0

    128: CapID         0004 Power Budgeting Capability
         Version       1
         NextPtr       600

    600: CapID         000b Vendor Specific Capability
         Version       1
         NextPtr       000
         Vendor Specific ID 0001 - Ver. 1  Length: 024

这个视图的好处是，我们可以看到有关配置空间的 Capabilities 部分的详细信息。Capabilities 是 config 空间中的一组结构，它准确描述了 device 能够实现的功能。Capabilities 包括链接速度和设备支持的中断类型等信息。PCI 规范中添加的任何新功能都将通过这些结构进行公布，这些结构在配置空间中形成了一个功能链表，可以迭代以发现设备的所有功能。并非所有这些功能都与操作系统相关，有些功能仅与本文未涵盖的硬件方面相关。现在，我不会详细介绍该设备的功能。

PCIe：一切都与内存相关

现在我们已经研究了几个设备和 PCI 总线的层次结构，让我们谈谈与软件和 PCI 设备的通信实际上是如何运作的。当我第一次学习 PCI 时，我很难理解当软件与 PCI 设备连接时到底发生了什么。因为整个事务对作为软件开发人员的你来说是抽象出来的，所以很难仅通过从调试工具中探入 PCI 内存来构建所发生的事情的心智模型。希望这篇文章能提供比我刚开始时所能得到的更好的概述。

首先，我要做一个大胆的声明：所有现代 PCIe 通信都是通过内存读写完成的。如果你了解 PCIe 中的内存如何工作，你就会了解 PCIe 软件通信的工作原理。（是的，在某些平台上还有其他传统的通信方式，但我们不会讨论这些方式，因为它们已被弃用）。

现在，让我们谈谈现代平台上不同类型的内存。在启动的早期，操作系统的 CPU 将使用虚拟内存。也就是说，CPU 看到的内存地址是映射到物理内存世界的内存视图。

就我们的目的而言，系统上有两种类型的物理内存：

• RAM - 读取或写入时从计算机上的 DRAM DIMM 存储和检索的地址。这就是大多数人在想到“内存”时所想到的。
• Device Memory（设备内存） - 在读取或写入时与系统上的设备“对话”的地址。这里的关键词是“对话”。它不会在设备上存储内存，也不会检索设备上的内存（尽管设备可能同时能够同时检索两者）。你可能正在与之通信的地址甚至可能根本不是内存，而是一个更抽象的“device register” ，用于配置设备的内部工作。这种访问会发生什么取决于设备。你所做的只是与设备通信。你通常会看到这称为 MMIO，它全称是 Memory-Mapped I/O。

注意：每当设备不响应设备内存区域中访问的地址时，PCI 的设备内存将始终读取“全 1”或“所有 FF”。这是了解设备何时实际响应的便捷方法。如果你看到所有 FF，则表示你正在读取无效的设备地址。

初学者认为所有物理内存都是 RAM，这是错误的。当软件与 PCI 区域中的 PCI 设备通信时，它不会从 RAM 读取和写入数据。相反，该设备从 RC 接收一个数据包（TLP，传输层数据包），当 PCI 区域内的地址被读/写时，你的 CPU 会立即自动生成该数据包。你无需在软件中创建这些数据包，所有这些数据包都是在访问此内存后立即完全在后台生成的。在软件中，你甚至无法查看或捕获这些数据包，而需要一个特殊的硬件测试设备来拦截和查看正在发送的数据包。稍后会详细介绍。

如果有帮助，请将物理内存视为设备的映射。RAM 是为你映射到物理内存中的设备。PCI 还会自动为你映射区域。尽管它们截然不同且行为也非常不同，但它们在软件中看起来是相同的。

在下图中，我们可以看到典型系统如何将虚拟内存映射到物理内存。请注意，有两个 RAM 区域和两个 PCI 内存区域。这是因为某些较旧的 PCI 设备只能寻址 32 位内存。因此，如果你的 RAM 不适合 4GB 以下的地址窗口，则一些 RAM 会上移到 4GB 以上。由于你的处理器支持 64 位地址，因此这不是问题。此外，在 4GB 行上方为支持 64 位地址的 PCI 设备创建第二个窗口。由于 4GB 区域可能非常有限，因此设备最好在 4GB 以上移动尽可能多的内存，以免弄乱下面的空间。

首先，让我们来谈谈我们已经见过存储器：配置空间（Configuration Space）。

配置空间位于一个名为 ECAM（Extended Configuration Access Management，扩展配置访问管理）的内存部分。因为它是一种设备内存，所以要从内核（使用虚拟内存）访问这段内存，内核必须请求内存管理器将这部分物理内存映射到一个虚拟地址上。然后，软件指令可以使用映射的虚拟地址来从物理地址读取和写入。在 Windows 上，定位和映射这段内存的工作部分由pci.sys处理，部分由acpi.sys处理，还有部分由内核（具体来说是 HAL）处理。

注意：通常，在 Windows 中映射设备内存的方式是通过 MmMapIoSpaceEx，这是驱动程序可用于映射物理设备内存的 API。但是，为了进行配置空间访问，软件必须使用 HalGetBusDataByOffset 和 HalSetBusDataByOffset 来确保 pci.sys 的内部状态与你正在执行的配置空间读/写保持同步。如果你尝试自己映射和更改配置空间，则可能会使 pci.sys 状态不同步并导致蓝屏死机。

注意：ECAM/PCI 区域在物理内存中的位置取决于平台。引导时的固件将分配系统物理内存的所有特殊区域。然后，固件会在引导期间向操作系统公布这些区域的位置。在 x86-64 系统上，ECAM 区域将使用称为 MCFG 的表（结构）通过 ACPI 从固件进行通信。现在知道使用什么特定协议来检索此信息不是很重要吗，只需了解操作系统从固件中检索这些区域的地址，固件决定了将它们放在哪里。

因此，为了进行配置空间访问，内核必须将配置空间（ECAM）映射到虚拟内存。这是这样的事情会是什么样子：

在此之后，内核现在可以使用虚拟映射与设备的配置空间进行通信。但是这个配置空间是什么样的呢？嗯，它只是我们上面讨论的一堆配置空间结构块。设备可能具有的每个可能的 BDF 都在 ECAM 中提供了空间来对其进行配置。它的布局方式是，设备的 BDF 会告诉你其配置空间在 ECAM 中的确切位置。也就是说，给定一个 BDF，我们可以计算要添加到 ECAM 区域基数的偏移量，以便与设备通信，因为每个功能的所有 ECAM 区域的大小都相同。

从这张图中，我们可以开始看到 PCIe 的枚举实际上是如何发生的。当我们读回有效的配置空间数据时，我们知道该 BDF 上存在设备。如果我们改为读回 FF，我们知道设备不在该插槽或功能中。当然，我们不会为了枚举所有设备而暴力破解每个地址，因为由于 MMIO 的开销，代价比较大。但是，这种蛮力的高级版本是我们如何快速枚举所有已通电并在配置空间上响应我们的设备。

把它们放在一起 - 软件配置空间访问

现在我们了解了如何访问配置空间，我们可以将两端（层次结构和 MMIO）放在一起，以查看从内核模式读取配置空间的指令的完整路径。

让我们逐步完成此处采用的整个路径（从左到右）：

• 在内核模式下运行的某些代码从 ECAM 虚拟映射中读取偏移量。
• 虚拟映射由 CPU 的页表转换为 ECAM 中的物理地址。
• 读取物理地址，导致内部 CPU 互连中发生操作，以通知RC访问。
• RC将请求的数据包化版本生成为 TLP，该 TLP 显示“读取设备 02:00.0 的偏移量 0x0 处的值”，并通过层次结构发送该请求。
• TLP 由总线 2 上的此显示控制器接收，并看到它是一个配置空间 TLP。现在，它知道使用包含偏移量 0x0 处的值内容的配置空间响应 TLP 进行响应。

现在让我们看看响应：

响应路径没那么有趣了。设备以含有偏移 0 处的值（我们知道这是供应商 ID）的特殊 TLP 进行响应。这个数据包找到回到请求者（即RC），然后互连通知 CPU 更新 rax 的值为 0x10DE，这是 NVIDIA 显卡的供应商 ID。然后，CPU 开始执行下一条指令。

如你所想那样，通过这种方式进行访问可能比通过全部的 TLP 生成的 RAM 慢很多。这确实是事实，并且这也是存在比这种 MMIO 方法更多的方式去与设备通信的主要原因之一。在接下来的文章中，我将详细介绍另一种方法，即 DMA，以及它对于确保软件能够尽可能快地在 CPU 和设备之间传输内存的至关重要性。

练习：通过 WinDbg 手动访问 ECAM

我们看了一下 config space access 理论上是如何发生的，但让我们自己用 debugger 做同样的事情。为此，我们希望：

• 找到 ECAM 在系统上的位置。
• 计算到 ECAM 的偏移量以读取设备的供应商 ID。为此，我选择了 NVIDIA 显卡上的Multimedia Device @ 02:00.1
• 在该地址执行物理内存读取以检索值。

第一步是找到 ECAM。鉴于 ECAM 的位置来自 ACPI，特别是 ACPI 中的 MCFG 表，这部分有点棘手。这是 firmware 用来告诉操作系统 ECAM 在系统的物理内存映射中的位置的表。关于 ACPI 以及如何将其与 PCI 结合使用，有很多内容要讨论，但现在，我将快速跳到相关部分以实现我们的目标。

在我们的调试器中，我们可以通过使用!acpicache来转储所有 ACPI 表的缓存副本。要转储 MCFG，请点击链接 MCFG 来转储其内容，或手动键入!acpitable MCFG：

8: kd> !acpicache
Dumping cached ACPI tables...
  XSDT @(fffff7b6c0004018) Rev: 0x1 Len: 0x0000bc TableID: SLIC-WKS
  MCFG @(fffff7b6c0005018) Rev: 0x1 Len: 0x00003c TableID: SLIC-WKS
  FACP @(fffff7b6c0007018) Rev: 0x4 Len: 0x0000f4 TableID: SLIC-WKS
  APIC @(fffff7b6c0008018) Rev: 0x2 Len: 0x000afc TableID: SLIC-WKS
  DMAR @(fffff7b6c000a018) Rev: 0x1 Len: 0x0000c0 TableID: SLIC-WKS
  HPET @(fffff7b6c015a018) Rev: 0x1 Len: 0x000038 TableID: SLIC-WKS
  TCPA @(ffffdc89b07209f8) Rev: 0x2 Len: 0x000064 TableID: EDK2    
  SSDT @(ffffdc89b0720a88) Rev: 0x2 Len: 0x0003b3 TableID: Tpm2Tabl
  TPM2 @(ffffdc89b0720e68) Rev: 0x3 Len: 0x000034 TableID: EDK2    
  SSDT @(ffffdc89b07fc018) Rev: 0x1 Len: 0x0013a1 TableID: Plat_Wmi
  UEFI @(ffffdc89b07fd3e8) Rev: 0x1 Len: 0x000042 TableID: 
  BDAT @(ffffdc89b07fd458) Rev: 0x1 Len: 0x000030 TableID: SLIC-WKS
  MSDM @(ffffdc89b07fd4b8) Rev: 0x3 Len: 0x000055 TableID: SLIC-WKS
  SLIC @(ffffdc89b07fd538) Rev: 0x1 Len: 0x000176 TableID: SLIC-WKS
  WSMT @(ffffdc89b07fd6d8) Rev: 0x1 Len: 0x000028 TableID: SLIC-WKS
  WDDT @(ffffdc89b0721a68) Rev: 0x1 Len: 0x000040 TableID: SLIC-WKS
  SSDT @(ffffdc89b2580018) Rev: 0x2 Len: 0x086372 TableID: SSDT  PM
  NITR @(ffffdc89b26063b8) Rev: 0x2 Len: 0x000071 TableID: SLIC-WKS
  ASF! @(ffffdc89b2606548) Rev: 0x20 Len: 0x000074 TableID:  HCG
  BGRT @(ffffdc89b26065e8) Rev: 0x1 Len: 0x000038 TableID: TIANO   
  DSDT @(ffffdc89b0e94018) Rev: 0x2 Len: 0x021c89 TableID: SLIC-WKS
8: kd> !acpitable MCFG
HEADER - fffff7b6c0005018
  Signature:               MCFG
  Length:                  0x0000003c
  Revision:                0x01
  Checksum:                0x3c
  OEMID:                   HPQOEM
  OEMTableID:              SLIC-WKS
  OEMRevision:             0x00000001
  CreatorID:               INTL
  CreatorRev:              0x20091013
BODY - fffff7b6c000503c
fffff7b6`c000503c  00 00 00 00 00 00 00 00-00 00 00 d0 00 00 00 00  ................
fffff7b6`c000504c  00 00 00 ff 00 00 00 00                          ........

要了解如何阅读此表，遗憾的是，我们需要查看 ACPI 规范。与其让你这样做，不如省去你的痛苦，把相关部分拉到这里：

由于 ！acpitable 命令已经解析并显示此表中 Creator Revision 之前的所有内容，因此 BODY 的前 8 个字节将是偏移量 36 处的 8 个字节的 Reserved 内存。因此，我们跳过这 8 个字节并找到以下结构：

此字节的前 8 个字节是 Reserved 后面的区域的 ECAM 区域的地址。这意味着 ECAM 基址的偏移量为偏移量 8。

BODY - fffff7b6c000503c
fffff7b6`c000503c  00 00 00 00 00 00 00 00-00 00 00 d0 00 00 00 00  ................
fffff7b6`c000504c  00 00 00 ff 00 00 00 00                          ........

对于这个系统，ECAM 位于地址：0xD0000000。（请别忘了以小端序来读取这个地址）

为了验证我们得到了正确的地址，让我们读取00:00.0的供应商 ID，这也是 ECAM 的前两个字节。我们将使用!dw命令来完成这个操作，该命令代表的dump physical word（感叹号代表物理）。这个命令要求你指定一个缓存类型，在我们的情况下，总是使用[uc]或者说未缓存。它还提供了一个长度，这是由 L1 指定要读取的 word 的数量。

注意：请务必始终将目标设备内存的大小与我们从软件中读取的大小相匹配。这意味着，如果我们要读取的值是 16 位值（如供应商 ID），则必须执行 16 位读取。执行 32 位读取可能会更改设备响应的结果。对于配置空间，我们可以读取供应商 ID 的更大大小，但并非在所有情况下都是如此。最好养成将读取大小与目标大小匹配的习惯，以避免任何意外结果。请记住：设备内存不是 RAM。

综上所述，我们读取 00：00.0 的 VendorID，如下所示：

8: kd> !dw [uc] D0000000 L1
#d0000000 8086

我们读取的结果值为 0x8086，它恰好是 Intel 的供应商 ID。为了验证这是正确的，让我们使用 ！pci 转储相同的内容。

8: kd> !pci 100 0 0 0

PCI Configuration Space (Segment:0000 Bus:00 Device:00 Function:00)
Common Header:
    00: VendorID       8086 Intel Corporation

从特定函数读取 VendorID

现在要计算我们希望与之通信的另一个函数（02：00.1 的 NVIDIA 卡）的 ECAM 地址，我们需要通过使用目标函数的 BDF 和一些位数学计算到 ECAM 的偏移量来手动执行“数组访问”。

计算方法存在于 PCIe 规范中，该规范为总线、器件和函数分配了一定数量的 ECAM 位来计算偏移量：

| 27 - 20 | 19 - 15 | 14 - 12     |  11 - 0       |
| Bus Nr  | Dev Nr  | Function Nr | Register      |

通过填写 BDF 并根据每个元素的位位置对结果进行移位和 OR 运算，我们可以计算出要添加到 ECAM 的偏移量。

我将使用 python，但你可以使用任何你想要的计算器：

>>> hex(0xD0000000 + ((2 << 20) | (0 << 15) | (1 << 12)))
'0xd0201000'

这意味着 02：00.1 的 ECAM 区域位于 0xD0201000。

现在，要从函数中读取 VendorID 的值：

8: kd> !dw [uc] D0201000 L1
#d0201000 10de

结果是 0x10de，我们从上面知道它是 NVIDIA Corporation！这意味着我们成功地从 ECAM 中读取了此函数的第一个值。

总结

这篇帖子最终比我预期的要长得多！我不会继续这篇文章，而是将其拆分并随着时间的推移充实该系列。关于 PCIe，我想介绍的主题太多了，但空闲时间却很少，但在下一篇文章中，我将更详细地介绍设备 BAR（一种特定于设备的 MMIO 形式）和 DMA（直接内存访问）。本系列将继续使用与以前相同的租户，更侧重于理解而不是具体细节。

希望你喜欢这个对 PCIe 世界的小小了解！期待更多精彩。

单击此处查看第 2 部分！

// module/cmn700/src/mod_cmn700.c
static struct mod_system_info_get_info_api *system_info_api;

int cmn700_start(fwk_id_t id)
{
    ...
    status = system_info_api->get_system_info(&system_info);
    if (status == FWK_SUCCESS) {
        chip_id = system_info->chip_id;
        multi_chip_mode = system_info->multi_chip_mode;
    }
    ...
}

他调用了system_info_api->get_system_info这个函数，实际这就是 mod_system_info 暴露给 mod_cmn700 的一个 API。用于获取系统信息。

为何这个静态变量system_info_api就能调用到mod_system_info的函数呢？我们继续搜索代码，可以看到如下代码：

// module/cmn700/src/mod_cmn700.c
static int cmn700_bind(fwk_id_t id, unsigned int round)
{
    ...
    if (fwk_id_is_type(id, FWK_ID_TYPE_MODULE)) {
        /* Bind to system info module to obtain multi-chip info */
        status = fwk_module_bind(
            FWK_ID_MODULE(FWK_MODULE_IDX_SYSTEM_INFO),
            FWK_ID_API(FWK_MODULE_IDX_SYSTEM_INFO, MOD_SYSTEM_INFO_GET_API_IDX),
            &system_info_api);
        return status;
    }
    ...
}

在cmn700_bind函数中，调用了fwk_module_bind函数，这个函数的作用是绑定一个模块的 API，这样就可以通过这个 API 调用模块的函数。fwk_module_bind函数的第一个参数是提供 API 的模块的 ID，比如当前是模块system_info的 ID，如果是要用 USB 的 API，那么就是 USB 模块的 ID。第二个参数是 API 的 ID，这个 ID 是在模块的头文件中定义的，比如mod_system_info.h中定义了MOD_SYSTEM_INFO_GET_API_IDX，这个宏定义的值就是 API 的 ID。第三个参数是 API 的指针，这个指针就是开头提到的静态变量的地址，它是定义在使用 API 的模块中的。这样就可以通过 API 的指针调用模块的函数。对于 USB 模块，我们就需要在使用到 USB 的模块中定义一个静态变量。

fwk_module_bind做了什么呢？进入该函数，可以看到它回调了mod_system_info的process_bind_request函数，也就是system_info_process_bind_request函数。

// framework/src/fwk_module.c
int fwk_module_bind(fwk_id_t target_id, fwk_id_t api_id, const void *api)
{
    ...
    status = fwk_mod_ctx->desc->process_bind_request(
        fwk_module_ctx.bind_id, target_id, api_id, (const void **)api);
    ...
}

system_info_process_bind_request函数的作用是根据 API 的 ID 返回 API 的指针。它把get_system_info_api的地址赋值给了api。这就实现了 API 的暴露。经过这个函数，system_info_api就指向了get_system_info_api。实际就是我们在cmn700_bind函数中使用system_info_api就是在调用get_system_info_api。

// module/system_info/src/mod_system_info.c
static int system_info_process_bind_request(fwk_id_t requester_id,
        fwk_id_t targer_id, fwk_id_t api_id, const void **api)
{
    switch (fwk_id_get_api_idx(api_id)) {
    case MOD_SYSTEM_INFO_GET_API_IDX:
        *api = &get_system_info_api;
        break;
    default:
        return FWK_E_PARAM;
    }
    return FWK_SUCCESS;
}

解释完这个 bind 函数，它是在哪被调用的？它在框架初始化时就会被调用，分析fwk_arch_init函数，可以看到在fwk_module_start函数中会对每一个模块调用bind函数。函数调用流程参考图片文件。在此就不再赘述了。

经过以上分析，提供 API 的模块需要做的事情就是：

1. 在模块的头文件中定义 API 的 ID，它有一定的格式，具体可以参考 MSCP 文档doc/framework.md的APIs章节。

   enum mod_modulename_api {
       MOD_MODULENAME_API_A,
       MOD_MODULENAME_API_B,
   };
   

2. 在模块的源文件中定义 API 结构体，用于在其他模块中使用。

   struct mod_system_info_get_info_api {
       int (*get_system_info)(const struct mod_system_info **sys_info);
   };
   

3. 在模块原文件中提供process_bind_request函数，用于根据 API 的 ID 返回 API 的指针。

   static int system_info_process_bind_request(fwk_id_t requester_id,
       fwk_id_t targer_id, fwk_id_t api_id, const void **api)
   {
       switch (fwk_id_get_api_idx(api_id)) {
       case MOD_SYSTEM_INFO_GET_API_IDX:
           *api = &get_system_info_api;
           break;
       default:
           return FWK_E_PARAM;
       }
       return FWK_SUCCESS;
   }
   

4. 在模块的源文件中定义 API 的指针，用于提供 API 的地址。

   static struct mod_system_info_get_info_api get_system_info_api = {
       .get_system_info = system_info_get_system_info,
   };
   

5. 实现需要提供的 API 函数。

   static int system_info_get_system_info(const struct mod_system_info **sys_info)
   {
       *sys_info = &system_info;
       return FWK_SUCCESS;
   }
   

以上就是大致的移植流程了。

下载配置工具链

访问ARM 官网下载工具链下载自己系统的版本的工具链。如果你也是 x86_64 的 Linux 系统，直接点击该链接下载 arm-gnu-toolchain-13.3

解压工具链：

xz -d arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz
tar -xvf arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu.tar

将工具链路径添加到环境变量中。

编译源码

源码使用 CMake 进行编译，CMake 版本需要 3.18.4 以上。如果你是 Ubuntu 20.04，直接安装即可。

sudo apt install cmake

如果你是 Ubuntu 18.04，需要升级 CMAKE。可以通过下面的方式下载源码编译安装 CMAKE。

wget https://github.com/Kitware/CMake/releases/download/v3.22.0/cmake-3.22.0-linux-x86_64.tar.gz
tar -zxvf cmake-3.22.0-linux-x86_64.tar.gz
mv cmake-3.22.0-linux-x86_64 /usr/local/cmake
export PATH=/usr/local/cmake/bin:$PATH

源码编译：

make -f Makefile.cmake PRODUCT=totalcompute/tc2 MODE=debug firmware-scp_ramfw

源码编译成功后，会在build/tc2/GNU/debug/firmware-scp_ramfw/bin目录下生成二进制文件。具体编译参数，可以参考源码根目录下的user_guide文档。

初始化流程分析

fwk_module_init 初始时，module_config_table 是在什么时候被初始化的？

module_config_table 无法在源码中直接搜索到，因为它是在编译过程中生成的，当你编译一次后，就会在 output/build/mpw/GNU/debug/firmware-scp_romfw/framework/src/fwk_module_list.c 找到这个变量。具体它是如何生成的，注意通过 framework/CMakeLists.txt 文件中的这段代码完成，我们逐行分析这段代码。

list(LENGTH SCP_MODULES SCP_MODULE_IDX_MAX)

获取模块列表的长度，保存在 SCP_MODULE_IDX_MAX 变量中。在每个 Firmware.cmake 文件中，都会有一个 SCP_MODULES 变量，这个变量保存了该产品所包含的模块。

# product/juno/scp_romfw/Firmware.cmake
list(APPEND SCP_MODULES "test")
list(APPEND SCP_MODULES "uart")

当前我们加入了两个模块，所以 SCP_MODULE_IDX_MAX 的值为 2。

foreach(idx RANGE ${SCP_MODULE_IDX_MAX})
    if(idx EQUAL SCP_MODULE_IDX_MAX)
        string(APPEND SCP_MODULE_IDX_GEN "    FWK_MODULE_IDX_COUNT = ${idx},\n")

        break()
    endif()

遍历模块列表，生成模块索引的定义，如下：

enum fwk_module_idx {
    FWK_MODULE_IDX_COUNT = 0,
};

    list(GET SCP_MODULES ${idx} SCP_MODULE)

将 SCP_MODULES 列表中索引为 idx 的元素赋值给变量 SCP_MODULE，以便在后续的代码中使用。当前 idx 为 0，所以 SCP_MODULE 为 test。

    string(MAKE_C_IDENTIFIER ${SCP_MODULE} SCP_MODULE)
    string(TOUPPER ${SCP_MODULE} SCP_MODULE_UPPER)

将 SCP_MODULE 转换为 C 标识符。将 SCP_MODULE 转为大写并保存在 SCP_MODULE_UPPER 中，即 SCP_MODULE_UPPER="TEST"

    string(APPEND SCP_MODULE_IDX_GEN "    FWK_MODULE_IDX_${SCP_MODULE_UPPER} = ${idx},\n")
    string(APPEND SCP_MODULE_ID_INIT_GEN "#define FWK_MODULE_ID_${SCP_MODULE_UPPER}_INIT FWK_ID_MODULE_INIT(FWK_MODULE_IDX_${SCP_MODULE_UPPER})\n")
    string(APPEND SCP_MODULE_ID_GEN "#define FWK_MODULE_ID_${SCP_MODULE_UPPER} FWK_ID_MODULE(FWK_MODULE_IDX_${SCP_MODULE_UPPER})\n")
    string(APPEND SCP_MODULE_ID_CONST_GEN "static const fwk_id_t fwk_module_id_${SCP_MODULE} = FWK_MODULE_ID_${SCP_MODULE_UPPER}_INIT;\n")
    string(APPEND SCP_MODULE_EXTERN_GEN "extern const struct fwk_module module_${SCP_MODULE};\n")
    string(APPEND SCP_MODULE_EXTERN_CONFIG_GEN "extern const struct fwk_module_config config_${SCP_MODULE};\n")
    string(APPEND SCP_MODULE_GEN "    &module_${SCP_MODULE},\n")
    string(APPEND SCP_MODULE_CONFIG_GEN "    &config_${SCP_MODULE},\n")

进行一些宏替换，替换后的结果如下：

SCP_MODULE_IDX_GEN: "   FWK_MODULE_IDX_TEST = 0,"
SCP_MODULE_ID_INIT_GEN: "#define FWK_MODULE_ID_TEST_INIT FWK_ID_MODULE_INIT(FWK_MODULE_IDX_TEST)"
SCP_MODULE_ID_GEN: "#define FWK_MODULE_ID_TEST FWK_ID_MODULE(FWK_MODULE_IDX_TEST)"
SCP_MODULE_ID_CONST_GEN: "static const fwk_id_t fwk_module_id_test = FWK_MODULE_ID_TEST_INIT;"
SCP_MODULE_EXTERN_GEN: "extern const struct fwk_module module_test;"
SCP_MODULE_EXTERN_CONFIG_GEN: "extern const struct fwk_module_config config_test;"
SCP_MODULE_GEN: "&module_test,"
SCP_MODULE_CONFIG_GEN: "&config_test,"

    target_compile_definitions(framework
                               PUBLIC "BUILD_HAS_MOD_${SCP_MODULE_UPPER}=1")

将 BUILD_HAS_MOD_TEST 定义为 1，以便在后续的代码中使用。

在源码文件中有两个模板文件，分别为 fwk_module_list.c.in 和 fwk_module_idx.h.in，这两个文件中包含了一些宏定义，这些宏定义在编译过程中会被替换为上面生成的宏定义。

#include <stddef.h>

@SCP_MODULE_EXTERN_GEN@

const struct fwk_module *module_table[FWK_MODULE_IDX_COUNT] = {
@SCP_MODULE_GEN@
};

@SCP_MODULE_EXTERN_CONFIG_GEN@

const struct fwk_module_config *module_config_table[FWK_MODULE_IDX_COUNT] = {
@SCP_MODULE_CONFIG_GEN@
};

#include <fwk_id.h>

@SCP_MODULE_ID_INIT_GEN@
@SCP_MODULE_ID_GEN@

enum fwk_module_idx {
@SCP_MODULE_IDX_GEN@
};

@SCP_MODULE_ID_CONST_GEN@

在编译过程中就会生成下面两个文件，当使用module_config_table时，就会引用这两个文件，找到对应的配置。

// build/mpw/GNU/debug/firmware-scp_romfw/framework/include/fwk_module_idx.h
#define FWK_MODULE_ID_TEST_INIT FWK_ID_MODULE_INIT(FWK_MODULE_IDX_TEST)
#define FWK_MODULE_ID_UART_INIT FWK_ID_MODULE_INIT(FWK_MODULE_IDX_UART)


#define FWK_MODULE_ID_TEST FWK_ID_MODULE(FWK_MODULE_IDX_TEST)
#define FWK_MODULE_ID_UART FWK_ID_MODULE(FWK_MODULE_IDX_UART)


enum fwk_module_idx {
    FWK_MODULE_IDX_TEST = 0,
    FWK_MODULE_IDX_UART = 1,
    FWK_MODULE_IDX_COUNT = 2,

};

static const fwk_id_t fwk_module_id_test = FWK_MODULE_ID_TEST_INIT;
static const fwk_id_t fwk_module_id_uart = FWK_MODULE_ID_UART_INIT;

// build/mpw/GNU/debug/firmware-scp_romfw/framework/src/fwk_module_list.c
extern const struct fwk_module module_test;
extern const struct fwk_module module_uart;


const struct fwk_module *module_table[FWK_MODULE_IDX_COUNT] = {
    &module_test,
    &module_uart,

};

extern const struct fwk_module_config config_test;
extern const struct fwk_module_config config_uart;


const struct fwk_module_config *module_config_table[FWK_MODULE_IDX_COUNT] = {
    &config_test,
    &config_uart,
};

如何确定各个模块在初始化过程中的执行顺序？

在每个产品目录 mscp/product/juno/scp_romfw/Firmware.cmake 中，都会有一个 Firmware.cmake 文件，这个文件中会包含该产品所包含的模块：

list(APPEND SCP_MODULES "juno-ppu")
list(APPEND SCP_MODULES "juno-rom")
list(APPEND SCP_MODULES "gtimer")
list(APPEND SCP_MODULES "sds")
list(APPEND SCP_MODULES "bootloader")
list(APPEND SCP_MODULES "juno-soc-clock")

编译后会在 output 文件夹中生成fwk_module_idx.h文件，这个文件中会包含所有模块的索引，如下：

配置Windows侧网卡

将Windows与开发板通过USB网卡连接，开发板的网卡插口选择eth0，也就是靠近拨码开关的网口。开发板开机，Windows的设备管理器中出现以下网卡表示网卡功能正常。

打开网络和共享中心，选择更改适配器设置，找到USB网卡，右键属性，选择Internet协议版本4（TCP/IPv4），点击属性，选择使用以下IP地址，设置IP地址为以下内容：

• IP地址：192.168.1.111
• 子网掩码：255.255.225.0
• 默认网关：192.168.1.1

网卡的IP要和你Window主机自己的IP在一个网段，不能盲目设置为手册里的192.168.5.10，这样会导致Windows主机无法访问开发板。可以通过在Windows命令行输入ipconfig查看Windows主机的IP地址。一般来说，如果没有设置过路由器，默认都是在192.168.1.x网段。那么网关通常就是这个网段的第一个地址，也就是192.168.1.1，这也是路由器的地址。

如果你配置完网卡以及开发板的IP后能正常相互ping通，那么说明网络配置成功。如果你很不巧和我一样，USB网卡一直无法通过DHCP自动获取IP地址，并且配置完静态IP后只能单侧ping通，那么也可以和我一样将USB网卡和主机的WIFI网卡桥接，这样就可以实现双向通信。这里有个前提条件就是你的主机原先就有两张网卡，一张用于连接路由器，一张是WIFI网卡。不能直接将USB网卡和连接路由器的网卡桥接。

万万没想到一张整年闲置的WIFI网卡竟然派上了用场。

选择WIFI网卡和USB网卡，右键桥接，这样就创建一个网桥，网桥会自动获取IP地址。

开发板侧配置网卡

配置网卡IP，这个IP也是需要和Windows主机在一个网段的。因为路由器分配IP时会从小到大分配，为了避免和已有的设备IP冲突，我们就可以设置一个比较大的IP，比如112。

# 配置网卡ip为192.169.1.112，子网掩码为255.255.255.0
ifconfig eth0 192.168.1.112

设置默认网关：

ip route add default via 192.168.1.1

注意：更换网口需要重启开发板

[Match]
    Name=eth0
[Network]
    Address=192.168.1.112/24 Gateway=192.168.1.1

挂载NSF共享目录

Windows侧配置

1. 安装haneWIN NFS 服务器（https://pan.baidu.com/s/1y2R2aJyEExnCJ7FRqdaNdA 提取码：esdw）

   1. 安装路径一般为：C:\Program Files (x86)\nfsd。使用VScode打开该目录下的exports文件，修改内容如下，保存时需要用管理员身份保存：

   d:\nfs -public 192.168.1.112
   

   • d:\nfs：共享目录为D盘的nfs，可以根据自己的实际情况修改。
   • -public：表示共享目录为公共目录，即所有用户都可以访问。
   • IP：为开发板的IP地址，表示要与这个IP进行共享。

2. 关闭防火墙或者开启必要的通信端口

   1. 如果为了省事，可以直接关闭Windows防火墙
   2. 如果不想关防火墙需要开启以下端口的通信：
      • TCP 111
      • UDP 111
      • TCP 2049
      • UDP 2049
      • TCP 1058
      • UDP 1058
   3. 开启端口的方法为：控制面板 -> 系统和安全 -> Windows Defender 防火墙 -> 高级设置 -> 入站规则 -> 新建规则 -> 端口 -> 下一步 -> TCP -> 特定本地端口 -> 2049 -> 下一步 -> 允许连接 -> 下一步 -> 下一步 -> 规则名称 -> 完成。
   4. 需要注意在出站规则和入站规则都需要添加。

3. 重启Windows NFS Server服务

   1. 右键Windows徽标键，打开计算机管理，找到服务和应用程序，点击服务，找到NFS Server，右键重启。
      1. 
   2. 点击软件的输出选项卡，点击重启服务器，如果出现如图配置表示正确启动服务：
      

开发板侧配置

1. 新建一个目录，用于挂载共享目录

   1. mkdir /nfs

2. 挂载共享目录

   mount -vvv  -t nfs -o nolock -o vers=3,port=2049 192.168.1.7:/d/nfs  /nfs
   

   • -vvv：表示挂载时输出详细信息，可省略
   • -t nfs：表示挂载的文件系统类型为nfs
   • -o nolock：表示不使用锁定机制
   • -o vers=3：表示使用NFSv3版本
   • -o port=2049：表示NFS服务端口号
   • 192.168.1.7:/d/nfs：表示NFS服务器的IP地址和共享目录
   • /nfs: 表示开发板上的共享目录

常见错误

挂载时报错：portmap query failed: RPC: Timed out

点击NFS服务的端口映射页面，可以查看RPC使用的所有端口，需要将这些端口都开放，或者直接关闭防火墙。

一些可能用到的命令：

ip route add default via 192.168.1.1

ip route del 0.0.0.0/0 via 192.168.1.1 dev eth0

ip route del 192.168.1.0/24 dev eth0

vi  /etc/systemd/network/50-static.network

systemctl enable systemd-networkd

如何在Windows上搭建NFS服务器实现开发板与Windows之间的文件共享_opencv_Jack_小明-GitCode 开源社区

文件系统与根文件系统

文件系统（File System）是操作系统用于管理和存储数据的一种方式。它定义了如何在存储设备（如硬盘、SSD、USB 驱动器等）上组织文件和目录，以及如何进行数据的读写操作。

常见的文件系统类型有：

• ext4：Linux 最常用的文件系统，支持大文件和大分区。
• NTFS：Windows 操作系统常用的文件系统，支持文件加密和权限控制。
• FAT32：一种兼容性广泛的文件系统，常用于 USB 驱动器和内存卡。
• XFS：适用于高性能和高容量存储需求的文件系统。
• btrfs：一种现代 Linux 文件系统，支持快照、压缩和多设备管理。

根文件系统（Root File System，通常简称为 rootfs）是文件系统层次结构中的顶级文件系统。它包含了操作系统启动和运行所需的所有基本文件和目录。根文件系统是整个文件系统层次的起点，在 Linux 中由单个斜杠（/）表示。根文件系统首先是内核启动时所 mount 的第一个文件系统，内核代码映像文件保存在根文件系统中，而系统引导启动程序会在根文件系统挂载之后从中把一些基本的初始化脚本和服务等加载到内存中去运行。

根文件系统是建立在文件系统之上的。根文件系统使用某种具体的文件系统类型（如 ext4）来管理和存储其内容。

基于内存的文件系统

ramdisk 是一种基于内存的文件系统，它将内存的一部分用作硬盘驱动器，这样就可以在内存中创建一个文件系统。ramdisk 是一个虚拟磁盘，它的大小和硬盘驱动器的大小一样。ramdisk 的优点是速度快，缺点是断电后数据丢失。

根文件系统中各种配置文件的作用以及配置文件的格式介绍

/etc/inittab

/etc/inittab 是 Linux 系统中的一个配置文件，它是 init 程序的配置文件，用于配置系统的运行级别和 init 程序的行为。在 Linux 系统中，init 程序是系统的第一个进程，它负责启动系统中的所有其他进程。/etc/inittab 文件中的每一行都是一个配置项，每个配置项由四个字段组成，字段之间用空格或制表符分隔。/etc/inittab 文件的格式如下：

id:runlevels:action:process

每个字段用冒号分隔，可以缺省。各字段的含义如下：

• id：配置项的标识符，用于标识配置项。
• runlevels：配置项所对应的运行级别，可以是一个或多个运行级别的组合。
• action：配置项的动作，可以是以下几种动作之一：
  • sysinit：系统初始化时运行。
  • respawn：如果进程终止，立即重新启动。
  • askfirst：在运行 process 之前询问用户。并在控制台上显示 Please press Enter to active this console。
  • wait：等待进程终止，然后继续执行下一个配置项。
  • once：只运行一次，进程终止后不会重新启动。
  • boot：在系统引导时运行。
  • bootwait：在系统引导时运行，等待进程终止后继续引导。
  • initdefault：设置默认运行级别。
  • shutdown：在系统关机时运行。
• process：要执行的进程或脚本的路径。

示例：

# /etc/inittab
#系统开机或重新启动，执行rcS文件
::sysinit:/etc/init.d/rcS
#系统启动后，运行登录程序  
::askfirst:-/bin/login
#按下组合键“ctrl+alt+del”，重启Linux系统
::ctrlaltdel:-/sbin/reboot   
#系统关机时，卸载所有文件系统
::shutdown:/bin/umount -a -r
#重启init进程
::restart:/sbin/init

/etc/fstab

/etc/fstab 是 Linux 系统中的一个配置文件，用于配置文件系统的挂载信息。在 Linux 系统中，文件系统是通过挂载的方式来访问的，/etc/fstab 文件中记录了系统中所有文件系统的挂载信息。/etc/fstab 文件的格式如下：

device mount_point fs_type options dump pass

各字段的含义如下：

• device：设备文件或 UUID。
• mount_point：挂载点。
• fs_type：文件系统类型。
• options：挂载选项。
• dump：备份标志，用于备份工具。
• pass：文件系统检查顺序。

示例：

# /etc/fstab
# <文件系统>  <挂载点>  <类型>  <选项>        <dump>  <fsck>

# 根文件系统
/dev/sda1       /           ext4    defaults        1       1  # 根分区，使用 ext4 文件系统，默认挂载选项

# /boot 分区，用于存放引导加载程序和内核镜像
/dev/sda2       /boot       ext4    defaults        1       2  # /boot 分区，使用 ext4 文件系统，默认挂载选项

# 交换分区，用作虚拟内存
/dev/sda3       none        swap    sw              0       0  # 交换分区，不需要挂载点，使用 swap 类型

# /home 分区，用于存放用户的个人数据
/dev/sda4       /home       ext4    defaults        1       2  # /home 分区，使用 ext4 文件系统，默认挂载选项

# /tmp 分区，用于存放临时文件
/dev/sda5       /tmp        ext4    defaults        1       2  # /tmp 分区，使用 ext4 文件系统，默认挂载选项

# /var 分区，用于存放可变数据文件，如日志、邮件、缓存等
/dev/sda6       /var        ext4    defaults        1       2  # /var 分区，使用 ext4 文件系统，默认挂载选项

# /mnt/data 分区，用于存放额外的数据文件
/dev/sda7       /mnt/data   ext4    defaults        1       2  # /mnt/data 分区，使用 ext4 文件系统，默认挂载选项

# 挂载 proc 文件系统，用于访问进程和系统信息
proc            /proc       proc    defaults        0       0  # proc 虚拟文件系统，默认挂载选项

# 挂载 sysfs 文件系统，用于访问设备和内核信息
sysfs           /sys        sysfs   defaults        0       0  # sysfs 虚拟文件系统，默认挂载选项

# 挂载 tmpfs 文件系统，用于临时文件存储
tmpfs           /dev/shm    tmpfs   defaults        0       0  # tmpfs 虚拟文件系统，默认挂载选项

# 挂载 devpts 文件系统，用于伪终端设备
devpts          /dev/pts    devpts  gid=5,mode=620  0       0  # devpts 虚拟文件系统，默认挂载选项

/etc/init.d/rcS

/etc/init.d/rcS 是 Linux 系统中的一个初始化脚本，用于系统初始化时运行。在 Linux 系统中，/etc/init.d/rcS 脚本是系统初始化时运行的第一个脚本，它负责初始化系统中的各种服务和配置。/etc/init.d/rcS 脚本通常包含了一些初始化命令，如加载模块、挂载文件系统、启动服务等。/etc/init.d/rcS 脚本的格式如下：

#!/bin/sh
# 这行是 shebang，用于指定这个脚本将由 /bin/sh 解释执行

# 挂载 proc 文件系统到 /proc 目录
mount -t proc none /proc
# proc 文件系统是一个虚拟文件系统，用于提供内核和进程的信息

# 挂载 sysfs 文件系统到 /sys 目录
mount -t sysfs none /sys
# sysfs 文件系统是一个虚拟文件系统，用于提供设备和内核信息

# 挂载 devtmpfs 文件系统到 /dev 目录
mount -t devtmpfs none /dev
# devtmpfs 是一个用于设备节点的临时文件系统

# 运行 mdev 以创建设备节点
/sbin/mdev -s
# mdev 是一个轻量级的设备管理工具，用于创建和管理 /dev 目录中的设备节点

# 设置主机名
echo "myhostname" > /proc/sys/kernel/hostname
# 将主机名设置为 "myhostname"，这个名字可以根据需要更改

# 启动网络接口配置脚本
ifconfig lo up
# 启动回环接口 lo，这是一个特殊的网络接口，用于网络软件本地通信

# 运行所有位于 /etc/init.d/ 目录中的初始化脚本
for script in /etc/init.d/S*; do
  if [ -x "$script" ]; then
    "$script" start
  fi
done
# 遍历 /etc/init.d/ 目录中的所有以 S 开头的脚本，并执行它们以启动相应的服务
# -x 选项用于检查文件是否可执行

# 挂载用户文件系统（可选，根据实际需要）
mount -a
# 挂载 /etc/fstab 文件中列出的所有文件系统

# 打印启动完成信息
echo "System initialization complete."
# 输出系统初始化完成信息

/etc/profile

/etc/profile 是 Linux 系统中的一个全局配置文件，用于配置系统的环境变量和用户的 shell 环境。在 Linux 系统中，/etc/profile 文件是系统启动时加载的第一个配置文件，它包含了系统的全局环境变量和用户的 shell 环境配置。/etc/profile 文件的格式如下：

# /etc/profile
#!/bin/sh
# 这行是 shebang，用于指定这个脚本将由 /bin/sh 解释执行

# 设置 PATH 环境变量，定义系统命令的搜索路径
PATH="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
export PATH
# /usr/local/sbin:/usr/local/bin 是系统管理员和用户安装的程序路径
# /sbin:/bin:/usr/sbin:/usr/bin 是系统默认的命令路径

# 设置用户 umask，定义新文件和目录的默认权限掩码
umask 022
# umask 022 表示新文件的默认权限是 755，新目录的默认权限是 644

# 设置系统语言和区域
LANG="en_US.UTF-8"
export LANG
# LANG 变量定义了系统的语言环境，这里设置为美国英语 UTF-8 编码

# 设置历史记录文件和大小
HISTSIZE=1000
HISTFILESIZE=2000
export HISTSIZE HISTFILESIZE
# HISTSIZE 定义了 shell 会话历史记录的条目数，HISTFILESIZE 定义了历史记录文件的最大条目数

# 系统启动信息
echo "Welcome to your Linux system!"
# 在用户登录时显示欢迎信息

# 读取并执行 /etc/bashrc（如果存在）
if [ -f /etc/bashrc ]; then
    . /etc/bashrc
fi
# /etc/bashrc 是另一个全局配置文件，通常包含 bash shell 的配置
# 使用 . /etc/bashrc 命令将其内容导入当前 shell 环境

# 配置别名（示例）
alias ll='ls -l'
alias la='ls -A'
alias l='ls -CF'
# 定义一些常用命令的别名
# ll 代表 ls -l，显示详细列表
# la 代表 ls -A，显示所有文件包括隐藏文件（但不包括 . 和 ..）
# l 代表 ls -CF，以分类格式显示文件

# 读取用户特定的配置文件（如果存在）
if [ -f "$HOME/.profile" ]; then
    . "$HOME/.profile"
fi
# .profile 是用户的个人配置文件
# 使用 . $HOME/.profile 命令将其内容导入当前 shell 环境

# 设置编辑器
EDITOR=vim
export EDITOR
# 定义默认的文本编辑器为 vim

# 设置主机名显示，也就是终端最前面提示符的样式
PS1='\u@\h:\w\$ '
export PS1
# PS1 定义了 shell 提示符的样式
# \u 代表用户名
# \h 代表主机名
# \w 代表当前工作目录

Busybox 简介以及如何制作 Busybox 文件系统

准备 QEMU

cd && mkdir -p /home/user/program/riscv64-qemu
cd workspace
git clone https://github.com/qemu/qemu.git
cd qemu
cd qemu && ./configure --target-list=riscv32-softmmu,riscv32-linux-user,riscv64-linux-user,riscv64-softmmu \
               --enable-kvm --enable-sdl \
               --prefix=/home/user/program/riscv64-qemu
make install -j $(nproc)

准备 OpenSBI

cd workspace
git clone https://github.com/riscv-software-src/opensbi.git
cd opensbi
make ARCH=riscv CROSS_COMPILE=riscv64-unknown-linux-gnu- PLATFORM=generic

准备 Linux 内核

cd workspace
git clone https://github.com/torvalds/linux.git
make ARCH=riscv CROSS_COMPILE=riscv64-unknown-linux-gnu- defconfig
make ARCH=riscv CROSS_COMPILE=riscv64-unknown-linux-gnu- -j $(nproc)

准备 Busybox

进入下载软件包，https://busybox.net/downloads/

wget https://busybox.net/downloads/busybox-1.36.1.tar.bz2
tar -xvf busybox-1.36.1.tar.bz2
mv busybox-1.36.1 busybox
cd busybox

配置编译选项

make CROSS_COMPILE=riscv64-unknown-linux-gnu- menuconfig

选择静态库模式，设置路径：Settings -> Build static binary (no shared libs)

编译 Busybox

make CROSS_COMPILE=riscv64-unknown-linux-gnu- -j $(nproc)

如果需要频繁编译，也可以在 Menuconfig 中设置交叉编译器路径，这样就不需要每次都指定了。设置路径为：Settings -> Build Options -> Cross Compiler prefix。将其设置为 riscv64-unknown-linux-gnu-。

安装 Busybox：

make CROSS_COMPILE=riscv64-unknown-linux-gnu- install

Busybox 默认安装在当前目录的_install 目录下，也可以在 Menuconfig 中设置安装目录，路径为：Settings -> Build Options -> Destination path for ‘make install’。

查看安装目录

ls _install 
bin  linuxrc  sbin  usr

制作根文件系统

qemu-img create -f raw rootfs.img 256M
mkfs.ext4 rootfs.img
mkdir rootfs
sudo mount -o loop rootfs.img rootfs
sudo cp -r _install/* rootfs

cd rootfs
sudo mkdir proc sys dev etc etc/init.d
cd etc
cd init.d
sudo touch rcS
sudo chmod +x rcS

sudo vim rcS

写入以下内容：

#!/bin/sh  
mount -t proc none /proc  
mount -t sysfs none /sys  
/sbin/mdev -s

sudo umount rootfs

qemu 启动内核：

#!/usr/bin/env bash
RESTORE=$(echo -en '\001\033[0m\002')
YELLOW=$(echo -en '\001\033[00;33m\002')

## Configuration
vcpu=8
memory=16
drive="/home/user/workspace/rootfs.img"
kernel=" /home/user/workspace/linux-stable/arch/riscv/boot/Image"
fw="/home/user/workspace/opensbi/build/platform/generic/firmware/fw_jump.bin"
ssh_port=12070

cmd="/home/user/program/riscv64-qemu/bin/qemu-system-riscv64 \
  -nographic -machine virt \
  -smp "$vcpu" -m "$memory"G \
  -cpu rv64\
  -bios "$fw" \
  -kernel "$kernel" \
  -drive file=$drive,format=raw,id=hd0 \
  -device virtio-blk-device,drive=hd0 \
  -append "root=/dev/vda console=ttyS0" "

echo ${YELLOW}:: Starting VM...${RESTORE}
echo ${YELLOW}:: Using following configuration${RESTORE}
echo ""
echo ${YELLOW}vCPU Cores: "$vcpu"${RESTORE}
echo ${YELLOW}Memory: "$memory"G${RESTORE}
echo ${YELLOW}Disk: "$drive"${RESTORE}
echo ${YELLOW}SSH Port: "$ssh_port"${RESTORE}
echo ""
echo ${YELLOW}:: NOTE: Make sure ONLY ONE .qcow2 file is${RESTORE}
echo ${YELLOW}in the current directory${RESTORE}
echo ""
echo ${YELLOW}:: Tip: Try setting DNS manually if QEMU user network doesn\'t work well. ${RESTORE}
echo ${YELLOW}:: HOWTO -\> https://serverfault.com/a/810639 ${RESTORE}
echo ""
echo ""

sleep 2

eval $cmd

一款 SoC 芯片，会支持多种方式启动，比如从 NAND Flash、SPI Flash、eMMC、USB、UART 启动。对于 SPI Flash 启动，BootROM 需要知道 SPI Flash 的型号、容量、页大小、擦除大小等信息，以便正确读取、写入、擦除 SPI Flash。但是，不同厂家的 SPI Flash，这些参数可能不同，而 ROM 中的代码是无法修改的，并且容量有限，如何以最小的代码量，适配不同厂家的 SPI Flash 呢？

SPI 开发流程

• SPI 控制器初始

  • SPI 控制器有自己的寄存器，可以配置 SPI 的页，块的擦除时间，是否需要 DMA，是否开启中断，单次读写的大小等等。

• 使用 SPI 对 Flash 进行配置

  • BootROM 的 SPI 支持三种模式：Single、Dual、Quad，这不仅要配置 SPI 本身的寄存器，也需要配置 Flash 的寄存器。配置 Flash 的寄存器就需要使用 SPI 来完成。
    • BootROM 中配置 SPI 控制器的 SPIC_CSR_01 寄存器的spi_bus_mode 位可以配置 SPI 的模式；
    • 查阅 Flash 手册，找到配置总线模式的寄存器以及操作它的命令，如 WINBOND-W25Q128JW 这款 Flash 的配置寄存器为 Status Register-2，Flash 的寄存器是无法直接读写的，所以需要在 Flash 手册中找到操作这个寄存器的命令，在手册的 Instructions 章节可以找到这款 Flash 的配置命令为 Write Status Register-2，命令码为 0x31，只要我们向 Flash 发送 0x31，就可以配置 Flash 的总线模式了。
      
      
    • 如何向 Flash 发送指令？需要将真正要发送的指令写入 SPI 的寄存器SPIC_CSR_06，该寄存器的各个 Bit 可以配置命令码，命令类型，命令是否有效等信息。我们将之前的命令码0x31写入到SPIC_CSR_06的command_code位，然后将SPIC_CSR_06的command_type位设置为write status register，SPI 就会自动将这些信息发送给 Flash。Flash 接收到命令后，会根据命令码执行配置寄存器的操作。

• SPI 读写 Flash

  • 和配置 Flash 总线模式一样，读写 Flash 也需要配置 SPI 控制器的寄存器，以及配置 Flash 的寄存器。SPI 控制器的寄存器配置和配置 Flash 总线模式一样，只是命令码和命令类型不同。稍有不同的是需要先配置好 SPI 寄存器，配置读写的大小以及读写的地址，然后再配置SPIC_CSR_06。Flash接收到命令后，会根据命令码执行读写操作。主设备只需要读写 Flash 的指定地址即可读写到数据。

SPI 驱动如何适配不同的 Flash

在开发流程中我们并未考虑不同厂家的 Flash 如何操作，只是关心了 WINBOND-W25Q128JW 这款 Flash 的操作。在操作过程中我们可以发现，不同厂家的 Flash 的操作基本一致，只是命令码、页大小、擦除大小等参数不同。我们只要针对不同的 Flash，配置不同的参数即可。但是，如何知道当前 Flash 的参数呢？这就需要用到 SFDP 了。

SFDP 是 JEDEC 发布的 JESD216 的一个新标准，目前的版本号是 V1.0。简而言之，SFDP（Serial Flash Discoverable Parameters）就相当于一张存储了 FLASH 部分属性的表，此表是不占用 FLASH 本身的存储空间的。SFDP 中的信息自出厂就被固定，只供读取，开发人员可通过发送操作指令 0x5A 来读取当前 FLASH 的 SFDP 相关内容，这有利于开发人员了解 FLASH 之间的差异，提高开发效率，缩短整个开发周期。

也就是只要 Flash 研发时遵循了 JESD216 这个标准，我们都可以通过发送 0x5A 这个命令码，去获取Flash相关参数。最为关键的就是其中会保存 Flash 厂商的 ID，当我们获取到 Flash 厂商的 ID 时，我们就可以根据 ID 执行不同的配置操作。

对于 WINBOND-W25Q128JW 这款 Flash，在数据手册的Feature里就可以看到它是支持 SFDP 的：

• 常用的脚本语言有 sh、bash、csh、ksh、perl、python；
• 在 Linux 下常用的脚本语言其实就是 bash、sh；
• 脚本语言一般在嵌入式中应用，主要是用来做配置。（一个复杂的嵌入式程序都是可配置的，配置过程就是用脚本语言来实现的）自然不会使用过于复杂的脚本语言特性，因此只需要针对性的学习即可。

shell 脚本的运行机制

• C/C++ 语言这种编写过程是：编写出源代码（源代码是不能直接运行的）然后编译链接形成可执行二进制程序，然后才能运行；而脚本程序不同，脚本程序编写好后源代码即可直接运行（没有编译链接过程）；
• shell 程序是解释运行的，所谓解释运行就是说当我们执行一个 shell 程序时，shell 解析器会逐行的解释 shell 程序代码，然后一行一行的去运行。（顺序结构）
• CPU 实际只认识二进制代码，根本不认识源代码。脚本程序源代码其实也不是二进制代码，CPU 也不认识，也不能直接执行。只不过脚本程序的编译链接过程不是以脚本程序源代码为单位进行的，而是在脚本运行过程中逐行的解释执行时才去完成脚本程序源代码转成二进制的过程（不一定是编译链接，因为这行脚本程序可能早就编译连接好了，这里我们只是调用它）。

动手写第一个 shell

编辑器与编译器

• shell 程序是文本格式的，只要是文本编辑器都可以。但是因为我们的 shell 是要在 Linux 系统下运行的，所以换行符必须是\n，而 Windows 下的换行符是\r\n，因此 Windows 中的编辑器写的 shell 不能在 Linux 下运行。
• 编译器不涉及，因为 shell 是解释性语言，直接编辑完就可以运行。

shell 程序运行的运行的三种方法

• ./xx.sh，和运行二进制可执行程序方法一样。这样运行 shell 要求 shell 程序必须具有可执行权限。chmod a+x xx.sh 来添加可执行权限。
• source xx.sh，source 是 Linux 的一个命令，这个命令就是用来执行脚本程序的。这样运行不需要脚本具有可执行权限。
• bash xx.sh，bash 是一个脚本程序解释器，本质上是一个可执行程序。这样执行相当于我们执行了 bash 程序，然后把 xx.sh 作为 argv[1] 传给他运行。

hello world 程序和解释

• shell 程序的第一行一般都是以#!/bin/sh开始，这行话的意思就是指定 shell 程序执行时被哪个解释器解释执行。所以我们这里写上/bin/sh意思就是这个shell将来被当前机器中/bin目录下的sh可执行程序执行。可以将第一行写为#!/bin/bash来指定使用bash执行该脚本。
• 脚本中的注释使用#，#开头的行是注释行。如果有多行需要注释，每行前面都要加#。（#就相当于是 C 语言中的//）;
• shell 程序的正文，由很多行 shell 语句构成。

shell 语法

shell 就是把以前命令行中键入执行的命令写成了程序。shell 其实就是为了避免反复的在命令行下手工输入而发明的一种把手工输入步骤记录下来，然后通过执行 shell 脚本程序就能再次复述原来记录的手工输入过程的一种技术。

shell 中的变量定义和引用

• 变量定义和初始化。shell 是弱类型语言（语言中的变量如果有明确的类型则属于强类型语言；变量没有明确类型就是弱类型语言），和 C 语言不同。在 shell 编程中定义变量不需要制定类型，也没有类型这个概念。
• 变量定义时可以初始化，使用=进行初始化赋值。在 shell 中赋值的=两边是不能有空格的。 注意：shell 对语法非常在意，非常严格。很多地方空格都是必须没有或者必须有，而且不能随意有没有空格。
• 变量赋值，变量定义后可以再次赋值，新的赋值会覆盖老的赋值。shell 中并不刻意区分变量的定义和赋值，反正每个变量就是一个符号，这个符号的值就是最后一个给他赋值时的值。
• 变量引用。shell 中引用一个变量必须使用$符号，$符号就是变量解引用符号。

注意：$符号后面跟一个字符串，这个字符串就会被当作变量去解析。如果这个字符串本身没有定义，执行时并不会报错，而是把这个变量解析为空。也就是说在 shell 中没有被定义的变量其实就相当于是一个定义并赋值为空的变量。

注意：变量引用的时候可以$var，也可以${var}。这两种的区别是在某些情况下只能用${var}而不能简单的$var。

shell 中无引用、单引号和双引号的区别

• shell 中使用字符串可以不加双引号，直接使用。而且有空格时也可以，但是缺陷是不能输出"或者其他转义字符。
• shell 中也可以使用单引号来表示字符串，也是直接使用的，不能输出转义字符。
• 单引号中：完全字面替换（不可包含单引号本身）
• 双引号中：
  • $加变量名可以取变量的值
  • 反引号仍表示命令替换
  • \$表示$的字面值（输出$符号）
  • `表示`的字面值
  • \"表示"的字面值
  • \\表示\的字面值

除以上情况之外，在其它字符前面的\无特殊含义，只表示字面值。

单引号会原样输出，双引号可以调用命令：

PATH_A="`pwd`/include"
PATH_B='`pwd`/include'
echo $PATH_A
# /home/a/b/include
echo $PATH_B
# `pwd`/include

shell 中调用 Linux 命令

• 直接执行
• 反引号括起来执行。有时候我们在 shell 中调用 Linux 命令是为了得到这个命令的返回值（结果值），这时候就适合用一对反引号 (键盘上 ESC 按键下面的那个按键，和~在一个按键上) 来调用执行命令。

shell 中的选择分支结构

• shell 的 if 语言用法很多，在此只介绍常用的，其他感兴趣可以自己去学

典型if语言格式：

if [ 表达式 ]; then
  xxx
  yyy
  zzz
else
  xxx
  ddd
  uuu
fi

if 的典型应用

• -f判断文件是否存在，注意[]里面前后都有空格，不能省略

• -d判断目录是否存在

• "str1" = "str2"判断字符串是否相等，注意用一个等号而不是两个

• 判断数字是否相等

  • -eq等于
  • -gt大于
  • -lt小于
  • -ge大于等于
  • -le小于等于

• -z判断字符串是否为空，注意-z判断时如果变量本身没定义也是不成立（也就是说-z 认为没定义不等于为空）

• -o表示逻辑或，连接两个表达式

  • if [ 10 -eq 10 -o ]; then

• && ||表示逻辑与和逻辑或

shell 中的循环结构

for 循环，要求能看懂、能改即可。不要求能够完全不参考写出来。因为毕竟嵌入式并不需要完全重新手写。

while 循环，和 C 语言的循环在逻辑上无差别，要注意很多格式要求，譬如：while 后面的 [] 两边都有空格，[] 后面有分号（如果 do 放在一行的话），i++的写法中有两层括号。

echo 的创建和追加输入文件

• 在 shell 中可以直接使用 echo 指令新建一个文件，并且将一些内容传入这个文件中。创建文件并输入内容的关键就是>。
• 还可以使用 echo 指令配合追加符号>> 向一个已经存在的文件末尾追加输入内容。

shell 中其他值得关注的知识点

case 语句

• shell 中的 case 语句和 C 语言中的 switch case 语句作用一样，格式有差异
• shell 中的 case 语句天生没有 break，也不需要break，和 C 语言中的 switch case 不同。shell 中的 case 默认就是匹配上哪个执行哪个，不会说执行完了还去执行后面的其他 case

调用 shell 程序的传参

• C 语言中可以通过 main 函数的 argc 和 argv 给程序传参
• shell 程序本身也可以在调用时传参给他。在 shell 程序内部使用传参也是使用的一些特定符号来表示的，包括：
  • $#表示调用该 shell 时传参的个数。（$#计数时只考虑真正的参数个数）
  • $0、$1、$2·····则依次表示传参的各个参数

./a.out aa bb cc     

# argc = 4
# argv[0] = ./a.out
# argv[1] 是第一个有效参数····

source a.sh aa bb cc  
# $# = 3
# $0是执行这个 shell 程序的解析程序的名字
# $1是第一个有效参数的值
# $2是第 2 个有效参数的值·····

while 循环和 case 语言和传参结合

• shell 中的 break 关键字和 C 语言中意义相同（都是跳出）但是用法不同。因为 shell 中 case 语句默认不用 break 的，因此在 shell 中 break 只用于循环跳出。所以当 while 中内嵌 case 语句时，case 中的 break 是跳出外层的 while 循环的，不是用来跳出 case 语句的。
• shell 中的$# $1等内置变量的值是可以被改变，被 shift 指令改变。shift 指令有点像左移运算符，把我们给 shell 程序的传参左移了一个移出去了，原来的$2变成了新的$1，原来的$#少了 1 个。

IIC（Inter-Integrated Circuit），也叫 I2C（Inter-IC Communication）总线，是一种串行通信协议，由 Philips 公司在 1980 年代初开发。IIC 总线用于连接微控制器、传感器和其他集成电路，它具有以下特点：

1. 双线制结构简单：由一条数据线（SDA）和一条时钟线（SCL）组成。
2. 多主机并行通信：多个 Master 设备可同时接入同一条 IIC 总线上进行数据交换。
3. 硬件资源占用少：只要两根线就可以连接多个器件。
4. 数据传输速率快：现代 IIC 总线的最高传输速率可达到 400Kbps。
5. 低功耗设计：使用者可以通过软件控制设备进入睡眠模式以减少功耗。

传输协议

写操作

• 主机要发出一个起始信号
• 主机发出一个设备地址用来确定是往那一个芯片写数据，以及写标记（0）
• 从设备回应（用来确定这个设备是香存在，然后就可以传输数据）
• 主设备发送一个字节数据给从设备，并等待回应
• 每传输一字节故据，接收方要有一个回应信号（确定故据是否接受完成），然后再传输下一个故据。
• 数据发送完之后，主机就会发送一个停止信号。

读操作

• 主机要发出一个起始信号
• 主机发出一个设备地址用来确定是往那一个芯片读数据，以及读标记（1）
• 从设备回应（用来确定这个设备是否存在），然后就可以传输数据
• 从设备发送一个字节放据给主设备，并等待回应
• 每传输一字节数据，接收方要有一个回应信号（确定数据是否接受完成），然后再传输下一个放据。
• 数据发送完之后，主芯片就会发送一个停止信号。

状态

空闲状态

• SCL 和 SDA 都为高电平

此时各个器件的输出级场效应管均处在截止状态，即释放总线，由两条信号线各自的上拉电阻把电平拉高。

起始状态

• SCL 为高电平，SDA 由高电平变为低电平

标志着一次数据传输的开始。起始信号是由主控器主动建立的，在建立该信号之前 I2C 总线必须处于空闲状态。

结束状态

• SCL 为高电平，SDA 由低电平变为高电平

数据传输状态

• SCL 高电平期间，SDL 保持稳定
  • SDL 为高电平表示 1，低电平表示 0

在 IIC 总线上传送的每一位数据都有一个时钟脉冲相对应 (或同步控制)，即在 SCL 串行时钟的配合下，数据在 SDA 上从高位向低位依次串行传送每一位的数据。进行数据传送时，在 SCL 呈现高电平期间，SDA 上的电平必须保持稳定，低电平为数据 0，高电平为数据 1。只有在 SCL 为低电平期间，才允许 SDA 上的电平改变状态。下图是 0xaa 在 IIC 总线上有效传输 (有效传输是指第 9 个时钟的高电平期间，从机给主机反馈了一个有效的应答位 0) 的图示

在时序图中，MSB 代表的是 Most Significant Bit（最高位）。它表示二进制数中最左边的一位，也就是最高位。在一个 n 位的二进制数中，最高位的权值为 2^(n-1)。因此，MSB 在时序图中通常用来指示二进制数或数据字的最高位。同理，LSB 代表的是 Least Significant Bit（最低位）。它表示二进制数中最右边的一位，也就是最低位。

应答状态

• SCL 为高电平，SDA 由高电平变为低电平（上图最后的 ACK 标记）

I2C 总线上的所有数据都是以 8 位字节传送的，发送器 (主机) 每发送一个字节，就在第 9 个时钟脉冲期间释放数据线，由从设备反馈一个应答信号。应答信号为低电平时，规定为有效应答位 (ACK 简称应答位)，表示接收器已经成功地接收了该字节；应答信号为高电平时，规定为非应答位 (NACK)，一般表示接收器接收该字节没有成功。对于反馈有效应答位 ACK 的要求是，接收器在第 9 个时钟脉冲之前的低电平期间将 SDA 线拉低，并且确保在该时钟的高电平期间为稳定的低电平。

以下四种情况 IIC 通信过程中会产生非应答位（NACK）：

• 从机正在处理某些实时的操作无法与主机实现 IIC 通信的时候，从机会给主机反馈一个非应答 (NACK)
• 主机发送数据的过程中，从机无法解析发送的数据，从机也会给主机反馈一个非应答位 (NACK)
• 主机发送数据的过程中，从机无法再继续接收数据，从机也会给主机反馈一个非应答位 (NACK)
• 主机从从机中读取数据的过程中，主机不想再接收数据，主机会给从机反馈一个非应答位 (NACK)，注意，这种情况是主机给从机反馈一个非应答位 (NACK)

参考资料

1. IIC总线的原理与Verilog实现 - jgliu - 博客园
2. IIC时序分析 - 夏天师妹 - 博客园

SPI 是一种同步的、全双工的、高速的串行通信总线。

4 线制 SPI 四个信号：

• SCLK：串行时钟信号，由主设备产生，用于同步数据传输。
• CS：片选信号，由主设备产生，用于选择从设备。
• MOSI：主设备输出，从设备输入，用于主设备向从设备传输数据。
• MISO：主设备输入，从设备输出，用于从设备向主设备传输数据。

除了四线式 SPI 总线之外，还有三线式 SPI 总线和双线式 SPI 总线。

• 四线式 SPI 总线，也称为标准 SPI 总线，由 SCLK、MOSI、MISO 和 SS（Slave Select）四个信号线组成。其中，SCLK 是时钟信号线；MOSI 是主设备向从设备发送数据的信号线；MISO 是从设备向主设备发送数据的信号线；SS 是从设备的片选信号线，用于选择要通信的从设备。

• 三线式 SPI 总线将 MOSI 和 MISO 合并为单一的信号线。这种 SPI 总线有一个专门的叫做 MOMI 的信号线，既可以作为主设备向从设备发送数据的信号线，又可以作为从设备向主设备发送数据的信号线。

• 双线式 SPI 总线（也称为 MICROWIRE 或 uWire），由一个串行数据线和一个时钟线组成。在这种 SPI 总线上，没有单独的片选信号线，而是使用一个帧选择控制位来选择相应的从设备。

他们传输速率有差别吗？ 是的，SPI 总线的不同类型之间存在传输速率上的差别。一般情况下，四线式 SPI 总线的传输速度最快，而双线式 SPI 总线的传输速度最慢。但具体的传输速度会受到很多因素的影响，例如工作频率、数据线长度等等。如果要在实际应用中选择合适的 SPI 总线类型，需要考虑诸如这些因素的影响，并根据具体情况进行权衡取舍。 SPI 总线的传输速度快慢与其信号线数量有关。双线式 SPI 总线一共只有两条信号线：一个主设备 (Master) 输出时钟信号 (SCLK)，一个主设备通过该信号线读取从设备 (Slave) 的应答信号。而四线式 SPI 总线除了上述两条信号线外，还有两条用于数据传输的信号线：主设备通过 MOSI 信号线向从设备发送数据，从设备则通过 MISO 信号线将数据返回给主设备。由于四线式 SPI 总线有专门的数据传输信号线，故可以通过同时在这两条信号线上传输数据来实现更高的传输速率，从而比双线式 SPI 总线快一些。

时钟极性和时钟相位

在 SPI 中，主机可以选择时钟极性和时钟相位。在空闲状态期间，CPOL 位设置时钟信号的极性。空闲状态是指传输开始时 CS 为高电平且在向低电平转变的期间，以及传输结束时 CS 为低电平且在向高电平转变的期间。CPHA 位选择时钟相位。根据 CPHA 位的状态，使用时钟上升沿或下降沿来采样和/或移位数据。主机必须根据从机的要求选择时钟极性和时钟相位。根据 CPOL 和 CPHA 位的选择，有四种 SPI 模式可用。表 1 显示了这 4 种 SPI 模式。

CPOL 和 CPHA 可以通过 SPI 的状态寄存器设置。

显示了四种 SPI 模式下的通信示例。在这些示例中，数据显示在 MOSI 和 MISO 线上。传输的开始和结束用绿色虚线表示，采样边沿用橙色虚线表示，移位边沿用蓝色虚线表示。

下图给出了 SPI 模式 1 的时序图。在此模式下，时钟极性为 0，表示时钟信号的空闲状态为低电平。此模式下的时钟相位为 1，表示数据在下降沿采样（由橙色虚线显示），并且数据在时钟信号的上升沿移出（由蓝色虚线显示）。

多从机配置

标准 SPI 模式

在常规模式下，主机需要为每个从机提供单独的片选信号。一旦主机使能（拉低）片选信号，MOSI/MISO 线上的时钟和数据便可用于所选的从机。如果使能多个片选信号，则 MISO 线上的数据会被破坏，因为主机无法识别哪个从机正在传输数据。

从上图可以看出，随着从机数量的增加，来自主机的片选线的数量也增加。这会快速增加主机需要提供的输入和输出数量，并限制可以使用的从机数量。可以使用其他技术来增加常规模式下的从机数量，例如使用多路复用器产生片选信号。

菊花链模式

在菊花链模式下，所有从机的片选信号连接在一起，数据从一个从机传播到下一个从机。在此配置中，所有从机同时接收同一 SPI 时钟。来自主机的数据直接送到第一个从机，该从机将数据提供给下一个从机，依此类推。

使用该方法时，由于数据是从一个从机传播到下一个从机，所以传输数据所需的时钟周期数与菊花链中的从机位置成比例。为使第 3 个从机能够获得数据，需要 24 个时钟脉冲，而常规 SPI 模式下只需 8 个时钟脉冲。下图显示了时钟周期和通过菊花链的数据传播。并非所有 SPI 器件都支持菊花链模式。请参阅产品数据手册以确认菊花链是否可用。

SPI 实现

参考资料

SPI 接口简介 | 亚德诺半导体

SPI 协议 - 杰哥的{运维，编程，调板子}小笔记

也就是内部存储器，主要用来运行程序的，典型的就是 RAM 随机存储器（Random Access Memory），那么随机是什么意思？所谓随机，指的是当存储器中的数据被读取或写入时，所需要的时间与这段信息所在的位置无关（任何位置读写速度一样）。

DRAM（Dynamic Random Access Memory，动态随机存储器）是最为常见的系统内存。我们使用的电脑和手机的运行内存都是 DRAM。DRAM 使用电容存储，DRAM 只能将数据保持很短的时间。为了保持数据，所以必须隔一段时间刷新（refresh）一次，如果存储单元没有被刷新，存储的信息就会丢失。数据的存储，请参考数据存储模型。我们知道，电容中的电荷很容易变化，所以随着时间推移，电容中的电荷数会增加或减少，为了确保数据不会丢失，DRAM 每隔一段时间会给电容刷新（充电或放电）。动态：定时刷新数据

SRAM（Static Random Access Memory，静态随机存储器），它是一种具有静止存取功能的内存，其内部机构比 DRAM 复杂，可以做到不刷新电路即能保存它内部存储的数据。静态：不需要刷新

DDR SDRAM（Double Data Rate SDRAM）：为双信道同步动态随机存取内存，是新一代的 SDRAM 技术。DDR 内存芯片的数据预取宽度（Prefetch）为 2 bit（SDRAM 的两倍）。

DDR2 SDRAM（Double Data Rate Two SDRAM）：为双信道两次同步动态随机存取内存。DDR2 内存 Prefetch 又再度提升至 4 bit（DDR 的两倍）

DDR3 SDRAM（Double Data Rate Three SDRAM）：为双信道三次同步动态随机存取内存。DDR3 内存 Prefetch 提升至 8 bit，即每次会存取 8 bits 为一组的数据。运算频率介于 800MHz -1600MHz 之间。

外存

外部存储器，通常用来存储文件的，一般也叫 ROM（Read-only memory）只读存储器。

CPU 连接内存和外存的连接方式不同。内存需要直接地址访问，所以是通过地址总线&数据总线的总线式访问方式连接的（好处是直接访问，随机访问；坏处是占用 CPU 的地址空间，大小受限）；外存是通过 CPU 的外存接口来连接的（好处是不占用 CPU 的地址空间，坏处是访问速度没有总线式快，访问时序较复杂）

我们平时用的硬盘，SD 卡都属于 ROM，但是他们却可以写入？ROM 严格意义来讲确实是只读的，但是随着储存器的发展，出现了可擦可编程只读存储器（EPROM）、电可擦可编程只读存储器（EEPROM）形式的半导体存储器，以及 flash。他们都是可写的。ROM 就不再单单只表示只读存储器了，一般来说与 RAM 相对，掉电不易失的存储器都被当做 ROM。

ROM

ROM（Read Only Memory）只读存储器，这种存储器（Memory）的内容任何情况下都不会改变，电脑与用户只能读取保存在这里的指令，和使用存储在 ROM 的资料，但不能变更或存入资料。ROM 被存储在一个非易失性芯片上，也就是说，即使在关机之后记忆的内容仍可以被保存，所以这种存储器多用来存储特定功能的程序，如固件。ROM 存储用来启动电脑的程序（如BIOS），电脑引导的时候 BIOS 提供一连串的指令对中央处理器（CPU）等组件进行初始化，在初始化过程中，BIOS 程序初始化并检查RAM。

NorFlash

总线式访问，接到 SROM bank，优点是可以直接总线访问，一般用来启动。

NandFlash

SLC：容量小，价格高，稳定性高

MLC：容量大，价格低，稳定性差，易出坏块

iNand SanDisk 公司出产的 eMMC

moviNand 三星公司出产的 eMMC

oneNAND 三星公司出的一种 Nand，价格贵，用的少

SD 卡（Secure Digital Memory Card）

TF 卡（TransFLash Card, MicroSD）

MMC 卡

eMMC 卡（embeded MMC） 嵌入式的 MMC，可以当成一种芯片，内部做了坏块处理

SATA 硬盘

特点：机械式访问、磁存储原理、SATA 是接口。

当你按下电源开关的那一瞬间，第一行代码如何在芯片上运行起来的呢？嵌入式软件代码需要一定的方式烧录到芯片中才能运行，除了物理刻蚀，无论是通讯端口的传输或者调试端口的烧录，都需要驱动程序的支持。所以说是程序烧录了程序，软件启动了软件。

这就像自己提着自己的鞋带，把自己拎起来。靴子（Boot）,鞋带（Strap），提鞋带（Loader）。这就是Boot Strap Loader的命名来源。通常称BootLoader，中文翻译为自举。

BootLoader是芯片最初运行的代码吗？当然不是，其实每一块芯片在出厂时都在其内部的ROM中，烧录了它最基础的软件。CPU 搬运并运行的第一条代码的默认位置，就在ROM的地址空间。所以一切的起始都在硬件上。

以 X86 架构的鼻祖 8086 芯片为例，按下开关的一瞬间，芯片 Reset 引脚接收到了电平跳变，在一连串电路的作用下，代码段寄存器CS恢复成0XFFFF，指令指针寄存器IP恢复成0X0000，他们组合成 20 位的地址正好等于 ROM 中存放第一条代码的位置。之后取出这里的指令在跳转到别处。

ARM 架构的芯片也是类似的过程，对于 32 位的芯片，通电后，PC指针寄存器复位至零地址，随后从中断向量表表头的 reset 向量处获取下一个跳转的地址。这时候的代码已经以二进制形式存储，处理器可以直接搬到自身缓存中运行。有了这部分代码，就能跳转到存放有更多更复杂的代码的地址。执行硬件自检，基本的初始化操作，提供基础的输入输出支持。之后可以将操作系统从外部的存储空间加载到内部。代码就这样接力式的流转起来。

所以我们把出厂就写在ROM里，负责启动后续用户软件的软件，称为Boot ROM或者ROM Code。现在不一定是用只读存储器（Read Only Memory），但是至少是一块掉电不易失的存储器，现在主要用EEPROM，NOR Flash。我们一般没有权限修改它，但是它也不完全是黑盒，大部分芯片都会有外部启动配置引脚，通常是以拨码快关的形式。对于 PC 机来说，Boot ROM就是我们常说的BIOS，它也有启动配置途径。而且提供了交互界面，用于配置部分功能和选择后续的引导设备。

除了芯片自带的Boot ROM，还需要再给自己实际的应用程序，写一个二次引导代码或者 N 次引导代码，用作操作系统，文件系统加载等等。我们所说的Bootloader时，其实大多数就是这样的二次引导代码。

这些事其实Boot ROM它也能做，但是Boot ROM实现的功能和配置方法不灵活，但是Bootloader是开发人员可以而完全控制的引导代码。

在设计Bootloader时，MCU的引导步骤就开始和嵌入式 Linux 或者 PC 有所不同。这一定程度与芯片架构所采用的的存储方案有关。

先来说MCU，与SOC相比MCU的主要特征是单核和或多核同构的微处理器，单核或多核同构，主频 < 1GHz，没有MMU内存管理单元，只能运行实时操作系统。常见MCU内核：

程序的主要运行介质为NOR Flash，因为和RAM一样有分离的地址线和数据线。并且可以以字节长度精确寻址，所以程序不需要拷贝到RAM中运行的。

以英飞凌家的 TC27x 系列 MCU 为例，上电后的默认取址位置是0x8FFF 8000，这就是他的Boot ROM在NorFlash中的地址。并且这块Boot Rom分为SSW，BSL，TF。

SSW 每次上电必须运行，他会根据写在program flash，PFO地址的前 32byte 中的配置字，来决定SSW执行完的跳转地址。我们可以选择一个合适的跳转地址，比如0x80000020，放上自己写的Bootloader。也可以选择不跳转，运行厂家提供的Bootloader（BSL）。

MCU下的Bootloader主要完成的事情有以下：

• 关闭看门狗，初始化中断和 trap 向量表，进行时钟和外设初始化，让芯片正常运行起来。
• 提供CAN,UART, ETH等用于通讯功能的驱动，能够接收外部数据传输请求。
• 提供FLASH的读写与擦除驱动，设计服务来对通讯端口接收到的更新代码进行校验、存储，以及跳转操作系统或后续应用程序代码。
• 如有必要，还会开发一些基础诊断服务，串口交互程序等等。

那么运行 Linux 的SOC和 PC 的这一过程有何不同呢。还是先看存储方案，运行嵌入式 Linux 的 SoC。一般将它的操作系统，文件系统和他的应用程序放在nand flash中。运行代码前，现将代码搬运到SRAM中，相比MCU多了一道步骤。

对于SOC的Boot ROM 和 PC 的BIOS而言，他们结束运行前的最终任务，是将某些代码从nand flash搬运到SRAM中，其中最重要的内容就是Boot Loader。

而一般SOC的Bootloader，又分为SPL（Secondary Program Loader）和uBOOT两个阶段。SPL的 Secondary 就是相对于BootROM而言，他就像是接力赛中的第二棒选手。SPL会初始化更大空间的外部DRAM，再把uBoot搬运到外部DRAM中去运行。uBoot作为第三棒选手，开始运行它的初始化程序。之后再根据系统环境变量，将 OS 内核搬运到外部DRAM中去运行。OS 再完成根文件系统的加载等等等等。

定时器（Timer），又叫计时器，顾名思义，它的主要功能就是计时。因为 CPU 计时会占用大量资源，而定时器独立于 CPU，专门用来计时。单核 CPU 好比人的大脑，一心不可二用，它只能知道自己当前要干什么。人可以用闹钟来提醒自己某个时间需要做某件事，而 CPU 就需要定时器来完成这样的工作。

当定时器被开启后，里面的计数器就以计数器时钟的频率开始运行，内部的计数值不断增加。例如一个时钟为1MHz的定时器，被开启后每隔1us计数值就会加 1。但计数值不可能无限增加，最大值比如65535。将这个十进制数转为二进制数后应该是一个 16 位的二进制数1111 1111 1111 1111。所以我们需要有一个 16 位大小的存储空间来存储它。那这就是一个 16 位定时器。

功能

定时器可以让 SoC 在执行主程序的同时，可以 (通过定时器) 具有计时功能，到了一定时间 (计时结束) 后，定时器会产生中断提醒 CPU，CPU 会去处理中断并执行定时器中断的 ISR，从而去执行预先设定好的事件。打个比方，定时器就像一个秘书，CPU 就是老板。老板每天都有很多事要做，具体时间安排不想操心，就安排给秘书。秘书每天就是盯着表，到点就提醒老板要做某事。

原理

外设的工作频率是与它所挂载在的外设总线的时钟频率相同的。但工作频率不是时钟频率，工作频率到时钟频率需要进行一次分频。这个可调节的分频值使得定时器的计时更加灵活。这个分频值就是需要设置的第一个参数预分频系数。

$$ 计数器时钟频率 = 工作频率/(预分频系数+1) $$

$$ 定时频率 = 计时器时钟频率/(自动重载值+1) $$

假设定时器时钟频率为1MHz，那定时1ms该如何做？计数 1000 次即可。最大的计数值就是自动重载值，是我们需要设置的第二个参数。定时器被打开后，计数值就增加，一旦达到自动重载值就会出发定时器溢出中断，就实现了定时1ms。

计数模式

• 中心计数：计数器从 0 开始计数到自动装入的值 -1，产生一个计数器溢出事件，0 然后向下计数到 1 并且产生一个计数器溢出事件，然后再从 0 开始重新计数。

• 向上计数：计数器从 0 计数到自动加载值 (TIMx_ARR) ，然后重新从 0 开始计数并且产生一个计数器溢出事件。

• 向下计数：计数器从自动装入的值 (TIMx_ARR) 开始向下计数到 0，然后从自动装入的值重新开始，并产生一个计数器向下溢出事件。