1. 为什么你必须搞懂ZYNQ的启动模式做ZYNQ开发的人不管是跑裸机还是上Linux迟早都会碰到启动配置这道坎。很多新手第一次接触ZYNQ被FSBL、bitstream、U-Boot、image.ub这一串名词砸晕更别提SD卡和QSPI Flash两种启动方式之间的区别了。先说结论SD卡启动适合开发调试阶段因为改代码、换镜像、重编内核都方便一张卡在手说换就换QSPI Flash启动适合生产部署和单板稳定运行的场景因为Flash焊在板子上不怕拔插、不怕松、不怕丢上电就跑。而双启动模式就是让你在一套硬件上同时保留这两种能力——SD卡没了、坏了、或者没插的时候自动从QSPI Flash启动反过来Flash里烧坏了、想快速换固件插上SD卡就能覆盖。这种“冗余灵活”的组合在工业现场、项目交付、样机调试中都是刚需。这篇文章面向的是刚接触ZYNQ的开发者也适合被启动配置折磨过几次、想系统梳理一遍的工程师。我会把从制作启动文件、格式化SD卡、生成boot.bin到烧写QSPI Flash、配置双启动、排查启动失败的全过程讲清楚。有些步骤看起来很基础但每一步背后都有坑我会把踩过的坑一并交代。顺便说明一下“5分钟”指的是你工具链已经装好、工程已经能编译出镜像的前提下从准备SD卡到完成启动验证的纯操作时间。如果你是第一次从零搭环境那还得预留出安装Vivado和PetaLinux的时间那个不在本文讨论范围内。2. ZYNQ启动机制与双启动方案选型2.1 从BootROM到FSBLZYNQ上电后到底发生了什么ZYNQ的启动过程可以简单拆成三个阶段。第一阶段是BootROM。芯片上电后片上固化的BootROM代码会先运行。它会根据硬件引脚的电平状态也就是启动模式引脚决定从哪个外设加载下一级代码。ZYNQ-7000系列的启动模式引脚是MIO[6:2]一共5根对应不同的启动介质SD卡、QSPI Flash、Nor Flash、Nand Flash、JTAG等。板卡设计时通过上下拉电阻来固定这些引脚的默认电平而软件上也可以通过修改寄存器值来临时覆盖启动源但一般用不到。第二阶段是FSBLFirst Stage Boot Loader。BootROM会从SD卡的BOOT.BIN分区、或者QSPI Flash的起始地址处加载FSBL镜像到片上内存OCM运行。FSBL的任务是完成DDR初始化、时钟初始化、PS端的MIO/EMIO配置然后把FPGA bitstream加载进PL侧如果工程里有PL逻辑的话最后跳转到U-Boot或裸机应用程序。第三阶段就是U-Boot或者裸机主程序。Linux场景下U-Boot负责初始化必要的硬件、引导内核裸机场景下FSBL直接引导elf格式的应用程序即可。这个流程是理解所有启动问题的总纲。启动失败、卡死、打印乱码归根结底都是这三个阶段中的某一环出了问题。2.2 为什么推荐SD卡QSPI Flash双启动而不是只用一种我在实际项目里吃过只依赖一种启动介质的亏。有一次交付给客户的一批板子全部只烧了QSPI Flash。后来发现BootROM中QSPI头几个字节有坏块几块板子直接变砖还得用JTAG挨个救回来。从那以后我的所有设计都要求带SD卡启动的冗余能力。SD卡启动的优势是灵活缺点是SD卡本身是机械触点结构在振动环境下容易接触不良而且卡内文件可能被误删、被格式化。QSPI Flash的优势是固定、可靠、上电即用缺点是容量小常见16MB/32MB/64MB、擦写次数有限而且用JTAG烧写比较费时间。双启动的意义不在于同时用两种介质启动而是在于“优先级”和“故障降级”。常见的设计思路是SD卡优先QSPI Flash兜底。SD卡上有一个合法的boot.bin时系统从SD卡启动SD卡上没有合法镜像时BootROM会切换到QSPI Flash启动。两者互不干扰非常适合开发调试和现场维护场景。需要提醒的是这里的“优先级”并不会在BootROM阶段自动切换。后面我会讲清楚如果没有特殊处理BootROM只会按照MIO引脚配置选择单一启动源。真正的双启动逻辑是靠FSBL或U-Boot里的Secondary Boot机制来实现的这块是本文的核心知识点。2.3 双启动逻辑实现思路BootROM只认一个源剩下的交给软件ZYNQ的BootROM启动源选择是硬件引脚决定的它不会自动“看SD卡不行再走QSPI”。如果你把MIO引脚配置成了SD启动BootROM只会在SD卡里找BOOT.BIN找不到就停在那根本不会去看QSPI。那怎么实现双启动有两种常见做法。第一种做法是让QSPI Flash里的Boot.bin作为主启动然后在U-Boot环境变量里配置“如果SD卡上有可用镜像则从SD卡加载kernel/rootfs”。这种方式下FSBL和bitstream始终从Flash加载只有系统镜像内核、设备树、根文件系统可以从SD卡加载。成本低改动小。第二种做法是我比较推荐的自研方案把MIO引脚设为SD启动SD卡里放一个“特殊用途”的BOOT.BIN这个BOOT.BIN就是FSBL但FSBL在代码里检测如果指定标志位存在比如SD卡上存在某个特定文件、或者SD卡分区有特定标记就正常引导Linux如果不存在FSBL直接跳到QSPI Flash地址把QSPI里存的另一个BOOT.BIN再加载一遍。相当于自己实现了一个软件BootROM的角色。这个方案灵活性很高但需要改FSBL源码对新手有一定门槛。对于大部分项目我建议先按第一种“Flash为主、SD为辅”的思路来理解。本文后面讲的具体配置步骤实际上是在帮你把两种介质都准备好至于最终启用哪种优先级由你的启动引脚和U-Boot环境变量决定。3. 工具链准备与启动文件制作3.1 需要准备哪些材料和工具在动手之前先列一份清单免得操作到一半发现缺东西。硬件方面一块ZYNQ开发板本文以ZYNQ-7000系列为例ZC706、ZedBoard、黑金、正点原子的板子都可以对照操作、一张SD卡建议Class 10容量8GB以上、一个USB读卡器最好是支持UHS-I的、一根Micro USB线用于串口调试、以及电源线。另外强烈建议准备一个带电源开关的插线板因为调试启动问题时断电重启是最高频的操作。软件方面Vivado和SDK/Vitis版本不限2019.1以后都可以、PetaLinux如果用Linux系统启动2023.2及以上版本更好、一个串口调试工具MobaXterm、SecureCRT、minicom都行、以及格式化SD卡的工具Windows下用Rufus或者SD Card FormatterLinux下用fdisk mkfs。这里提一句热词里的“PetaLinux 2025.1”目前已经发布了较新的版本功能和编译速度都有优化但核心步骤跟老版本差别不大。如果你用的是ZYNQ-7000系列建议直接用2023.2及以后的版本对老芯片支持得很稳定。3.2 用Vivado硬件工程生成bitstream和硬件描述文件这一步是制作启动文件的地基。打开Vivado加载你已有的ZYNQ工程或者创建一个新的最小系统工程勾选ZYNQ Processing System加上DDR、UART、SDIO外设即可不需要额外的PL逻辑除非你确实需要。综合、实现、生成bitstream。然后通过File Export Hardware导出硬件配置注意勾选“Include bitstream”这样生成的XSA文件里才包含FPGA配置文件。如果你对Vivado的完整流程还不熟悉可以在网上搜“Vivado ZYNQ创建工程搭建最小系统”之类的教程照着做一遍大概半小时能搞定。这一步的结果是生成一个后缀为.xsa的文件后面FSBL和U-Boot的编译都依托于它。3.3 生成FSBL和BOOT.BINPetaLinux一行命令搞定传统做法是打开SDK/Vitis新建FSBL工程、新建U-Boot工程然后在“Create Boot Image”界面里把FSBL.elf、bitstream、U-Boot.elf按顺序加进去生成BOOT.BIN。这个方法步骤多、界面繁琐新手很容易点错。现在强烈推荐用PetaLinux一条命令完成。在PetaLinux工程根目录下执行petalinux-package --boot --fsbl --fpga --u-boot --force -o BOOT.BIN这条命令会自动从当前工程的镜像目录中找FSBL、bitstream和U-Boot帮你打包生成BOOT.BIN。不需要手动拖拽文件也不容易漏步骤。实测下来用这个命令生成的BOOT.BIN在ZedBoard和自定义板卡上都能正常启动。如果你维护的是老工程没有用PetaLinux管理那就老老实实打开Vitis在XSA文件基础上创建FSBL工程然后走Create Boot Image向导。注意三者的顺序不能错FSBL在最前bitstream在中间U-Boot在最后。顺序错了启动时FSBL找不到bitstream会直接卡在DDR初始化阶段打印乱码。3.4 制作U-Boot引导脚本和Linux内核镜像Linux系统要跑起来光有BOOT.BIN是不够的。U-Boot启动后还需要引导脚本boot.scr和内核镜像image.ub。先编译内核镜像。PetaLinux工程里执行petalinux-build -c kernel petalinux-package --image -c kernel --format uImage生成image.ub文件。这个文件本质是把内核、设备树、ramdisk打包成一个镜像U-Boot通过boot.scr里的命令加载它。然后是boot.scr。这个文件是U-Boot脚本的二进制版本。先创建一个文本文件boot.cmd内容大致如下echo Booting from SD/QSPI Dual Boot... fatload mmc 0:1 0x3000000 image.ub bootm 0x3000000解释一下fatload表示从FAT分区读取文件mmc 0:1代表第0个MMC设备的第1个分区0x3000000是加载到DDR的地址bootm启动这个镜像。这个地址在不同DDR配置下可能不同但0x3000000在多数ZYNQ平台是可用的。然后执行命令生成二进制mkimage -c none -A arm -T script -d boot.cmd boot.scr如果没有mkimage工具说明U-Boot工具链没装在PetaLinux安装目录下搜mkimage或者装一下u-boot-tools包。到这里启动Linux所需的三个关键文件就齐了BOOT.BIN、image.ub、boot.scr。接下来就是往SD卡和QSPI Flash里安排它们的位置。4. SD卡启动盘制作与验证4.1 分区格式化BOOT分区必须是FAT32SD卡的准备工作是整个流程中最容易出问题的地方。很多新手反应“SD卡显示没有文件”十有八九是分区格式不对或者分区表类型不对。我的习惯做法是用SD Card Formatter把整张卡格式化一遍选“Overwrite format”文件系统选“FAT32”。这样能把卡上残留的分区表清干净避免之前烧写过Linux系统的分区残留干扰。格式化完成后用fdiskLinux或者磁盘管理器Windows重新分区。ZYNQ的BootROM只认FAT32分区中的BOOT.BIN所以你要做的其实很简单一个FAT32分区就够了后面uEnv、rootfs再单独分也行为了这篇教程的简洁我建议第一版先只分一个FAT32分区把BOOT.BIN、image.ub、boot.scr三个文件直接放在根目录下。如果你是老手习惯把rootfs也放SD卡上那就分两个区第一个分区FAT328GB以内放启动文件第二个分区ext4放rootfs。注意第一个分区必须是主分区且位于SD卡的前面扇区BootROM才能找到。4.2 三步完成SD卡启动盘制作第一步把BOOT.BIN复制到FAT32分区根目录。第二步把image.ub复制进去。第三步把boot.scr复制进去。文件放好后把SD卡插回板子确保启动模式跳线或拨码开关拨到SD启动位置通常是MIO[6:2]的电平组合板卡手册里都有标注常见ZedBoard是跳线JP4/JP5设到SD模式。连接串口线打开串口工具设置波特率1152008N1然后给板子上电。上电瞬间串口工具里应该立刻出现BootROM的加载信息。如果一切正常你会陆续看到U-Boot的版本信息、加载image.ub的日志最后进入Linux系统登录提示符。从写入文件到看到登录提示符熟练操作不超过5分钟。我第一次做的时候卡在分区格式问题上折腾了一个晚上现在回想起来核心就是两点第一BootROM只认FAT32第二BOOT.BIN必须在FAT32分区根目录不在子目录。4.3 通过串口确认当前启动模式是否生效有些板卡支持通过软件读取当前启动模式。在U-Boot命令行里可以输命令检查启动设备。mmc list如果列出SD卡设备说明MMC控制器已经初始化。然后执行printenv bootcmd看U-Boot启动命令是否指向mmc。如果你的镜像没有自动启动会停在U-Boot命令行这时候手动执行fatload mmc 0:1 0x3000000 image.ub bootm 0x3000000手动敲命令能跑起来说明文件没问题是boot.scr的环境变量没配好。如果连fatload都失败那就是SD卡分区或者文件系统的问题了。5. QSPI Flash烧写与验证5.1 QSPI Flash在ZYNQ启动流程中的角色QSPI Flash是板上焊接的Nor Flash芯片通过SPI接口挂在PS端。ZYNQ-7000的BootROM支持直接从QSPI Flash启动从地址0x0读取BOOT.BIN实际是Flash内的映象加载到OCM执行。QSPI Flash的优点是启动速度快、不依赖外部介质、环境适应性强。缺点是容量有限大多数板载Flash是16MB到64MB。Image.ub动辄十几MB再加上BOOT.BIN和boot.scr你需要计算好空间是否够用。5.2 使用U-Boot的update命令在线烧写Flash在线烧写QSPI Flash有几种方式最简单的是通过U-Boot的tftp命令从网络加载镜像烧写。但考虑到很多人没有搭建TFTP服务器我这里介绍一种更通用的做法把烧写镜像放到SD卡上从SD卡启动后在U-Boot命令行里把SD卡上的镜像写入QSPI Flash。首先在SD卡根目录放好待烧写的BOOT.BIN假设命名为BOOT_QSPI.BIN避免跟SD启动的BOOT.BIN混淆。然后从SD卡正常启动进入U-Boot命令行执行sf probe 0 fatload mmc 0:1 0x1000000 BOOT_QSPI.BIN sf erase 0x0 0x400000 sf write 0x1000000 0x0 0x400000逐条解释sf probe 0是初始化QSPI控制器检测Flash型号fatload从SD卡的FAT32分区读取文件到DDR地址0x1000000sf erase擦除Flash从0x0开始、大小4MB的空间——注意擦除大小必须跟文件实际大小匹配我习惯按4MB来擦确保覆盖整个BOOT.BIN所在区域sf write把DDR里的数据写入Flash的0x0地址。烧写完成后可以再用sf read把Flash内容回读到内存然后用md命令对比校验确认写入无误。这一点非常关键我吃过亏——Flash芯片的老化或者擦除不彻底会导致写入后前几个字节错误直接启动失败但烧写过程不会报错。校验这一步能提前拦截这类问题。5.3 从QSPI Flash启动的验证流程烧好Flash后把板卡断电把启动模式跳线切换到QSPI Flash启动模式再上电。由于QSPI里烧的是BOOT.BINBootROM会直接从Flash加载FSBL并启动。串口里应该能看到FSBL完整打印和U-Boot启动信息。如果QSPI Flash里只烧了BOOT.BIN而没有image.ubU-Boot会停在命令行等待输入。这时候你可以手动从SD卡加载image.ub再启动fatload mmc 0:1 0x3000000 image.ub bootm 0x3000000这就是双启动模式的雏形操作系统镜像从SD卡加载而引导程序本身固定在Flash里。很多工业产品就是这么做的。6. 双启动模式配置实操6.1 确定你自己的启动优先级策略配置双启动之前先想清楚一个问题你希望系统优先从哪个介质启动如果你是开发者大概率希望SD卡优先这样每次编译完新内核只要把image.ub复制到SD卡插卡重启就行不用反复擦写Flash。如果你是交付方希望用户拿到板子插电就跑那Flash优先更合适SD卡只是备用维护通道。两种策略的配置方式不同下面分别展开。6.2 Flash优先从Flash启动从SD卡加载系统镜像这种模式下启动引脚的MIO[6:2]应该配置为QSPI Flash启动模式具体电平组合查板卡原理图或手册。BootROM上电后从Flash加载FSBLFSBL加载bitstream然后U-Boot从Flash中继续执行。U-Boot启动后我们要做的是让它从SD卡加载kernel和rootfs。修改U-Boot环境变量setenv bootcmd fatload mmc 0:1 0x3000000 image.ub; bootm 0x3000000 saveenv这样每次上电U-Boot先去SD卡找image.ub找不到就停在命令行等待人工介入。如果SD卡里没有image.ub你可以手动敲命令从Flash加载备用镜像或者进入维护模式。这个方案的优点是BootROM阶段就有双重保障Flash里存BOOT.BINSD卡里存image.ub两个介质任何一个出问题都还有救。缺点是大部分内核和设备树都在SD卡上Flash有点浪费。6.3 SD优先从SD启动失效时自动回退Flash如果要SD卡优先启动引脚配成SD模式SD卡上的BOOT.BIN正常工作。那Flash里的BOOT.BIN什么时候用呢答案是SD卡丢了、SD卡第一个分区没有BOOT.BIN文件、或者BOOT.BIN损坏的时候BootROM不会自动回退到Flash这是由硬件决定的。所以SD优先模式下真正的“回退机制”要靠FSBL源码实现在FSBL的main函数里检测SD卡读取是否正常如果读取失败就直接跳转到QSPI Flash地址重新加载FSBL。具体实现方式是在Vitis中修改FSBL工程添加一段跳转代码在检测到SD卡文件缺失时执行XilOut32和Branch指令。这个方法比较进阶新手可以先不用实现但要明白一个基本原理BootROM只认一个源真正的双启动要靠软件来兜底。6.4 用U-Boot环境变量实现简单且稳定的双启动对于不想改FSBL源码的新手U-Boot环境变量的灵活性可以帮我们实现一个简化版的双启动。做法是启动引脚设为Flash模式Flash里必须烧好BOOT.BIN在U-Boot环境变量里加入一段自动检测逻辑。上电后U-Boot会自动执行bootcmd我们可以把bootcmd设置成“先尝试从SD卡加载镜像加载失败则从Flash加载备用镜像”setenv bootcmd if fatload mmc 0:1 0x3000000 image.ub; then bootm 0x3000000; else sf probe 0; sf read 0x2000000 0x1000000 0x2000000; bootm 0x2000000; fi saveenv这段命令的意思是尝试从SD卡加载image.ub到DDR地址0x3000000成功就直接启动失败就初始化QSPI Flash从Flash的0x1000000偏移地址读出一个备用image.ub到0x2000000然后启动。这种方案的鲁棒性已经不错至少能应对SD卡文件丢失这种最常见故障。实测下来这个方案非常稳定。我目前在用的板卡就是这样配置的平时从SD卡启动新镜像SD卡没插或者文件被误删系统能自动从Flash里读出出厂固件继续运行故障排查时省心不少。7. 常见问题排查与避坑实战7.1 启动失败排查速查表以下是这些年遇到频率最高的启动问题汇总成一张速查表按从硬件到软件的排查顺序排列。遇到问题先对着表格一条条过能解决大部分烦恼。现象可能原因排查思路与解决办法上电后串口完全没有输出启动模式引脚配置错误 / 供电异常 / 串口线接触不良先量电压确认板卡供电正常再查拨码开关或跳线是否在对应启动模式最后确认串口线接的是PS端UART的TX/RX串口有乱码或重复打印特殊字符波特率不匹配 / FSBL镜像损坏 / DDR配置错误确认串口波特率是115200重新生成BOOT.BIN检查FSBL中的DDR型号和参数是否与板卡匹配BootROM打印后卡住无FSBL输出SD卡分区格式不是FAT32 / BOOT.BIN不在根目录用fdisk确认分区表类型是MBR且主分区是FAT32确认BOOT.BIN在根目录不要在子目录U-Boot打印后停在命令行不自动启动bootcmd环境变量为空 / boot.scr文件缺失手动执行fatload和bootm测试设置bootcmd并saveenv确认boot.scr存在且内容正确能加载image.ub但内核启动过程中崩溃设备树与硬件不匹配 / DDR配置错误确认设备树中DDR时序与容量和硬件一致对比上次能正常启动的内核配置QSPI烧写后从Flash启动失败Flash擦除不彻底 / BOOT.BIN在Flash中的地址不对重新擦除整个Flash再烧写确认sf write的目标地址是0x0BOOT.BIN起始地址固定是Flash的0地址7.2 热词里那个报错的解法valid fsbl file is required不少人在Vitis里烧写Flash时遇到过一句报错“a valid fsbl file is required for flash operation”。翻译过来就是Vitis在做Flash操作时需要一个合法的FSBL文件。这个报错的原因很直接你在Vitis的“Program Flash”对话框里没有指定FSBL文件或者指定的FSBL跟当前硬件的DDR配置不匹配。解决方法是在Flash Programming界面里点击“FSBL file”右侧的浏览按钮选择当前工程XSA文件生成的FSBL.elf。如果界面上没有这个选项先去SDK/Vitis里右键FSBL工程选择“Build Project”重新编译生成FSBL.elf。顺带提醒一点如果FSBL的DDR配置跟你板卡实际DDR不一致烧写过程不会报错但烧写后从Flash启动会卡死。这个坑比较隐蔽排查时可以启动一个从SD卡运行但使用相同FSBL的组合来对比验证看FSBL是否能在SD卡模式下跑完初始化。7.3 “SD卡显示没有文件”的真相热词里反复提到“SD卡显示没有文件”这个问题我在好几个项目群都看到过原因五花八门最常见的三个第一Windows下插入SD卡后系统提示需要格式化或者打开后是空的。这通常是因为SD卡之前被Linux的fdisk写过分区表Windows不认。用SD Card Formatter做一次全盘覆盖格式化即可解决。第二在Linux下用df查看发现SD卡挂载点还是旧分区。这多半是因为你把新分区格式化成FAT32后系统还缓存着旧分区信息。执行sync partprobe /dev/sdbsdb是你的SD卡设备名刷新分区表然后重新挂载。第三SD卡物理损坏或接触不良。有的板卡SD卡座是自弹式的卡没推到底、或者弹片卡位不紧也会导致识别不到。换一张卡或者换个卡座测试来排除硬件因素。还有一个小细节如果SD卡容量超过32GBFAT32分区的兼容性在某些板卡的BootROM里会有问题。ZYNQ BootROM对SD卡的支持从老的版本开始就要求FAT32格式和MBR分区表很多新出的SD卡默认是exFAT或GPT格式BootROM根本不识别。所以如果你用的是64GB、128GB的大卡建议先用Rufus之类的工具强制转换成MBRFAT32再分区使用。7.4 双启动配置后启动正常但每次上电都自动进入U-Boot命令行这个现象我遇到得很多。表现为系统正常启动过一次但断电重启后每次都停在U-Boot命令行输入boot命令又能正常启动。这个问题的根源在于U-Boot的环境变量没有保存成功。U-Boot有一块独立的环境变量存储区可能在SD卡的FAT分区、也可能在QSPI Flash中取决于配置。如果你设置了bootcmd但没有执行saveenvU-Boot重启后会使用编译时写死的默认环境变量你设置的bootcmd就丢了。解决办法是执行saveenv然后确认保存成功。如果保存时报错“Saving Environment to SPI Flash failed”说明Flash的环境变量存储区被写保护或者Flash擦除失败需要先检查Flash驱动是否正常。7.5 双启动高级玩法通过拨码切换启动介质如果你手头的板卡支持多组启动模式引脚同一套硬件可以方便地通过拨码开关在SD和Flash之间切换。这种情况下我把双启动的理念做实为“手动双启动”开发时拨到SD模式随意刷交付调试时拨到Flash模式稳定跑。有的板卡启动模式拨码开关只有两位甚至一位但ZYNQ需要5位MIO[6:2]所以你可能需要查原理图确认哪些拨码对应哪些MIO位。即使不清楚每个拨码具体控制哪一位也可以按二进制组合穷举从00000到11111一共32种组合对应32种启动模式把常见的几种记下来即可。实操中我给自己的板卡留了这样一套组合逻辑MIO[6:2]00110是SD启动具体值因板而异MIO[6:2]00010是QSPI启动。其他组合全部不用避免误操作。拨码开关上贴个小标签写明两个位置分别是什么模式方便现场人员使用。8. 我的经验和建议做完这一整套流程有几个心得想分享给刚入门的朋友。第一启动问题80%出在分区和文件系统上而不是FPGA逻辑或代码上。遇到启动异常先不要怀疑你的Vivado工程有Bug先检查SD卡分区表是不是MBR、FAT32是否干净、BOOT.BIN是否在根目录。这三步排除了再往下查FSBL和DDR配置。第二养成“从Flash启动从SD卡加载镜像”的习惯。这个组合在绝大多数项目里都是最优解兼顾了稳定部署和快速迭代。即便你的产品最终不需要双启动也建议在开发阶段按这个思路配置省得后期频繁擦写Flash。第三对ZYNQ启动的理解一定要从BootROM开始而不是从U-Boot开始。很多人在U-Boot阶段调试得风生水起却回答不了“BootROM是怎么找到U-Boot的”这个问题。一旦遇到板子不启动、串口无输出这种最底层故障没有BootROM这个概念就很难定位问题。最后再分享一个小技巧每次修改了SD卡或Flash里的镜像文件做完后务必执行sync命令Linux下或者“安全弹出”操作Windows下确保文件真的写入了物理介质。我自己就曾经在快速拔卡后BOOT.BIN内容不完整导致板卡无法启动排查了整整一下午。最后发现是缓存没落盘重新复制一遍就好了。这个习惯到现在都在坚持。