代码收藏家 高通8155/8295 boot分析
目录
前言
本文将基于高通8155/8295 Q+A hypervisor平台分析整个boot的启动流程。高通其他SOC芯片的启动流程大致相同，所以本文也具备一定的参考性。
阅读本文需要你有一定的嵌入式开发经验或者具备一定的操作系统原理知识。
CPU通用boot流程
下面这张图展示了一个通用的boot流程：
注：图片来源于Arria ® 10 SoC Boot User Guide，1.1.1. Typical Boot Flow，PG 4
1，SOC power on/reset之后，将会首先执行CPU内部的Boot ROM代码
2，Boot ROM至少完成下面几个事情：
2.1，根据bootconfig判断当前SOC启动方式
2.2，根据不同的启动方式，初始化对应的驱动，例如如果设定为UFS启动，BootROM则会初始化UFS驱动
2.3，从UFS中加载第一阶段的bootloader，并在片内ram中，跳转到第一阶段的bootloader
2.4，第一阶段bootloader初始化ddr硬件，并从UFS中加载第二阶段bootloader到ddr中
2.5，跳转到第二阶段bootloader（Second-Stage Boot Loader）
3，Second-Stage Boot Loader加载并跳转到操作系统内核镜像
4，操作系统挂载文件系统，开始运行application
上面的boot流程比较简单，很多细节并没有描述到，大部分人对于boot流程的理解可能也仅限于此.但是还有一部分喜欢思考的同学会有几个问题：
1，什么是BootROM？
BootROM是固化在SOC内部的一段代码，不同厂家的叫法可能不太一样，比如高通的叫法是PBL（primary boot loader），其他家也有的叫romcode
2，BootROM上电之后是怎么运行的？
上电之后，如果CPU供电正常，晶振正常起振，那么CPU的指针会被reset到BootROM的第一条指令开始执行
3，SOC是如何知道是哪一种启动方式？
一般通过CPU的boot config pin脚来判断启动方式，当然也可以通过内部的fuse来判断，前提是硬件支持e-fuse（可编程熔断保险丝），且产品已经fuse完成
8155/8295 boot流程概述
下图是8155/8295 boot阶段中XBL的大致工作流程：
8155/8295 boot流程框图
上面我们已经介绍了通用的CPUboot流程，接下来我们会对8155/8295的boot流程进行简单的介绍。
注：80-PG469-11 Rev. B
Boot流程说明
1 . After reset, the Kryo Silver core 0 comes out of reset and then executes PBL
On Kryo Silver core 0, applications PBL initializes hardware (clocks, and so on), CPU caches and MMU, and detects the boot device as per the
boot option configuration:
- Default boot option: UFS > SD > USB
- Default boot option: overridden by EDL cookie or Force USB GPIO
2a. Loads and authenticates XBL-SEC (region #0) from the boot device to OCIMEM
2b. Loads and authenticates XBL-Loader (region #1) from the boot device to Boot IMEM
2c. Loads and authenticates XBL-Debug (region #2) from the boot device to OCIMEM
Jumps to XBL-SEC
3. XBL-SEC runs the security configuration in EL3 mode, and then executes the XBL-Loader in EL1 mode
XBL-Loader initializes hardware and firmware images, CPU caches, MMU, boot device, XBLConfig, PMIC driver, and DDR. It performs DDR
training if applicable, executes an SCM call to XBL-SEC to initialize PIMEM, and initializes clocks and configures the clock frequencies as per
clock plan
4a. Loads and authenticates applications debug policy (APDP) image from the boot device
4b. If, DLOAD cookie is set, loads, and authenticates XBL-RAM dump and jumps to XBL-RAM dump to collect crash dump
4c. Initializes SMEM (shared memory) and fills platform ID and RAM partition table
4d. Loads and authenticates AOP image from the boot device and then bring AOP out of reset
4e. Loads and authenticates DEVCFG (TZ device configuration) image from the boot device
4f. Loads SEC.dat (fuse blowing data) image from the boot storage if exists
4g. Loads and authenticates QTEE image from the boot device
4h. Loads and authenticates QHEE image from the boot device
4i. Loads and authenticates ABL image from the boot device
4j. Executes an SCM call to XBL-SEC to jump to QTEE cold boot
5. QTEE sets up a secure environment, and then transfers the execution to QHEE image
6. QHEE proceeds to execute the XBL core (or XBL region #3) and then, XBL core mounts and transfers the execution to UEFI application processor (ABL FV)
7. Linux loader application (part of ABL FV) loads and authenticates the HLOS kernel with verified boot
8-8’. PIL driver in HLOS applications loads each subsystem image to DDR and configures clocks and power rails required
9. PIL driver in HLOS applications executes an SCM call to request secure PIL driver, authenticates the images, and brings each subsystem out of reset
10-14’. For SP image, SP PBL decrypts the image and loads it to SP SRAM注：80-PG469-11 Rev. B
Boot流程 Q&A
1, CPU是通过哪几个pin来判断boot启动方式的？这些pin脚是受谁控制？
注：80-PG469-11 Rev. B
上图展示了使用GPIO和e-fuse控制启动具体细节。如果使用GPIO控制启动方式，通常是使用GPIO64/67/68/69这四个pin脚来控制，这几个pin脚在高通EVB开发板中是通过拨码开关来控制高低电平。在实际的产品中，通常是有另外的单片机来控制高低电平，这个单片机通常为NXP的S32单片机系列或者瑞萨的RH850系列.
需要注意，在8155上存在FORCED_USB_BOOT pin(GPIO136),拉高这个pin脚可以直接让SOC强行从USB启动。
2，如果boot config pin没有指定，默认是什么启动方式？
我们假定boot config pin没有指定指的是低电平，那么按照上面表格的顺序会默认尝试首先从UFS启动，如果UFS启动失败会切换到SD启动，如果SD启动还是失败的则会尝试从USB3.1的口上通过USB方式启动.
3，如何判断boot config是否正确?
一般判断boot config是否正确可以通过测量对应的启动方式的clock/data引脚来确定。
4，实际项目开发中是否需要对boot流程中的代码进行修改？
DEMO项目不需要，SOP项目一般都需要，因为在实际SOP的项目中，需要考虑太多的异常场景了，举个例子，现在一般都是MCU和SOC协同工作，MCU负责监控SOC，这就需要MCU实时的了解到SOC当前所处的状态（boot，work，update，flash），很多场景是没有操作系统运行的，实际在跑的可能只有bootloader，此时就要求bootloader以某种方式通知MCU，当前自己所处的状态。再一个例子，MCU对SOC的watchdog机制是需要覆盖到整个运行期间的，其中当然也包括了bootloder阶段，否则一旦出现hang在bootloader阶段但是又不触发重启就麻烦了.
