TF-A上电后从bl1_entrypoint执行的原因涉及硬件启动机制和软件设计的结合。让我详细解释:
1.硬件层面的原因
ARM架构的启动流程
上电/复位 → CPU从固定地址开始执行 → 执行第一条指令对于大多数ARM处理器:
- 复位向量地址固定:CPU复位后,程序计数器(PC)会跳转到固定的物理地址
- 典型地址:
- ARMv7:通常为
0x00000000或0xFFFF0000 - ARMv8:通常为
0x00000000或0xFFFF0000(取决于配置) - 具体地址由SoC设计决定
- ARMv7:通常为
SoC内存映射
+-------------------+ 高地址 | DDR | +-------------------+ | ... | +-------------------+ 0x00010000 (示例) | BL1 | ← 上电后CPU从这里开始执行 +-------------------+ 0x00000000 | Boot ROM | ← 可能包含初始引导代码 +-------------------+2.链接脚本的作用
BL1链接脚本(bl1.ld.S)
ENTRY(bl1_entrypoint)/* 指定入口点 */SECTIONS{.=BL1_BASE;/* BL1的加载地址,通常是SoC的启动地址 */.text:{*(.text.entrypoint)/* bl1_entrypoint代码段 */*(.text*)/* 其他代码 */}...}关键点:
ENTRY(bl1_entrypoint):告诉链接器这是程序的入口点. = BL1_BASE:设置BL1的加载地址为SoC的启动地址.text.entrypoint段:确保bl1_entrypoint函数位于镜像的最开始
3.BL1镜像布局
BL1镜像布局: +-------------------+ | .text.entrypoint | ← bl1_entrypoint (第一条指令) | (bl1_entrypoint) | +-------------------+ | 其他.text代码 | +-------------------+ | .data段 | +-------------------+ | .bss段 | +-------------------+4.完整的启动链
阶段0:BootROM(固化在芯片中)
// SoC内部的BootROM代码(不可修改)voidbootrom_entry(void){// 1. 初始化最基本硬件(时钟、最小内存)// 2. 从启动介质(如eMMC、SPI Flash)读取BL1// 3. 将BL1加载到SRAM的固定地址(如0x00000000)// 4. 验证BL1签名(可选)// 5. 跳转到BL1的入口地址jump_to(BL1_BASE);// 跳转到bl1_entrypoint}阶段1:BL1入口点(bl1_entrypoint.S)
// bl1/bl1_entrypoint.S bl1_entrypoint: /* 1. 设置异常向量表 */ adr x0, exception_vectors msr vbar_el3, x0 /* 2. 设置栈指针 */ ldr x0, =bl1_stack_base mov sp, x0 /* 3. 清零.bss段 */ ldr x0, =__BSS_START__ ldr x1, =__BSS_SIZE__ bl zeromem /* 4. 初始化.data段 */ ldr x0, =__DATA_START__ ldr x1, =__DATA_ROM_START__ ldr x2, =__DATA_SIZE__ bl copymem /* 5. 跳转到C语言主函数 */ b bl1_main5.为什么是bl1_entrypoint而不是bl1_main?
启动顺序要求:
汇编初始化 → C语言环境 → C主函数 ↑ ↑ ↑ 必须用汇编 需要栈 需要初始化 设置CPU状态 和内存 的.data/.bss具体原因:
- CPU状态初始化:需要汇编代码设置异常向量、CPU模式等
- 内存环境准备:C语言需要有效的栈空间和初始化数据段
- 平台无关性:
bl1_entrypoint处理架构相关初始化,bl1_main处理逻辑
6.实际SoC示例
Rockchip RK3399启动流程:
1. 上电 → BootROM从eMMC读取idbloader.img 2. BootROM验证idbloader.img → 加载到SRAM 0xff8c0000 3. 跳转到0xff8c0000执行(BL1入口) 4. BL1初始化DDR → 加载BL31/BL32/BL33STM32MP1启动流程:
1. 上电 → ROM代码从FSBL分区读取TF-A BL2 2. 但TF-A将其重命名为BL1,实际执行BL1功能 3. 跳转到BL1入口点执行7.验证方法
查看BL1镜像布局:
# 使用readelf查看入口点aarch64-none-elf-readelf -h bl1.bin# 输出示例:Entry point address: 0x00000000 Start of program headers:0(bytes intofile)Start of section headers:0(bytes intofile)查看反汇编:
aarch64-none-elf-objdump -d bl1.elf|head-50# 会显示:0000000000000000<bl1_entrypoint>:0: d2800000 mov x0,#0x04: d5384100 mrs x0, elr_el3...总结
为什么上电后从bl1_entrypoint执行?
- 硬件强制:CPU复位后必须从固定地址开始执行
- 链接器配置:
bl1_entrypoint被放置在BL1镜像的最开始 - 启动介质加载:BootROM将BL1加载到CPU的启动地址
- 初始化需求:需要汇编代码完成C语言运行环境准备
- 安全启动要求:BL1作为信任根,必须首先执行验证
这种设计确保了:
- ✅确定性启动:每次复位都从相同位置开始
- ✅安全性:BL1作为信任链的起点
- ✅可移植性:架构相关代码与平台逻辑分离
- ✅可靠性:逐步初始化,避免复杂依赖
这就是TF-A(以及大多数bootloader)采用这种分层启动架构的根本原因。