i.MX6ULL SD卡启动盘制作避坑指南：为什么你的uboot烧录后没反应？

i.MX6ULL SD卡启动盘制作避坑指南：为什么你的uboot烧录后没反应？

当你按照网上的教程一步步操作，却发现开发板毫无反应时，那种挫败感我深有体会。LED不亮、串口无输出，仿佛所有努力都石沉大海。这不是你一个人的困境——事实上，i.MX6ULL的SD卡启动过程中藏着几个关键陷阱，稍有不慎就会导致整个流程失败。本文将带你直击问题核心，从失败场景反推解决方案。

1. 分区起始扇区：被忽视的致命细节

大多数教程会告诉你分区起始扇区是20480，但很少有人解释为什么是这个数字。实际上，这个值直接关系到uboot能否被正确加载。i.MX6ULL的ROM代码在启动时会严格检查这个位置。

1.1 扇区计算背后的硬件逻辑

NXP官方文档中明确要求uboot必须存放在扇区2到20479之间（共20478个扇区）。这是因为：

• 扇区0：保留给分区表
• 扇区1：保留给扩展引导记录
• 扇区2开始：uboot镜像区域

使用fdisk分区时常见的错误操作：

# 错误示例：起始扇区设置错误 fdisk /dev/sdb n (新建分区) p (主分区) 1 (分区号) 2048 # ← 错误！应该用20480 +500M

正确的分区参数对照表：

提示：使用fdisk -l确认分区起始位置时，注意观察"Start"列的值是否精确匹配20480

2. dd命令的魔鬼参数：bs与seek的精准配合

即使分区正确，uboot烧写阶段的参数错误同样会导致启动失败。那个看似简单的dd命令里藏着两个关键陷阱。

2.1 bs参数的单位陷阱

常见错误是混淆了块大小单位：

# 危险操作：块大小单位错误 dd if=u-boot.imx of=/dev/sdb bs=512 seek=2 # 使用512字节单位

这会导致：

1. 写入位置偏移量计算错误
2. 可能破坏分区表结构

正确的命令应该是：

# 标准写法：使用1K块大小 dd if=u-boot.imx of=/dev/sdb bs=1k seek=1 conv=fsync

参数解析：

• bs=1k：每次读写1KB（对应SD卡2个扇区）
• seek=1：跳过输出文件开头的1KB（即从扇区2开始写入）
• conv=fsync：确保数据完全写入物理介质

2.2 验证烧写结果的技巧

执行后不要急着拔卡，先用这些命令验证：

# 检查写入的字节数 stat -c %s u-boot.imx # 对比SD卡内容 hexdump -n 1024 -C /dev/sdb | head -20 hexdump -n 1024 -C u-boot.imx | head -20

3. 内核与设备树的匹配难题

当uboot成功加载却卡在后续阶段时，问题往往出在内核与设备树的搭配上。我见过太多开发者在这步栽跟头。

3.1 文件位置验证清单

确保FAT分区包含以下文件且命名正确：

• zImage（内核镜像）
• imx6ull-*.dtb（设备树二进制文件）

常见错误场景：

1. 文件放错了分区（应该在第一FAT分区）
2. 设备树文件与硬件版本不匹配
3. 文件名大小写错误（Linux区分大小写）

使用以下命令验证：

# 挂载检查 mkdir -p /mnt/sd mount /dev/sdb1 /mnt/sd ls -lh /mnt/sd umount /mnt/sd

3.2 设备树选择矩阵

不同开发板对应的设备树文件：

注意：同一个.dtb文件可能有多个变体（如带/不带emmc版本）

4. 文件系统完整性的终极验证

当系统启动到挂载根文件系统阶段失败时，问题可能出在文件系统解压过程。以下是常见问题排查点：

4.1 解压过程的三重保险

1. 使用-j参数处理.bz2压缩包：

   tar -jxvf rootfs.tar.bz2 -C /mnt/sd

2. 保留文件权限：

   cp -a rootfs/* /mnt/sd/

3. 强制同步写入：

   sync

4.2 空间不足的隐蔽症状

即使分区大小足够，以下情况仍会导致问题：

• SD卡实际容量小于标称值（假冒存储卡）
• 文件系统开销占用额外空间
• 解压临时文件耗尽内存

检查命令：

# 查看分区使用情况 df -h /mnt/sd # 验证SD卡真实容量 fdisk -l /dev/sdb | grep Disk

5. 硬件相关的隐藏陷阱

有时候问题不在软件操作，而是硬件特性在作祟。这些细节往往被教程忽略。

5.1 启动模式引脚配置

i.MX6ULL的启动模式由BOOT_MODE[1:0]引脚决定：

• 00：保留
• 01：串行下载模式
• 10：内部BOOT模式
• 11：保留

验证方法：

1. 检查开发板原理图
2. 确认跳线帽位置
3. 测量引脚电压（应为3.3V或0V）

5.2 SD卡槽的兼容性问题

某些廉价读卡器或SD卡可能导致：

• 数据传输不稳定
• 识别为只读设备
• 供电不足导致写入失败

推荐配件组合：

• 读卡器：川宇C362
• SD卡：SanDisk Extreme 16GB
• 供电：独立5V/2A电源

6. 终极诊断工具：串口调试技巧

当所有操作都正确却仍无法启动时，串口控制台是最后的救命稻草。

6.1 串口配置黄金参数

# Linux下minicom配置 sudo minicom -s

设置参数：

• 波特率：115200
• 数据位：8
• 停止位：1
• 无校验
• 无流控

6.2 关键启动日志解读

正常启动流程中的关键消息：

U-Boot 2020.04 (Jun 15 2022 - 15:30:25 +0800) CPU: Freescale i.MX6ULL rev1.1 792 MHz (running at 396 MHz) DRAM: 512 MiB MMC: FSL_SDHC: 0 Loading Environment from MMC... OK In: serial Out: serial Err: serial Net: FEC0

异常情况分析：

• 无任何输出：uboot未运行
• 卡在DRAM初始化：DDR配置错误
• 找不到MMC设备：SD卡识别失败

7. 制作流程优化：一键化脚本方案

为避免手动操作失误，我整理了这个自动化脚本：

#!/bin/bash # 参数检查 if [ $# -ne 4 ]; then echo "用法: $0 <uboot镜像> <内核镜像> <设备树> <根文件系统>" exit 1 fi UBOOT=$1 KERNEL=$2 DTB=$3 ROOTFS=$4 # 确认设备 echo "可用磁盘：" lsblk read -p "输入SD卡设备(如/dev/sdb): " DEVICE # 分区处理 echo "正在分区..." sudo umount ${DEVICE}* 2>/dev/null sudo fdisk $DEVICE <<EOF o n p 1 20480 +500M n p 2 1228800 w EOF # 格式化 echo "格式化分区..." sudo mkfs.vfat ${DEVICE}1 sudo mkfs.ext4 ${DEVICE}2 # 烧写uboot echo "烧写uboot..." sudo dd if=$UBOOT of=$DEVICE bs=1k seek=1 conv=fsync # 拷贝内核 echo "拷贝内核..." sudo mount ${DEVICE}1 /mnt sudo cp $KERNEL /mnt/zImage sudo cp $DTB /mnt/ sudo umount /mnt # 解压根文件系统 echo "处理根文件系统..." sudo mount ${DEVICE}2 /mnt sudo tar -jxvf $ROOTFS -C /mnt sudo umount /mnt echo "SD卡制作完成！" sync

使用方式：

chmod +x make_sd.sh ./make_sd.sh u-boot.imx zImage imx6ull.dtb rootfs.tar.bz2

8. 替代方案：TFTP网络启动调试

当反复SD卡启动失败时，可以先用网络启动验证系统完整性：

8.1 环境搭建步骤

1. 配置开发板IP：

   setenv ipaddr 192.168.1.100 setenv serverip 192.168.1.1 saveenv

2. 主机搭建TFTP服务器：

   sudo apt install tftpd-hpa sudo systemctl restart tftpd-hpa

3. 通过uboot加载：

   tftp 80800000 zImage tftp 83000000 imx6ull.dtb bootz 80800000 - 83000000

8.2 网络启动优势对比

最后提醒：完成调试后，别忘了将启动模式切换回SD卡启动。有时候最复杂的问题，往往是最简单的设置错误导致的。