3、U-Boot环境变量：环境变量的作用、常用环境变量（bootargs、bootcmd）、环境变量的存储与加载

环境变量这东西，说简单也简单，说复杂也复杂。我刚开始接触U-Boot时，觉得它不就是一堆key-value嘛，有啥好研究的？后来被坑过几次才明白——环境变量是整个启动流程的指挥中心。你想想看，内核从哪启动、传给内核什么参数、根文件系统挂在哪，全由它说了算。

3.1 环境变量的作用

说白了，环境变量就是U-Boot运行时的一组全局键值对。它解决了三个核心问题：

• 解耦硬件与软件：同样的U-Boot二进制，换块Flash改个环境变量就能适配，不用重新编译。
• 动态配置启动行为：调试时改个bootargs，生产时改个bootcmd，不用烧写固件。
• 持久化用户偏好：IP地址、启动延时、默认启动项，用户改一次就能记住。

我在一个项目里遇到过这种情况：同一块板子，A批次Flash的erase block大小是128KB，B批次是256KB。如果硬编码在代码里，得维护两个版本。用环境变量存个mtdparts，一行命令搞定。这就是环境变量的价值。

3.2 常用环境变量详解

U-Boot的环境变量有几十上百个，但真正核心的就那么几个。我挑两个最重要的说——bootargs和bootcmd，这两个搞明白了，其他都是锦上添花。

3.2.1 bootargs：内核启动参数

bootargs是传给Linux内核的命令行参数。内核启动时，会解析这个字符串来配置内存、控制台、根文件系统等。格式如下：

console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootwait

每个参数的含义：

参数	含义	典型值
console	指定控制台设备及波特率	ttyS0,115200
root	根文件系统设备	/dev/mmcblk0p2
rw	以读写方式挂载根文件系统	固定
rootwait	等待根设备就绪	SD卡/MMC设备必加
init	指定init进程路径	/sbin/init
mtdparts	MTD分区信息	mtdparts=nand0:1m@0x0(boot),...

3.2.2 bootcmd：启动命令

bootcmd是U-Boot上电后自动执行的命令序列。它定义了"从哪加载、加载什么、怎么启动"的完整流程。一个典型的bootcmd长这样：

bootcmd=mmc dev 0; ext4load mmc 0:2 ${loadaddr} /boot/zImage; ext4load mmc 0:2 ${fdtaddr} /boot/board.dtb; bootz ${loadaddr} - ${fdtaddr}

拆开来看：

1. mmc dev 0 — 选择MMC设备0
2. ext4load mmc 0:2 ${loadaddr} /boot/zImage — 从分区2加载内核到内存
3. ext4load mmc 0:2 ${fdtaddr} /boot/board.dtb — 加载设备树
4. bootz ${loadaddr} - ${fdtaddr} — 启动zImage格式内核

我曾经踩过一个坑：bootcmd里忘了加rootwait，结果内核启动时MMC设备还没初始化完成，直接panic。查了两天才找到原因。嗯，这种细节最磨人。

3.3 环境变量的存储与加载

环境变量存在哪？怎么加载的？这涉及到U-Boot的存储架构。我画了张图，你看完就明白了。

整个流程分四层：

• 存储介质层：环境变量以二进制格式保存在Flash、SD卡或eMMC的特定扇区。默认偏移量由CONFIG_ENV_OFFSET定义。
• 存储驱动层：根据介质类型调用对应的驱动。比如env_sf.c操作SPI Flash，env_mmc.c操作MMC设备。
• 核心层：负责CRC校验、解析键值对、维护哈希表。U-Boot启动时会自动加载环境变量到内存。
• 运行时层：用户通过printenv、setenv、saveenv操作内存中的环境变量表。修改后必须saveenv才能持久化。

3.4 环境变量的存储格式

环境变量在存储介质中的格式其实很简单。每个变量以name=value\0的形式连续存放，最后以两个\0结尾。整个数据块前面有一个CRC32校验头。

/* 环境变量存储结构（简化版） */
struct env_header {
    u32 crc;        /* 整个数据块的CRC32校验值 */
    u8  data[];     /* 连续的 name=value\0 序列 */
};

/* 数据区示例 */
"bootargs=console=ttyS0,115200 root=/dev/mmcblk0p2 rw\0"
"bootcmd=mmc dev 0; ext4load mmc 0:2 ${loadaddr} /boot/zImage\0"
"baudrate=115200\0"
"ipaddr=192.168.1.100\0"
"\0"  /* 结束标志 */

U-Boot启动时，会先读取整个数据块，校验CRC。如果CRC不对，就使用默认环境变量（编译时硬编码在U-Boot二进制里的那份）。

3.5 环境变量的冗余与备份

有些场景下，环境变量损坏会导致设备变砖。比如Flash的某个bit翻转，CRC校验失败，U-Boot就会回退到默认环境。如果默认环境里bootcmd是空的，设备就起不来了。

为了解决这个问题，U-Boot支持冗余环境变量（redundant environment）。说白了就是存两份：

特性	单份存储	冗余存储
存储空间	1个env分区	2个env分区（A/B）
可靠性	单点故障	一份损坏自动切换
配置宏	CONFIG_ENV_IS_IN_MMC	CONFIG_ENV_IS_IN_MMC + CONFIG_SYS_REDUNDAND_ENVIRONMENT
启动行为	CRC失败→默认环境	CRC失败→切到备份→仍失败→默认环境

我参与的一个工业控制项目，要求MTBF（平均无故障时间）超过10万小时。那会儿我坚持用了冗余环境变量。后来有一批Flash出现老化，环境变量区频繁出现bit翻转，冗余机制自动切到备份，设备照常运行。嗯，这种设计投入是值得的。

3.6 环境变量的调试技巧

最后分享几个我常用的调试命令：

• printenv — 打印所有环境变量。如果某个变量没显示，说明没定义或值为空。
• setenv foo bar — 设置变量。注意等号两边不要加空格，U-Boot的解析器很死板。
• saveenv — 保存到存储介质。不执行这一步，重启后修改就丢了。
• env default -a — 恢复所有变量到默认值。慎用，会清空你的所有修改。
• env info — 查看环境变量存储状态，包括CRC是否有效、是否使用冗余备份。