U-Boot SPI Flash 操作实战：从 sf 命令到数据完整性验证

1. 环境准备与基础概念：为什么是SPI NOR Flash？

如果你刚开始玩嵌入式开发，尤其是涉及到系统引导这块，听到U-Boot和SPI Flash可能会有点发怵。别担心，我刚开始接触的时候也一样，感觉这一堆命令和硬件操作离我们平时写应用代码很远。但实际搞过几次你就会发现，这其实是嵌入式开发里最基础、也最“硬核”的乐趣之一。今天，我就把自己这些年调试SPI NOR Flash的经验，特别是U-Boot里sf命令的那些坑和技巧，掰开揉碎了跟你聊聊。

首先，我们得搞清楚我们在操作什么。SPI NOR Flash，你可以把它想象成你电脑上的硬盘，但它是焊在你开发板上的一个小芯片。它通过SPI（Serial Peripheral Interface）这个简单的四线或更多线的串行接口和主控芯片（比如你的ARM Cortex-A系列处理器）通信。为什么是“NOR”？这涉及到内部的存储结构，你暂时可以简单理解为：NOR Flash的特点是能像内存一样随机读取，并且通常用来存储像U-Boot、Linux内核、设备树（DTB）这种需要CPU直接读取并执行的代码。所以，对它进行可靠的读写和验证，直接关系到你的板子能不能正常启动、系统能不能稳定运行。

那么，U-Boot在这里扮演什么角色呢？U-Boot就是一个强大的引导加载程序，它最早启动，负责初始化硬件，然后加载操作系统。在开发阶段，我们经常需要在U-Boot的命令行界面里，手动去更新Flash里的固件、备份数据或者修复启动问题。这时候，U-Boot内置的sf（SPI Flash）命令集就成了我们最得力的“瑞士军刀”。它不需要你额外写驱动，开箱即用，直接就能对Flash进行探测、擦除、读写。但就像任何强大的工具一样，用对了事半功倍，用错了可能就是一场调试噩梦。接下来，我们就从最基础的探测设备开始，一步步深入。

2. 核心武器：U-Boot sf 命令详解与实战

很多教程一上来就扔给你一堆命令格式，看得人头大。咱们换个方式，我带着你，就像我第一次在真实的板子上操作一样，把每个命令都“摸”一遍。你最好手边有一块支持U-Boot的开发板（比如常见的i.MX6ULL、RK3288、全志H3等平台），跟着我一起敲命令，感受会更深刻。

2.1 第一步：sf probe – 和Flash芯片“握手”

想象一下，你要操作一个外设，总得先告诉系统：“嘿，我这儿有个设备，你认识一下。”sf probe干的就是这个事儿。它的作用是初始化并探测连接到SPI总线上的Flash芯片。

在U-Boot命令行里，你直接输入sf probe并回车：

=> sf probe

如果一切正常，你会看到类似这样的输出：

SF: Detected XXXXXX with page size XX Bytes, erase size XX KiB, total XX MiB

这行信息非常宝贵！它告诉了你几个关键参数：

• 检测到的芯片型号：比如W25Q128JV。
• 页大小（Page Size）：通常是256字节或更大。这是写操作的最小单位，但注意，sf write命令内部会处理，你不用手动对齐页。
• 擦除块大小（Erase Size）：比如4 KiB或64 KiB。这是擦除操作的最小单位，这个必须牢记，后面会重点讲。
• 总容量：比如16 MiB。

有时候，你的板子上可能有多个SPI Flash，或者Flash接在非默认的SPI总线和片选（CS）上。这时你可以指定参数：

=> sf probe 0:0 50000000

这里0:0表示bus 0, cs 0（即第0个SPI总线的第0个片选），50000000是SPI时钟频率（50MHz）。模式（mode）参数通常指SPI的工作模式（如0,1,2,3），大多数情况下U-Boot能自动识别，除非你有特殊需求。

我踩过的坑：有一次在一个定制板上，sf probe总是失败，返回“No SPI flash selected”。折腾了半天才发现，是板级设备树（DTS）里SPI Flash的兼容性字符串（compatible）没写对，U-Boot的驱动没匹配上。所以，如果sf probe失败，先别怀疑命令，检查一下硬件连接和U-Boot的配置（CONFIG_CMD_SF、CONFIG_SPI_FLASH等宏是否开启）以及设备树支持。

2.2 第二步：sf erase – 给Flash“格式化”

Flash有个很重要的特性：在写入数据之前，对应的存储区域必须处于已擦除状态。擦除后的位是‘1’（所有比特位为高电平）。你可以把Flash想象成一张用铅笔（写）和橡皮（擦）写字的纸。新纸是空白的（全1）。你想写字（写0），直接写就行。但如果你想修改已经写了字的地方，你必须先用橡皮把那一整块擦干净（恢复成全1），才能重新写。sf erase就是这块橡皮。

命令格式是：

sf erase <offset> <len>

• offset：要擦除的起始地址，相对于Flash的0地址。默认是十六进制，不加0x前缀也行。
• len：要擦除的长度。关键点来了：这个长度必须是芯片擦除块大小的整数倍！

比如，你的芯片擦除块大小是4KB（0x1000）。你想擦除从0x5000地址开始的8KB区域：

=> sf erase 5000 2000

这是合法的，因为0x2000（8KB）正好是0x1000（4KB）的两倍。

但如果你这么写：

=> sf erase 5000 3000

U-Boot很可能会报错：ERROR: erase length not multiple of erase block size。因为它试图擦除12KB，不是4KB的整数倍。

这里有个超级实用的小技巧：使用+符号。像这样：

=> sf erase 5000 +3000

在len前面加一个+号，U-Boot会自动帮你把长度向上对齐到最近的擦除块边界。比如上面这个命令，它会实际擦除从0x5000开始到0x8000（因为0x5000+0x3000=0x8000，但需要对齐到4KB块，所以会计算需要擦除的块数）的整个区域，非常省心。我强烈建议你总是使用+len的形式，避免因计算失误导致的擦除失败。

2.3 第三步：sf write – 把数据“刻”进Flash

擦干净了“画布”，现在可以“作画”了。sf write命令将内存中的数据写入Flash。

命令格式：

sf write <内存地址> <Flash偏移地址> <长度>

这里我结合一个完整例子讲，你会更明白。假设我们想向Flash的0x10000地址写入1KB（0x400）的测试数据。

第一步，先在内存里准备数据。U-Boot提供了mw（memory write）命令来填充内存。我们往内存地址0x20000000开始处，连续写入0x400个字节的0xAA（10101010b，一个很常用的测试模式）：

=> mw.b 20000000 AA 400

mw.b表示按字节（byte）写入。现在，从0x20000000到0x20000400的这1KB内存，每个字节都是0xAA。

第二步，执行写入。确保你已经擦除了Flash的对应区域（比如sf erase 10000 +400）：

=> sf write 20000000 10000 400

如果成功，会显示SF: 1024 bytes @ 0x10000 Written: OK。

一个至关重要的细节：sf write命令内部会自动处理页编程（Page Program）的边界。也就是说，即使你写入的数据长度跨越了Flash的页边界（比如页大小256字节，你写300字节），命令也会帮你拆分成多次页写操作。你不需要手动拆分。但是，它不保证“位翻转”。什么意思？Flash只能把‘1’变成‘0’，不能把‘0’变回‘1’。如果你往一个未擦除（某位是0）的位置写1，是无效的。这就是为什么必须先擦除。

2.4 第四步：sf read – 把数据从Flash“取”回来

写进去了，我们怎么知道写对了呢？这就需要读出来对比。sf read命令是sf write的逆过程。

命令格式：

sf read <内存地址> <Flash偏移地址> <长度>

继续上面的例子，我们把刚刚写入Flash 0x10000地址的1KB数据，读到内存的另一个地方，比如0x21000000：

=> sf read 21000000 10000 400

成功后会显示SF: 1024 bytes @ 0x10000 Read: OK。现在，内存0x21000000处也有了1KB的数据。

2.5 第五步：数据完整性验证 – 眼见为实

读出来就完事了吗？当然不是！嵌入式开发里，“以为对了”和“真的对了”之间隔着无数个熬夜调试的晚上。我们必须严谨地验证。

U-Boot提供了cmp（compare）命令来比较两块内存区域的内容：

cmp <地址1> <地址2> <长度>

它会比较从地址1和地址2开始的、指定长度的内存内容。如果完全一致，没有任何输出（在Unix哲学里，没有消息就是好消息）。如果不一致，它会打印出第一个不匹配的地址。

我们来验证刚才写入和读出的数据：

=> cmp 20000000 21000000 400

如果命令行直接返回新的提示符=>，恭喜你，数据完全一致，读写操作成功！

如果不一致，它会显示类似：

word at 0x20000000 (0xaaaaaaaa) != word at 0x21000000 (0xaaaaaaab) Total of 1 word(s) were different

这就说明出了问题。可能的原因有：1) Flash物理损坏；2) 写入前未正确擦除；3) 电源不稳定导致写入过程出错；4) 内存地址无效或冲突。

更直观的验证方法：md命令除了cmp，你还可以用md（memory display）命令直接查看内存内容，人工比对。

=> md.b 20000000 10 20000000: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ => md.b 21000000 10 21000000: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................

md.b表示按字节显示，后面跟起始地址和要显示的字节数（十六进制）。这样你能亲眼看到数据。

3. 高级技巧与避坑指南

掌握了基本流程，我们来看看一些能让你效率倍增的高级操作和那些容易栽跟头的坑。

3.1 一键更新：sf update 的妙用

你有没有觉得“先擦除、再写入”这个流程有点繁琐？U-Boot早就想到了。sf update命令将擦除和写入合二为一，并且它非常智能：它只会擦除需要写入的区域，并且会先比较Flash中现有数据和要写入的数据，只有内容不同时才会执行擦写。这大大加快了更新速度，也减少了Flash的磨损。

命令格式和sf write一样：

sf update <内存地址> <Flash偏移地址> <长度>

比如，你要更新内核镜像：

=> tftp 0x20000000 uImage # 先从网络加载内核到内存 => sf update 20000000 80000 ${filesize} # 将内存中的数据更新到Flash的0x80000位置

这里的${filesize}是一个U-Boot环境变量，tftp命令执行后，它会自动保存下载文件的大小，非常方便。sf update会自己计算需要擦除哪些块，然后写入变化的数据。

3.2 地址与长度的“进制陷阱”

这是新手，甚至是有经验的开发者都容易犯错的地方！U-Boot的sf命令，以及mw、md、cmp等命令，它们的地址和长度参数，默认都解释为十六进制数，即使你没有加0x前缀。

看这个命令：

=> sf erase 1000 2000

你以为擦除了从地址4096（十进制1000）开始，8192（十进制2000）字节的区域吗？错了！U-Boot把它解释为：擦除从地址0x1000（4096）开始，长度为0x2000（8192）字节的区域。和你预期的完全不一样！

如果你想使用十进制，必须明确指出来。U-Boot使用#符号表示后面的数字是十进制。

=> sf erase 1000 2000 # 十六进制：擦除 0x1000~0x3000 => sf erase 1000 0x2000 # 十六进制：同上，显式使用0x前缀 => sf erase 1000 #2000 # 十进制：擦除地址0x1000开始的2000个字节（注意长度不是块对齐的，会报错）

我个人的习惯是：对于所有内存/Flash操作，一律使用十六进制，并且养成加0x前缀的习惯。比如0x10000000,0x2000。这样意图最清晰，不会产生歧义。

3.3 内存地址的有效性：别让系统“崩溃”

sf read/write命令中的<内存地址>，必须是一个有效的、可访问的物理内存地址。如果你指向了一个没有映射内存的地址，或者指向了正在运行的关键代码区域，U-Boot会直接触发异常（Data Abort），导致系统挂起或重启。

怎么知道哪些地址是安全的呢？

1. 查看板级信息：bdinfo命令可以显示板子的内存映射信息，告诉你内存的起始地址和大小。比如，系统内存从0x80000000开始，大小1GB，那么0x80000000到0xC0000000这个范围一般是安全的。
2. 使用高位地址：通常，U-Boot自身会加载在内存较低地址（如0x10000000附近），而内核会被加载到更高地址（如0x20008000）。为了安全起见，我习惯使用一个比较高的、空闲的地址作为数据缓冲区，比如0x21000000。你可以通过md命令先看一眼这个地址附近的内容，如果全是0或者ff，大概率是空闲的。
3. 避开保留区域：有些内存区域可能被预留用作GPU、VPU或其他外设的缓冲区，这些信息需要查阅芯片手册或板级文档。

3.4 实战案例：备份与恢复出厂固件

假设你的设备Flash里，在0x00000到0x60000存放U-Boot，0x60000到0x150000存放内核，0x150000之后是根文件系统。现在你想完整备份整个Flash的内容。

第一步，探测Flash并确认容量。

=> sf probe SF: Detected W25Q128JV with page size 256 Bytes, erase size 64 KiB, total 16 MiB

总容量16MB，即0x1000000字节。

第二步，将整个Flash读取到内存。我们需要找一个足够大的内存区域。16MB数据，我们需要一个连续的16MB空闲内存。假设从0x21000000开始有足够内存。

=> sf read 0x21000000 0x0 0x1000000

这个过程可能需要几秒到十几秒，取决于SPI速度和芯片性能。

第三步，将内存中的数据通过网络（TFTP）保存到开发主机。

=> tftp 0x21000000 backup.bin 0x1000000

这样，你就得到了一个完整的Flash镜像备份backup.bin。当Flash内容意外损坏时，你可以用tftp将它下载回内存，再用sf update写回Flash，实现恢复。

4. 深入原理：理解sf命令背后的硬件操作

知道了“怎么用”，我们稍微深入一点，看看“为什么”，这样遇到奇怪问题时你才能有的放矢。

4.1 SPI Flash的物理约束：页、扇区、块

不同的Flash芯片，其内部架构稍有不同，但大体都有这些概念：

• 页（Page）：写操作的最小单位。典型大小是256字节或512字节。sf write命令内部会处理跨页写入。你不能只写一个字节，硬件要求你必须以页为单位发送数据，但起始地址可以在页内任意位置。
• 扇区（Sector）/块（Block）：擦除操作的最小单位。常见的有4KB（小扇区）和64KB（大块/块）。sf erase命令必须对齐到这个边界。擦除操作很慢，通常需要几十到几百毫秒。
• 全片擦除（Chip Erase）：有些芯片支持一个命令擦除整个芯片，但U-Boot的sf erase命令通常不直接暴露这个，因为它太危险了。

当你执行sf write时，U-Boot的驱动会：

1. 检查目标地址是否已擦除（通过读取并比较？不，通常不检查，依赖用户先擦除）。
2. 启用写使能（Write Enable）。
3. 发送“页编程”命令和地址、数据。
4. 等待编程完成（轮询状态寄存器）。
5. 如果数据跨页，重复步骤3-4。

4.2 数据校验的更多手段：CRC与Hash

cmp命令是逐字节比较，很可靠。但对于大文件（比如几MB的内核），我们有时还想快速验证数据的整体一致性。U-Boot支持计算CRC32和SHA256哈希值。

计算内存中数据的CRC32：

=> crc32 0x20000000 0x400 crc32 for 20000000 ... 200003ff ==> 1a2b3c4d

计算Flash中数据的CRC32（需要先读到内存）：

=> sf read 0x21000000 0x10000 0x400 => crc32 0x21000000 0x400 crc32 for 21000000 ... 210003ff ==> 1a2b3c4d

比较两次计算的CRC32值是否一致。对于更大的镜像，计算SHA256更可靠：

=> sha256sum 0x20000000 0x400 sha256 for 20000000 ... 200003ff ==> ae3b...（很长一串哈希值）

4.3 性能优化：时钟频率与双线/四线模式

在sf probe时，我们可以指定时钟频率（如50000000表示50MHz）。在保证稳定的前提下，使用芯片支持的最高频率可以显著提升读写速度。此外，一些高性能的SPI Flash支持双线（Dual SPI）或四线（Quad SPI）模式，在时钟的上升沿和下降沿都传输数据，或者同时用4根数据线传输，带宽成倍增加。这需要在sf probe时指定正确的mode参数，并且硬件连接要支持（多接了几根数据线IO0~IO3）。如果你的板子和芯片支持QSPI，一定要用起来，更新一个几十MB的根文件系统镜像时，时间差异是巨大的。

最后，唠叨一句我自己的体会：玩转U-Boot的Flash操作，三分在命令，七分在细心。每次操作前，心里默念“地址对不对？长度对齐没？内存够不够？擦过了没？”。养成用+len擦除、用sf update更新、操作前后用md看一眼的好习惯，能帮你省下无数个抓耳挠腮的调试夜晚。嵌入式开发就是这样，和硬件打交道，容不得半点模糊，每一步的确定性和可验证性，才是项目稳步推进的基石。好了，关于U-Boot和SPI Flash的操作，今天就先聊这么多，希望这些实实在在的命令和踩过的坑，能让你下次面对Flash时，心里更有底。