recovery模式差分(增量)升级小结

最近在做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模式升级功能其实高通已经完成了很多关键,主要的功能,我们也是简单的使用了下。

你可能感兴趣的:(linux,运维,服务器)