[Android]高通平台BootLoader启动流程

一、什么是BootLoader

BootLoader代码是芯片复位后，进入操作系统之前执行的一段代码。主要用于完成由硬件启动到操作系统启动的过渡，从而为操作系统提供基本的运行环境。

BootLoder主要的启动流程可以概括为：PBL阶段、SBL阶段、LK阶段。之后会加载并启动kernel。

二、名词解释

5个处理器：

APPS ：Cortex A53 core(MSM8953)，运行android。
RPM(Resource Power Manager)：CortexM3 core，主要用于低功耗应用。
Modem(MSS_QDSP6) ：高通自有指令集处理器，处理3G、4G通信协议等。
Pronto(WCNSS)：处理wifi相关代码。
LPASS ：音频相关。

启动相关：

PBL（Primary Boot Loader）：位于芯片内ROM中，是芯片上电后执行的真正第一行代码，在正常启动流程中会加载SBL1。如果启动异常会虚拟出9008端口可用于 Emergency download（短接板子上的force_boot_from_usb引脚(MSM8953 为gpio37)到1.8v可以强制进入紧急下载模式）。（此段代码封装在芯片内部，并不开源）
SBL1 (Second BootLoader stage 1) ：位于eMMC中，由PBL加载，初始化buses、DDR、clocks等。
QSEE/TrustZone 安全相关。
Debug Policy 调试相关。
APPSBL ：即为BootLoader，目前使用LK（little kernel）。
HLOS (High LevelOperating System) 即为Linux/Android。

三、启动流程

AP侧CPU上电。
在芯片内部ROM的PBL首先运行，PBL会从boot device(eMMC)中加载并验证SBL1到TCM中。这里的TCM可以理解为CPU的二级缓存。既然PBL能够从boot device(eMMC)中加载SBL1，那PBL应该是初始化过boot device的。
SBL1初始化DDR，并从boot device中加载并且校验如下镜像： QSEE或者TZ镜像、QHEE镜像、RPM_FW、镜像、APPSBL等。
SBL1加载并验证完上述镜像后，即将执行权转移到QSEE中，QSEE将设置并初始化一个安全的执行环境。
QSEE通知RPM去执行RPM_FW相关代码。
QSEE将执行权转移到APPSBL中，APPSBL也就是LK。
LK加载HLOS的kernel。

四、代码流程简要流程

SBL

PBL部分并不开源，所以从SBL开始。

sbl1入口： sbl1.s

此部分代码路径在：boot_images/core/boot/secboot3/hw/msm89xx/sbl1/sbl1.s，此文件引导处理器，主要有实现如下操作：

部分源码：

设置硬件，继续boot进程。
初始化ddr。
加载Trust_Zone操作系统。
加载RPM固件。
加载APPSBL然后继续boot进程。

IMPORT |Image$$SBL1_SVC_STACK$$ZI$$Limit|
IMPORT |Image$$SBL1_UND_STACK$$ZI$$Limit|
IMPORT |Image$$SBL1_ABT_STACK$$ZI$$Limit|
IMPORT boot_undefined_instruction_c_handler
IMPORT boot_swi_c_handler
IMPORT boot_prefetch_abort_c_handler
IMPORT boot_data_abort_c_handler
IMPORT boot_reserved_c_handler
IMPORT boot_irq_c_handler
IMPORT boot_fiq_c_handler
IMPORT boot_nested_exception_c_handler
IMPORT sbl1_main_ctl #主要关注此函数
IMPORT boot_crash_dump_regs_ptr
...

sbl1_main_ctl函数

路径：...\sbl1\sbl1_mc.c

/* Calculate the SBL start time for use during boot logger initialization. */
sbl_start_time = CALCULATE_TIMESTAMP(HWIO_IN(TIMETICK_CLK));
boot_clock_debug_init();
/* Enter debug mode if debug cookie is set */
sbl1_debug_mode_enter();
/* Initialize the stack protection canary */
boot_init_stack_chk_canary();/* Initialize boot shared imem */
boot_shared_imem_init(&bl_shared_data);
/*初始化RAM*/
boot_ram_init(&sbl1_ram_init_data);
/*初始化log系统，即串口驱动*/
sbl1_boot_logger_init(&boot_log_data, pbl_shared);
/*检索PBL传递过来的数据*/
sbl1_retrieve_shared_info_from_pbl(pbl_shared);
/* Initialize the QSEE interface */
sbl1_init_sbl_qsee_interface(&bl_shared_data,&sbl_verified_info);
/* Initialize SBL memory map. Initializing early because drivers could be located in RPM Code RAM. */
sbl1_populate_initial_mem_map(&bl_shared_data);
/*初始化DAL*/
boot_DALSYS_InitMod(NULL);
/*配置PMIC芯片，以便我们能通过PS_HOLD复位*/
sbl1_hw_init();
/*执行sbl1的目标依赖进程*/
boot_config_process_bl(&bl_shared_data, SBL1_IMG, sbl1_config_table);

sbl1_config_table函数

路径：boot_images\core\boot\secboot3\hw\msmxxxx\sbl1\sbl1_config.c

sbl1_config_table为一个结构体数组，里面存储了加载QSEE、RPM、APPSBL等镜像所需要的配置参数及执行函数。

boot_configuration_table_entry sbl1_config_table[] =
{/* SBL1 -> QSEE */{SBL1_IMG,                   /* host_img_id */CONFIG_IMG_QC,              /* host_img_type */GEN_IMG,                    /* target_img_id */CONFIG_IMG_ELF,             /* target_img_type */...load_qsee_pre_procs,        /* pre_procs */ load_qsee_post_procs,       /* post_procs */
}
/* SBL1 -> QHEE */
...
/* SBL1 -> RPM */
...
/* SBL1 -> APPSBL （即lk部分） */
...

LK

LK大概流程：

bootloader/lk目录结构：

进行各种早期的初始化工作，包括 cpu, emmc, ddr, clocks, thread 等。
判断进入 recovery 或 fastboot 的条件是否被触发，不触发则为Normal Boot。
从 emmc 中获取 boot.img 并加载到指定内存区域 (scratch region)。
加载Kernel、Ramdisk、DeviceTree等到指定地址。
引导Kernel

-app        #应用相关
-arch       #arm体系、CPU架构
-dev        #设备驱动
-images     #image图片资源
-include    #头文件
-kernel     #LK系统、主文件，main.c
-lib        #库文件
-platform   #平台文件，如：msm8916
-project    #mk文件
-scripts    #脚本文件
-target     #目标设备文件

代码流程：

lk 是使用 arm 汇编 和 c 语言联合编译而成的，其中偏向硬件和底层的代码使用 arm 汇编 编写，而偏上层提供功能的代码则使用 c 编写。

入口：

lk 代码的入口点是在 arch/arm 目录下的以 .ld 为后缀的 link 脚本文件中指定。

指定的入口点均为位于 arch/arm/crt0.S 文件中的 _start 函数：

system-onesegment.ld
system-twosegment.ld

_start 最主要的作用是设置一些 cpu 的特性，然后初始化各种 c 程序运行需要的栈环境，完成后直接跳转到 kmian 函数进入 c 语言环境。

Kmain()函数：

void kmain(void)
{thread_init_early(); // 初始化化lk线程上下文arch_early_init(); // 架构初始化，如关闭cache，使能mmuplatform_early_init(); // 平台硬件早期初始化target_early_init(); //目标设备早期初始化bs_set_timestamp(BS_BL_START);call_constructors(); //静态构造函数初始化heap_init(); // 堆初始化thread_init(); // 初始化线程dpc_init();  //lk系统控制器初始化timer_init(); //kernel时钟初始化#if (!ENABLE_NANDWRITE)thread_resume(thread_create("bootstrap2", &bootstrap2, NULL, DEFAULT_PRIORITY, DEFAULT_STACK_SIZE)); // 创建一个线程初始化系统exit_critical_section(); //使能中断thread_become_idle(); //本线程切换为idle线程
#elsebootstrap_nandwrite();
#endif
}

bootstrap2

此函数由kmain中创建的线程调用，路径为:bootable\bootloader\lk\kernel\main.c。

static int bootstrap2(void *arg)
{arch_init(); //架构初始化bio_init();fs_init();platform_init(); //平台初始化, 主要初始化系统时钟,超频等target_init(); //目标设备初始化,主要初始化Flash,整合分区表等apps_init(); // 应用功能初始化,调用aboot_init,加载kernel等
}

apps_init()函数：

app_init 函数位于 app/app.c 文件中

/* app entry point */
struct app_descriptor;
typedef void (*app_init)(const struct app_descriptor *);
typedef void (*app_entry)(const struct app_descriptor *, void *args);/* app startup flags */
#define APP_FLAG_DONT_START_ON_BOOT 0x1/* each app needs to define one of these to define its startup conditions */
struct app_descriptor {const char *name;app_init  init;app_entry entry;unsigned int flags;
};void apps_init(void)
{const struct app_descriptor *app;/* call all the init routines */for (app = &__apps_start; app != &__apps_end; app++) {if (app->init)app->init(app);}/* start any that want to start on boot */for (app = &__apps_start; app != &__apps_end; app++) {if (app->entry && (app->flags & APP_FLAG_DONT_START_ON_BOOT) == 0) {start_app(app);}}
}static void start_app(const struct app_descriptor *app)
{thread_t *thr;printf("starting app %s\n", app->name);thr = thread_create(app->name, &app_thread_entry, (void *)app, DEFAULT_PRIORITY, DEFAULT_STACK_SIZE);if(!thr){return;}thread_resume(thr);
}

整个遍历 app 并启动的过程并不复杂，有趣的是 __apps_start 和 __apps_end 的定义，这两个变量符号在所有源文件中并不存在，而是在 arch/arm/*.ld 链接脚本中存在， __apps_start 和 __apps_end 是自定义的两个符号，代表了自定义段 .apps 的开始位置和结束位置。也就是说所有的 app 都通过在特殊的段 .apps 中注册实现了一套插件系统，是一个十分精巧的设计。后续的任何新的 app 只需要使用以下两个宏声明即可注册到 .apps 段中：

#define __SECTION(x) __attribute((section(x)))
#define APP_START(appname) struct app_descriptor _app_##appname __SECTION(".apps") = { .name = #appname,
#define APP_END };

在bootloader/lk/app/aboot/aboot.c 结尾：

APP_START(aboot).init = aboot_init,
APP_END

说明apps_init函数调用了aboot_init函数。

aboot_init函数：

是通过 APP_START注册的 aboot 入口函数， aboot 的所有功能都是由此开始。位于 bootloader/lk/app/aboot/aboot.c文件中。

简单流程：

设置NAND/eMMC读取信息页面的大小。
打印一些设备模块的Log信息以及初始化。
检测按键，判断是否进入fastboot或者recovery模式。
获取device info(设备是否lock，是否root，img是否已鉴权等信息)
从eMMC或NAND flash中加载内核。

主要函数：boot_linux_from_mmc

boot.img 解析：https://blog.csdn.net/ty3219/article/details/78879398

首先加载boot image
获取image header size，分配image header buffer，从指定分区加载image header。
如果配置了Secure Boot
imagesizeActure += 签名size
imagesize = imagesizeActure + image header pagesize
分配image buffer并从分区中加载image
校验签名
校验失败通知TZ，启动失败。
校验成功则即系加载image。
解压缩boot.img，分别加载kernel、ramdisk、device tree等到指定地址。
通知TZ加载结束。启动kernel。
BootLoader结束。

boot.image加签：

将原始boot.img通过SHA256算法进行计算得到一个哈希值。
使用private key对哈希值进行加签。
将最终的哈希值和签名添加到原始boot.img末尾。

签名校验：

将boot.img进行SHA256哈希计算，获得文件digest1。
将签名通过public key进行解密，获得文件digest2。
对比digest1和digest2两个文件。
相同则校验成功，不同则校验失败。

Boot流程的粗略理解。