题图这种事我就不放了毕竟搞固件的人心里都有数——真正的图在各自的板卡原理图和call stack里。这篇文章我基于Arm-Trusted-FirmwareATF源码从架构全景、安全审计、平台移植三个维度做一次深度拆解。内容偏实践向不绕圈子尽量把源码背后的设计动机、工程权衡和移植时会踩的坑一次讲透。1. 为什么ATF值得你花时间读源码1.1 一个启动链路里的“隐形总管”大多数人接触ATF是从看U-Boot启动日志开始的。从BL1、BL2跳转再到BL31、BL32ATF在bootloader之前、内核之前就已经把CPU从EL3拉到了安全世界的运行态。简单说ATF就是在ARMv8/AArch64系统上负责EL3运行时代码、安全启动链校验、以及普通世界和安全世界之间切换的那一层固件。很多嵌入式工程师一开始都以为“固件启动就是U-Boot kernel”等真正查起来才发现U-Boot之前的BL1/BL2、U-Boot之后的BL31/BL32全是ATF的活。而且它不只是“跳到下一级再来一遍”它在你还没看到任何日志之前已经完成了CPU早期初始化、可信启动链的前置验证、内存布局的心理预期建立。写U-Boot驱动之前不读ATF很多系统级问题根本无从下手。1.2 ATF到底管了哪些事展开说的话它管的事很多但最核心的离不开这几个垂直方向安全世界入口也就是EL3 runtime固件处理Secure Monitor CallSMC负责切换世界、保存和恢复上下文。可信启动链从BL1到BL33每一级通过证书链验证镜像合法性防止固件被篡改或回滚。PSCI实现电源状态协调接口比如CPU的开启/关闭、系统挂起/复位都是由ATF的PSCI服务向内核提供标准接口。中断路由GIC路由规则确定哪些中断进安全世界哪些直接给普通世界关键就在于EL3里怎么配置和分发给trusted OS。内存隔离与页表管理翻译表Translation Table从EL3视角划分安全和非安全地址空间确保普通世界不能顺手摸到安全内存。这几点理解了ATF在系统中的位置就清楚了。它不是一个孤立的小固件而是连接Bootloader、hypervisor、OS和Trusted OS之间的骨架。你看代码时如果把ATF当成“另一个启动固件”来读会觉得它搅和了一堆乱七八糟的东西但如果你把它当成操作系统内核一样对待理解异常级别、上下文、资源隔离所有代码路径就顺了。2. ATF源码架构全景从目录结构到关键模块2.1 异常级别模型与EL3的比特级真相ARMv8的异常级别模型是ATF存在的根基。EL0是用户态EL1是内核态EL2是虚拟化层EL3是安全固件。ATF主要工作在EL3但boot过程中它会短暂出现在EL1、EL2这些低异常级别里准备环境。很多人问为什么要在EL3单独放一层固件而不是像ARMv7那样直接塞给secure monitor因为从ARMv8开始ARM把安全世界拆得更细了。EL3管安全监控EL1/EL0的Trusted OS比如OP-TEE管安全服务两个世界通过SMC指令进入EL3由EL3判断下一个该把控制权交给谁。换句话说你看到的每一次“世界切换”背后其实都是异常级别的上升到EL3、上下文保存、路由分发、再降级回去的过程。源码里与此对应的核心是lib/el3_runtime/aarch64/context_mgmt.c和lib/el3_runtime/aarch64/context.S。前者负责建立cpu_context结构体保存普通世界和安全世界的寄存器状态后者负责在world switch时真正执行保存与恢复动作。我记得第一次翻到这里时看代码里的el1_sysregs、gpregs这些偏移展开背后对应的就是一个个系统寄存器。代码写得非常规整几乎没有任何奇技淫巧很适合当汇编和系统寄存器学习的范本。2.2 六大源码模块逐层拆解ATF的仓库结构不算大顶层目录却分得很清楚目录/文件作用bl1/第一阶段bootloader。一般存放在ROM或片上SRAM负责最基础的硬件初始化然后加载BL2。bl2/第二阶段bootloader负责加载BL31、BL32、BL33镜像执行可信启动链验证。bl31/EL3 runtime固件包含SMC分发、PSCI、中断管理、运行时服务。bl32/可选的安全OS入口比如OP-TEE的对接层一般会调用到spd/下的specific dispatcher。common/公共代码启动逻辑、FIP解析、镜像加载、bl_common等。lib/通用库包含el3_runtime、xlat_tables_v2、psci、smc、extensions等。drivers/各类驱动常见的有arm/gic、arm/uart、ti/uart、st/uart、arm/gpio等。plat/平台相关代码每个SoC或board一个目录。tools/证书创建、fiptool、sptool等工具。include/公共头文件定义常量、结构体、函数声明。makefile顶层构建入口支持大量编译选项。其中plat/目录是最需要花时间看的。以plat/arm/board/fvp来说它是ARM官方提供的固定虚拟平台Fixed Virtual Platform参考实现也是绝大多数移植工作的起点。2.3 运行时服务与SMC分发机制ATF里最像“内核调度器”的部分就是SMC分发。当普通世界想进安全世界执行smc #0CPU就陷到EL3BL31里的handle_smc开始找对应的runtime service。在源码里这个机制体现为runtime service框架每个服务都注册了自己的SMC调用号范围比如PSCI服务是ARM_SVC_STD_CALL范围内的标准调用OP-TEE服务由opteed dispatcher注册。运行时服务表中的rt_svc_descs数组就是核心调度表每个描述符里有初始化函数、调用处理函数还有调用号范围。SMC处理流程并不复杂但调试时很容易忽略一点在发给对应handler之前ATF会做参数校验。比如is_caller_secure()根据调用来源判断是Secure世界还是Normal世界发起的来决定能不能访问某些敏感服务。源码在bl31/bl31_main.c里写得很清楚值得当规范来读。3. 安全固件工程审计不只是“开个TBB开关”3.1 可信启动链的密码学验证流程很多人把可信启动理解为一个开关TRUSTED_BOARD_BOOT1一打开万事大吉。实际用起来才知道TBB是个完整的证书链验证体系。ATF的TBB流程大致是这样的在构建时用cert_create工具生成一组密钥对和证书。每级镜像对应一张证书比如BL2的证书、BL31的证书、BL32的证书、BL33的证书。证书与镜像通过fiptool打包成一个FIP固件镜像包。启动时BL1在ROM里执行验证BL2镜像的证书和哈希确保BL2没有被替换。BL2再依次验证BL31、BL32、BL33的镜像一层一层往下信任传递。关键点在于根密钥Root of Trust。BL1验证BL2时用的那把公钥是在芯片出厂烧录阶段就写死在OTP里的不是从FIP里读出来的。这就是“信任根”的物理基础。如果OTP密钥没写or被人改了整套可信启动就是纸糊的。做安全审计时我最先检查的不是算法强不强而是密钥放哪。曾有项目把根公钥直接放在FLASH里TBB开了等于没开攻击者把公钥换成自己的整个验证链瞬间崩掉。这个问题审计报告里经常出现实际code review时很难一眼看出来。3.2 审计时需要重点盯的代码路径代码审计和写feature是两码事。写feature关心怎么把功能做通审计关心“如果这里被恶意输入打了会怎样”。所以在ATF里我要盯的是几个边界路径SMC参数校验所有从普通世界进EL3的SMC参数都会经过scr_el3设置和函数入口检查。有没有对参数范围做过校验有没有可能存在越界访问重点看fid是否被用来做数组索引。翻译表权限lib/xlat_tables_v2负责在安全世界建立页表。一旦某块区域被映射成可写可执行就是攻击者的马场。审计时我习惯用脚本扫出所有MT_CODE | MT_WRITE的映射组合逐个核对是否必要。BL2/SP的镜像加载BL2解析FIP时如果镜像描述符里的offset、size没有范围检查可能通过超大的镜像大小把数据读到预期之外的区域。ATF在bl2/bl2_image_load_desc.c里对这类数据做了比较严格的控制但如果你改过镜像加载顺序就要重新检查。缓存一致性、side channel防护这些属于进阶项一般量产固件可以先看有没有打开ARM_ARCH_SAFETY相关的选项和流水线预测相关的防护。3.3 常见安全弱项与修复建议我在实际审计中见到的ATF安全问题排第一的不是什么高级攻击而是“没启用安全启动”。很多基于ATF的产品还是只用了U-Boot去校验kernelATF层面的TBB根本没打。第二常见的就是私钥管理混乱。构建机上私钥跟镜像包放一起随随便便打包传到车间泄露了也无感知。第三类是硬件层面的安全隐患比如UART调试口在量产固件里没有关闭攻击者可以通过console直接进到U-Boot控制台绕过ATF的引导。ATF本身不负责管UART但它配合TBB时如果bootrom阶段就允许console指令跳转链就断了。修复建议通常比较接地气。生产固件里把DEBUG关掉LOG_LEVEL降到40以下不要再拿RSA-2048当传家宝ARMv8.3以上的芯片尽快切到ECDSA或者支持PAuthOTP里存放的公钥要和开发证书严格分离CI里做一条专门的“生产密钥检查”防止误打包私钥。4. 平台移植落地指南从FVP到你的板子4.1 移植前准备和平台选择移植ATF有点像装修房子先看户型图纸才能动线。你至少需要三样东西SoC的TRM技术参考手册、板级原理图里的DDR/UART/GIC地址信息、以及一份参考平台的ATF代码。如果你是第一次尝试我最推荐的路径是从FVPFixed Virtual Platform入手。FVP没有真实硬件约束随便改代码、随便调地址跑挂了也只是虚拟环境崩掉不会锁死开发板。等你在FVP上调通了基本启动流程再迁移到真实SoC成功率会高一大截。选择真实平台时尽量从plat/arm/board/下的参考板开始。ARM官方提供的qemu、juno、fvp这些平台代码已经处理好了GIC、UART、内存布局这些底层配置你要做的通常是“改地址替换驱动”。从零写一个platform目录不是不行而是工作量太大容易一头扎进寄存器旋涡里出不来。4.2 一步步搭建平台目录以从FVP迁移到一个典型Armv8 SoC为例我通常会做这几步在plat/vendor/下新建平台目录比如plat/mycompany/myboard。直接复制plat/arm/board/fvp里的文件结构再改比空手写省事很多。处理platform_def.h这是整个移植里最重要的头文件。你需要根据SoC的地址映射配置BL31_BASE、TZRAM_BASE、TZRAM_SIZE、ARM_GICD_BASE、ARM_GICC_BASE等宏。宏配错了启动直接挂在莫名其妙的位置连log都看不到。在platform.mk里声明你依赖的驱动和编译选项。比如这个SoC用的是GICv3就需要有ARM_GIC_V3相关的定义如果用PL011要把PL011_GENERIC_UART这些项打开。实现平台回调函数。最基础的一组包括platform_setup()、bl31_platform_setup()、plat_get_next_bl_params()、plat_get_image_source()。这些函数决定了BL31运行后硬件被初始化成什么样、从哪里加载下一级镜像。配置FIP镜像加载顺序。ATF通过FIP包统一管理各镜像你需要确保BL33U-Boot/EDK2的镜像ID、加载地址和加载方式都符合你的平台预期。我自己移植时还习惯在plat/mycompany/myboard/include/下放一个platform_def.h来统一宏管理然后通过include到公共代码里避免改动过多样板文件。4.3 内存布局、GIC与定时器三座大山这三项是移植ATF时最容易翻车的点。内存布局的坑最隐蔽。有些SoC的DDR起始地址不是0x00000000而是从0x80000000或更高地址开始。如果你沿用FVP的BL31_BASE配置BL31会加载到一块既不连续又不存在的地址上出现“代码可以编译但永远跑不起来”的诡异问题。解决方式很笨但靠谱对照TRM的memory map把所有关键地址在platform_def.h里重新推导一遍再在代码里加打印验证实际加载地址。GIC的坑主要在中断路由上。GIC里每个中断都要配置group和priorityATF会设置安全中断的目标核心。如果你把SPI中断配置成了group1非安全正常世界的OS和EL3看到的中断归属就会错乱。更隐蔽的是GICR Base和GICD Base搞反导致基金会收不到任何中断。移植时先把driver/arm/gic相关代码读明白尤其是arm_gic_pcpu_distif_init之后的启动顺序。定时器看起来最简单其实是第二个容易翻车的地方。EL3需要CNTPCT、CNTHP这些系统定时器。如果SoC里定时器基地址和中断号定义错误PSCI的SYSTEM_SUSPEND、CPU_ON会直接挂死。调这问题时先确认CNTFRQ_EL0频率是否设置正确过低或过高都会导致功耗管理状态判断异常。5. 构建、调试与经验心得5.1 构建系统解析与常用build选项ATF使用嵌套的Makefile系统顶层makefile加上各平台的platform.mk。构建时通过PLAT指定平台make PLATfvp DEBUG1 V1能输出详细编译信息。常用选项里TRUSTED_BOARD_BOOT1开启TBBGENERATE_COT1在构建时生成证书链FIP_ALIGN控制FIP对齐BL33指定下一级bootloader路径。在开发调试阶段我建议把LOG_LEVEL调到50左右这样能看到BL31早期初始化的详细日志。量产时再降下来。如果想产出一个完整FIP构建命令一般是make PLATmyboard BL33u-boot.bin TRUSTED_BOARD_BOOT1 GENERATE_COT1 all fip这套流程跑通后FIP文件会生成在build/myboard/release/下。注意如果开了TBB且用了自定义证书工具cert_create和fiptool要放在构建路径里才能正常完成打包。5.2 调试ATF的实用性技巧调试ATF最直接的方式就是串口log。由于ATF在EL3阶段禁用MMU也不是没可能早期的log输出会非常“裸”。确认UART能打印后一切问题都好定位。遇到“停在BL1没下文”的case先检查BL1加载BL2的地址是否正确。很多时候是BL2_BASE和BL31_BASE在链接时产生冲突代码和镜像互相踩内存。遇到BL31起来但U-Boot无法跳转的case优先查BL33的加载地址有没有超过DDR大小以及BL31在退出去之前有没有把EL2的MMU配置清理干净。用FVP调试时配合--data参数指定DDR内容非常顺手。比如启动时把U-Boot镜像直接放到FVP的DDR区域能跳过U-Boot加载前的很多环节。步骤大概是FVP_Base_RevC-2xAEMvA \ -C cluster0.NUM_CORES4 \ -C bp.secure_memory1 \ -C bp.trusted_boot1 \ --data cluster0.cpu0.u-boot.bin0x80000000调PSCI或SMC时可以借助DS-5或者OpenOCD在ATF入口加断点。bl31_main是第一个C路径在这里看上下文切换前的寄存器状态非常有效。5.3 踩过的坑与最后的建议这几年下来ATF移植方面我踩得最经常的坑可以总结成一个速查表现象第一排查点启动无logUART驱动是否打开、console基地址是否匹配、串口复用配置BL1加载BL2后car死BL2_BASE是否与BL1的rw区重叠BL31起来但SMC崩溃检查SMC handler是否注册、调用号是否冲突内核启动后CPU hotplug失败PSCI的CPU_ON实现是否完整、target cpu id是否正确系统挂起后无法唤醒定时器频率CNTFRQ_EL0是否一致、GIC唤醒源是否配置安全世界经常收到伪中断GICD/GICR地址错误、SPI中断分组归属错误给新手朋友的建议就一条不要一上来就改代码先把FVP上的ATF跑通编译、烧录、看日志、加断点各路径都有体感之后再去动自己的平台。ATF是一个逻辑非常严密、归约得很干净的代码库早期阶段看不懂不代表它乱多半是异常级别和执行流程在脑子里的3D模型没搭起来。等那个模型成型了后续看BL31、PSCI、SPMC都会很快。我个人的习惯是同时开两个窗口左边ATF源码右边ARM ARM指令手册比看十篇博客都有效。
题图这种事我就不放了毕竟搞固件的人心里都有数——真正的图在各自的板卡原理图和call stack里。这篇文章我基于Arm-Trusted-FirmwareATF源码从架构全景、安全审计、平台移植三个维度做一次深度拆解。内容偏实践向不绕圈子尽量把源码背后的设计动机、工程权衡和移植时会踩的坑一次讲透。1. 为什么ATF值得你花时间读源码1.1 一个启动链路里的“隐形总管”大多数人接触ATF是从看U-Boot启动日志开始的。从BL1、BL2跳转再到BL31、BL32ATF在bootloader之前、内核之前就已经把CPU从EL3拉到了安全世界的运行态。简单说ATF就是在ARMv8/AArch64系统上负责EL3运行时代码、安全启动链校验、以及普通世界和安全世界之间切换的那一层固件。很多嵌入式工程师一开始都以为“固件启动就是U-Boot kernel”等真正查起来才发现U-Boot之前的BL1/BL2、U-Boot之后的BL31/BL32全是ATF的活。而且它不只是“跳到下一级再来一遍”它在你还没看到任何日志之前已经完成了CPU早期初始化、可信启动链的前置验证、内存布局的心理预期建立。写U-Boot驱动之前不读ATF很多系统级问题根本无从下手。1.2 ATF到底管了哪些事展开说的话它管的事很多但最核心的离不开这几个垂直方向安全世界入口也就是EL3 runtime固件处理Secure Monitor CallSMC负责切换世界、保存和恢复上下文。可信启动链从BL1到BL33每一级通过证书链验证镜像合法性防止固件被篡改或回滚。PSCI实现电源状态协调接口比如CPU的开启/关闭、系统挂起/复位都是由ATF的PSCI服务向内核提供标准接口。中断路由GIC路由规则确定哪些中断进安全世界哪些直接给普通世界关键就在于EL3里怎么配置和分发给trusted OS。内存隔离与页表管理翻译表Translation Table从EL3视角划分安全和非安全地址空间确保普通世界不能顺手摸到安全内存。这几点理解了ATF在系统中的位置就清楚了。它不是一个孤立的小固件而是连接Bootloader、hypervisor、OS和Trusted OS之间的骨架。你看代码时如果把ATF当成“另一个启动固件”来读会觉得它搅和了一堆乱七八糟的东西但如果你把它当成操作系统内核一样对待理解异常级别、上下文、资源隔离所有代码路径就顺了。2. ATF源码架构全景从目录结构到关键模块2.1 异常级别模型与EL3的比特级真相ARMv8的异常级别模型是ATF存在的根基。EL0是用户态EL1是内核态EL2是虚拟化层EL3是安全固件。ATF主要工作在EL3但boot过程中它会短暂出现在EL1、EL2这些低异常级别里准备环境。很多人问为什么要在EL3单独放一层固件而不是像ARMv7那样直接塞给secure monitor因为从ARMv8开始ARM把安全世界拆得更细了。EL3管安全监控EL1/EL0的Trusted OS比如OP-TEE管安全服务两个世界通过SMC指令进入EL3由EL3判断下一个该把控制权交给谁。换句话说你看到的每一次“世界切换”背后其实都是异常级别的上升到EL3、上下文保存、路由分发、再降级回去的过程。源码里与此对应的核心是lib/el3_runtime/aarch64/context_mgmt.c和lib/el3_runtime/aarch64/context.S。前者负责建立cpu_context结构体保存普通世界和安全世界的寄存器状态后者负责在world switch时真正执行保存与恢复动作。我记得第一次翻到这里时看代码里的el1_sysregs、gpregs这些偏移展开背后对应的就是一个个系统寄存器。代码写得非常规整几乎没有任何奇技淫巧很适合当汇编和系统寄存器学习的范本。2.2 六大源码模块逐层拆解ATF的仓库结构不算大顶层目录却分得很清楚目录/文件作用bl1/第一阶段bootloader。一般存放在ROM或片上SRAM负责最基础的硬件初始化然后加载BL2。bl2/第二阶段bootloader负责加载BL31、BL32、BL33镜像执行可信启动链验证。bl31/EL3 runtime固件包含SMC分发、PSCI、中断管理、运行时服务。bl32/可选的安全OS入口比如OP-TEE的对接层一般会调用到spd/下的specific dispatcher。common/公共代码启动逻辑、FIP解析、镜像加载、bl_common等。lib/通用库包含el3_runtime、xlat_tables_v2、psci、smc、extensions等。drivers/各类驱动常见的有arm/gic、arm/uart、ti/uart、st/uart、arm/gpio等。plat/平台相关代码每个SoC或board一个目录。tools/证书创建、fiptool、sptool等工具。include/公共头文件定义常量、结构体、函数声明。makefile顶层构建入口支持大量编译选项。其中plat/目录是最需要花时间看的。以plat/arm/board/fvp来说它是ARM官方提供的固定虚拟平台Fixed Virtual Platform参考实现也是绝大多数移植工作的起点。2.3 运行时服务与SMC分发机制ATF里最像“内核调度器”的部分就是SMC分发。当普通世界想进安全世界执行smc #0CPU就陷到EL3BL31里的handle_smc开始找对应的runtime service。在源码里这个机制体现为runtime service框架每个服务都注册了自己的SMC调用号范围比如PSCI服务是ARM_SVC_STD_CALL范围内的标准调用OP-TEE服务由opteed dispatcher注册。运行时服务表中的rt_svc_descs数组就是核心调度表每个描述符里有初始化函数、调用处理函数还有调用号范围。SMC处理流程并不复杂但调试时很容易忽略一点在发给对应handler之前ATF会做参数校验。比如is_caller_secure()根据调用来源判断是Secure世界还是Normal世界发起的来决定能不能访问某些敏感服务。源码在bl31/bl31_main.c里写得很清楚值得当规范来读。3. 安全固件工程审计不只是“开个TBB开关”3.1 可信启动链的密码学验证流程很多人把可信启动理解为一个开关TRUSTED_BOARD_BOOT1一打开万事大吉。实际用起来才知道TBB是个完整的证书链验证体系。ATF的TBB流程大致是这样的在构建时用cert_create工具生成一组密钥对和证书。每级镜像对应一张证书比如BL2的证书、BL31的证书、BL32的证书、BL33的证书。证书与镜像通过fiptool打包成一个FIP固件镜像包。启动时BL1在ROM里执行验证BL2镜像的证书和哈希确保BL2没有被替换。BL2再依次验证BL31、BL32、BL33的镜像一层一层往下信任传递。关键点在于根密钥Root of Trust。BL1验证BL2时用的那把公钥是在芯片出厂烧录阶段就写死在OTP里的不是从FIP里读出来的。这就是“信任根”的物理基础。如果OTP密钥没写or被人改了整套可信启动就是纸糊的。做安全审计时我最先检查的不是算法强不强而是密钥放哪。曾有项目把根公钥直接放在FLASH里TBB开了等于没开攻击者把公钥换成自己的整个验证链瞬间崩掉。这个问题审计报告里经常出现实际code review时很难一眼看出来。3.2 审计时需要重点盯的代码路径代码审计和写feature是两码事。写feature关心怎么把功能做通审计关心“如果这里被恶意输入打了会怎样”。所以在ATF里我要盯的是几个边界路径SMC参数校验所有从普通世界进EL3的SMC参数都会经过scr_el3设置和函数入口检查。有没有对参数范围做过校验有没有可能存在越界访问重点看fid是否被用来做数组索引。翻译表权限lib/xlat_tables_v2负责在安全世界建立页表。一旦某块区域被映射成可写可执行就是攻击者的马场。审计时我习惯用脚本扫出所有MT_CODE | MT_WRITE的映射组合逐个核对是否必要。BL2/SP的镜像加载BL2解析FIP时如果镜像描述符里的offset、size没有范围检查可能通过超大的镜像大小把数据读到预期之外的区域。ATF在bl2/bl2_image_load_desc.c里对这类数据做了比较严格的控制但如果你改过镜像加载顺序就要重新检查。缓存一致性、side channel防护这些属于进阶项一般量产固件可以先看有没有打开ARM_ARCH_SAFETY相关的选项和流水线预测相关的防护。3.3 常见安全弱项与修复建议我在实际审计中见到的ATF安全问题排第一的不是什么高级攻击而是“没启用安全启动”。很多基于ATF的产品还是只用了U-Boot去校验kernelATF层面的TBB根本没打。第二常见的就是私钥管理混乱。构建机上私钥跟镜像包放一起随随便便打包传到车间泄露了也无感知。第三类是硬件层面的安全隐患比如UART调试口在量产固件里没有关闭攻击者可以通过console直接进到U-Boot控制台绕过ATF的引导。ATF本身不负责管UART但它配合TBB时如果bootrom阶段就允许console指令跳转链就断了。修复建议通常比较接地气。生产固件里把DEBUG关掉LOG_LEVEL降到40以下不要再拿RSA-2048当传家宝ARMv8.3以上的芯片尽快切到ECDSA或者支持PAuthOTP里存放的公钥要和开发证书严格分离CI里做一条专门的“生产密钥检查”防止误打包私钥。4. 平台移植落地指南从FVP到你的板子4.1 移植前准备和平台选择移植ATF有点像装修房子先看户型图纸才能动线。你至少需要三样东西SoC的TRM技术参考手册、板级原理图里的DDR/UART/GIC地址信息、以及一份参考平台的ATF代码。如果你是第一次尝试我最推荐的路径是从FVPFixed Virtual Platform入手。FVP没有真实硬件约束随便改代码、随便调地址跑挂了也只是虚拟环境崩掉不会锁死开发板。等你在FVP上调通了基本启动流程再迁移到真实SoC成功率会高一大截。选择真实平台时尽量从plat/arm/board/下的参考板开始。ARM官方提供的qemu、juno、fvp这些平台代码已经处理好了GIC、UART、内存布局这些底层配置你要做的通常是“改地址替换驱动”。从零写一个platform目录不是不行而是工作量太大容易一头扎进寄存器旋涡里出不来。4.2 一步步搭建平台目录以从FVP迁移到一个典型Armv8 SoC为例我通常会做这几步在plat/vendor/下新建平台目录比如plat/mycompany/myboard。直接复制plat/arm/board/fvp里的文件结构再改比空手写省事很多。处理platform_def.h这是整个移植里最重要的头文件。你需要根据SoC的地址映射配置BL31_BASE、TZRAM_BASE、TZRAM_SIZE、ARM_GICD_BASE、ARM_GICC_BASE等宏。宏配错了启动直接挂在莫名其妙的位置连log都看不到。在platform.mk里声明你依赖的驱动和编译选项。比如这个SoC用的是GICv3就需要有ARM_GIC_V3相关的定义如果用PL011要把PL011_GENERIC_UART这些项打开。实现平台回调函数。最基础的一组包括platform_setup()、bl31_platform_setup()、plat_get_next_bl_params()、plat_get_image_source()。这些函数决定了BL31运行后硬件被初始化成什么样、从哪里加载下一级镜像。配置FIP镜像加载顺序。ATF通过FIP包统一管理各镜像你需要确保BL33U-Boot/EDK2的镜像ID、加载地址和加载方式都符合你的平台预期。我自己移植时还习惯在plat/mycompany/myboard/include/下放一个platform_def.h来统一宏管理然后通过include到公共代码里避免改动过多样板文件。4.3 内存布局、GIC与定时器三座大山这三项是移植ATF时最容易翻车的点。内存布局的坑最隐蔽。有些SoC的DDR起始地址不是0x00000000而是从0x80000000或更高地址开始。如果你沿用FVP的BL31_BASE配置BL31会加载到一块既不连续又不存在的地址上出现“代码可以编译但永远跑不起来”的诡异问题。解决方式很笨但靠谱对照TRM的memory map把所有关键地址在platform_def.h里重新推导一遍再在代码里加打印验证实际加载地址。GIC的坑主要在中断路由上。GIC里每个中断都要配置group和priorityATF会设置安全中断的目标核心。如果你把SPI中断配置成了group1非安全正常世界的OS和EL3看到的中断归属就会错乱。更隐蔽的是GICR Base和GICD Base搞反导致基金会收不到任何中断。移植时先把driver/arm/gic相关代码读明白尤其是arm_gic_pcpu_distif_init之后的启动顺序。定时器看起来最简单其实是第二个容易翻车的地方。EL3需要CNTPCT、CNTHP这些系统定时器。如果SoC里定时器基地址和中断号定义错误PSCI的SYSTEM_SUSPEND、CPU_ON会直接挂死。调这问题时先确认CNTFRQ_EL0频率是否设置正确过低或过高都会导致功耗管理状态判断异常。5. 构建、调试与经验心得5.1 构建系统解析与常用build选项ATF使用嵌套的Makefile系统顶层makefile加上各平台的platform.mk。构建时通过PLAT指定平台make PLATfvp DEBUG1 V1能输出详细编译信息。常用选项里TRUSTED_BOARD_BOOT1开启TBBGENERATE_COT1在构建时生成证书链FIP_ALIGN控制FIP对齐BL33指定下一级bootloader路径。在开发调试阶段我建议把LOG_LEVEL调到50左右这样能看到BL31早期初始化的详细日志。量产时再降下来。如果想产出一个完整FIP构建命令一般是make PLATmyboard BL33u-boot.bin TRUSTED_BOARD_BOOT1 GENERATE_COT1 all fip这套流程跑通后FIP文件会生成在build/myboard/release/下。注意如果开了TBB且用了自定义证书工具cert_create和fiptool要放在构建路径里才能正常完成打包。5.2 调试ATF的实用性技巧调试ATF最直接的方式就是串口log。由于ATF在EL3阶段禁用MMU也不是没可能早期的log输出会非常“裸”。确认UART能打印后一切问题都好定位。遇到“停在BL1没下文”的case先检查BL1加载BL2的地址是否正确。很多时候是BL2_BASE和BL31_BASE在链接时产生冲突代码和镜像互相踩内存。遇到BL31起来但U-Boot无法跳转的case优先查BL33的加载地址有没有超过DDR大小以及BL31在退出去之前有没有把EL2的MMU配置清理干净。用FVP调试时配合--data参数指定DDR内容非常顺手。比如启动时把U-Boot镜像直接放到FVP的DDR区域能跳过U-Boot加载前的很多环节。步骤大概是FVP_Base_RevC-2xAEMvA \ -C cluster0.NUM_CORES4 \ -C bp.secure_memory1 \ -C bp.trusted_boot1 \ --data cluster0.cpu0.u-boot.bin0x80000000调PSCI或SMC时可以借助DS-5或者OpenOCD在ATF入口加断点。bl31_main是第一个C路径在这里看上下文切换前的寄存器状态非常有效。5.3 踩过的坑与最后的建议这几年下来ATF移植方面我踩得最经常的坑可以总结成一个速查表现象第一排查点启动无logUART驱动是否打开、console基地址是否匹配、串口复用配置BL1加载BL2后car死BL2_BASE是否与BL1的rw区重叠BL31起来但SMC崩溃检查SMC handler是否注册、调用号是否冲突内核启动后CPU hotplug失败PSCI的CPU_ON实现是否完整、target cpu id是否正确系统挂起后无法唤醒定时器频率CNTFRQ_EL0是否一致、GIC唤醒源是否配置安全世界经常收到伪中断GICD/GICR地址错误、SPI中断分组归属错误给新手朋友的建议就一条不要一上来就改代码先把FVP上的ATF跑通编译、烧录、看日志、加断点各路径都有体感之后再去动自己的平台。ATF是一个逻辑非常严密、归约得很干净的代码库早期阶段看不懂不代表它乱多半是异常级别和执行流程在脑子里的3D模型没搭起来。等那个模型成型了后续看BL31、PSCI、SPMC都会很快。我个人的习惯是同时开两个窗口左边ATF源码右边ARM ARM指令手册比看十篇博客都有效。
