结合 ARMv8 官方 Trusted Firmware-A（TF-A）的标准启动阶段定义，MTK 平台的整条启动链与标准架构职能完全对齐，仅组件命名、运行架构、切换方式有平台化差异。先给出总览对应表，再逐段拆解匹配逻辑与差异化设计。

BL1 是芯片出厂固化在片内ROM中的第一级引导代码，不可修改，是整个系统的硬件信任根。它的唯一职责是：从启动设备读取BL2镜像，完成签名校验，校验通过后跳转到BL2。

完全匹配芯片内置的 Boot ROM（BROM），也就是你之前分析的、验签Preloader的那一段固化代码：

• 锚定 eFuse/OTP 中的根公钥哈希，硬件级信任根；
• 从eMMC读取preloader镜像，完成签名校验；
• 校验通过后，将启动参数存入r4寄存器，跳转preloader入口；
• 校验失败则进入下载模式，拒绝启动。

标准ARMv8的BL1通常运行在AArch64 EL3；MTK多数中低端芯片（含MT8766）的BROM运行在AArch32 EL3，属于平台兼容性设计。

BL2 是可信引导的第二阶段，运行在安全态，核心职责：

1. 基础硬件初始化（时钟、串口、存储、内存）；
2. 从存储设备加载 BL31、BL32、BL33 镜像；
3. 对所有BL3x镜像做签名校验，保证镜像可信；
4. 配置安全硬件、内存隔离、MPU权限；
5. 跳转进入 BL31（EL3），移交控制权。

Preloader 100% 承担了标准BL2的全部职能，你之前分析的所有代码都在对应BL2的标准工作：

标准ATF的BL2通常与BL31同架构（AArch64），直接通过函数调用跳转EL3；

MTK Preloader 运行在 AArch32 安全SVC模式，无法直接切换到AArch64 EL3，因此采用了暖复位（Warm Reset）的方式：先配置复位向量和架构状态，触发CPU软复位，复位后直接以AArch64 EL3模式进入BL31。

这是MTK 32位ROM + 64位核心架构的典型适配设计，职能上依然完全等价于标准BL2。

BL31 是ATF的核心运行时固件，常驻EL3最高特权级，是安全世界与普通世界的唯一交互关口，核心能力：

• 初始化EL3异常向量表，处理SMC调用、中断、异常；
• 实现PSCI（电源状态协调接口），负责CPU热插拔、休眠唤醒、系统重启/关机；
• 负责安全世界与普通世界的上下文切换、权限管控；
• 启动BL32（TEE OS），再启动BL33（普通世界Bootloader）。

完全匹配MTK tee分区中的 BL31 固件，也就是代码中bl31_base_addr指向的镜像：

• 运行在AArch64 EL3，是整个系统的最高权限层；
• 承接Preloader传入的启动参数、密钥、内存布局；
• 初始化SMC分发框架、PSCI服务、安全中断；
• 启动BL32（TEE OS）后，切换到非安全态启动BL33（LK）；
• 系统运行过程中常驻后台，响应普通世界的SMC安全请求。

MTK的ATF基于ARM官方TF-A定制开发，增加了平台级的电源管理、安全外设适配，核心框架完全遵循ARMv8标准。

BL32 运行在 Secure EL1 特权级，是完整的可信操作系统（TEE OS），向上提供安全业务能力，向下依赖BL31的特权级服务。

标准实现如OP-TEE、Trusted Firmware-M等，核心提供：密钥管理、安全存储、身份认证、DRM版权保护等可信服务。

完全匹配tee分区中的 TEE OS 镜像，也就是代码中tee_entry_addr指向的固件：

• 支持Trustonic、Google Trusty、微诚、天宸等多家TEE方案，代码中通过编译宏适配；
• 运行在AArch64 Secure EL1，由BL31加载启动；
• 接收Preloader注入的RPMB密钥、FDE根密钥，实现安全存储、全盘加密的底层支撑；
• 向上对接Android Keymaster、Gatekeeper、Widevine等系统安全服务。

BL33 运行在非安全世界（Non-secure EL2/EL1），是普通世界的引导程序，不涉及安全世界核心逻辑，唯一目标是加载并启动操作系统内核。

标准实现如UEFI、U-Boot、EDK II等。

完全匹配 LK（Little Kernel） 引导程序：

• 运行在AArch64 Non-secure EL2，由ATF BL31从安全世界切换过来启动；
• 核心职责：外设初始化、开机Logo显示、AVB 2.0系统级验签、boot/recovery分区校验、加载内核与设备树、传递启动参数、跳转Linux内核；
• 提供Fastboot、Recovery等刷机/恢复模式。

之前关注的AVB 2.0链式验签、vbmeta校验，全部发生在BL33（LK）阶段，属于系统级安全校验，和BL1-BL2的芯片级安全启动是两层独立的信任链。

按执行顺序，整条链路的标准与MTK组件一一对应：

1. BL1（BROM）：芯片上电，固化ROM代码运行，验签Preloader → 跳转Preloader
2. BL2（Preloader）：初始化硬件、配置安全域、加载并验签ATF/TEE/LK → 暖复位切换架构，跳转BL31
3. BL31（ATF）：EL3运行时初始化、注册SMC/PSCI服务 → 启动BL32 TEE OS
4. BL32（TEE OS）：可信系统初始化、密钥服务就绪 → 返回BL31
5. BL33（LK）：BL31切换到非安全态，启动LK → LK执行AVB验证、加载内核 → 启动Android系统

1.职能完全对齐，仅实现方式有平台差异

MTK的preloader、LK不是脱离ATF标准的自研体系，而是ARMv8标准启动阶段的平台化实现，只是因为BROM是32位，才出现了AArch32 BL2 + 暖复位切换的特殊设计，核心职责与标准BL2完全等价。

2.两级安全启动的分层对应

• BL1→BL2 对应芯片级安全启动：BROM验签Preloader，锚定硬件根；
• BL2→BL31/BL32 对应安全世界信任链：Preloader验签ATF/TEE，保证安全世界可信；
• BL33 内部执行系统级AVB验证：LK验签系统分区，保证普通世界系统可信。

3.行业通用命名习惯

可以把preloader称作BL2、把LK称作BL33，本质就是沿用了ARMv8 ATF的标准阶段划分。