1. 先搞清楚u-boot flash子系统在整个启动链路里扮演什么角色我最早接触u-boot的时候总觉得它就是个引导加载程序——把内核从flash里读出来跳到内存里跑完事。直到有一次调一个量产板子的启动问题发现明明内核镜像没损坏u-boot却总是加载失败折腾了整整两天最后定位到是flash子系统的读操作在某种时序下会偶发超时。从那以后我才意识到u-boot的flash子系统远不只是读个镜像那么简单它实际上是整条启动链路上持久化能力的第一责任人。1.1 开机到进入命令行flash在哪一步登场先把时间线捋一下。芯片上电后首先执行的是固化在芯片内部ROM里的代码这段代码负责做最基本的时钟初始化、DDR初始化然后按照启动引脚的配置从一个预定的启动设备里读取u-boot的SPL如果是带SPL的架构或者完整u-boot镜像到内存。这个启动设备可以是NOR flash、NAND flash、SPI NOR flash、SD卡、eMMC等等。从这一刻开始flash子系统就已经在干活了。SPL阶段通常只做最精简的驱动——够把u-boot主镜像读出来就行。到了u-boot主镜像跑起来之后flash子系统的完整形态才真正展现它要支持命令行的交互操作sf probe、nand read、erase、flinfo这些要支持环境变量env的读写要支持从flash加载内核和设备树还要支持系统升级时的镜像写入。很多人容易忽略的是flash子系统的工作范围不只是启动那一刻。系统运行到命令行交互阶段、执行bootcmd自动启动阶段、以及你在u-boot里手动执行各种flash操作命令的阶段全都归它管。换句话说只要板子没进操作系统所有跟非易失存储打交道的活儿都是flash子系统在扛。1.2 从代码搬运到数据读写flash子系统的边界u-boot的flash子系统本质上是一个分层结构。最上层是命令处理层对应源码里的cmd/目录比如cmd/sf.c是SPI flash命令、cmd/nand.c是NAND命令、cmd/flash.c是传统NOR flash命令。中间层是MTDMemory Technology Device框架层对应drivers/mtd/目录这一层提供了统一的事务抽象——不管底层是什么介质上层都用同样的接口来擦除、读写。最底层才是具体的驱动比如drivers/mtd/spi/spi-nor-core.c、drivers/mtd/nand/raw/下的各类NAND控制器驱动等。这个设计跟Linux内核里的MTD框架是一脉相承的u-boot本身就是从Linux继承了MTD子系统的思想。它的核心价值在于上层代码不需要关心底下是什么flash芯片、什么总线接口只管调用统一的API就行。比如说mtd_read()、mtd_erase()、mtd_write()这些接口既可以用在SPI NOR上也可以用在并行NOR上还可以用在raw NAND上。换flash型号的时候大部分上层逻辑不用动只需要适配底层驱动和配置。这里要特别注意一个边界u-boot里的flash这个词通常特指NOR型flash包括并行NOR和SPI NOR而NAND的代码路径是独立于flash命令存在的。我们在命令行里输入flinfo查看的是NOR flash信息而NAND有自己的命令集nand info、nand read。eMMC又不一样它走的是MMC子系统。所以严格来说u-boot的flash子系统更像是一个以MTD为骨架、分介质各自实现的复合体而不是一个大一统的模块。理解这个结构对后续排查问题非常重要——很多人拿着NOR flash的命令去操作NAND自然就找不到入口。1.3 为什么说flash子系统是持久化的第一责任人持久化这个词放在u-boot的语境下有两个层面的含义。第一层是存储介质本身的持久化。NOR和NAND都是非易失存储断电不丢数据。u-boot的代码、内核镜像、设备树、根文件系统、环境变量全都靠这一点才能在掉电后依然存在。u-boot flash子系统要保证的首先就是对这类介质的正确访问。第二层是系统运行所需数据的持久化。u-boot最典型的例子就是环境变量env。你在u-boot命令行里setenv bootargs ...、saveenv这个env数据必须被写到flash的一个专门区域里下次上电才能生效。env的存储是flash子系统最核心的持久化场景之一它有自己的格式、校验机制CRC32、冗余设计双备份分区、磨损均衡策略尤其是NAND上。如果env存储设计得不好轻则每次开机环境变量丢失重则频繁写坏flash分区导致整板变砖。再往下想内核和设备树的存放也是持久化问题。设备量产之后u-boot要从flash的固定偏移位置读取内核这个位置的地址映射、坏块管理、ECC校验逻辑统统都是flash子系统要负责的。系统升级的时候新的固件要被安全地写入flash分区写入过程中掉电了怎么办写入了一半怎么办这些都是持久化可靠性设计的内容。所以我把flash子系统称作持久化第一责任人一点都不过分。它不只是启动的一环更是整个系统里所有非易失数据管理的基础设施。搞懂了u-boot flash子系统你基本也就搞懂了嵌入式设备从启动到升级的完整数据通路。2. 分层拆解从command到driver数据到底怎么走前面说了flash子系统是一个分层的结构这节我就带大家顺着一条实际的数据流把每一层拆开来看。理解了这条路之后遇到报错你就能很快定位到是哪一层出了问题而不是对着串口log干瞪眼。2.1 命令层用户和flash之间的翻译官u-boot的命令层其实机制很简单每个命令对应一个U_BOOT_CMD宏定义的命令入口里面包含命令名、参数个数范围、帮助信息和一个do_xxx()函数指针。你在命令行输入的东西会被u-boot的命令解析器拆成argv然后分发给对应命令的处理函数。以SPI NOR为例源码里cmd/sf.c定义了sf命令它的子命令包括probe、read、write、erase、protect、update等。我们输入sf probe实际上执行的是do_spi_flash_probe()它做的事情是根据你在环境变量里配置的SPI控制器参数和flash芯片型号去初始化SPI总线然后调用SPI NOR驱动层的探测函数识别出flash的ID、容量、扇区大小等信息填充到一个struct spi_flash结构体里。这里有个很实用的细节sf probe成功之后u-boot会维护一个当前选中的flash设备指针。后续的sf read、sf erase、sf write都默认操作这个设备。所以如果你换了flash芯片或者重新初始化了SPI控制器一定要重新执行sf probe否则后续命令会报no flash device之类的错误。NAND的命令层类似cmd/nand.c里的nand命令提供了device选择NAND控制器、info打印信息、erase、read、write、bad显示坏块、scrub完全擦除等子命令。跟SF命令不太一样的是NAND命令更强调设备选择和坏块管理这是因为NAND介质的特性决定的——后面驱动层部分我会细讲。至于早期的并行NOR flash用的是cmd/flash.c里的flinfo、erase带地址范围参数、protect这些命令。这类flash在现在的消费级设备里见得少了但在一些工控板、通信设备上还很常见。它的核心特点是支持XIPExecute in Place执行可以直接映射到CPU地址空间读操作跟读内存一样但写操作比较麻烦通常需要先擦除再编程。2.2 MTD框架统一的介质抽象从u-boot的角度看MTD框架主要是提供一套统一的数据结构和方法集。核心结构体是struct mtd_info里面包含type设备类型MTD_NORFLASH、MTD_NANDFLASH、MTD_UBI等size设备总大小字节erasesize擦除块大小不同介质差异很大NOR通常是4KB/64KBNAND通常是128KB/256KB要注意这个值是最小擦除单位writesize写操作的最小单位NOR通常是1字节NAND通常是页大小或更小的子页oobsizeNAND独有每个页附加的OOB区域大小方法集-_erase()、-_read()、-_write()、-_lock()、-_unlock()等有了struct mtd_info上层就可以用统一方式操作所有flash设备。比如cmd/mtd.c里提供了一个通用的mtd命令在里面你可以mtd list查看所有注册的MTD设备mtd read/mtd write/mtd erase操作指定设备。这个命令在调试的时候非常好用因为它不区分底层介质——只要驱动正确注册了MTD设备都可以用mtd命令操作。实际开发中我建议你们多关注这个MTD层。很多u-boot的存储相关功能比如后面的U-Boot环境变量保存、U-Boot的U-BI支持、fastboot的flash命令都是直接面向struct mtd_info编程的而不是面向某个具体flash型号。这样上层逻辑可以做到介质无关换flash时只需要保证底层驱动能正确注册MTD设备。2.3 驱动层NOR、NAND、SPI-NOR各自的门道这一层是真正跟硬件打交道的部分也是最容易出现兼容性问题的部分。SPI NOR驱动。现在的drivers/mtd/spi/spi-nor-core.c实现了一套比较完整的SPI NOR芯片支持通过JEDEC ID读取0x9F命令返回的3字节ID来自动识别芯片型号。它维护了一张芯片参数表spi_nor_ids里面有芯片名称、JEDEC ID、大小、扇区大小、四字节地址支持能力等信息。如果你的芯片型号在表里通常sf probe就能直接识别如果不在表里你就需要自己添加条目。添加时要注意几个参数SECT_4K标志是否支持4KB子扇区擦除、SPI_NOR_HAS_TOP_BUF之类的能力标志还有quad_enable函数某些芯片要发特定命令才能开启四线QSPI模式。踩坑点往往是同一系列芯片不同批次会有细微差异比如有的支持4K擦除有的不支持这会导致分区擦除失败。NAND驱动。NAND驱动比NOR复杂一个量级。它要处理的东西包括页读写时序、OOB区域管理、坏块标记、ECC校验硬件ECC或软件ECC、多plane操作、ONFI/JEDEC参数解析等。u-boot里一般把NAND控制器驱动放在drivers/mtd/nand/raw/在nand_scan()过程中会解析ONFI参数从而确定页大小、块大小、OOB大小等关键参数。这里有一个常见的混淆点uboot里看到的nand参数比如nand info打印的页大小必须和你在分区表里、在烧录工具里使用的参数完全一致否则会出现数据错位。如果你用烧录器烧了一个NAND镜像但烧录器的参数配置和u-boot的NAND驱动解析结果不一致等上电后内核去读分区表就很可能会失败。并行NOR驱动。这个相对传统一般直接挂在CPU的memory映射总线上读操作就是普通的总线读写操作需要按照NOR芯片的编程时序来。QNX、VxWorks老项目里这种场景很多。u-boot里它通过CONFIG_FLASH_CFI_DRIVER等配置项来使能CFICommon Flash Interface查询机制CFI允许软件通过查询芯片内部的信息表来获得容量、扇区布局等参数。这种flash的调试重点是地址映射和写保护——很多芯片默认是写保护的需要在初始化前序里先解锁否则erase会静默失败。2.4 顺着一条命令走一遍erase到nor flash的完整链路光说结构太抽象我拿一个实际例子把整条链路串起来。假设我在u-boot命令行输入sf erase 0x100000 0x20000这条命令的意思是在当前SPI NOR flash的偏移0x100000处擦除0x20000字节的区域。它的完整调用链是这样的cmd/sf.c中的do_spi_flash_erase()解析参数得到偏移和长度调用spi_flash_erase()老接口或直接走MTD接口mtd_erase()MTD层会检查参数合法性偏移和长度是否按擦除块大小对齐比如4KB扇区偏移必须是0x1000的整数倍、是否超出设备范围然后调用驱动层的-_erase()函数SPI NOR驱动层根据当前地址发写使能命令0x06WREN然后发扇区擦除命令0x204KB扇区擦除或0xD864KB块擦除带上目标地址然后轮询状态寄存器等待WIP位清零如果芯片支持四字节地址模式且当前地址超过16MB驱动还需要先切换地址模式如果是在QSPI模式下还需要切换协议完成后MTD层把擦除结果返回给命令层命令层打印SF: 131072 bytes 0x100000 Erased: OK。这条链路上任何一环出问题表现都不一样命令层参数解析问题会直接报usageMTD层对齐检查不过会报Erase not aligned驱动层状态寄存器轮询超时会报erase timed out如果SPI总线时序不对或者CS片选控制有误可能连ID都读不到直接卡在sf probe阶段。排查的时候从log往上回溯就能很快定位是哪一层的事。3. 真正要用起来配置、分区和env持久化的那些事理解了分层结构接下来就是实战了。一个flash子系统跑起来需要配置一堆宏开关设计好分区表还要想清楚env存在哪里。这一节我把实际操作中必须面对的几件事逐一说清楚。3.1 让子系统先跑起来哪些CONFIG是必须打开的u-boot的配置体系对新手来说非常劝退——编译开关几千个不知道哪些必须开。我列一份最小清单按优先级排基础存储框架CONFIG_MTDMTD框架总开关不开的话下面一切免谈CONFIG_MTD_DEVICE允许注册MTD设备某些版本用CONFIG_MTD自动带出CONFIG_CMD_MTD提供mtd命令强烈建议开启调试神器CONFIG_MTD_PARTITIONS支持分区概念CONFIG_CMD_MTDPARTS提供mtdparts命令用来查看和设置分区表SPI NOR相关CONFIG_DM_SPISPI总线的驱动模型driver modelCONFIG_DM_SPI_FLASHSPI flash的驱动模型CONFIG_SPI_FLASHSPI flash支持总开关CONFIG_SPI_FLASH_W25Q64之类的具体型号开关或者CONFIG_SPI_FLASH_USE_4BYTE_ADDR这类能力开关大容量flash需要CONFIG_CMD_SF提供sf命令NAND相关CONFIG_CMD_NAND提供nand命令CONFIG_NAND_XXX具体控制器驱动如CONFIG_NAND_S3C24XX、CONFIG_NAND_OMAP_GPMC等按芯片平台选CONFIG_SYS_NAND_BASENAND控制器寄存器基地址CONFIG_SYS_MAX_NAND_DEVICE最大NAND设备数量CONFIG_SYS_NAND_USE_BBT建议开启使用Bad Block Table这能显著加快坏块检查和启动速度env存储相关这块最容易漏存在SPI NOR时CONFIG_ENV_IS_IN_SPI_FLASH配合CONFIG_ENV_SECT_SIZEenv区域大小通常是flash扇区的整数倍、CONFIG_ENV_OFFSETenv起始偏移存在NAND时CONFIG_ENV_IS_IN_NAND配合CONFIG_ENV_SIZE、CONFIG_ENV_OFFSET、CONFIG_ENV_RANGE有些实现会做冗余备份需要CONFIG_ENV_OFFSET_REDUND如果用了UBI来说保存envCONFIG_ENV_IS_IN_UBI这时env保存在UBI卷里可靠性更好NAND上强烈建议这种方案一个非常容易踩的坑CONFIG_ENV_SECT_SIZE和CONFIG_ENV_OFFSET必须和你的flash实际扇区大小、分区布局匹配。很多人只改了分区表没改env偏移结果一saveenv就把内核镜像区域给覆盖了导致下次启动直接死掉。这种问题非常隐蔽因为启动时env加载可能是正常的读的是旧环境的正确数据但一旦保存就出事。3.2 分区表mtdparts的前世今生u-boot的分区体系经历了几个阶段。早期是用CONFIG_MTD_PARTITIONS加上一系列MTDPARTS_DEFAULT宏来静态定义分区现在的主流做法是在环境变量mtdparts里动态定义分区表或者干脆在设备树里定义partition0、partition1这样的子节点配合read-only属性等。mtdparts环境变量的格式是这样的mtdpartsmtd0U-Boot(bootloader)ro,U-Boot-env(env)ro,kernel(linux-kernel),rootfs(rootfs),userdata(userdata)其中mtd0是设备名必须跟驱动注册的MTD设备名对应后面用逗号分隔各个分区每个分区的格式是name(size)或者name(size)ro只读-表示剩余空间归最后一块分区。如果地址布局不是连续的也可以显式指定偏移比如kernel(4M)0x200000这种格式表示从偏移0x200000开始长度4M。实际开发中我强烈建议把mtdparts写到环境变量里然后在bootcmd里配合mtdparts default如果编译时配置了默认分区来使用。这样做的优势是调整分区的时候不需要重新编译u-boot只需要改环境变量。对量产设备来说这个便利性意味着你不用为了调整分区大小就重新烧bootloader。设备树方式的优势则在于一次定义u-boot和内核共用。内核的mtd分区解析逻辑drivers/mtd/parsers/ofpart.c会直接读取设备树里的分区节点如果你在u-boot和内核里分别定义两份分区表那就有两份数据需要同步很容易出现u-boot里能读到的分区内核里不存在这类问题。所以我现在的习惯是能上设备树就用设备树定义分区u-boot这边开启CONFIG_OF_CONTROL并且在启动时解析设备树分区。3.3 env存放策略你选对持久化区域了吗env的存储方案直接决定了现场调试和量产稳定性。我给你梳理一下主流方案各自的脾气。SPI NOR上存env这是最常见的方案。NOR的优点是可靠性高、随机读写友好、几乎没有坏块概念。u-boot在NOR上存env一般是这样在固定偏移写一份env数据数据带CRC校验。启动时读出来校验校验失败就尝试冗余备份如果配置了或者恢复默认env。NOR上env的写入速度比较慢一次全片重写或扇区重写但胜在简单可靠。注意NOR的擦写寿命通常10万次左右如果设备频繁保存env比如每次开机都记录一次开关机计数就要考虑磨损问题——这也是为什么CONFIG_ENV_OFFSET要尽量避开经常变动的区域或者干脆用双备份轮流写。NAND上存envNAND的问题是天然有坏块、需要ECC。u-boot对NAND上的env支持有两种一种是简单的写入固定偏移nandwrite读到坏块就出错另一种是配合U-BI卷保存利用UBI的wear-leveling和坏块管理能力这在可靠性上要强得多。如果你用的是raw NAND且分区里有UBI卷我建议直接上CONFIG_ENV_IS_IN_UBI。它的配置略复杂需要先定义一个UBI卷比如uboot-env然后在u-boot编译时配置好卷名saveenv实际是把env写入那个UBI卷。其他方案比如存eMMC的特定分区CONFIG_ENV_IS_IN_MMC、存FAT文件CONFIG_ENV_IS_IN_FAT等。这些在特定平台上也很常用但如果你在做通用BSP我更推荐前两者。这里有一个我很想强调的坑saveenv前必须确认当前u-boot识别到的flash设备和你环境变量里的偏移一致。有些板卡有两片SPI NOR一片跑系统一片跑备份如果你的sf probe选错了设备saveenv会把env写错地方。这个错误在开发阶段表现往往不明显因为启动时env加载可能恰好也能读到点什么但一旦出现改了env不生效或env随机丢失先查这个。3.4 UBI/UBIFSNAND上更适合的持久化方案提到NAND和持久化就躲不开UBI。如果你要在NAND上存文件系统、存大量日志、做可靠的系统升级直接用raw NAND分区是很折磨人的——坏块管理、磨损均衡、掉电保护全都得自己处理。UBI层帮你把这些事做了大部分。u-boot里启用UBI支持的配置大致是这样CONFIG_CMD_UBI提供ubi命令ubi attach、ubi create、ubi write、ubi read等CONFIG_CMD_UBIFS提供ubifsmount、ubifsload、ubifsls等命令CONFIG_MTD_UBIUBI核心支持CONFIG_RBTREE、CONFIG_LZOUBI压缩支持可选实际用法是先把一个MTD分区attach成UBI设备比如ubi part rootfs假设rootfs分区是UBI卷然后创建卷往卷里烧写数据。在启动的时候bootcmd里就可以ubi part rootfs; ubifsmount ubi0:rootfs; ubifsload ${loadaddr} /boot/zImage这样加载内核。UBI方案带来的好处很实际掉电保护能力好。UBI在写入时有原子性保护配合UBIFS的日志机制系统在升级过程中断电下次启动大概率还能恢复到一个可引导的状态。而如果直接向raw NAND分区写文件系统一次写了一半断电整个分区可能就废了尤其是根文件系统区域。当然UBI也不是银弹它本身有开销UBI头信息、磨损均衡预留块而且如果再叠加一层U-Boot env在UBI卷里env读写路径变长操作延迟会高一些。但综合看在中大容量NAND256MB以上上UBI方案的可靠性优势是碾压性的。4. 实战中一定会踩的坑调试手段与问题排查写了这么多年u-boot我总结出一个经验flash子系统99%的问题都能通过看log定位剩下的那1%是硬件问题。问题的关键是你要会看log、会复现、会对照代码。这一节我把自己常用的排查手段和常见问题清单整理出来可以当成一份速查手册。4.1 从log定位问题u-boot flash相关打印怎么看u-boot的log输出是分级别的LOGL_DEBUG、LOGL_INFO、LOGL_WARNING等。flash子系统相关的打印主要来自几个地方驱动初始化时的探测打印、命令执行后的返回打印、以及printf直接输出的信息流。初始化阶段如果你开了CONFIG_SPL_DISPLAY_PRINT或相关调试宏SPL阶段会打出类似U-Boot SPL 2023.04 ...的信息。进入u-boot主镜像后SPI NOR驱动的spi_nor_scan()通常不主动打印太多只有sf probe命令成功后才显示类似SPI-NOR: device id 0xef4019 SF: Detected w25q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB这几行信息很关键它们告诉你设备ID识别到了、容量大小正确。如果设备ID和实际芯片不符说明你芯片的JEDEC ID没被识别驱动用了兼容参数后续可能能读但写会出问题。如果直接报SF: unrecognized JEDEC id bytes: xx, xx, xx说明芯片型号不在驱动表里需要添加条目。NAND初始化阶段nand info会打印Device 0: nand0, sector size 128 KiB Page size 2048 b OOB size 64 b Erase size 131072 b这些参数务必和你的烧录工具参数对比。如果u-boot识别出的页大小和烧录镜像时用的页大小不一致烧进去的镜像读出来就是乱的。命令执行阶段u-boot命令返回值会决定是否打印错误信息。sf erase成功会打印SF: ... Erased: OK失败会打印SF: ... Erased: ERROR。NAND命令类似。nand read成功会返回nand read: device 0 offset 0x0 size 0x... OK。这里我建议每次调试都开着串口完整记录log并且对照代码里的printf去理解。不要怕log多log多反而好。4.2 高频问题清单和对应排查思路我按出现频率排了一下基本就这几类。现象可能原因排查思路sf probe提示No SPI flash foundSPI总线初始化失败、CS引脚配置错误、芯片不在驱动表、供电异常先用示波器量SPI时钟和MOSI/MISO波形检查设备树里SPI控制器的时钟频率是否超规格检查CONFIG_SPI_FLASH_xxx型号开关是否开启sf erase提示Erase timed out地址未对齐、flash芯片被写保护、时序不匹配、操作超大区域超出芯片上限确认地址是否按erase size对齐看protect状态尝试用sf probe后再试小块擦除4KB如果是大容量芯片确认是否触发四字节地址模式nand write提示ECC errorNAND页面参数不匹配、坏块、镜像未按页对齐用nand bad检查坏块列表确认写入地址按页大小对齐确认烧录镜像的ECC策略和u-boot一致启动时env加载失败恢复默认值env偏移错误、env校验失败、env介质初始化失败直接printenv看当前值用env default -a重置检查CONFIG_ENV_OFFSET和分区表是否冲突如果用了双备份检查CONFIG_ENV_OFFSET_REDUNDbootm加载内核时报Bad Magic Number内核镜像没写到正确的偏移、镜像损坏、加载地址不对用sf read或nand read把镜像读出来用md命令查看头部字节是否为0x016f2818ARM64内核头的魔数确认bootcmd里的加载地址和烧写偏移对应升级后启动失败升级过程中掉电导致写了一半、版本不匹配、新镜像校验失败设计升级流程时必须坚持先校验后切换在u-boot里对镜像做crc或sha校验确认有一个可靠的bootable分区或recovery流程4.3 常见的热词场景download failed、no loader specified这类报错的本质你可能会在网上看到类似flash download failed - target dll has been cancelledflash download failed - could not load file这类报错。这些虽然不一定直接出自u-boot但背后暴露的问题往往就出在flash子系统的配合上。这类报错绝大多数来自Keil、IAR、J-Flash这些烧录工具。它们报download failed通常意味着调试器连接到了目标CPU但在执行flash编程算法Flash Programming Algorithm也叫Flash Loader时失败。具体原因包括目标板供电不稳定或目标芯片在编程时被复位调试器与目标板之间有信号完整性问题导致写入flash的校验不通过目标芯片的flash保护位使能了读保护RDP或写保护工具无法解锁这正是你在热词里看到flash timeoutflash完整性 0xaa55 ok1flag这类字样的场景工具里选择的Flash Loader型号和目标芯片型号不匹配对应热词里device: tle9863qxw20: flash bank 0x11000000: no loader specified这种报错——工具不知道自己该用哪个loader来操作这片flash从u-boot开发者的角度这类问题给你的提示是你的板卡在进入u-boot之前flash的初始化是否正常如果烧录工具都连不上flashu-boot里的flash子系统大概率也会在probe阶段失败。排查的时候我会先把烧录和u-boot两者分开验证先用烧录工具单独验证能不能读写flash再用u-boot的sf probe看看能否识别。两边都不行那就是板上硬件或接线问题只有一边不行那就要怀疑配置或参数不匹配。另外热词里出现了cid:spi flash、guiguider spi flash、w25q64 spi flash芯片的读写操作这些说明很多人都在折腾SPI flash特别是W25Q系列。我给个通用建议凡是SPI flash调试第一优先级永远是确认SPI时钟极性/相位别配错第二优先级是确认片选极性。这两个参数只要错一个flash的ID都读不对。5. 我的实操心得几个能直接用的建议最后这部分我不打算做总结就分享几个我在实际项目里验证过的做法和踩过的坑你们可以按需取用。5.1 在u-boot里做flash自检的经验量产设备最怕的就是flash介质老化或出厂不良导致设备在客户现场变成砖。我现在的做法是在u-boot里加一个生产自检模式通过一个gpio状态或者环境变量触发进入u-boot后自动跑一遍flash读写回读校验。具体做法在board_late_init()里判断是否进入自检如果是就对整个存储镜像区做CRC校验读出来重新计算和出厂时写入的CRC值对比对env区域做一次写-读-再写回的回读测试注意不要破坏真实env数据可以在env的冗余备份区域做NAND的话再跑一遍坏块扫描输出坏块分布图这个自检流程对生产测试和售后返修非常有帮助。它能快速区分是flash硬件坏了还是系统软件问题省掉大量异地返修的沟通成本。5.2 升级流程设计时注意的几个点系统升级是flash子系统最关键的写操作场景我强烈建议几个原则永远不要直接用sf erase然后停顿几秒再sf write。中间掉电就砖了。正确做法是先写入一个临时区域完整写入并校验通过后再用一个切换标志env变量或单独flag分区告知u-boot下次启动用新镜像。校验不能省。写入后必须回读比对最好用硬件CRC或SHA256。市面上很多升级后变砖的案例都是因为烧写工具没做校验或者校验不可靠。保留一个永不覆盖的recovery分区。这个分区里放一个最小可启动的u-boot和可能的恢复内核。量产板的recovery分区一旦被覆盖那就只能返厂用烧录器救砖了。5.3 迁移到新flash型号时的checklist最后如果你要把现有板子上的flash换一个型号按这个顺序检查基本不会出大问题确认新flash的JEDEC ID在u-boot驱动表里如果不在自己添加条目测试reset命令是否正常、四字节地址是否支持确认SPI频率、工作电压和原来的板子匹配把sf probe、sf erase、sf write、sf read的完整链接全部测一遍建议在主u-boot和SPL里都测因为SPL的SPI配置可能和主u-boot不一致对比新旧flash的擦除块大小。如果从4KB扇区换成64KB扇区分区表里的对齐方式得跟着改env的CONFIG_ENV_SECT_SIZE也得改NAND的话重点确认页大小、OOB大小、ECC算法是否一致否则原有烧录工具的输出镜像可能不兼容最后一定要做一次掉电测试在擦除、写入、env保存的各个阶段随机掉电确认不能变砖我自己最近一次换flash就是因为在第一步没注意四字节地址模式导致容量超过16MB的部分读写全部异常。而这种情况最坑的点在于sf probe还显示识别成功了但读高地址数据全是0xFF光看log根本找不到问题。后来对照数据手册才发现那款芯片默认是3字节地址模式访问超过16MB地址空间时必须先发BANK_SELECT或切换到四字节模式。这种问题在SPI NOR上非常典型你们如果也在调大容量NOR一定要先确认这条。u-boot flash子系统说白了就是一个数据持久化的管家从启动到升级、从环境变量到内核镜像处处有它的身影。把它内部的分层逻辑理顺、把配置参数搞明白、把调试手段练熟很多看起来玄乎的启动问题其实就是几分钟的事。希望这篇梳理能帮你们少走一些我当年绕过的弯路。