深入理解SoC上电和boot流程

版权声明：
本文作者：烓围玮未。主要从事ISP/MIPI/SOC/车规芯片设计/SOC架构设计
首发于知乎专栏：芯片设计进阶之路
微信公众号：芯片设计进阶之路(x_chip)
转发必须授权，同时保留这段声明，盗版必究！

当SoC芯片流片回来后，并不是直接通电就可以使用的。需要进行上电复位，然后对SoC进行配置使其进入到正常工作状态，然后才能运行正常的程序和任务。这是一个比较复杂的过程，也是在芯片设计阶段，SoC需要重点考虑的问题。上电不能成功，芯片流片回来直接就不能启动，这也是最重大的失败，所以保证芯片能正常上电启动是SoC设计最重要的第一步。

由于SoC各种各样，不同是SoC的启动流程是有区别的，但是大部分SoC遵循着基本的流程：

上电复位：芯片通电后，所有寄存器和内存被重置到初始状态。
Boot阶段：初始化硬件；
操作系统启动：内核初始化，加载驱动，挂载文件系统。
用户空间初始化：启动系统服务和用户界面。

这个过程确保了SOC从断电状态到操作系统完全运行的平滑过渡。下面详细说明每个阶段的内容。

上电复位（Power-On Reset）

当SOC通电或复位信号触发时，SOC进入复位状态。复位电路会将所有寄存器和内存重置为已知的初始状态，确保系统从一个干净的状态开始启动。

Power-On Reset缩写为POR，这是一个非常常见的缩写，需要记住。

这个阶段还需要准备好Boot Mode Pin，确定Boot的介质，Boot Mode在POR释放时候锁存。

POR释放后开始reset flow阶段，SoC内部一般有一个控制reset sequence的状态机FSM，来进行启动阶段的reset。这个reset的控制和SoC内部实现强相关，不同的SoC有不同的实现方式。

同时还会完成下面任务：

确认PLL输出时钟稳定；
会启动必要的外设的时钟；
释放必要的模块的reset；
使用OTP配置内部模块；
进行进行Power-On Self-Test（POST）等

越是复杂的SoC，在这个阶段需要做的事情越多。

Boot阶段

系统引导程序

在遥远的单片机时代，嵌入式设备功能比较单一，每个设备只需要执行一件简单的任务，因此在系统初始化完成后，程序就运行在一个大循环中，此时，系统启动流程和功能代码并没有很严格的区分。随着技术的发展，嵌入式系统变得越来越复杂，单片机（MCU）和系统级芯片（SoC）之间的差异也越来越明显。在早期的单片机时代，设备的处理能力有限，通常只需要执行一些简单的任务，如控制一个电机或者读取传感器数据。这些任务通常可以通过一个简单的程序循环来实现，不需要复杂的操作系统。

然而，随着SoC的出现，情况发生了变化。SoC通常包含多个处理器核心、图形处理单元（GPU）、数字信号处理器（DSP）、以及其他专用硬件模块，如网络接口、存储控制器等。这些复杂的硬件需要更高级的管理，以便它们能够协同工作，提供更丰富的功能。

系统引导程序（Bootloader）在SoC中扮演着至关重要的角色。它的主要任务包括：

硬件初始化：在系统上电后，引导程序首先需要初始化硬件，包括设置时钟、配置内存、初始化外设等。
安全启动：为了保护系统不被恶意软件攻击，引导程序会检查操作系统映像的完整性和合法性。
配置系统环境：设置系统运行所需的参数，如CPU工作模式、内存管理单元（MMU）配置等。
加载操作系统：将操作系统映像从存储设备（如闪存、硬盘）加载到内存中。
跳转到操作系统：一旦操作系统加载完成，引导程序会将控制权交给操作系统，让操作系统接管系统的控制。

这些操作系统或启动程序是由c或者c++等程序写成的，编译成.bin或者.hex文件，存储到非易失性存储器中，或者存储在外部存储设备上。这些文件被称为镜像文件（image）

BootROM和XIP

在系统初始化时，cpu只能访问可以直接寻址的存储器：

如果支持XIP启动方式，可被存储在片外可直接执行的介质中（如NOFLASH）;
如果不支持XIP启动，则需要存储到芯片内部的ROM中，也就是最常见的BootROM;

在芯片出厂后该部分代码就将被固化，后续再也不能被修改和升级。若芯片要支持安全启动，则需要将BOOTROM作为启动时的信任根，此时除调试阶段外，SOC必须禁用XIP。

BOOT流程

一般情况下都会采用内部ROM的方式进行boot，如果内部ROM出问题了，可以采用XIP进行debug或者作为备份。

典型的boot流程一般分为：

First stage (BootRom)->Second Stage (u-boot/bare metal)

两个阶段。对不同的cpu架构，规定的boot流程规范是不同的。

ARM boot流程

ARM V8 Boot流程：

Armv8的启动流程包含多个阶段，典型地有BL1、BL2、BL31、BL32、BL33，根据需求的不同，这些阶段可以适当地裁剪或添加。

它们的源码会被编译成独立的启动镜像，并被保存到特定的存储介质中。由于一般的存储介质（如SPI Flash，nand flash、emmc、ssd等）都不支持代码的直接执行，因此需要在启动时先将镜像加载到可直接执行代码的存储介质，如SRAM中，然后运行相关代码。其典型的加载流程如下：

在ARMv8架构中，启动流程包含多个阶段，这些阶段通常被称为BL（Bootloader）阶段：

BL1：这是第一阶段的启动固件，通常位于ROM中，负责引导BL2并对其进行安全验证。
BL2：第二阶段的启动固件，通常存储在Flash中，负责平台相关的初始化，比如内存（DDR）初始化，并寻找BL31或BL33执行。
BL31：如果存在，BL2会加载BL31。BL31是持久存在的可信固件，负责系统安全服务和在安全与非安全世界之间切换。
BL32（可选）：通常包含OP-TEE OS和安全应用，运行在EL1，启动EL0的安全应用，完成后返回BL31。
BL33：这是非安全世界的启动固件，通常是U-Boot或者直接启动Linux内核。

这里说明一下:

armv8架构分为Secure World和Non-Secure World（Normal World），四种异常级别从高到低分别为EL3，EL2，EL1，EL0。

安全世界与非安全世界：

Secure World：执行可信的固件和应用，如支付、指纹识别等。
Non-Secure World：运行常见的操作系统和裸机程序。

异常级别：

EL3：最高权限级别，负责安全监控和模式切换。
EL2：提供虚拟化支持。
EL1：特权模式，运行操作系统或安全OS。
EL0：无特权模式，运行应用程序。所有APP应用都在EL0。

完整的调用流程如下：

ARM Trusted Firmware (ATF) 是为 ARMv8-A 架构设计的一套开源安全固件，它实现了从芯片启动到操作系统加载的整个过程中的安全启动要求。ATF 支持 ARM 的 TrustZone 技术，提供了Secure和Non-Secure执行环境之间的隔离。

BL2根据是否存在BL31和BL32可选择性的加载不同firmware，若系统需要支持Secure和Non-Secure两种执行状态，也就是支持ATF启动，则必须要从secure空间开始启动，且启动完成后需要通过secure monitor（BL31）完成normal os对secure空间服务相关请求的处理。

不支持ATF的启动

如果不支持ATF，那么阶段对应关系如下：

BL1: BootROM;
BL2: SPL(Secondary Program Loader),SPL在启动链中一般由bootrom加载而作为第二级启动镜像（bl2），它主要用于完成一些基础模块和ddr的初始化，以及加载下一级镜像uboot。
BL33：最常见的是u-boot；

这时候流程为：