前言
高通芯片平台种类众多涵盖低端到高端的各种档次种类繁多：低端有诸如8909，中端有8916、8929、8937等，高端的有8953、8953、8953pro、8993，8996、8996pro。从存储介质上讲，从早期emmc慢慢发展到emcp最终由向ufs转化的趋势，运行位数更是从早期的32位全体过渡到64位地址总线。科技发展日新月异成果遍地！
也正是由于技术和平台的差异较大，很难通过一篇文章来穷尽所有高通平台的流程。好在所有的chip在boot时有很大的通性，便于举一反三，故本文将以2017年正在使用的Qcom平台为例，带领大家从宏观上把握开机流程的核心。
子系统模块架构
要了解高通的平台，必须先了解下芯片中集成了那些子系统(SubSystem)。与Intel的做法不同，高通芯片中所包含的子系统数量多，集成度高，这些子系统都有各自独立的cpu，只要在开机过程中通过主cpu子系统(APPS)引导/烧录进对应的firmware，就可以地独立运行起来。
在较新的高通芯片中较常见到的子系统(SubSystem)有下面这些：
| SubSystem | Function |
|---|---|
| APPS | (Application Processer Subsystem) 主CPU |
| RPM | (Resource Power Manager) 电源管理模块(带独立cpu) |
| Venus | 高通的图像处理模块 |
| LPASS | (LowPower Audio Subsystem)音频处理模块 |
| WCNSS (Pronto) | Wifi模块 |
| Modem | Modem处理器或称之为baseband |
| TZ | (TrustZone) Arm平台负责Security的Cpu，主系统可通过scm call与之通讯获取想要的数据 |
Boot流程
既然芯片中集成了这么多颗cpu，讲解开机流程的核心就演变为讲解主cpu是如何逐步引导子cpu完整boot的流程了。
- 按PowerKey引导主CPU Reset
- cpu抓取存取器(emmc or ufs)中已预先烧入的sbl1 fw 执行。
- 将sbl1fw加载到L2缓存
- 将rpm的初始化引导代码(存放在sbl1中)加载到rpm子系统中
- jump到L2中执行sbl1(因为DDR还没初始化，所以此时在cache中运行最为方便)
- sbl1开始初始化DDR为后续大内存的使用代码提供运行环境
- sbl1将TZ img加载到DDR中
- sbl1将RPM的firmware(img)导入rpm子系统中
- sbl1将HLOS APPSBL Image(指的是lk即little kernel，有人习惯称之为aboot或是大家尝叫的BootLoader;其中的HLOS是Qcom常用的说法，指的是High-Level Operationg System)引导进DDR
- sbl1将执行权转交给TZ，完成系统安全环境(TrustZone)的建立、xpu的初始化和fuse的代码支援(security boot)
- TZ开始设置memory和io接口的访问权限，并通知RPM子系统开始运行
- TZ将引导执行HLOS APPSBL(LK)代码，并转移执行权到LK
LK根据此时用户的按键行为(是否长按音量键等)决定下一步的运行模式。
Boot模式一般有如下三种: 1:Normal Boot(boot进kernel) 2:Fastboot Mode 3:Recovery Mode 我们这里将只分析Normal Boot的情况LK加载Kernel
- LK通过执行SCM call将执行权转交给kernel
- Kernel通过PIL(Peripheral image loader)将MBA(Modem Boot Authenticator)加载到DDR
- Kernel开始warm reset(warm reset DDR 不会掉电，内存数据保留) Modem的Cpu以便MBA开始boot流程，等待Modem完整Firmware的到来
- Kernel通过PIL加载Modem img到DDR
- Modem cpu开始正常启动
- Kernel通过PIL加载WCNSS img到DDR，然后warm reset wcnss子系统以便WCNSS img被正常执行
- Kernel通过PIL加载LPASS img到DDR，然后warm reset LPASS子系统以便LPASS img被正常执行
… - Kernel通过PIL加载并执行Venus img
- kernel继续正常boot，调用init和zygote将android系统调用起来
这样一来，所有的子系统都正常开始执行，并且我们有了一个security的环境(TZ),来保证与用户隐私和权限相关的data会非常安全。
总结
上面的流程是基于中高端高通平台的通用流程，有些细节在不同平台上有细小的区别故没有特意展开。在8996平台上，高通引入了xbl这样的新机制替代了sbl1，但他们功能类似，行为相仿。
每个子系统由于都是独立的cpu，可能有些读者会产生这样的疑惑：万一某个子系统运行不正常，那Kernel如何才能对他们进行有效监控和管理呢？高通引入了QMI(Qcom Message Interface)的接口，让各个子系统可以通过其进行较为高效的数据交换，当然这些数据是可以包含系统日志(log)的，这样我们就可以对其进行一定程度上的管理和监控了。当然，我们还有一系列的driver节点，可以通过其对子系统进行reset和clock的管理。最最重要的是，每个子系统都提供了一个sub-system restart的监控节点，这样只要某个子系统异常宕机(例如modem偶尔重启，用户可能看到短暂的无服务)，我们可以通过modem的引导程序，将modem子系统的整个运行内存状态完整的dump出来，这样就可以分析crash前的所有变量和堆栈状态了。
了解高通平台的boot流程，对做bsp的同仁来说是十分有必要的，我们bring up某个新平台的EVB主板时，有了基础知识才能很找到不开机时的问题点，才能尽快进行针对性的debug。
顺便分享点经验：电池电量，电池id电阻，DDR是否有部分虚焊点是常常导致无法开机的元凶。这些问题可以通过log或在edl mode下烧入不同的firehouse来快速验证。
欢迎大家提出宝贵意见和建议，共同成长。