从SD卡到EMMC：u-boot烧写全流程实战与避坑指南

1. 从零开始：理解u-boot与存储介质的关系

第一次接触嵌入式开发的朋友，可能会对u-boot这个名词感到陌生。简单来说，u-boot就像是开发板的"开机键"，负责最基础的硬件初始化、加载操作系统等任务。它通常存储在开发板的非易失性存储器中，比如EMMC或者SD卡。这就好比电脑的BIOS，只不过在嵌入式领域我们更习惯称之为bootloader。

在实际项目中，我们经常会遇到这样的场景：拿到一块全新的开发板，需要将u-boot从最初的SD卡媒介，最终固化到板载EMMC中。为什么要这么做呢？因为SD卡更适合作为临时启动介质，而EMMC则更适合长期稳定运行。就像我们平时使用电脑，安装系统时会先用U盘启动，最后把系统装到硬盘里是一个道理。

在开始操作之前，我们需要准备以下硬件：

• 开发板（支持SD卡和EMMC启动）
• SD卡（建议8GB以上）及读卡器
• 网线（用于TFTP传输）
• 电源适配器
• 串口调试工具

软件方面则需要：

• u-boot镜像文件（通常由厂商提供或自行编译）
• Win32DiskImager（Windows平台）
• dd命令工具（Linux平台）
• TFTP服务器软件
• 串口终端工具（如Putty、Minicom）

2. Windows环境下SD卡烧写实战

对于Windows用户来说，使用Win32DiskImager是最简单的入门方式。这个绿色软件无需安装，下载后直接运行即可。不过在使用过程中有几个关键点需要注意：

首先，插入SD卡前建议先格式化，确保没有残留数据。我遇到过好几次因为SD卡原有分区表导致烧写失败的情况。格式化时选择FAT32格式，分配单元大小保持默认即可。

打开Win32DiskImager后，软件界面非常简洁。点击文件夹图标选择u-boot镜像文件（通常是.bin或.img后缀），然后在右侧设备下拉菜单中选择对应的SD卡盘符。这里有个大坑：一定要确认选择的盘符确实是你的SD卡，而不是系统硬盘！我曾经不小心选错了盘符，差点把系统盘给覆盖了。

点击"写入"按钮后，软件会弹出警告提示。确认无误后，写入过程通常只需要几秒钟。完成后不要急着拔出SD卡，建议点击"退出"按钮安全移除设备。这时候如果你查看SD卡的属性，可能会发现容量变小了，这是因为写入过程覆盖了原有的分区表，属于正常现象。

测试阶段，将SD卡插入开发板，设置从SD卡启动（具体方法参考开发板手册），通过串口终端应该能看到u-boot的启动信息。如果卡在某个步骤不动，可能是镜像文件不匹配或者烧写过程出现问题，需要重新检查。

3. Linux下的高级烧写方式

对于习惯使用Linux的开发者，dd命令提供了更灵活的控制选项。与Windows下的傻瓜式操作不同，dd命令需要手动指定各种参数，这也意味着更高的出错概率。下面我就详细解释下这个"磁盘销毁者"命令的正确用法。

首先插入SD卡前，先在终端执行：

bash复制ls /dev/sd*

记住当前的设备列表。插入SD卡后再次执行该命令，新增的设备就是你的SD卡，通常是/dev/sdb或/dev/sdc。千万不要搞错设备名，否则可能导致系统盘数据丢失。

完整的烧写命令如下：

bash复制sudo dd if=u-boot.bin of=/dev/sdb bs=512 seek=1 conv=sync

这个命令的每个参数都很有讲究：

• if：输入文件，指定u-boot镜像路径
• of：输出设备，必须是SD卡的设备文件
• bs：块大小，SD卡通常使用512字节
• seek：偏移量，设置为1表示跳过第一个512字节块
• conv=sync：确保数据完全同步写入

seek=1这个参数特别重要，它让u-boot从第二个块开始写入，避开了第一个块的分区表区域。这也是Linux下烧写和Windows烧写的主要区别：Windows方式会覆盖整个开头区域，而Linux方式可以精确定位。

烧写完成后，同样需要通过串口终端验证是否成功启动。如果遇到问题，可以尝试以下排查步骤：

1. 确认镜像文件是否完整（md5sum校验）
2. 检查SD卡是否接触良好
3. 确认开发板启动顺序设置正确
4. 查看串口输出信息，定位卡在哪一步

4. 进阶：将u-boot迁移到EMMC

当我们在SD卡上验证u-boot工作正常后，下一步就是把它永久烧写到EMMC中。这个过程需要通过网络（TFTP）将u-boot镜像加载到内存，再写入EMMC。听起来复杂，但跟着步骤走其实很简单。

首先确保开发环境满足以下条件：

• 开发板与主机在同一局域网
• 主机已配置TFTP服务器
• u-boot镜像已放在TFTP目录
• 开发板能通过SD卡启动到u-boot命令行

在u-boot命令行中，依次执行以下命令：

bash复制tftp 0x40000000 u-boot.bin
update_mmc 2 2ndboot 0x40000000 0x200 0x60000

第一条命令通过TFTP将u-boot.bin下载到内存地址0x40000000处。传输完成后会显示字节数，这个数字很重要，后面写入EMMC时要用到。

第二条命令的update_mmc参数需要重点解释：

• 第一个参数2表示EMMC设备编号（通过mmc list查询）
• 2ndboot表示写入类型
• 0x40000000是内存源地址
• 0x200是EMMC目标地址偏移
• 0x60000是要写入的长度

这里最容易出错的就是地址和长度的设置。我遇到过好几次因为长度设置太小导致写入不完整，或者地址错误导致写入失败的情况。建议在设置长度时，取比TFTP传输显示的字节数更大的值，一般取整到0x10000的倍数比较安全。

写入完成后，将开发板设置为从EMMC启动，如果能看到u-boot启动信息，就说明迁移成功了。这时候SD卡就可以取出来，开发板以后都会从EMMC启动了。

5. 常见问题与解决方案

在实际操作过程中，难免会遇到各种"坑"。下面我就分享几个最常见的错误及其解决方法：

问题一：SD卡烧写后无法启动
可能原因：

1. 镜像文件不匹配（确认是否针对该开发板编译）
2. 烧写过程出错（重新烧写并验证md5）
3. 启动模式设置错误（检查开发板跳线）

问题二：TFTP传输失败
排查步骤：

1. 确认网络连接正常（ping测试）
2. 检查TFTP服务器配置（防火墙设置）
3. 确认文件名和路径正确（区分大小写）

问题三：update_mmc命令报错
典型错误信息：

code复制Fail: start 0 block(0x0) is in MBR zone (0x200)

解决方法：
将目标地址从0x0改为0x200，因为EMMC的前0x200块是保留区域。

问题四：写入EMMC后启动卡住
可能原因：

1. 写入长度不足（增加length参数值）
2. EMMC分区损坏（尝试擦除后重新写入）
3. 电压不稳导致写入错误（检查电源供应）

对于更复杂的问题，建议采取以下调试方法：

1. 提高u-boot的调试级别（setenv verbose 1）
2. 使用md命令查看内存内容
3. 对比正常和异常时的串口输出
4. 在开发者社区搜索类似案例

6. 优化与进阶技巧

当掌握了基本操作后，可以尝试一些进阶技巧来提升效率：

技巧一：自动化脚本
将常用命令写成u-boot脚本：

bash复制setenv bootcmd 'tftp 0x40000000 u-boot.bin; update_mmc 2 2ndboot 0x40000000 0x200 0x60000'
saveenv

这样每次启动都会自动执行烧写流程。

技巧二：批量烧写
对于生产环境，可以使用dd命令的变种：

bash复制cat u-boot.bin | pv | sudo dd of=/dev/sdb bs=512 seek=1 conv=sync

加入pv可以显示进度，适合大容量烧写。

技巧三：备份恢复
在修改前先备份原始u-boot：

bash复制sudo dd if=/dev/sdb of=backup.bin bs=512 count=2048

出现问题时可快速恢复。

技巧四：性能优化
调整bs参数可以提升烧写速度：

bash复制sudo dd if=u-boot.bin of=/dev/sdb bs=1M seek=1 conv=sync

但要注意bs值不能超过设备支持的最大值。

最后提醒一点：所有关键操作前都要做好备份，特别是对EMMC进行操作时。我见过太多因为操作失误导致开发板变砖的案例了。虽然大部分情况下可以通过SD卡恢复，但预防总是好过补救。