最近在做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模式升级功能其实高通已经完成了很多关键，主要的功能，我们也是简单的使用了下。
10-24 新增流程图
简单说明
1、流程图中省略也很多细节，其实好多细节都是可以拿出来大写特写，比如差分文件是如何计算生成的（涉及imgdiff 与bsddiff），对于有文件系统的文件权限的处理
（full package时更关心一点） updater-script脚本用于执行的脚本解析器的运行，等等
2、标注红色的部分是我认为比较关键和重要的部分，包括为说明的updater-script每条命令对应的回调函数。
3、可能不同的应用场景不一样，当前没有将ui部分的逻辑，还有升级前的条件检查处理，升级异常等等。
4、recovery进程执行结束之后会执行收尾工作，保存日志，写升级结果等等，然后就是syse_reboot,图中带recovery 的块其实就是在recovery进程中执行的， 按照函数
调用顺序写的。
长按二维码关注【嵌入式C部落】，获取更多编程资料及精华文章