U-Boot MMC读写命令实战：从参数解析到数据完整性校验

1. 环境准备与命令初探：你的U-Boot工具箱

大家好，我是老李，在嵌入式这行摸爬滚打十几年了，调试过的板卡少说也有上百款。今天咱们不聊那些虚头巴脑的理论，就聊一个嵌入式开发者在调试阶段几乎每天都会遇到的“硬核”操作：在U-Boot里，如何精准、安全地读写板载的eMMC或者SD卡。你可能觉得这不就是几条命令吗？但据我观察，很多新手朋友在操作时，要么地址算错，要么数据对不上，最后烧录的固件启动不了，排查起来一头雾水。这篇文章，我就带你从最基础的命令参数开始，一步步构建一个“傻瓜式”但绝对可靠的验证闭环，确保你每次写入eMMC的数据，都和你想的一模一样。

首先，咱们得搞清楚战场在哪。U-Boot，这个在Linux内核启动前运行的“小系统”，是我们操作硬件最直接的窗口。而mmc read和mmc write，就是我们手里的两把“手术刀”。别被它们的简单语法迷惑了，用好了事半功倍，用错了可能就是“板砖”一块。你需要准备的东西很简单：一块已经能正常启动到U-Boot命令行界面的开发板，一根串口线，以及一颗不怕折腾的心。我强烈建议你跟着我的步骤，在自己的板子上敲一遍，这比你读十遍文章都管用。

在开始之前，咱们先统一一下认知。U-Boot里操作存储设备，最核心的就是mmc这个命令家族。我们今天聚焦的mmc read/write，是针对块设备的读写。什么叫块设备？你可以把它想象成一个巨大的、被切分成无数个标准小方块（扇区）的仓库。在MMC（包括eMMC、SD卡）的世界里，这个标准小方块的大小通常是 512字节。这是所有计算的基石，务必记住！我们所有的操作，无论是读还是写，都是以这个“小方块”为基本单位进行的。所以，当你看到命令里的blk#和cnt时，脑子里要立刻反应：这是“第几个方块”和“要操作几个方块”。

2. 庖丁解牛：深度解析 mmc read/write 的每一个参数

很多教程只告诉你命令格式，却不讲为什么，这就像只给你一把枪却不教你怎么瞄准。咱们这一节就来当一回“庖丁”，把mmc read和mmc write这两个命令的每个参数都拆解得明明白白。

2.1 mmc read：把数据从“仓库”搬进“内存”

命令格式看起来非常简单：

mmc read <addr> <blk#> <cnt>

但这三个参数，每一个都至关重要。

• <addr>：内存目标地址。 这是数据从MMC读出来后，在系统内存（RAM）里的“临时存放点”。你可以把它想象成你家门口的快递暂存柜。这个地址必须是你的板子当前可用的、未被系统占用的内存地址。怎么知道哪些地址可用？这取决于你的硬件内存布局。通常，开发板厂商的文档会告诉你一段“安全”的内存区域，比如0x82000000往后的一段空间。我个人的习惯是，在板子启动后，先用bdinfo命令查看一下内存信息，找一个远离内核加载地址和设备树地址的高位地址，比如0x90000000，这样不容易冲突。

• <blk#>：起始块号（扇区号）。 这是MMC这个“大仓库”里的“第几个小方块”。这里的数字是扇区编号，不是字节地址！ 这是新手最容易栽跟头的地方。比如，你想读取MMC物理地址0x80000（十六进制，即524288字节）开始的数据，该怎么算？很简单，用字节地址除以扇区大小（512字节，即0x200）。所以，blk# = 0x80000 / 0x200 = 0x400。也就是说，你需要执行的命令是mmc read 0x90000000 0x400 ...，而不是