企业官网建设流程全解析

做嵌入式的朋友应该都有印象，以前玩 STM32F1、F4 的时候，启动这件事特别简单：改一下 BOOT0/BOOT1 引脚，固件从 Flash 或者系统存储区起来就完事了。但到了 STM32N6 这一代，情况完全变了。这颗 800MHz、带 NPU、能跑 AI 推理的芯片，启动路径已经从“点灯”级别上升到了“系统部署”级别。你要让它从 eMMC 跑起来，面前至少站着四个必须搞定的角色：BootROM、FSBL、U-Boot、TrustZone。

偏偏这几个环节环环相扣，任何一个地方出问题，现象都可能一模一样：串口什么输出都没有，或者说输出停在半路，然后板子就躺平了。而且因为涉及 eMMC 协议、启动镜像格式、DDR 初始化顺序、安全属性配置，排查难度比以往任何 MCU 项目都高。这篇文章就把我这段时间在 STM32N6 上做 eMMC 启动的完整过程拆开来讲，包括为什么这么设计、每一步在干什么、哪些配置最关键、哪些坑我替你先踩过了。适合正在接触 STM32N6、需要把产品从“开发板能跑”推进到“量产镜像能启动”的工程师参考。

1. 为什么这次要从 eMMC 启动：需求与方案选型

先说一个核心问题：STM32N6 内部不是没有 Flash，但它的定位决定了你不太可能靠片内 Flash 做完整产品。这颗芯片主打的是视觉、语音、微型 AI 推理这些场景，模型文件、图像缓存、日志数据动辄几十 MB 甚至上百 MB。片内 Flash 容量有限，外部扩展成了刚需。而外部存储的选项无非就那几类：SPI NOR Flash、SPI NAND Flash、SD 卡、eMMC。

SPI NOR Flash 读取快、接口简单，但容量上到 64MB/128MB 之后性价比很难看，而且 STM32N6 这类芯片跑 AI 模型时对代码的 XIP 执行需求其实没这么强，更多是把镜像和数据先加载到外部 DDR 里再跑。SPI NAND 容量上去了，但坏块管理、页映射逻辑要自己做，启动流程里还要在 FSBL 阶段实现一套 NAND 驱动，调试周期拉长很多。SD 卡拆机方便、替换容易，可是对量产产品来说，卡座可靠性、接触氧化、插拔误操作都是隐患，很难作为工业设备的默认存储方案。

所以 eMMC 几乎是水到渠成的选择：单芯片封装，不需要额外做 Flash 控制器，主控自己处理磨损均衡和坏块管理，容量从 4GB 到 128GB 随便选，基本不用管后期生命周期衰减问题。而且 eMMC 内置了 Boot Partition，天生就是为“承载启动镜像”设计的。把 FSBL、U-Boot、内核、根文件系统按固定偏移放进去，启动链路非常清晰。

1.1 eMMC 协议和接口，快速过一遍

第一次用 eMMC 的朋友最容易把它当成“一块大号的 NAND Flash”来操作，只要会读写扇区就行了。实际上 eMMC 是一颗完整的、符合 JEDEC eMMC 规范的小系统，里面有自己的控制器、Flash 介质和接口逻辑。你看到的引脚并不多，核心就三类：

• CLK：时钟信号，最高工作频率决定了数据吞吐的上限
• CMD：双向命令线，主机发命令、设备回响应都走这一根
• DAT0~DAT7：8 根数据线，可以配置成 1-bit、4-bit、8-bit 模式

我们常说的 eMMC 5.1，指的就是 JEDEC 的 eMMC 规范版本，它定义了 HS400、HS200、DDR52 这些传输模式。比如 HS400 模式是 8-bit 总线 + DDR 双沿采样，接口时钟最高到 200MHz，理论带宽能达到 400MB/s。STM32N6 上的 eMMC 控制器一般会支持 HS200 或 HS400，但实际能跑到哪个档位，取决于板级走线质量和芯片封装。这点后面调试部分还会专门说。

153-ball eMMC 引脚定义是大家在画原理图时最常查的东西。封装虽然引脚多，但大量引脚是电源、地和 NC，真正需要连到 SoC 的通常是 CLK、CMD、DAT0~7、RST_n 和 DS 信号。DS 是 HS400 模式下的数据选通信号，如果只跑 HS200 可以悬空。画板时特别注意 CLK 和 DS 要走差分或阻抗受控走线，CMD 和 DAT 需要上拉，上拉电阻典型值在 10kΩ 到 47kΩ 之间，具体参考 SoC 数据手册。这里有个容易踩的坑：很多人把 CMD 和 DAT 的上拉漏了，结果初始化时设备能识别，但高速传输阶段随机失败，一开始完全摸不着头脑。

1.2 eMMC 到了 STM32N6 上解决的实际问题

STM32N6 的启动链路里，eMMC 其实承担了两层职责。第一层是 BootROM 的阶段：芯片上电后，BootROM 会根据启动引脚或选项字节的配置，尝试从某个外设读取第一级启动镜像。如果选择 eMMC 启动，BootROM 会通过内置的 MMC 控制器去访问 eMMC 的 Boot Partition 1，在固定偏移处读取 FSBL。

第二层是系统运行阶段的存储职责：U-Boot 从 eMMC 的 User Data Area 读取内核镜像和设备树，根文件系统也放在 User Data Area 里。这样整个系统的代码、数据、模型、日志分布就有了明确规划，既满足启动对“确定性地址”的要求，也满足产品对“大容量、可量产、可升级”的要求。

所以不要一上来就想着“我随便把二进制写进 eMMC 就能启动”，BootROM 可没这么通情达理。它认的是一种带头部信息的镜像格式，头部里包含加载地址、镜像长度、校验信息，有的还要签名。这就引出了 FSBL 存在的真正意义：它是 BootROM 和系统主镜像之间的翻译官和搬运工。

2. 从 BootROM 到 FSBL 再到 U-Boot：一条完整的启动链

顺着启动流程走一遍，你就能理解为什么 STM32N6 需要这么多层引导程序。简单说，BootROM 是芯片出厂固化的、无法修改的一段代码，它能力有限，不能把所有外设驱动都放进去，也不会去初始化外部 DDR。它只做一件确定的事：根据启动配置，从一个确定的介质读取一个确定偏移处的、确定格式的镜像，然后校验头部信息，最后跳转执行。

所以 BootROM 的代码量必须控制得很小，它不会帮你初始化 PLL、不会帮你配置 DDR 时序、更不会帮你处理 eMMC 的 EXT_CSD 设置。这些工作，全部落在 FSBL 身上。

2.1 BootROM 是怎么把控制权交出去的

以 eMMC 启动路径为例，STM32N6 上电后 BootROM 先配置基础的时钟和内部 SRAM，然后根据 boot pins 或者 option bytes 里写的启动介质编号，去访问对应的外设。对于 eMMC，BootROM 会做几件事：

• 初始化 MMC 控制器，发送 CMD1 让设备进入 Ready 状态
• 读取 CID/CSD 寄存器，拿到设备容量和分区信息
• 发送 CMD6，把访问窗口切到 Boot Partition 1
• 在块地址 0（也就是第一个块）读取 FSBL 镜像的前若干字节
• 解析镜像头部，确认加载地址、长度、校验值和签名

校验通过后，BootROM 把后续数据读入 SRAM 或 DDR（取决于 FSBL 镜像是否声明了需要 DDR 初始化），然后跳转到 FSBL 的入口地址。这里有个关键点：如果 FSBL 镜像长度超过了 BootROM 能缓存的内部 SRAM 容量，BootROM 就必须依赖 FSBL 自身来完成 DDR 初始化并加载剩余部分。所以 FSBL 的第一段代码通常要放在 SRAM 里运行，同时包含一个非常精简的 DDR 初始化序列，这样才能继续读取完整镜像到 DDR 中。

我见过不少朋友在第一次接触这个流程时有个误解，以为 BootROM 会把整个 U-Boot 都读起来。不是的，BootROM 只负责拉起 FSBL，U-Boot 是 FSBL 之后的事情。这个分层思想跟 PC 的 BIOS → Bootloader → OS 是一个道理，每一层只做有限的事，再交给下一层。

2.2 FSBL：贴身管家式的“初始化+搬运”

FSBL 全称 First Stage Boot Loader，它做的事情远不止“搬运镜像”。从实际调试经验来看，FSBL 至少要完成四类初始化，顺序错了都容易出问题：

• 时钟树初始化：给 CPU、总线、外设分配正确的时钟源和分频系数
• DDR 控制器初始化：配置时序参数、驱动强度、地址映射
• eMMC 控制器初始化：设置总线宽度、时钟频率、访问分区
• 安全/TrustZone 基础配置：划分 Secure/Non-Secure 内存区域，设置中断属性

DDR 初始化的优先级很高。如果没有 DDR，FSBL 连一块足够大的内存都没有，遇到大镜像就只能干瞪眼。而 DDR 配置又极度依赖具体的硬件设计：DDR 颗粒型号、走线拓扑、频率等级，都会影响寄存器中的时序参数。所以 ST 官方 SDK 和 CubeMX 生成的 FSBL 模板，都是针对特定开发板的，移植到自己的板子上时，DDR 部分必须重新对着硬件手册校准，不能直接照抄。

eMMC 控制器的初始化则相对“通⽤”一些。一般流程是：先复位控制器，设置时钟频率到低速模式，发送 CMD1 获取设备 OCR 寄存器，确认电压窗口；然后发送 CMD2 读 CID、CMD3 设置 RCA；再发送 CMD9 读 CSD、CMD7 选中设备；最后通过 CMD6 切换到高速或 HS200 模式。整个过程跟 Linux 内核里的 MMC 子系统初始化逻辑如出一辙，只是 FSBL 里没有设备模型和驱动程序框架，所有寄存器都要手动操作，所以代码看起来比较“裸”。

FSBL 最后一步通常是从 eMMC 的 Boot Partition 或 User Data Area 读取下一级镜像，并校验其完整性。这里的校验策略由产品需求决定：裸机工程可以直接把应用拖到 DDR 跳转；跑 Linux 的则要先加载 U-Boot，让 U-Boot 继续完成后续的复杂引导。

2.3 U-Boot 在其中的定位

U-Boot 是 Second Stage Boot Loader，但它和 FSBL 的职责有明显区别。FSBL 要快、要稳、要省代码，而 U-Boot 更像一个“半成品操作系统”：它有命令行、有文件系统支持、有网络协议栈、有环境变量，还能读 ext4、FAT、TFTP，调试阶段特别有用。

在 STM32N6 的 eMMC 启动方案里，U-Boot 主要干这几件事：

• 从 eMMC 指定分区加载内核镜像（通常是 Image 或 zImage）和设备树 dtb
• 解析设备树，把内存大小、外设地址、引脚复用信息传递给内核
• 设置 bootargs 参数，告诉内核根文件系统在哪里、控制台串口是哪个
• 如果有 A/B 分区或版本回滚需求，U-Boot 还会承担启动策略决策的任务

这就是典型的嵌入式 Linux 启动模型，只是把控制器从 MPU 换成了 STM32N6 这类高算力 MCU。因为 STM32N6 从设计上就是要兼顾 MCU 的实时性和应用处理器的泛用性，所以这套启动链路跟 STM32MP1 非常相似，熟悉 MP1 的朋友上手会很快。

TrustZone 在这里的作用，则是给这条链路加上安全边界。U-Boot 运行在非安全世界，它没有权限访问受安全保护的内存和外设。FSBL 或 SPL 阶段配置好 TrustZone 之后，安全侧代码和普通侧代码虽然在同一颗芯片上跑，但内存、中断、外设访问都被隔离，这在工业设备和边缘计算场景里非常重要。

3. FSBL 配置实战：从工程模板到 eMMC 读取镜像

文字毕竟抽象，聊点可以直接动手的部分。这里我以 ST SDK 里的 STM32CubeN6 FSBL 工程模板为基础，说的是通用配置思路，具体文件名和寄存器地址会以你的芯片型号和库版本为准，但整个配置逻辑是通的。

3.1 时钟与 DDR 初始化顺序

FSBL 启动后，第一件大事就是把时钟和 DDR 配好。注意顺序不能乱：如果先初始化 DDR 再配 PLL，DDR 控制器可能会因为输入频率不合规，产生无法预估的故障；如果先配 PLL 不到位就初始化 DDR，时序参数又可能超出 DDR 颗粒的余量范围。

我习惯的顺序是：

• 使用 HSI 作为临时时钟源，先把基础的系统时钟跑起来
• 配置主 PLL，把 CPU 和 AHB/AXI 总线时钟切到目标频率
• 对于 DDR，先根据 EMC 控制器要求的初始化序列，配置 DDR 控制器的时序寄存器
• 执行 DDR 控制器的 Training（如果需要），确认读写窗口
• 检查 DDR 读写测试结果，通过后再把 DDR 地址区域映射到 CPU 的寻址空间

这块最值得加日志。FSBL 阶段串口可能还没完全初始化，但你至少要留一个 GPIO 翻转或 LED 指示的调试手段，确认代码走到了哪一步。我见过太多项目，写 FSBL 从来不留日志，出问题只能靠猜，效率极低。

3.2 eMMC 控制器初始化细节

FSBL 阶段的 eMMC 初始化，跟 Linux 内核启动时做的事情差不多，但要注意几个细节：

• 第一，初始时钟要保守。eMMC 设备上电后标准要求主机先把 CLK 降到 400kHz 以下，完成识别流程后再切换到高速。如果一上来就直接跑 50MHz 甚至 200MHz，很多 eMMC 颗粒会直接不回 CMD1。
• 第二，访问 Boot Partition 需要先发 CMD6，把 EXT_CSD[179]（BOOT_PARTITION_ENABLE）设置为对应值。BootROM 自己已经处理过这一步，但你从 FSBL 重新初始化控制器后，需要再次配置。
• 第三，RCA 地址、CID、CSD 这些信息要在重新初始化后重新读取，不能缓存上一次的值。有些 eMMC 在软复位后会重新分配 RCA，你如果拿着旧地址去发命令，设备完全不响应。

手工初始化 eMMC 控制器时，大家可以在代码里维护一个状态机，把 CMD0 → CMD1 → CMD2 → CMD3 → CMD7 → CMD6 这个过程每一步的响应寄存器值打出来，这样一旦卡住，你能快速判断是设备没上电、时钟有问题，还是命令序列不对。

3.3 从 eMMC 读取镜像到 DDR 的关键参数

FSBL 从 eMMC 读取镜像到 DDR，有几个参数必须提前确定，不能拍脑袋：

• 镜像在 eMMC 中的起始块号：这是 BootROM 和 FSBL 之间的约定。BootROM 从块 0 读取 FSBL，FSBL 则按你自己的规划从块 N 读取 U-Boot。块号和偏移一旦不匹配，启动就断在下一级。
• 镜像长度：要精确到字节。读多了会读到无效数据，读少了镜像不完整，都可能触发校验失败。
• 加载目标地址：这个地址必须在 DDR 的有效映射范围内，并且要避开 TrustZone 中标记为 Secure 的区域（如果 U-Boot 被放在 Non-Secure 世界运行）。
• 校验算法：常见的是 CRC32 或 SHA256。CRC32 速度快，安全等级低；SHA256 更稳，但需要芯片支持硬件加密引擎，否则纯软件计算耗时较长。

还有一个容易忽略的点：读取时用的块大小。eMMC 支持可配置的块大小，但最稳妥的做法是固定使用 512 字节块，避免在 FSBL 阶段引入太多变量。读取多块操作时，要确保 DMA 目标地址对齐，很多 MCU 的 DMA 控制器要求源和目的地址按字对齐，不满足时会出现诡异的字节错位问题。

4. U-Boot 引导内核：分区布局与启动参数

FSBL 把 U-Boot 拉起来后，之后的事情基本就交给 U-Boot 了。U-Boot 的优势在于它有命令行和文件系统，调试策略可以灵活很多。但灵活也意味着约束变多，最典型的就是分区布局和环境变量管理。

4.1 eMMC 分区布局规划

建议在项目最开始就规划好 eMMC 的分区布局，不要等代码写完了再补。一张合理的分区表长这样：

之所以把 FSBL 和 U-Boot 放在 Boot Partition 里，是因为 Boot Partition 支持独立的写保护，误擦除或者被普通用户数据覆盖的风险低。U-Boot 环境变量单独划分一块区域，也是为了避免环境变量和根文件系统互相干扰。刷机时你会感谢这个决定：改错了环境变量，恢复默认值比重新刷整个系统快得多。

4.2 U-Boot 适配与配置要点

U-Boot 要适配 STM32N6 的 eMMC 启动，核心工作在设备树和 defconfig 两个地方：

• defconfig 里打开支持 eMMC 的 MMC 驱动，设置 CONFIG_MMC、CONFIG_MMC_SDHCI、CONFIG_FS_EXT4 等选项
• 配置 bootcmd 环境变量，让它从正确的设备号、分区号读取内核镜像
• 设置 loadaddr 和 fdtaddr，确保内核镜像和设备树的加载地址不会与 U-Boot 自身或 TrustZone 安全区域冲突
• 如果需要对启动镜像做版本控制，可以添加自定义环境变量，在 U-Boot 脚本里做分支判断

配置完成后，建议先用 mmc dev、mmc part、mmc read 这些命令行手动验证一遍启动路径，确认地址和分区都对，再固化到 bootcmd 里。命令行模式下出了错可以随时 reboot，不会变砖。

4.3 引导过程中的实际命令与日志分析

手动引导时我常用的几条命令：

setenv bootargs root=/dev/mmcblk0p4 rootwait rw console=ttySTM0,115200 mmc dev 0 mmc part fatload mmc 0:3 ${loadaddr} image.fit mmc read ${fdtaddr} <dtb_blk_addr> 200 bootm ${loadaddr} - ${fdtaddr}

看到这里，平时用 SPL + U-Boot 的朋友应该很有亲切感。要注意的是，这里的 mmc dev 0 对应的是哪个分区，取决于 U-Boot 的 MMC 设备枚举顺序，千万不要以为 dev 0 就是 User Data Area。如果设备树里把 Boot Partition 也注册成了一个独立设备，设备号可能会错位。查这个问题最快的方法是看 U-Boot 启动日志里的 mmc 设备列表：

mmc list mmc dev list

能直接把当前所有 MMC 设备、对应的分区和容量列出来。日志是最不会骗人的，比对着代码猜可靠得多。

5. TrustZone：安全启动链和内存隔离落地

TrustZone 是 STM32N6 启动里最容易被忽略、但影响范围最大的配置。很多人做完前几步启动链路，发现系统能跑起来了，就开始写业务逻辑，结果某天访问某个外设地址时突然 HardFault，查了半天发现是 TrustZone 的属性没配对。

5.1 TrustZone 的基础框架

ARM 的 TrustZone 技术把 CPU 的硬件资源划分为两个世界：安全世界（Secure World）和非安全世界（Non-Secure World）。安全世界的代码可以访问所有资源，非安全世界的代码只能访问被标记为 Non-Secure 的地址空间。具体到 STM32N6 上，这个隔离由两个关键模块管理：

• SAU（Security Attribution Unit）：把整个内存和部分外设地址空间按照地址区间，标记为 Secure、Non-Secure 或 Non-Secure Callable
• IDAU（Implementation Defined Attribution Unit）：由芯片厂家实现的附加安全属性逻辑，它和 SAU 一起决定最终的安全状态

一个地址最终是否被允许从非安全侧访问，取决于 SAU 和 IDAU 的“合并判决”。如果 IDAU 把一个外设永远标记为 Secure，那么即使 SAU 把它配成 Non-Secure，实际访问仍然会被拒绝。这层逻辑在 Cortex-M23/M33/M55 甚至更高端的 M85 上都有，但很多嵌入式工程师没接触过，第一次遇到时常常以为是普通权限问题。

5.2 安全启动逐级信任的实现

TrustZone 在启动链里的价值，不只是“隔离”，更是“逐级信任”。下面是典型的安全启动流程：

• BootROM 是信任根，它先验证 FSBL 的数字签名，只有签名为有效才跳转
• FSBL 运行在 Secure 世界，它负责初始化 DDR、设置 SAU 划分内存属性，然后验证 U-Boot 的签名
• U-Boot 运行在 Non-Secure 世界，它可以引导内核、加载根文件系统，但无法访问 Secure 世界持有的密钥、敏感数据和加密引擎
• 内核运行在 Non-Secure 世界，即使被攻破，攻击者也拿不到安全世界中存储的证书和密钥

这样一条链走下来，你的硬件上就有一块“即使主系统被拿下也相对安全”的空间。实际项目中，常常把固件校验密钥、设备证书、AES 密钥放在 OTP 里，通过 FSBL 设置 SAU 来保护。对云端设备来说，这套方案能解决设备身份认证和固件防篡改两个核心诉求。

签名验证一定要在跳转之前做，而且在 FSBL 阶段就要做，不能拖到 U-Boot 起来之后。因为一旦 U-Boot 被替换成恶意版本，它可能会伪造校验逻辑，让你的整个安全体系形同虚设。

5.3 实操中的内存安全属性配置

配置 TrustZone 的运行时特征，主要在 FSBL 阶段完成。核心是设置 SAU 的 region 属性，以及外设的 Security 位。一个简化示例：

// 把 0x30000000 到 0x3003FFFF 标记为 Non-Secure SAU->RNR = 0; SAU->RBAR = 0x30000000; SAU->RLAR = 0x3003FFFF | SAU_RLAR_ENABLE_Msk; SAU->CTRL = SAU_CTRL_ENABLE_Msk;

这里只做示例，实际寄存器名称和数值以 ARM 的对应文档为准。但原理上要注意几点：

• SAU region 的起始地址和结束地址必须对齐到指定的粒度，通常是 32 字节，不满足会让配置无效
• 如果某个外设要暴露给 Non-Secure 侧，不仅要配 SAU，还要把该外设的 NVIC 中断属性配成 Non-Secure，否则中断来了也进不了 Non-Secure 的中断处理函数
• Secure 和 Non-Secure 之间的函数调用不能直接跳，要走 SG（Secure Gateway）指令。如果没有配置 Non-Secure Callable 区域，Non-Secure 侧调用 Secure 函数会直接触发 HardFault

常见的错误是把整个内存都配成 Non-Secure，结果安全功能失效；或者把整个内存都配成 Secure，结果 U-Boot 一启动就内存访问异常。正确做法是：代码所在 RAM、外设寄存器、中断、DMA 缓冲区，都要明确划分安全和普通属性，而不是一刀切。

6. 常见问题与调试技巧：启动日志、引脚、时钟一个都不能少

最后这部分是最贴近实战的，我把遇到过的概率最高的几个问题按“现象、原因、排查方法”的方式整理一下。

6.1 排查思路速查表

6.2 调试开关与日志级别

很多 ST SDK 的 FSBL 模板默认把日志输出关掉，或者只输出警告级别。调试时务必要把调试开关打开。热搜词里提到的“fsbl 调试开关”，其实就是这个：在评估板工具链中确认 FSBL 工程的全局宏定义，通常类似 DEBUG、TRACE_ENABLE 这类编译选项，打开后代码里会启用从串口打印函数。每个板子的串口引脚不一样，注意把打印串口的 GPIO 复用和波特率配置对。

U-Boot 阶段则更简单，直接在编译时通过 menuconfig 打开 DEBUG 选项，或者运行时使用 setenv verbosity 提高日志级别。日志多打一点，排查的时候心里就有底。

6.3 我踩过的几个具体坑

第一个坑是 eMMC 的 HS400 模式：硬件上 CLK 和 DS 走线没有做等长，导致跑 HS400 时随机读错数据，最后降级到 HS200 并限制时钟频率，问题才消失。如果你的产品对启动时间要求不那么苛刻，建议量产的镜像先用 HS200 甚至 DDR52 跑，稳定性比那点带宽提升重要得多。

第二个坑是 TrustZone 的 SAU 配置里我漏掉了外设的中断属性。代码在 Non-Secure 世界访问了一块 Secure 外设，结果调用时直接 HardFault。查了很久才定位到，因为看着像是普通数据异常。排查时务必要同时看内存属性和中断属性，两处都要配齐。

第三个坑是 U-Boot 环境变量存到了 eMMC 的随机位置。最初分区布局没定好，env 区域跟内核镜像重叠，改一次环境变量就把内核分区清了，重新刷机才恢复。后来改成固定 1MB 偏移并严格固化在分区表里，再没出过这种问题。

说到最后，我最大的体会是：STM32N6 的 eMMC 启动链路，说到底是一个“分而治之”的过程。BootROM 管最开始的识别和搬运，FSBL 管硬件初始化和镜像加载，U-Boot 管灵活引导，TrustZone 全程给安全边界兜底。每一层代码量不大，但层与层之间的契约——镜像格式、加载地址、块号偏移、签名算法、内存属性——一旦没对齐，整个系统就会在最不起眼的地方卡住。建议你动手前先把分区表和内存属性图画出来，再写代码，能省掉一大半排查时间。如果项目时间紧，也至少要把 FSBL 和 U-Boot 的串口日志留足，让出问题的时候有线索可以追。