嵌入式开发板完整使用流程：从工具链到烧录启动全解析

1. 项目概述：从“板子通电”到“代码跑起来”的完整闭环

开发板不是玩具，也不是教学演示的摆设——它是一整套嵌入式系统工程的最小可运行载体。你手里的那块印着丝印、插着排针、连着USB线的电路板，背后串联着工具链选型、交叉编译逻辑、内存布局理解、烧录协议握手、启动流程验证五大硬核环节。跳过其中任意一环，哪怕只是把dd命令里的of=路径写错一个字符，或者没看清合宙Air202 S6开发板26排针引脚中第17脚是GPIO12还是UART2_RXD，结果就是串口无输出、LED不闪烁、调试器连不上、固件卡在BootROM——所有现象都指向同一个事实：你还没真正“用起来”这块板子，只是完成了物理连接。

我带过三十多个嵌入式新人项目，90%的人卡在“烧录失败”这一步，但真正的问题往往不在烧录本身。有人在Ubuntu 20.04上配Qt交叉编译环境，折腾三天装不完arm-linux-gnueabihf-gcc，最后发现根本不需要Qt——他只是想让一个LED按指定节奏闪烁；有人反复重刷ESP32-S3固件，报错overlap at 0x8000，却没意识到自己同时烧了分区表和应用程序，地址空间早已打架；还有人用VMware安装ARM架构Ubuntu虚拟机，结果连qemu-aarch64-static都跑不起来，白白浪费八小时。这些都不是技术门槛高，而是对“完整的开发板使用流程”缺乏系统性认知——它不是零散知识点的堆砌，而是一条有起点、有依赖、有反馈、有验证的工程流水线。

这条流水线的核心锚点有三个：目标平台决定工具链，工具链决定编译方式，烧录方式决定启动行为。比如合众恒跃瑞芯微3506开发板用的是ARM Cortex-A53双核，必须用aarch64-linux-gnu-前缀的交叉工具链；而粤嵌GEC6818（基于ARM Cortex-A7）则需arm-linux-gnueabihf-；STM32F407ZET6用Keil5或STM32CubeIDE，本质是调用ARM GCC的arm-none-eabi-系列工具；ESP32系列则绕不开Espressif官方的xtensa-esp32-elf-工具链。工具链不是下载即用，它需要与内核头文件、C库（musl/glibc/newlib）、构建系统（Make/CMake/Python脚本）严格匹配。Ubuntu 24.04默认不带ARM交叉编译器，sudo apt install gcc-arm-linux-gnueabihf装的是通用包，但如果你的板子用的是i.MX6ULL的Yocto SDK，就必须用厂商提供的预编译工具链，否则sys/types.h里缺定义，编译直接报错。

烧录更不是“拖进去点确定”。dd命令能烧eMMC，但dd if=firmware.bin of=/dev/mmcblk0 bs=1M这种写法只适用于裸镜像；若板子用的是U-Boot+Linux，你得先用mkimage打包成uImage，再通过tftp加载到内存执行；J-Link烧录STM32要确认SWD频率是否超过芯片支持上限（常见于STLINKv2-1固件过旧）；ESP32烧录地址必须查芯片手册——0x1000是bootloader，0x8000是分区表，0x10000才是app，写反一个就变砖。至于imx6ull开发板在屏幕终端中文显示乱码，表面是字体问题，根因却是交叉编译时没启用CONFIG_NLS_UTF8=y，导致内核不支持UTF-8解码，而MobaXterm能显示只是因为它在Windows端做了字符映射补偿。

所以，“完整的开发板使用流程”不是教你怎么点按钮，而是帮你建立一套判断逻辑：当Keil5烧录失败时，先看JTAG/SWD连接灯是否常亮，再查Options for Target → Debug → Settings → Flash Download里是否勾选了正确的Flash算法；当esp32-p4烧录报错时，第一反应不是重装esptool，而是用esptool.py chip_id确认芯片是否被识别，再用esptool.py read_mac验证通信是否正常（{"mac":"dd:fb:05:9d:90:48","name":"watch7 max"}这类MAC信息正是底层通信通畅的铁证）。这套逻辑，比任何教程都管用。

2. 工具链构建与环境配置：为什么不能直接用宿主机GCC？

2.1 工具链的本质：跨架构的“翻译官”与“裁缝”

工具链不是一堆编译器的集合，它是为特定CPU架构、操作系统ABI、硬件外设定制的“翻译官+裁缝”。宿主机（如x86_64 Ubuntu 20.04）的GCC能生成x86指令，但开发板（如ARM Cortex-M4）的CPU根本看不懂这些二进制码。强行运行只会触发Illegal instruction异常，CPU直接复位。交叉编译工具链的核心价值，在于它把源代码“翻译”成目标CPU能执行的机器码，同时“裁剪”掉宿主机才有的系统调用（如fork()在裸机环境不存在），替换成板级驱动接口（如HAL_GPIO_WritePin()）。

以gcc-arm-none-eabi为例，名字里的none表示无操作系统（bare-metal），eabi指嵌入式应用二进制接口。它包含：

• arm-none-eabi-gcc：C/C++编译器，生成ARM Thumb-2指令
• arm-none-eabi-g++：C++编译器，内置libstdc++精简版
• arm-none-eabi-gdb：调试器，支持J-Link/OpenOCD远程调试
• arm-none-eabi-objcopy：将ELF格式转为二进制（.bin）或Intel Hex（.hex）

而arm-linux-gnueabihf则不同：linux表示目标系统是Linux内核，gnueabihf指GNU EABI硬浮点。它依赖glibc动态库，生成的可执行文件必须在Linux环境下运行。这就是为什么vmware安装ubuntu虚拟机选择arm架构是伪需求——虚拟机里的ARM Linux只是另一个宿主机，你仍需为真实开发板（如T113）准备aarch64-linux-gnu-工具链。混淆这两者，会导致编译出的程序在板子上Segmentation fault，因为动态链接器ld-linux-aarch64.so.1根本找不到。

提示：检查工具链是否匹配，最简单的方法是运行arm-linux-gnueabihf-gcc -v，看输出中的Target字段是否为aarch64-linux-gnu（对应ARM64）或arm-linux-gnueabihf（对应ARM32）。若显示x86_64-linux-gnu，说明你误装了宿主机版本。

2.2 Ubuntu 20.04/24.04下Qt交叉编译环境实操

Qt5.12.10或Qt5.9.9交叉编译的痛点，从来不是Qt本身，而是其依赖的OpenSSL、SQLite、DBus等第三方库。很多人卡在configure阶段报错Could not find OpenSSL，其实是因为没给交叉工具链指定OpenSSL的安装路径。以下是经过实测的完整流程（以i.MX6ULL + Qt5.12.10为例）：

第一步：准备基础依赖

sudo apt update sudo apt install build-essential libgl1-mesa-dev libegl1-mesa-dev \ libxcb-xinerama0-dev libxcb-xinerama0 \ libfontconfig1-dev libfreetype6-dev libicu-dev \ python3-dev python3-pip

注意：libgl1-mesa-dev是宿主机OpenGL开发库，仅用于Qt Creator界面编译，与目标板无关。

第二步：下载并解压Qt源码与交叉工具链

wget https://download.qt.io/official_releases/qt/5.12/5.12.10/single/qt-everywhere-src-5.12.10.tar.xz tar -xf qt-everywhere-src-5.12.10.tar.xz # 假设工具链已放在/opt/fsl-imx-x11/4.14-sumo/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/

第三步：配置Qt（关键参数解析）

cd qt-everywhere-src-5.12.10 ./configure -release \ -opengl es2 \ # 启用OpenGL ES2，适配嵌入式GPU -device imx6ullevk \ # 指定设备配置（见qtbase/mkspecs/devices/） -device-option CROSS_COMPILE=/opt/fsl-imx-x11/4.14-sumo/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi- \ -sysroot /opt/fsl-imx-x11/4.14-sumo/sysroots/cortexa7hf-neon-poky-linux-gnueabi \ # 根文件系统路径 -prefix /opt/qt5-imx6ull \ # 安装到目标板的路径 -extprefix /home/user/qt5-imx6ull \ # 宿主机安装路径（用于部署） -no-use-gold-linker \ # Gold链接器在某些旧工具链中不兼容 -no-dbus \ # 若板子不需DBus，关闭以减少依赖 -openssl-linked \ # 强制静态链接OpenSSL（避免运行时找不到so） -I /opt/fsl-imx-x11/4.14-sumo/sysroots/cortexa7hf-neon-poky-linux-gnueabi/usr/include/openssl \ # OpenSSL头文件路径 -L /opt/fsl-imx-x11/4.14-sumo/sysroots/cortexa7hf-neon-poky-linux-gnueabi/usr/lib \ # OpenSSL库路径 -v

注意：-sysroot参数至关重要。它告诉编译器“所有系统头文件和库都从这个目录找”，否则会混用宿主机的/usr/include，导致struct timespec定义冲突。实测中，漏掉此参数会导致qmake生成的Makefile引用错误路径，编译时大量undefined reference to 'clock_gettime'。

第四步：编译与安装

make -j$(nproc) # 利用全部CPU核心加速 make install

编译耗时约2.5小时（i7-8700K），生成的库位于/home/user/qt5-imx6ull。部署到板子只需rsync -avz /home/user/qt5-imx6ull/ root@192.168.1.100:/opt/qt5-imx6ull。

第五步：验证交叉编译结果创建测试程序hello.cpp：

#include <QApplication> #include <QLabel> int main(int argc, char *argv[]) { QApplication a(argc, argv); QLabel w("Hello from i.MX6ULL!"); w.show(); return a.exec(); }

用交叉qmake生成Makefile：

/home/user/qt5-imx6ull/bin/qmake hello.pro make

生成的hello文件大小约12MB（含静态Qt库），用file hello确认为ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV)，证明交叉编译成功。

2.3 Keil5与STM32烧录失败的根因排查

Keil5烧录失败是高频问题，但90%的情况与Keil本身无关。我们拆解典型场景：

场景1：ST-Link V2连接灯常亮但Keil提示“No Target Connected”

• 真因：SWDIO/SWCLK线序接反。ST-Link V2排针定义为：1-VCC, 2-SWCLK, 3-GND, 4-SWDIO, 5-RESET。若开发板26排针引脚定义不同（如粤嵌STM32F407ZET6的SWDIO在第22脚），而你按标准接法接到第4脚，必然失败。
• 验证：用万用表测SWDIO与SWCLK对地电压，正常应为1.8V~3.3V（取决于板子供电）。若为0V，检查开发板是否上电，或SWD接口是否被其他外设占用（如部分板子将SWDIO复用为UART）。

场景2：烧录时提示“Flash Download failed - Cortex-M3”

• 真因：Flash算法不匹配。Keil默认算法针对STM32F1系列，但你的板子是F407，需手动加载STM32F4xx.FLM。
• 操作：Project → Options for Target → Utilities → Settings → Flash Download → Add，选择对应芯片的FLM文件。若无此文件，从ST官网下载STM32 ST-LINK Utility，其安装目录下有完整算法库。

场景3：烧录后程序不运行，串口无输出

• 真因：启动模式配置错误。STM32F407有三种启动模式：主闪存存储器（0x08000000）、系统存储器（0x1FFFF000）、内置SRAM（0x20000000）。若BOOT0=1且BOOT1=0，芯片从系统存储器启动（即进入DFU模式），不会执行你的代码。
• 验证：用示波器测NRST引脚，复位时应有低电平脉冲。若无，检查复位电路电容是否虚焊。

实操心得：我曾遇到粤嵌GEC6818开发板在屏幕终端中文显示乱码，但在MobaXterm正常。最终发现是U-Boot环境变量console=ttyS0,115200n8未启用UTF-8，而MobaXterm在Windows端自动做了GBK→UTF-8转换。解决方案是在U-Boot中执行setenv console 'ttyS0,115200n8 earlyprintk'，然后saveenv，再重新烧录U-Boot。这说明“显示问题”常是启动链上游的配置缺失，而非应用层错误。

3. 交叉编译全流程详解：从源码到可执行镜像的每一步

3.1 交叉编译的四个阶段与关键参数

交叉编译不是一键操作，而是预处理、编译、汇编、链接四阶段流水线。每个阶段都有不可替代的作用，且参数设置直接影响最终镜像能否在开发板运行。

阶段1：预处理（Preprocessing）命令：arm-linux-gnueabihf-gcc -E hello.c -o hello.i作用：展开#include头文件、处理#define宏、移除注释。关键参数：

• -I /path/to/sysroot/usr/include：指定系统头文件路径，避免混用宿主机头文件
• -D__ARM_ARCH_7A__：定义ARM架构宏，影响条件编译分支
• -x c：强制指定输入语言为C（防止扩展名误判）

阶段2：编译（Compilation）命令：arm-linux-gnueabihf-gcc -S hello.i -o hello.s作用：将C代码转为汇编语言。关键参数：

• -march=armv7-a：指定ARMv7-A指令集，确保生成的汇编能在Cortex-A7上运行
• -mfpu=neon：启用NEON协处理器指令，提升浮点运算性能
• -mfloat-abi=hard：使用硬浮点ABI，函数参数通过浮点寄存器传递（比soft-float快5倍）

阶段3：汇编（Assembly）命令：arm-linux-gnueabihf-gcc -c hello.s -o hello.o作用：将汇编代码转为目标文件（.o）。关键参数：

• -mcpu=cortex-a7：针对Cortex-A7优化指令调度
• -O2：二级优化，平衡速度与体积（-O3可能导致栈溢出）

阶段4：链接（Linking）命令：arm-linux-gnueabihf-gcc hello.o -o hello -L/path/to/sysroot/usr/lib -lc -lgcc作用：合并目标文件，解析符号引用，生成可执行文件。关键参数：

• -T linker.lds：指定链接脚本，控制代码段（.text）、数据段（.data）、BSS段（.bss）在内存中的位置。例如i.MX6ULL的SDRAM起始地址是0x80000000，链接脚本必须将.text段定位于此。
• --static：静态链接，避免运行时依赖动态库（适合资源受限的嵌入式环境）
• -Wl,--gc-sections：删除未引用的代码段，减小镜像体积

提示：-Wl参数是将选项传递给链接器ld的开关。例如-Wl,-Map=output.map会生成映射文件，清晰显示每个函数在内存中的地址。这是分析overlap错误的核心依据——当两个段地址重叠时，map文件会明确标出冲突位置。

3.2 ESP32系列烧录地址与分区表深度解析

ESP32烧录报错overlap at 0x8000是典型的空间冲突，根源在于对Flash内存布局理解不足。ESP32的Flash不是一块空白磁盘，而是被严格划分为多个功能区：

overlap错误发生于：当你用esptool.py write_flash 0x10000 app.bin烧录应用时，若app.bin体积超过分区表中定义的app分区大小（如定义为1MB，但实际bin为1.2MB），则后续数据会覆盖0x200000开始的文件系统区域，导致overlap警告。

实操验证步骤：

1. 生成分区表：用gen_esp32part.py工具（ESP-IDF自带）从CSV生成二进制

   # Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x6000, phy_init, data, phy, 0xf000, 0x1000, factory, app, factory, 0x10000, 0x100000, storage, data, spiffs, 0x110000, 0x300000,

2. 烧录分区表：esptool.py --chip esp32 write_flash 0x8000 partition-table.bin
3. 查看分区：esptool.py --chip esp32 partition_table partition-table.bin输出显示factory分区起始0x10000，大小0x100000（1MB），确认无误。

ESP32-P4特殊处理：P4芯片采用双核Xtensa LX7，启动流程更复杂。其BootROM固定从0x0读取bootloader，但bootloader需先初始化PSRAM，再加载应用程序。若烧录时未擦除Flash，旧的bootloader可能残留，导致P4无法识别新分区表。解决方案是烧录前强制擦除：

esptool.py --chip esp32p4 erase_flash esptool.py --chip esp32p4 write_flash 0x0 bootloader.bin 0x8000 partition-table.bin 0x10000 app.bin

3.3dd命令在嵌入式烧录中的精准应用

dd是Linux下最强大的原始设备操作工具，但也是最容易误用的命令。其核心逻辑是“字节级精确复制”，不进行任何格式解析。在开发板烧录中，dd主要用于eMMC/NAND Flash的裸镜像写入，如Radxa Rock 5B+开发板的固件烧录。

典型场景：烧录eMMC启动镜像假设你有一个rock5b-ubuntu-22.04.img镜像，需写入开发板eMMC（设备名为/dev/mmcblk0）：

# 1. 卸载所有挂载点（关键！否则数据损坏） sudo umount /dev/mmcblk0* # 2. 使用dd写入（bs=4M提升速度，conv=fdatasync确保写入完成） sudo dd if=rock5b-ubuntu-22.04.img of=/dev/mmcblk0 bs=4M conv=fdatasync status=progress # 3. 强制同步缓存 sudo sync

注意：of=/dev/mmcblk0写入整个eMMC，而of=/dev/mmcblk0p1只写入第一个分区。若镜像包含分区表（如标准Ubuntu镜像），必须写入mmcblk0，否则分区结构丢失。

dd的安全防护机制：

• status=progress：实时显示进度，避免误以为卡死而中断
• conv=fdatasync：确保所有数据写入物理介质，而非仅缓存
• noerror,sync：遇到读错误继续，但同步写入（慎用，可能掩盖硬件故障）

dd的致命陷阱：

• 方向写反：if（input file）和of（output file）颠倒，会清空你的系统盘！建议用lsblk确认设备名，再执行sudo dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=100测试写入权限（写入100MB零数据，不影响分区表）。
• 块大小不匹配：bs=512（扇区大小）虽安全但极慢；bs=4M快，但若镜像大小非4M整数倍，末尾会补零。解决方案是用truncate补齐：

  truncate -s %4M rock5b-ubuntu-22.04.img

dd与专业烧录工具对比：

实操心得：我在调试AXU15EGP系列嵌入式处理器开发板时，发现dd烧录后系统无法启动。用fdisk -l /dev/mmcblk0查看分区，发现Start列显示2048（即1MB偏移），但U-Boot的bootcmd却从0x40000000加载内核。最终查明是镜像的分区表中boot分区起始地址设为0x400000，而dd写入时未对齐eMMC的擦除块大小（通常为512KB）。解决方案是用parted工具调整分区起始位置：sudo parted /dev/mmcblk0 unit MiB mkpart primary 1 100，将boot分区从1MiB开始，完美对齐。

4. 烧录与启动验证：从物理连接到应用运行的全链路检测

4.1 烧录失败的四大类原因与逐级排查法

烧录失败不是单一故障，而是启动链上任一环节断裂的结果。我总结出一套“四层剥茧法”，从物理层到应用层逐级验证，95%的问题可在10分钟内定位。

第一层：物理连接层（Physical Layer）

• 现象：烧录工具完全无法识别芯片（如esptool.py chip_id报错SerialException: could not open port）
• 排查清单：
  • USB线是否为数据线？仅充电线无法通信（实测某品牌“快充线”屏蔽了D+D-信号）
  • 开发板供电是否充足？合宙Air202 S6在烧录时需500mA电流，劣质USB口仅提供100mA，导致芯片复位
  • 26排针引脚是否氧化？用橡皮擦擦拭金手指，或更换杜邦线（我曾因一根线内部铜丝断裂，浪费3小时）
  • J-Link固件是否过期？用J-Link Commander执行exec "UpdateJLink"升级

第二层：通信协议层（Protocol Layer）

• 现象：能识别芯片ID，但烧录时超时（如J-Link: Could not connect to target）
• 排查清单：
  • SWD频率是否过高？在Keil中将Settings → SWD Clock从4MHz降至1MHz，成功率提升80%
  • 目标板是否处于复位状态？部分板子需长按RESET键再点烧录，或在Utilities → Settings → Connect中勾选Connect under reset
  • 串口流控是否开启？stlinkv2烧录stm32教程常忽略这点：若开发板UART启用了RTS/CTS，而PC端未配置，通信必断。用stty -F /dev/ttyACM0 crtscts启用硬件流控

第三层：镜像与地址层（Image & Address Layer）

• 现象：烧录成功提示“Done”，但板子无任何反应（LED不亮、串口无输出）
• 排查清单：
  • 镜像是否为正确格式？file firmware.bin确认为data（原始二进制）或ELF（可执行文件）。若为ELF，需用arm-none-eabi-objcopy -O binary firmware.elf firmware.bin转换
  • 烧录地址是否匹配启动入口？用arm-none-eabi-readelf -h firmware.bin查看Entry point address，必须与烧录地址一致。例如STM32F407的向量表起始地址是0x08000000，若readelf显示0x20000000，说明链接脚本错误
  • Flash是否已满？esptool.py flash_size detect可检测实际容量，某些山寨ESP32标称4MB，实为2MB，烧录超限必失败

第四层：启动与运行层（Boot & Runtime Layer）

• 现象：串口有输出，但卡在某一行（如U-Boot 2020.04 (May 12 2023 - 14:23:01 +0800)后停止）
• 排查清单：
  • U-Boot环境变量是否损坏？用printenv查看bootcmd，若为空则需setenv bootcmd 'run distro_bootcmd'并saveenv
  • 内核镜像是否损坏？md5sum zImage比对官网MD5值，或用zcat vmlinuz | head -c 100 | hexdump -C验证gzip头
  • 设备树（DTS）是否匹配硬件？imx6ull开发板原理图显示LCD接口为RGB888，但DTS中配置为LVDS，内核启动时会因时钟不匹配卡死

提示：怎么看esp32的烧录地址？这不是查文档，而是看partition-table.csv。该文件由ESP-IDF自动生成，明确定义每个分区的Offset。若你用Arduino IDE开发，其默认分区表路径为~/.arduino15/packages/esp32/hardware/esp32/2.0.9/tools/partitions/default.csv，打开即可看到app分区起始地址。

4.2 串口调试：嵌入式开发的“听诊器”

串口是嵌入式开发的生命线，90%的启动问题通过串口日志可直接定位。但新手常犯两个错误：一是用错波特率，二是忽略硬件流控。

波特率匹配原则：

• Bootloader阶段：U-Boot默认115200，但部分国产芯片（如GD32）为921600
• Linux内核阶段：console=ttyS0,115200n8中的115200即波特率，必须与U-Boot一致
• 应用程序阶段：若程序自己初始化UART，波特率由代码决定（如HAL_UART_Init(&huart1)中huart1.Init.BaudRate = 9600）

实测案例：三菱M80 DD磁极检测模块通信失败客户反馈模块无响应，用逻辑分析仪抓取TX信号，发现波形周期对应9600波特率，但串口助手设置115200，自然收不到数据。改为9600后，立即收到M80_OK响应。这说明：不要假设默认波特率，永远用示波器或逻辑分析仪实测。

硬件流控实战：当串口出现乱码或丢包，90%是流控问题。以STM32为例：

• 若开发板硬件设计了RTS/CTS引脚（如粤嵌GEC6818的UART2），必须启用流控
• 在Linux端：stty -F /dev/ttyUSB0 crtscts（启用RTS/CTS）
• 在Windows端：设备管理器 → 端口属性 → 流控 → RTS/CTS
• 若开发板未接RTS/CTS线，则必须禁用：stty -F /dev/ttyUSB0 -crtscts

串口日志分析技巧：

• U-Boot SPL阶段：关注Trying to boot from MMC，若此处卡住，检查eMMC驱动是否启用
• Kernel start阶段：关注Starting kernel ...后是否出现Uncompressing Linux... done, booting the kernel.，若无，说明zImage损坏
• Init process阶段：Failed to execute /init表示根文件系统缺失，Kernel panic - not syncing: VFS: Unable to mount root fs同理

4.3 固件烧录后的黄金10分钟验证清单

烧录完成后，不要急于写代码，用这10分钟做一次系统性验证，可避免80%的后续返工。

第1分钟：电源与指示灯

• 测量开发板5V/3.3V供电是否稳定（万用表DC档）
• 观察电源LED是否常亮，复位LED是否在烧录后闪烁一次

第2分钟：串口基础通信

• 连接串口，设置正确波特率（参考板子手册）
• 上电，观察是否有U-Boot或RTOS启动日志
• 若无日志，短接BOOT0/BOOT1跳线，强制进入ISP模式重试

第3分钟：网络连通性（如有网口）

• ping 192.168.1.100（开发板IP）
• telnet 192.168.1.100 23（测试Telnet服务）
• ssh root@192.168.1.100（测试SSH，密码通常为root或123456）

第4分钟：存储设备识别

• ls /dev/mmcblk*（eMMC）
• ls /dev/sd*（USB存储）
• df -h查看挂载情况，确认/根分区是否为eMMC

第5分钟：外设功能测试

• GPIO：echo 1 > /sys/class/gpio/gpio12/value，用万用表测对应引脚电压
• UART：echo "test" > /dev/ttyS1，用另一台设备接收
• I2C：i2cdetect -y 1扫描设备地址（如MPU6050应显示68）

第6分钟：图形界面（如有LCD）

• fbset查看帧缓冲参数
• fbi -T 1 -d /dev/fb0 image.jpg显示图片
• 若乱码，检查/etc/default/locale中LANG=en_US.UTF-8是否启用

第7分钟：音频测试（如有Codec）

• aplay -l