3. CRC校验失败的直接表现：常见的控制台错误信息与系统行为

当U-Boot在启动过程中检测到CRC校验失败时，系统会通过控制台输出明确的错误信息，并伴随特定的硬件行为。理解这些直接表现，是快速定位故障源的第一步。本节将系统性地梳理CRC校验失败时的典型症状，包括控制台错误信息、系统挂死与重启现象，并通过流程图和表格帮助您建立故障模式的快速识别能力。

3.1 控制台错误信息：最常见的“求救信号”

U-Boot在检测到CRC校验失败时，会通过串口控制台输出特定的错误字符串。这些字符串通常包含“CRC”或“Bad”等关键词，是诊断故障的最直接线索。下表列出了最常见的错误信息及其典型含义：

错误信息原文	常见出现场景	直接含义
CRC error	环境变量（env）加载、镜像校验	存储的数据与计算出的CRC值不匹配
Bad CRC	环境变量校验、FIT镜像校验	CRC校验失败，数据可能已损坏
CRC mismatch	NAND/NOR Flash读取校验	读取的数据CRC与存储的CRC不一致
Wrong CRC	SPI Flash、SD卡镜像加载	镜像头部或数据段CRC校验未通过
CRC check failed	U-Boot自身镜像校验、Legacy镜像	整体CRC校验未通过，通常导致启动中止

3.2 系统挂死与重启：硬件层面的连锁反应

CRC校验失败不仅会输出错误信息，还会引发系统级的异常行为。根据校验失败的阶段和严重程度，系统可能表现出以下三种典型状态：

• 完全挂死（Hang）： 当CRC校验失败发生在U-Boot自身代码段或关键数据结构（如中断向量表、MMU表）时，CPU可能直接进入异常状态，控制台无任何输出，系统完全停止响应。此时通常需要硬件复位才能恢复。
• 看门狗复位（Watchdog Reset）： 如果CRC校验失败导致U-Boot在某个循环中无法继续执行（例如等待无效的镜像加载），硬件看门狗定时器会超时，触发系统自动重启。这种重启通常是周期性的，形成“启动→失败→重启”的死循环。
• 回退到默认环境（Fallback to Default）： 这是最温和的表现形式。当环境变量区域的CRC校验失败时，U-Boot会输出“Bad CRC, using default environment”并继续启动。虽然系统能运行，但所有自定义的启动参数、IP地址、启动命令等都会丢失。

3.3 故障现象与故障阶段的关联分析

不同的CRC校验失败阶段，会引发不同的系统行为。理解这种关联性，可以帮助您从现象反推故障发生的具体位置。下面的SVG流程图展示了从CRC校验失败到系统响应的完整路径：

3.4 典型场景的串口日志解读

在实际调试中，串口日志是判断CRC校验失败最可靠的依据。以下是三种典型场景的日志片段，请仔细对比其差异：

场景一：环境变量CRC失败（最常见）

U-Boot 2023.04 (Jan 15 2025 - 14:30:00 +0800)
DRAM:  512 MiB
NAND:  256 MiB
*** Warning - bad CRC, using default environment

Loading Environment from NAND... OK
Hit any key to stop autoboot:  0
=>

解读： 系统检测到NAND中存储的环境变量CRC错误，输出“bad CRC”警告，并加载默认环境。系统仍可进入U-Boot命令行，但所有自定义变量丢失。

场景二：镜像加载CRC失败（导致重启）

U-Boot 2023.04 (Jan 15 2025 - 14:30:00 +0800)
DRAM:  512 MiB
NAND:  256 MiB
Loading Kernel Image from NAND... OK
Checking CRC ... CRC error!
FIT image check failed
resetting ...
U-Boot 2023.04 (Jan 15 2025 - 14:30:05 +0800)

解读： 内核镜像的CRC校验失败，U-Boot输出“CRC error!”后执行复位操作。系统在5秒后重新启动，形成循环。注意日志中的时间戳变化。

场景三：U-Boot自身CRC失败（完全挂死）

U-Boot 2023.04 (Jan 15 2025 - 14:30:00 +0800)
DRAM:  512 MiB
NAND:  256 MiB
In:    serial
Out:   serial
Err:   serial
CRC check failed for U-Boot image
(系统完全停止，无任何后续输出)

解读： U-Boot在加载自身镜像时CRC校验失败，输出“CRC check failed”后直接挂死。此时CPU已进入异常状态，串口不再有任何响应。

3.5 快速诊断清单：从现象到根因

当您观察到上述现象时，可以按照以下清单进行初步诊断：

1. 检查串口日志： 确认是否存在“CRC error”、“Bad CRC”等关键词，并记录错误出现的上下文（如加载环境变量时、加载内核时）。
2. 观察系统行为： 系统是挂死、重启还是继续运行？挂死通常指向U-Boot自身代码或关键硬件；重启通常指向镜像或数据段；继续运行通常指向环境变量。
3. 检查复位源： 如果系统反复重启，通过读取复位状态寄存器（如 RST_SR）确认是否为看门狗复位。
4. 验证存储介质： 使用 md 命令读取疑似损坏区域的原始数据，与已知的正确CRC值进行比对，确认是数据损坏还是CRC计算逻辑错误。