企业官网建设流程全解析

TF-A上电后从bl1_entrypoint执行的原因涉及硬件启动机制和软件设计的结合。让我详细解释：

1.硬件层面的原因

ARM架构的启动流程

上电/复位 → CPU从固定地址开始执行 → 执行第一条指令

对于大多数ARM处理器：

• 复位向量地址固定：CPU复位后，程序计数器（PC）会跳转到固定的物理地址
• 典型地址：
  • ARMv7：通常为0x00000000或0xFFFF0000
  • ARMv8：通常为0x00000000或0xFFFF0000（取决于配置）
  • 具体地址由SoC设计决定

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*)/* 其他代码 */}...}

关键点：

1. ENTRY(bl1_entrypoint)：告诉链接器这是程序的入口点
2. . = BL1_BASE：设置BL1的加载地址为SoC的启动地址
3. .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_main

5.为什么是bl1_entrypoint而不是bl1_main？

启动顺序要求：

汇编初始化 → C语言环境 → C主函数 ↑ ↑ ↑ 必须用汇编 需要栈 需要初始化 设置CPU状态 和内存 的.data/.bss

具体原因：

1. CPU状态初始化：需要汇编代码设置异常向量、CPU模式等
2. 内存环境准备：C语言需要有效的栈空间和初始化数据段
3. 平台无关性：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/BL33

STM32MP1启动流程：

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执行？

1. 硬件强制：CPU复位后必须从固定地址开始执行
2. 链接器配置：bl1_entrypoint被放置在BL1镜像的最开始
3. 启动介质加载：BootROM将BL1加载到CPU的启动地址
4. 初始化需求：需要汇编代码完成C语言运行环境准备
5. 安全启动要求：BL1作为信任根，必须首先执行验证

这种设计确保了：

• ✅确定性启动：每次复位都从相同位置开始
• ✅安全性：BL1作为信任链的起点
• ✅可移植性：架构相关代码与平台逻辑分离
• ✅可靠性：逐步初始化，避免复杂依赖

这就是TF-A（以及大多数bootloader）采用这种分层启动架构的根本原因。