最近做Recovery的规范及操作指导文档，花了一些时间将流程搞清。

Android利用Recovery模式，进行恢复出厂设置，OTA升级，patch升级及firmware升级。而在进入Recover前面其实还有升级检测，数据下载，启动检查等等操作。系列文章将会将整个流程梳理清楚。

1、Android启动流程

简要的流程图示，升级到新的版本或指定版本：

系统上电时的详细检测流程图：

下面我们从代码的情况简略分析一下：

机顶盒上电一般都是从地址 0x00000000 处开始启动，此时启动的程序叫 boot ，在linux上使用最多一般是 Uboot ，我们找到main函数：

Start.s文件：

.globl _start

_start:

b reset

做一些 bootstrap_check --> bootstrap --> check_boot_mode  etc 

最后：

ldr pc, _start_armboot  @ jump to C code 

跳转到C代码，类似就是main函数

void start_armboot (void)   首先做一些各种各式的硬件初始化，如 arch_cpu_init 、 board_init、interrupt_init、env_init 等

然后做一些开机启动的画面显示（开机动画也可以在此做）--> load_recovery() 这里就是决定是进行 Recovery 还是进行 Normal 的开机流程最重要入口函数

void load_recovery(void){

if (!strcmp(boot_select(), "kernel"))   // 进入检测参数ng

return;

check_buttom_recovery(&keycode)

        if(keycode == RECOVERY_KEY){  // 确认有长按键强制升级

              load_recovery_image();

        }

}

如何检测参数呢？参考的信息从哪里来，这里就有必要引入分区概念了。这里使用的都是 NAND FLASH ,对于其管理可以参考如下文章：

下列给出一个常用的android上分区表图：（常见的分区表，可根据项目另行修改大小及分区情况）

需要注意的是： NAND Flash 分区占用必须以 block size 为单位，并且要考虑分区的差错，坏块，建议容错块 30%,最小2个容错块。所以如果定义访问者有多个用户情况下，读取与写数据保持一致情况下，定义数据结构，预留30%分区空间，进行整个分区的读和写，这样子可以省去关注坏区情况，简化上层逻辑操作。

对于如何选择是启动正常的 "kernel "还是 "recovery"，就是读取 misc 分区中的内容根据情况决定启动哪个。核心代码如下：

const char *boot_select(void)

{

HI_Flash_OpenByName("MISC");

        HI_Flash_Read(h,offset,buf,len);

        memcmp(buf,"boot-recovery",..); 还是 memcmp(buf,"kernel",..);

return "kernel" / "recovery";

}

另个一种模式就是长按键强制选择：

static int check_buttom_recovery( HI_U32 *keyvalue)

{

       HI_KEYLED_Open()

        HI_KEYLED_GetValue(&u32PressStatus, &u32KeyValue);

        while(u32KeyValue == RECOVERY_KEY){

                  udelay(1000);

                  if (s32Cnt >= MAX_KEY_PRESS_COUNT)

break;

                  s32Cnt++;

        }

｝

ok, 开机启动选择进入的模式流程基本搞定。下一遍进行 Recovery 代码继续分析。