最近在做recovery模式下的升级，简单的总结一下。
先说说recovery模式，他是个升级小系统，有单独的kernel，通过特定的系统命令就可以进入到此系统中，选择进入正常系统的kernel还是recovery系统的kernel，决定在于bootloader中，recovery中的boot与正常系统的boot烧写的是相同的kernel，不同点在于，recovery模式有一个单独的rootfs，这个是一个非常小的系统，系统的很多功能也是不启动的， 主要目的就是留给升级流出足够的内存，主系统与recovery系统通信的桥梁就是/cache分区，此分区在正常系统启动与recovery模式都是要被挂载mount。在主系统写命令到cache中，在recovery中读取，升级后，升级结果及日志也是在cache中。
recovery系统中大致流程，有些觉得不重要就省略了
1、执行find_recovery_partition.sh脚本它的工作就是生成/res/recovery_volume_detected文件，很重要的，挂载分区，attach类型为ubi的分区，如system modem。
2、rc启动脚本主要是启动了调用recovery进程的脚本，此脚本中运行recovery进程，升级的所有功能就在recovery进程中完成，recovery进程中涉及到的load_volume_table() 函数，读取的文件就是由find_recovery_partition.sh脚本生成的。
3、读取升级命令，升级命令位于/cache/recovery/command中，格式可以看函数注释。在此过程中会写misc分区一个msg，主要是防止升级过程中掉电，在lk中会读取misc中的msg，如果升级中异常掉电，系统加载起来之后就继续进入recovery模式进程升级。
4、接下来就是从升级包重获取可执行程序，读取到/tmp中，升级包签名校验，本项目没涉及到不多说，然后就是创建管道，创建子进程，子进程中执行updater进程。将进度，结果等通知到主进程，直到升级结束。
5、updater进程的执行过程，有太多的文件讲了及就不讲了。
6、升级结束后，finish_recovery做收尾工作，拷贝日志，写升级结果，然后系统reboot。
7、重启后，主系统正常启动后，就可以从cache中获取到当前升级的结果，日志，升级包等。
遇到的一些问题：
1、对nand来说，存在flash层的操作与mtd层的操作，lk中是对flash的操作可以按照页，页大小有2048/4096，mtd层对block操作的，一般都是好多个页组成，如64*2048，作为一个block。有个分区比较特殊，不能多写flash，因为就是recovery中是mtd层的操作，想要精确，只能在lk中去做，比较特殊。
2、使用的打包工具，高人写了脚本，可以将modem分区按照ubi的方式打包，很是厉害啊，对比了下文件展开方式，升级包比较小，升级还快，真实佩服啊。
3、整个recovery模式升级功能其实高通已经完成了很多关键，主要的功能，我们也是简单的使用了下。