烧录

Tutorial: 卓越工程师 Category: 嵌入式 Published: 2026-10-23 11:05:29 Views: 1 Likes: 0 Comments: 0

329.3.2烧录

#define BSP_USING_UART1              // 将 UART1 纳入当前 RT-Thread BSP 的编译配置。
#define BSP_UART1_TX_PIN      "PA9"  // 把 UART1 的发送功能映射到 PA9 引脚。
#define BSP_UART1_RX_PIN      "PA10" // 把 UART1 的接收功能映射到 PA10 引脚。
#define BSP_USING_UART2              // 将 UART2 纳入当前 RT-Thread BSP 的编译配置。
#define BSP_UART2_TX_PIN      "PA2"  // 把 UART2 的发送功能映射到 PA2 引脚。
#define BSP_UART2_RX_PIN      "PA3"  // 把 UART2 的接收功能映射到 PA3 引脚。
#define BSP_USING_UART3              // 将 UART3 纳入当前 RT-Thread BSP 的编译配置。
#define BSP_UART3_TX_PIN      "PB10" // 把 UART3 的发送功能映射到 PB10 引脚。
#define BSP_UART3_RX_PIN      "PB11" // 把 UART3 的接收功能映射到 PB11 引脚。

本节末尾只展示了上述 RT-Thread board.h 片段，用它类比 Linux 设备树的“描述硬件、让系统据此配置设备”作用。因此这里只按视频画面收录这九行宏并逐行注释，没有补写驱动初始化、设备注册或应用代码。这个类比便于入门，但二者不是同一种机制，详见 1.2.8。

本节先把课程提供的 U-Boot、Linux 内核、设备树和根文件系统烧入 iTOP-i.MX6ULL eMMC 版开发板，再从串口观察完整启动过程。实际链路是：

Windows 上的 MfgTool2
        │  USB OTG（i.MX ROM 串行下载通道）
        ▼
开发板进入 USB Serial Downloader 模式
        │  下载临时烧写环境并执行脚本
        ▼
把 U-Boot、zImage、DTB 和根文件系统写入 eMMC
        │  断电并改为 eMMC 启动
        ▼
U-Boot → 加载 zImage 与一个 DTB → Linux 内核 → 挂载根文件系统 → 启动用户空间

**烧写风险：**该操作会改写 eMMC，原有分区和数据可能被覆盖。烧写前应确认板卡确为 eMMC 版本、固件与板卡/BSP 匹配，并备份需要保留的数据。写入期间不要断电、拔 OTG 线、切换拨码或让虚拟机抢占 USB 设备。

一、交叉编译烧录

原标题中的“交叉编译烧录”概括了整套系统制作流程，但本节在 Windows 上进行的是部署已有镜像，不是由 MfgTool2 现场交叉编译源码。u-boot.imx、zImage 和 .dtb 等文件应当已经在前面的 Linux 构建环境中生成；MfgTool2 负责按照配置脚本把它们写入目标存储介质。

课程采取“先实践、后拆解”的顺序：先让开发板成功启动，再分别学习 U-Boot、内核、设备树和根文件系统的构建与原理。

1.1 烧录软件使用

1.1.1 烧录工具路径与固件放置

视频使用的烧录包目录名为：

mfgtools_for_6ULL

启动程序位于该目录根部：

mfgtools_for_6ULL\MfgTool2.exe

十个待烧写文件必须放入以下固定目录：

mfgtools_for_6ULL\Profiles\Linux\OS Firmware\files\linux

这里的路径不是随意的资料分类。MfgTool2 会根据 Profiles 下的配置和命令脚本按相对路径寻找文件；仅把镜像放在软件旁边，或自行改名，都会造成脚本找不到文件。使用课程资料时应保留整个工具包的目录结构。

本节使用的是较早的 MfgTool2.exe。NXP 当前维护的 UUU 是 MfgTools 的后续版本，但脚本格式和使用方式不同，不能只替换可执行文件就期待课程配置继续工作。NXP mfgtools/UUU 官方说明

1.1.2 烧录所需文件类型与来源

视频画面中的 linux 目录共有 10 个文件：1 个根文件系统归档、7 个设备树二进制、1 个 U-Boot 镜像和 1 个内核镜像。

文件类型与来源启动时的作用
u-boot.imx由 U-Boot 源码构建；通常是包含 i.MX Boot ROM 所需启动信息的镜像上电后首先运行的引导加载程序，完成必要初始化并加载内核与 DTB
zImageLinux 内核源码构建产物，常见位置为 arch/arm/boot/zImageARM Linux 的可启动压缩内核镜像；U-Boot 的 bootz 命令专门用于启动这种格式
topeet_emmc_4_3.dtb由内核设备树源文件编译得到课程板卡 4.3 英寸显示配置对应的硬件描述
topeet_emmc_5_0.dtb同上5.0 英寸显示配置
topeet_emmc_7_0.dtb同上7.0 英寸显示配置
topeet_emmc_9_7.dtb同上9.7 英寸显示配置
topeet_emmc_10_1.dtb同上10.1 英寸显示配置
topeet_emmc_1024x600.dtb同上1024×600 显示配置
topeet_emmc_hdmi.dtb同上HDMI 显示配置
rootfs.tar.bz2已打包的根文件系统目录树由烧写脚本解包/写入 eMMC 的根文件系统分区，供内核挂载后启动用户空间

设备树常见构建位置为：

arch/arm/boot/dts/

因此原笔记中的 arc/arm/boot 应为 arch/arm/boot，uboot.rmx、ubuntu.rmx 都应为 u-boot.imx，而“ze image”“zmagic”“imagine”均是 zImage 的语音转录/OCR 错误。NXP 官方工具说明也指出，i.MX6/7 常见的 ROM 可启动文件名为 u-boot.imx；U-Boot 官方文档则明确 bootz 用于启动 zImage。NXP UUU 说明、U-Boot bootz 文档

七个 DTB 都要放进烧写包，是为了覆盖课程支持的多种显示方案；一次启动只会使用其中一个。究竟加载哪一个由 U-Boot 环境变量和启动脚本等配置决定，不应理解成内核一定能自动识别屏幕并任意挑选文件。本次启动日志明确读入的是 topeet_emmc_hdmi.dtb。

1.1.3 设备树与根文件系统介绍

四类文件的边界如下：

组成部分它包含什么它不等于什么
U-Boot早期硬件初始化、启动介质选择、镜像加载、启动参数传递等引导逻辑不是完整 Linux，也不是对全部硬件进行全面自检的程序
Linux 内核调度、内存管理、文件系统框架、网络栈和设备驱动等核心能力不是包含全部命令、配置和应用的完整发行系统
DTB板级硬件拓扑与资源的二进制描述不包含设备驱动，也不是一个可以独立运行的程序
根文件系统/bin、/sbin、/lib、/etc、/usr 等用户空间文件及运行环境不只是“文件管理器”或鼠标、界面资源

rootfs.tar.bz2 是传输和烧写阶段使用的压缩归档。启动时真正挂载的是写入 eMMC 分区后的文件系统，而不是把这个 .tar.bz2 文件直接当根目录。/dev、/proc、/sys 等目录还常作为运行时伪文件系统的挂载点，其内容不应简单理解为全都来自归档包。

设备树源文件通常为 .dts/.dtsi，经设备树编译器转换成 .dtb。它用树形节点和属性描述许多不能像 USB/PCI 那样自动枚举的板载硬件，例如 SoC 内部控制器、I²C/SPI 外设、GPIO、时钟、复位、引脚复用和中断连接。Linux 官方文档强调，设备树只是硬件数据结构，不会“神奇地解决”全部硬件配置问题。Linux 内核设备树使用模型

1.1.4 烧录文件总结与操作指导

烧写前按下列清单核对：

  1. 板卡是课程所用的 i.MX6ULL eMMC 版本，不是 NAND 版本；不同存储介质的分区和脚本不能混用。
  2. linux 目录内上述十个文件均存在，文件名、大小写和扩展名没有被改动。
  3. 固件来自同一套匹配的 BSP，不能随意混用不同版本的 U-Boot、内核、DTB 和根文件系统。
  4. 使用可靠的数据线和稳定的独立供电；优先把 OTG 线直连电脑 USB 口，不经不稳定的扩展坞。
  5. 先关闭开发板电源再改拨码，确认方向后再上电。
  6. 如虚拟机正在运行，确保它没有自动捕获该 USB 设备；无需把“关闭所有虚拟机”理解成烧写协议本身的硬性要求。
  7. 写入开始后保持供电和连接，直到 MfgTool2 明确报告完成。

本项目课程资料中存在同名 rootfs.tar.bz2，但文件名相同不代表内容、分区布局和版本一定相同。复现实验时应优先使用烧写工具包原本配套的完整十文件集合，而不是单独替换其中一个文件。

1.2 烧写emmc启动模式

规范写法是 eMMC。原笔记和转录里的 EMSC、EMIC、EMRC 等均为识别错误。

1.2.1 USB串行启动模式设置

课程板卡用 8 位拨码开关选择启动方式。按视频所示表格，数字依次对应开关 1～8；拨向标有 ON 的一侧记为 1，另一侧记为 0，x 表示该模式下这一位无关。

启动方式12345678连写
USB 串行下载01xxxxxx01xxxxxx
SD/TF 卡启动1000001010000010
eMMC 启动1010011010100110
NAND Flash 启动1000100110001001

烧写时先断电，把第 1 位设为 0、第 2 位设为 1；其余位虽然标为 x，仍建议按课程照片固定好，避免开关处在中间或记录不清。拨码状态在复位/上电阶段被启动 ROM 采样，所以改完拨码后必须重新上电才会进入新模式。i.MX6ULL 官方资料也把 BOOT_MODE0/1 定义为复位时的启动模式选择输入。NXP i.MX6ULL 数据手册，第 5 章

这里的“USB 串行下载”是 i.MX Boot ROM 通过 USB OTG 使用 Serial Download Protocol（SDP）接收程序，不是 UART 串口烧写。NXP 的后续 UUU 工具同样要求把板卡置于 USB serial download mode，并把 i.MX6/7 的 ROM 下载协议称为 SDP。NXP mfgtools 官方说明、官方协议列表

视频中涉及的几个硬件接口不可混淆：

硬件本节用途连接关系
8 位拨码开关选择 ROM 启动模式必须断电调整，并按开关编号与 ON 方向判定 0/1
标有 OTG 的 USB 口MfgTool2 烧写数据通道OTG 口直连电脑 USB 口
标有 UART 的 USB 口通过板载 CH340 查看调试串口烧写完成后接电脑，在终端中打开对应 COM 口
DC 电源输入与蓝色电源按键给整板稳定供电并控制上电视频按下的是蓝色电源按键，不是“蓝色端子”
1.2.2 烧录软件使用及注意事项

按视频复现的步骤如下：

  1. **断电并设拨码。**把板卡设为 USB 串行下载模式 01xxxxxx。
  2. **接 OTG 数据线。**一端插板上 OTG USB 口，另一端直连电脑；不要误插到 UART 口。
  3. **核对固件目录。**确认 Profiles\Linux\OS Firmware\files\linux 内十个文件齐全。
  4. **启动 MfgTool2。**视频在 Windows 中右键以管理员身份运行 MfgTool2.exe。这是该旧版工具、驱动和课程环境的实测要求，不应扩展成所有烧写工具都必须管理员运行。
  5. **排除程序和 USB 占用。**若窗口打不开或报错，在任务管理器结束残留的 MfgTool (32 bit) 后重试；若虚拟机抢占 USB，应从虚拟机断开该设备或暂停虚拟机。
  6. **给开发板上电。**按下视频中的蓝色电源按键，确认电源指示灯亮。
  7. **等待正确识别。**MfgTool2 左侧应出现视频中的 Windows 设备名称：符合 HID 标准的供应商定义设备。看到该状态后再点 Start。
  8. **等待写入完成。**软件先装载烧写环境和文件，再写 eMMC。视频运行中曾短暂显示 No Device Connected，同时进度仍在推进；这通常对应设备从 ROM HID 阶段切换并重新枚举。只有它随后恢复并继续执行才可视为阶段性现象；若长期停住或进度不动，就应按故障处理。
  9. **确认结果。**视频完成画面为 Done、两条进度条全绿，并显示 Successful 1、Failed 0、Failure Rate 0.00%。这表示 MfgTool2 工作流报告成功，但最终仍要用 eMMC 启动日志验证镜像确实可运行。
  10. **正常退出。**先点 Stop，再点 Exit。

若软件始终识别不到板卡，优先按以下顺序排查，而不是一上来就重启电脑：

  • 开发板是否上电、拨码是否为 USB 下载模式，改拨码后是否重新上电；
  • 数据线是否插在 OTG 而非 UART，线缆是否支持数据而非仅充电；
  • Windows 设备管理器是否出现/消失相应 USB 设备；
  • 设备是否被 VMware 等虚拟机捕获，或被另一实例占用；
  • 任务管理器是否残留 MfgTool (32 bit)；
  • 换电脑原生 USB 口或可靠线缆，并查看工具目录中的 MfgTool.log；
  • 最后再考虑重新安装匹配驱动或重启 Windows。
1.2.3 烧录完成后的操作
  1. MfgTool2 全绿后依次点 Stop、Exit，再给开发板断电。
  2. 按开关 1～8 的顺序把拨码设为 eMMC 启动：10100110。
  3. 把电脑数据线从板卡的 OTG USB 口移到标有 UART 的 USB 口。视频使用板载 CH340，Windows 中显示为类似 USB-SERIAL CH340 (COM10)；实际 COM 号以本机为准。
  4. 打开 MobaXterm，新建 Serial 会话，选择对应 COM 口，波特率设为 115200。视频只明确给出了 115200；若软件要求完整串口格式，其余保持该串口会话默认的 8 数据位、无校验、1 停止位和无硬件流控即可。
  5. 打开串口会话后再给开发板上电，以免漏掉最早的 U-Boot 日志。
  6. 等待出现 Please press Enter to activate this console.，按回车后得到 [root@iTOP-iMX6UL]# 提示符，再执行 ls 验证用户空间可用。

课程思维导图还记录了用户名 root、密码 topeet，适用于启用了登录认证的镜像；视频这次实际启动直接提示按回车激活控制台，没有出现登录询问，不能把两种情形混为一谈。

建议把“烧写成功”分成五层验收：

层级应看到的证据
工具层MfgTool2：Done、全绿、Successful 1、Failed 0
引导层串口出现 U-Boot 版本、CPU、DRAM、MMC 等日志
镜像层出现 reading zImage、reading topeet_emmc_hdmi.dtb 和 Starting kernel ...
内核层Linux 内核持续输出，且没有停在 panic
用户空间层根文件系统挂载成功，出现控制台提示符，ls 能列出目录
1.2.4 启动模式与硬件初始化

视频首次从 eMMC 启动时，串口开头显示：

U-Boot 2016.03 (Feb 03 2024 - 20:22:52 -0800)
Board: MX6UL TOPEET
I2C:   ready
DRAM:  512 MiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1

这些信息表明 U-Boot 已开始运行，并完成或探测了启动所需的一部分资源。U-Boot 的核心职责包括早期时钟/DDR/串口/存储初始化、读取环境变量、选择启动介质、准备内核启动参数、把内核与 DTB 装入内存并把控制权交给内核。它输出某个控制器的信息，不等于对板上全部硬件做了完整功能测试；例如网口驱动被识别也不能证明网线、PHY 链路和网络配置都正常。

本次日志还出现：

*** Warning - bad CRC, using default environment
*** Warning use default panel:hdmi ***
Writing to MMC(1)... done
LCD type:hdmi
unsupported panel hdmi

这说明保存的 U-Boot 环境校验未通过，于是本次使用默认环境；随后 U-Boot 选择了默认 panel:hdmi，并出现一次 Writing to MMC(1)... done。仅凭这几行不能确定该写入的全部内容。系统随后仍继续启动，所以不能把 CRC 警告直接等同于烧写失败；若每次启动都重复出现，则应检查环境分区/偏移和保存动作。unsupported panel hdmi 只表明 U-Boot 当前阶段的面板处理不支持这个值；串口能够进入 Linux 既不能证明 HDMI 已正常显示，也不能单凭这行断定 Linux 阶段的 HDMI 必然不可用。

倒计时 Hit any key to stop autoboot 用于中断自动启动并进入 U-Boot 命令行。本节要验证正常启动，因此不按键，让倒计时归零。日志还显示读取 boot.scr 失败，但紧接着走入加载 zImage 的备用启动路径；在这个特定配置中它不是致命错误，不能据此推广为所有系统都可以缺少 boot.scr。

1.2.5 内核启动与设备树加载

本次关键日志为：

reading zImage
7186568 bytes read in 180 ms (38.1 MiB/s)
Booting from mmc ...
reading topeet_emmc_hdmi.dtb
40515 bytes read in 18 ms (2.1 MiB/s)
Kernel image @ 0x80800000 [ 0x000000 - 0x6da888 ]
## Flattened Device Tree blob at 83000000
Booting using the fdt blob at 0x83000000
Starting kernel ...

由此可以严格确认：

  • U-Boot 从 MMC 存储读取了 zImage，将它放到内存中的内核加载地址；
  • 本次只读取了 topeet_emmc_hdmi.dtb，并把扁平设备树放在 0x83000000；
  • U-Boot 把内核镜像和 FDT 地址交给 Linux，然后打印 Starting kernel ...；
  • 从下一行带 [ 0.000000] 时间戳的 Booting Linux on physical CPU 0x0 起，主要进入 Linux 内核阶段。

U-Boot 官方 bootz 文档给出的接口也同时接收 zImage 地址与 FDT 地址；因此 DTB 不是内核启动后再从根文件系统随意查找的普通配置文件，而是由当前启动链路在跳转前准备并传入。U-Boot bootz 文档

课程把多个 DTB 与不同显示方案对应是合理的，但选择动作发生在 U-Boot 环境/脚本中。本次 bad CRC 后回退到默认 panel:hdmi，与随后加载 HDMI DTB 的日志相互印证；不能据此得出“系统自动检测到 HDMI”的结论。

1.2.6 根文件系统挂载与系统启动

内核启动后会初始化内存管理、调度、中断、总线和驱动，并根据启动参数找到根设备。视频日志明确显示：

EXT3-fs (mmcblk1p2): mounted filesystem with ordered data mode
VFS: Mounted root (ext3 filesystem) on device 179:2.
devtmpfs: mounted

这里的 mmcblk1p2 表示 MMC 块设备 mmcblk1 的第 2 个分区；在本节板卡与启动配置中，它承载烧写后的 EXT3 根文件系统。随后系统启动用户空间初始化流程，最终打印：

Please press Enter to activate this console.
[root@iTOP-iMX6UL]#

内核并不等于完整的 Linux 使用环境。内核挂载根文件系统后，还要从其中执行 init/PID 1 或相应初始化程序，由它启动服务和控制台；Linux 内核文档也把“挂载真正的根设备并执行 init”作为从内核进入用户空间的关键衔接。Linux rootfs/initramfs 文档

视频日志里还可见几条并未阻止控制台出现的问题：

  • Direct firmware load for rtl8723bu_config failed with error -2：对应的蓝牙配置固件未找到；
  • grep: /etc/mtab: No such file or directory：用户空间脚本期望的挂载表路径不存在；
  • eth0: link is not ready：网口当时没有形成链路，不能据此判断内核启动失败。

这些日志说明“能进 Shell”和“全部外设无告警”是两种不同验收标准。MfgTool2 全绿只证明烧写流程报告完成，后续仍应按具体外设逐项验证。

可以把启动链路作如下近似类比，但不要混同各层：

嵌入式 Linux 组成近似角色必须保留的边界
Boot ROM芯片内固化的第一阶段启动逻辑先于 eMMC 中的 U-Boot 运行
U-Boot类似 PC 固件/启动管理器的一部分职责不只是品牌开机画面，也不是完整硬件检测程序
Linux 内核操作系统核心不包含完整用户命令和应用环境
根文件系统用户空间目录、库、配置与程序不只是图形文件管理器
1.2.7 设备树的作用与原理

设备树是一种分层的硬件描述数据结构。源文件 .dts/.dtsi 经编译成为 .dtb，启动加载器把 DTB 交给内核。典型节点会描述：

  • 总线与设备层级，例如 SoC、I²C 控制器、SPI 控制器、以太网、摄像头、显示接口；
  • compatible：设备的编程模型，用于与支持该字符串的驱动匹配；
  • reg：寄存器或地址范围；
  • interrupts/interrupt-parent：中断号、触发信息及中断控制器关系；
  • clocks、resets、GPIO、供电、DMA、pinctrl-* 等板级资源；
  • status：节点当前是否可用，常见值为 okay 或 disabled。

更准确的驱动建立条件是：节点可用 + compatible 与驱动匹配 + 驱动已编进内核或可作为模块加载 + 节点资源正确 + 驱动 probe 成功。任何一环失败，设备都可能不可用。因此设备树不是驱动本身，也不能简单等同于“驱动开关”。DTSpec 明确规定 compatible 供软件选择驱动，而 status = "okay" 只表示设备处于可运行状态；disabled 只表示当前不运行。Devicetree Specification：标准属性

还要注意两点：

  1. 设备树主要解决板级硬件描述与内核代码解耦的问题，不保证枚举“板上所有器件”；节点是否存在、属性是否准确仍取决于 BSP 作者。
  2. 对 USB、PCI 等可枚举总线，很多下游设备能够在运行时发现；设备树通常描述宿主控制器和板级连接。不能把“所有外设都必须逐个写进设备树”当成绝对规则。

本节七个 DTB 的差异主要服务于课程板卡的显示配置。修改设备树后必须重新编译得到相应 DTB，并确保启动脚本实际加载了新文件；只把新 DTB 放进目录、却继续加载旧文件，不会改变运行结果。

1.2.8 设备树在RT-Thread系统中的应用

视频回到之前的人脸识别 RT-Thread 工程，在 STM32F1 项目的 drivers/board.h 中展示了文首九行 UART 宏：UART1 用 PA9/PA10，UART2 用 PA2/PA3，UART3 用 PB10/PB11。它们的直接含义是：

  • BSP_USING_UARTx：让该 BSP 在条件编译中启用相应 UART 实例；
  • BSP_UARTx_TX_PIN、BSP_UARTx_RX_PIN：告诉 BSP 该实例采用哪组 TX/RX 引脚。

视频回顾这个工程用三路串口分别承担日志输出、人脸识别模块通信和语音模块通信，但当前画面只显示了使能宏与引脚映射，不能据此强行确定三项业务与 UART1～UART3 的逐一对应关系。PA9、PA10 等是 STM32 MCU 的端口/引脚名，不是开发板外壳上的接口编号；接外部串口模块时还要依据原理图找到实际排针，并做到本机 TX 接对端 RX、本机 RX 接对端 TX、双方共地，同时确认电平标准一致。

RT-Thread 官方 UART 文档同样要求在 board.h 中定义 BSP_USING_UARTx 并设置 TX/RX 引脚，编译下载后再通过设备列表确认串口是否已注册。RT-Thread Studio UART 官方文档

这个例子与 Linux 设备树都把“板级差异”从通用驱动逻辑中分离出来，但实现方式不同：

比较项Linux 设备树视频中的 RT-Thread STM32 BSP
描述载体.dts/.dtsi 编译成 .dtbC 预处理宏和 BSP 配置
生效时机DTB 通常在启动时由 U-Boot 传给内核宏在编译期决定哪些代码与配置进入固件
驱动匹配常通过设备树 compatible 与内核驱动匹配BSP 驱动根据条件宏编译，并在初始化阶段注册设备
修改后动作重新编译 DTB并确保启动时加载新 DTB重新编译并下载 RT-Thread 固件

仅定义这九行宏仍不保证三个串口一定可用：芯片时钟、GPIO 复用、BSP 串口驱动、设备注册、串口参数和引脚冲突都必须正确；需要 DMA 时还要启用相应 DMA 配置。也不能推广成“所有 RT-Thread 或所有芯片都必然有 Linux 式设备树”。本节 STM32 工程用的是静态 BSP 宏；其他架构或 BSP 是否使用 FDT，要看该平台实现。

视频随后提到 MPU6050 和 OLED：在 Linux BSP 中，通常需要在相应 I²C/SPI 控制器下正确描述器件地址、GPIO、中断等资源，并确保驱动和内核配置存在；不是把节点的 status 改为 okay 就必然工作。后续排错仍要结合设备树、驱动 probe 日志、供电、总线波形和实际接线。

二、常见故障的分层定位

停止位置先检查什么
MfgTool2 看不到 HID 设备USB 下载拨码、重新上电、OTG 端口、数据线、供电、虚拟机 USB 占用和 Windows 驱动
点 Start 后长期 No Device Connected 且进度不动USB 重新枚举是否失败、临时烧写环境是否匹配、线缆/端口稳定性、MfgTool.log
烧写未全绿或 Failed 增加十文件是否齐全、脚本相对路径、板卡存储版本、供电和工具日志；不要继续当作成功启动
eMMC 模式下完全无串口输出是否断电改成 10100110、数据线是否移到 UART、COM 号和 115200 是否正确、CH340 是否被识别
只有 U-Boot，未出现 reading zImageeMMC 分区/文件、U-Boot 环境变量、启动脚本和镜像文件名
已读内核/DTB，但没有 Starting kernel 或立刻异常内核格式、加载地址、DTB 与板卡匹配、启动参数
内核启动后出现 VFS: Unable to mount root fsroot= 参数、eMMC 分区号、EXT 文件系统驱动、根分区内容与分区表
已进入 Shell，但某外设不可用对应 DT 节点、compatible、status、pinctrl/clock/reset/GPIO、驱动配置与 probe 日志，再查硬件供电和接线

三、本节易错术语

错误/模糊写法正确写法或含义
boot 镜像此处是 U-Boot 引导加载器镜像
uboot.rmx、ubuntu.rmxu-boot.imx
ze image、z image、zmagiczImage
arc/arm/bootarch/arm/boot
EMSC、EMIC、EMRCeMMC；日志中的 DRAM、MMC 还应分别辨认
USB 串口烧写本节烧写通道是 USB OTG 上的 i.MX ROM 串行下载协议，不是 UART
蓝色端子视频操作的是蓝色电源按键
“符合 HID 协议”软件实际显示“符合 HID 标准的供应商定义设备”
设备数设备树（Device Tree）
设备树就是驱动开关设备树描述硬件并参与匹配；驱动、资源和 probe 仍须全部成立
Prev: 交叉编译器 Next: uboot编译启动流程