PyTorch 离线安装实战：解决 pip 找不到 CUDA 版本的问题
2026/10/12 1:17:39
MTK 启动组件与 ARMv8 标准 ATF 阶段对应关系
结合 ARMv8 官方 Trusted Firmware-A（TF-A）的标准启动阶段定义，MTK 平台的整条启动链与标准架构职能完全对齐，仅组件命名、运行架构、切换方式有平台化差异。先给出总览对应表，再逐段拆解匹配逻辑与差异化设计。
一、总览对应表
ARMv8 标准ATF阶段 | 标准职能定位 | MTK 平台对应组件 | 运行特权级 | 运行架构 | 核心作用匹配 |
BL1 | 芯片ROM级一级引导，硬件信任根，验签并加载BL2 | BROM（Boot ROM） | EL3 | AArch32 | 芯片固化代码，锚定eFuse硬件根，验签preloader，跳转执行 |
BL2 | 可信二级引导，完成硬件初始化、加载并验签所有BL3x镜像、配置安全环境、跳转BL31 | Preloader | SVC（EL1 安全态） | AArch32 | 初始化硬件/安全域、加载并验签ATF/TEE/LK、配置内存隔离、跳转ATF |
BL31 | 安全监视器固件，EL3运行时，负责特权级切换、SMC分发、电源管理 | ATF / BL31 固件 | EL3 | AArch64 | 安全世界核心底座，PSCI电源管理、SMC调用分发、安全/非安全世界切换 |
BL32 | 可信操作系统TEE，运行在安全世界EL1，提供可信服务 | TEE OS（Trustonic/Trusty等） | Secure EL1 | AArch64 | 密钥管理、安全存储、DRM、Keymaster等可信业务 |
BL33 | 普通世界Bootloader，非安全态引导程序，加载系统内核 | LK（Little Kernel） | Non-secure EL2/EL1 | AArch64 | 系统级引导、AVB验证、加载内核/设备树、启动Android |
二、逐阶段详细对应与代码佐证
1. BL1 ↔ MTK BROM（Boot ROM）
标准定义
BL1 是芯片出厂固化在片内ROM中的第一级引导代码，不可修改，是整个系统的硬件信任根。它的唯一职责是：从启动设备读取BL2镜像，完成签名校验，校验通过后跳转到BL2。
MTK 对应逻辑
完全匹配芯片内置的Boot ROM（BROM），也就是你之前分析的、验签Preloader的那一段固化代码：
- 锚定 eFuse/OTP 中的根公钥哈希，硬件级信任根；
- 从eMMC读取preloader镜像，完成签名校验；
- 校验通过后，将启动参数存入r4寄存器，跳转preloader入口；
- 校验失败则进入下载模式，拒绝启动。
差异点
标准ARMv8的BL1通常运行在AArch64 EL3；MTK多数中低端芯片（含MT8766）的BROM运行在AArch32 EL3，属于平台兼容性设计。
2. BL2 ↔ MTK Preloader
标准定义
BL2 是可信引导的第二阶段，运行在安全态，核心职责：
- 基础硬件初始化（时钟、串口、存储、内存）；
- 从存储设备加载 BL31、BL32、BL33 镜像；
- 对所有BL3x镜像做签名校验，保证镜像可信；
- 配置安全硬件、内存隔离、MPU权限；
- 跳转进入 BL31（EL3），移交控制权。
MTK 对应逻辑
Preloader 100% 承担了标准BL2的全部职能，你之前分析的所有代码都在对应BL2的标准工作：
标准BL2职能 | Preloader 对应代码/逻辑 |
硬件初始化 | platform_pre_init() / platform_init() ，初始化时钟、串口、存储、DDR |
安全硬件配置 | device_APC_dom_setup() 配置总线域隔离， trustzone_pre_init() 配置安全环境 |
加载并验签BL31/BL32 | bldr_load_tee_part() 加载ATF+TEE镜像， tee_verify_image() 做签名校验 |
加载BL33 | bldr_load_part_lk() 加载LK镜像 |
内存安全隔离 | tee_sec_config() 配置EMI MPU，锁定安全内存仅安全世界可访问 |
跳转BL31 | trustzone_jump() → jumparch64 切换架构并进入ATF |
MTK 专属差异（最核心的不同）
标准ATF的BL2通常与BL31同架构（AArch64），直接通过函数调用跳转EL3；
MTK Preloader 运行在 AArch32 安全SVC模式，无法直接切换到AArch64 EL3，因此采用了暖复位（Warm Reset）的方式：先配置复位向量和架构状态，触发CPU软复位，复位后直接以AArch64 EL3模式进入BL31。
这是MTK 32位ROM + 64位核心架构的典型适配设计，职能上依然完全等价于标准BL2。
3. BL31(ATF) ↔ MTK ATF / BL31 固件
标准定义
BL31 是ATF的核心运行时固件，常驻EL3最高特权级，是安全世界与普通世界的唯一交互关口，核心能力：
- 初始化EL3异常向量表，处理SMC调用、中断、异常；
- 实现PSCI（电源状态协调接口），负责CPU热插拔、休眠唤醒、系统重启/关机；
- 负责安全世界与普通世界的上下文切换、权限管控；
- 启动BL32（TEE OS），再启动BL33（普通世界Bootloader）。
MTK 对应逻辑
完全匹配MTK tee分区中的BL31 固件，也就是代码中bl31_base_addr指向的镜像：
- 运行在AArch64 EL3，是整个系统的最高权限层；
- 承接Preloader传入的启动参数、密钥、内存布局；
- 初始化SMC分发框架、PSCI服务、安全中断；
- 启动BL32（TEE OS）后，切换到非安全态启动BL33（LK）；
- 系统运行过程中常驻后台，响应普通世界的SMC安全请求。
补充
MTK的ATF基于ARM官方TF-A定制开发，增加了平台级的电源管理、安全外设适配，核心框架完全遵循ARMv8标准。
4. BL32(TEE OS) ↔ MTK TEE OS
标准定义
BL32 运行在 Secure EL1 特权级，是完整的可信操作系统（TEE OS），向上提供安全业务能力，向下依赖BL31的特权级服务。
标准实现如OP-TEE、Trusted Firmware-M等，核心提供：密钥管理、安全存储、身份认证、DRM版权保护等可信服务。
MTK 对应逻辑
完全匹配tee分区中的TEE OS 镜像，也就是代码中tee_entry_addr指向的固件：
- 支持Trustonic、Google Trusty、微诚、天宸等多家TEE方案，代码中通过编译宏适配；
- 运行在AArch64 Secure EL1，由BL31加载启动；
- 接收Preloader注入的RPMB密钥、FDE根密钥，实现安全存储、全盘加密的底层支撑；
- 向上对接Android Keymaster、Gatekeeper、Widevine等系统安全服务。
5. BL33 (UBOOT)↔ MTK LK（Little Kernel）
标准定义
BL33 运行在非安全世界（Non-secure EL2/EL1），是普通世界的引导程序，不涉及安全世界核心逻辑，唯一目标是加载并启动操作系统内核。
标准实现如UEFI、U-Boot、EDK II等。
MTK 对应逻辑
完全匹配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组件一一对应：
- BL1（BROM）：芯片上电，固化ROM代码运行，验签Preloader → 跳转Preloader
- BL2（Preloader）：初始化硬件、配置安全域、加载并验签ATF/TEE/LK → 暖复位切换架构，跳转BL31
- BL31（ATF）：EL3运行时初始化、注册SMC/PSCI服务 → 启动BL32 TEE OS
- BL32（TEE OS）：可信系统初始化、密钥服务就绪 → 返回BL31
- 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的标准阶段划分。