uboot环境变量saveenv学习

命令操作的简单回顾：

当设置完环境变量之后，如果执行了saveenv的话，则下次重新运行的时候环境变量则会被保存为上次保存的值，如果不保存，只会在设置好时还没重启之前生效，重启之后设置值会恢复成原来的值。
执行save/saveenv之后会出现（对于我这块开发板）
Saving Environment to SMDK bootable device…

从代码开始分析
为什么是 SMDK bootable device？

同样，通过U_BOOT_CMD这个宏，通过函数指针的方法，去执行do_saveenv函数

do_saveenv

注意：env_name_spec，根据现象得知，env_name_spec = SMDK bootable device
当我试图通过查找env_name_spec的时候，发现有很多个定义

不同的启动介质的话应该要对应不同的env_xxx.c文件，有movinand-三星的emmc
inand -sandisk的emmc
onenand -三星的一种nand
……
movinand和inand有啥区别,onenand呢？
链接: MoviNAND 和iNand一样，其实是emmc 标准的一种！
所以moviNAND 就是和iNand 一样的，甚至是兼容的东西，只是估计三星棒子价格比较贵，大家都选择sandisk的emmc iNand了。
.

根据现象会发现这里用的env_auto.c文件，为什么呢？
课程视频里面讲，这是因为在x210_sd.h头文件里面进行了定义，

定义了CFG_ENV_IS_IN_AUTO这个宏
所以对于env_auto.c文件的条件编译

成立，所以文件能用
对于其他的文件，例如onenand

因为没有定义这个宏，所以不能用。

从这里也可以看出uboot真的是一个整体，头文件.h、链接脚本.lds、Makefile、config.mk文件等等，都是有关联的。有时候代码里找不到的定义或者其他，可能就在别的文件里面。

回到do_saveenv的下一句return语句里面。
最终是调用了saveenv这个函数

saveenv在env_auto.c里面。
这里用了很多条件编译来判断到底使用哪个函数。有
saveenv_nand
saveenv_movinand
saveenv_onenand
……
这里x210是s5pc110的衍生出来的，肯定进入这里

再判断INF_REG3_REG到底是等于几?

INF_REG3_REG
我查看之前写的纸质笔记，INF_REG3_REG在start.S里面有操作过这个寄存器
回顾一下： 目的是知道INF_REG3_REG
看看下面截图的代码做了什么?
读取启动信息，看是从什么介质启动，然后最终是实现BL2的重定位。

1.通过读取启动信息，把得到的启动介质的信息放在r2寄存器里面

2.通过比较得知是SD卡启动的，即r2=0xc成立，所以mov语句起作用，
把BOOT_MMCSD宏对应的值放在r3寄存器里面 即r3里面存的是0x3
3.把r3寄存器里面的值写入INF_REG3_REG寄存器里面，即告诉开发板我的启动介质是什么东西。即INF_REG3_REG里面存了0x3

4.这里再去比较INF_REG3里面存的是哪个启动介质的信息。
上一步得知INF_REG3_REG里面存了0x3
之前得知#BOOT_MMCSD也是0x3
两者匹配了之后。
所以就跳转到mmcsd_boot函数里面去执行

5.mmcsd_boot里面进行重定位。

回顾过后
得到INF_REG3_REG里面存的就是0x3，也就是start.S开头一顿操作放在r2寄存器里面的启动信息。
所以在saveenv里面又跳转到saveenv_movinand函数里面去执行

env_ptr的值就是存储环境变量数组的地址

通过movi_write_env函数，把从这个地址里面的值写入sd卡里面

raw_area_control是uboot中规划iNnad/SD卡的原始分区表，这个里面记录了我们对iNand的分区，env分区也在这里，下标是2.追到这一层就够了，再里面就是调用驱动部分的写SD卡/iNand的底层函数了。

总结：

所以整个操作就是把环境变量的值写入SD卡里面进行保存。
当下一次开机的时候又可以把保存好的信息从SD卡里面读入。

通过一系列的代码分析、追溯，发现其实真的是一个整体，一个saveenv命令不仅仅跟它实现的函数有关，还有跟start.S里面关于启动介质的判断有关，还跟SD卡有关等等。而且最终还是围绕着default_environment[]这个数组。