1. 项目概述从开机到内核的第一行代码按下电脑的电源键屏幕上闪过一行行启动信息最终进入我们熟悉的操作系统界面。这个看似简单的过程背后隐藏着一系列精密而复杂的交接仪式。对于Linux内核开发者或系统底层爱好者而言理解这个过程尤其是内核自身如何“苏醒”并接管整个硬件世界是通往系统核心的必经之路。今天我们就来深入剖析这个启动交响乐中最关键的第一个音符——stext段。stext这个名字听起来有些神秘它其实是Linux内核镜像中一个特定代码段的标签全称是“start text”即“起始文本段”。在ARM64架构的Linux内核中它被标记为内核执行的绝对入口点。简单来说当引导加载程序如U-Boot完成它的使命将CPU的控制权移交给内核时CPU的程序计数器PC跳转到的第一个地址就是stext标签所在的位置。这行代码是内核世界对硬件世界说出的第一句“Hello, World!”。理解stext不仅仅是知道一个符号地址。它意味着我们要拆解内核启动最早期、最底层的初始化流程。这个阶段内核运行在一个非常“原始”的环境中内存管理单元MMU可能还没开启虚拟地址和物理地址是等同的多核处理器中只有一个核心通常是CPU0在活跃工作C语言运行环境尚未建立大部分代码需要用汇编语言编写。分析stext就是跟随内核的引导核心一步步搭建起能让复杂操作系统运行起来的基石。无论你是从事嵌入式开发、内核驱动编写还是单纯对计算机如何从零启动充满好奇这段旅程都将为你揭开系统最神秘的面纱。2. 核心需求与场景解析为什么必须深入stext2.1 解决启动“黑盒”问题对于绝大多数应用开发者操作系统启动是一个完全透明的“黑盒”。但当你的工作涉及到底层——比如定制一款嵌入式设备路由器、物联网终端、工控主板编写一个需要在内核启动早期就介入的驱动程序如时钟、中断控制器或者进行系统级的性能优化与安全加固时——这个“黑盒”就必须被打开。启动失败是嵌入式开发中最令人头疼的问题之一。板子上电后毫无反应串口只打印到“Starting kernel...”就再无下文。此时问题很可能就出在stext及其后续的早期初始化阶段。可能是内存初始化不对可能是处理器状态设置错误也可能是设备树DTB传递的地址有误。如果不理解stext在做什么排查这类问题就像在黑暗中摸索。通过分析stext你能清晰地知道内核在每一个步骤期望硬件处于什么状态从而精准定位是硬件配置问题、引导程序传递参数问题还是内核镜像本身的问题。2.2 掌握多核启动的同步原语现代处理器几乎都是多核SMP或众核的。内核如何唤醒并管理这些沉睡的核心答案的起点就在stext。在ARM64架构中主核CPU0从stext开始执行而其他从核CPU1, CPU2...在上电后则处于一个等待状态。主核在stext的执行路径中会进行一系列关键设置然后通过处理器间中断IPI或者设置特定的内存地址例如secondary_holding_pen来“唤醒”从核。从核被唤醒后同样会跳转到stext入口但通过检查自己的CPU ID会进入一条不同的、简化的初始化路径最终与主核汇合。理解这个过程对于编写高性能的多线程程序、调试多核间的竞争条件、甚至设计自己的调度算法都有深远意义。你会明白cpu_online_mask这个位图是如何被初始化的也会理解为什么在内核启动完成前不能随意假设其他CPU核心是可用的。2.3 构建安全与可信计算的基石在安全领域特别是可信启动Trusted Boot和机密计算Confidential Computing中系统启动初期的完整性至关重要。安全模块如ARM TrustZone中的安全监控模式调用的初始化、内存加密区域的建立、对内核镜像完整性的度量这些操作往往需要在操作系统完全启动之前在尽可能早的阶段完成。stext阶段由于还没有复杂的调度和内存管理是执行这些关键安全操作的理想时机。分析stext代码你可以看到内核如何与固件如UEFI或ATF交互如何准备安全扩展如ARMv8.4-A的指针认证PAC的运行环境。这对于从事固件安全、系统安全研究的工程师来说是不可或缺的基础知识。3. 环境准备与工具链选型要分析stext你不需要一块真实的开发板。一个能调试的模拟环境加上得心应手的工具就能开启探索之旅。3.1 核心工具交叉编译工具链由于我们分析的是ARM64内核但开发环境很可能在x86的PC上所以交叉编译工具链是必需品。推荐使用Linaro或Arm官方发布的GCC工具链。选择时要注意与目标内核版本的兼容性较新的内核可能需要支持特定架构扩展的工具链。# 例如安装aarch64-linux-gnu工具链在Ubuntu上 sudo apt-get install gcc-aarch64-linux-gnu验证安装aarch64-linux-gnu-gcc --version。确保它能正常工作。3.2 模拟与调试环境QEMU GDBQEMU是一个功能强大的开源模拟器可以模拟包括ARM64在内的多种处理器架构。用它来运行内核比在真机上方便无数倍尤其是单步调试。# 安装QEMU系统模拟器以Ubuntu为例 sudo apt-get install qemu-system-arm qemu-system-aarch64调试是理解代码执行流的关键。我们需要配置GDB进行远程调试。内核需要编译时开启调试符号CONFIG_DEBUG_INFOyQEMU启动时加入-s -S参数-S表示启动时暂停-s表示在1234端口开启GDB服务。3.3 内核源码获取与配置从 kernel.org 或你使用的芯片厂商的Git仓库获取内核源码。选择一个稳定的版本开始例如5.10或5.15 LTS版本它们代码结构清晰社区资料丰富。配置内核是第一步也是容易踩坑的地方。对于我们的分析目的最小化配置即可这样可以减少编译时间也让生成的镜像更简洁。# 进入内核源码目录 cd linux-5.15 # 导出交叉编译环境变量 export ARCHarm64 export CROSS_COMPILEaarch64-linux-gnu- # 使用默认的defconfig生成基础配置 make defconfig # 进入图形化配置界面确保打开调试信息 make menuconfig在menuconfig中确保以下选项被启用Kernel hacking-Compile-time checks and compiler options-Compile the kernel with debug info (CONFIG_DEBUG_INFO)为了简化可以关闭不必要的驱动和文件系统支持。注意在真机调试时你的内核配置必须匹配硬件特别是设备树DTB。在QEMU中我们可以使用它内置的virt机器模型它模拟了一个通用的ARM64虚拟机有标准化的硬件省去了适配具体硬件的麻烦。3.4 辅助分析工具objdump与readelf编译好的内核镜像是一个ELF文件。objdump和readelf是分析二进制文件的瑞士军刀。aarch64-linux-gnu-objdump -d vmlinux反汇编整个内核生成汇编代码。我们可以从中找到stext标签对应的汇编指令序列。aarch64-linux-gnu-readelf -S vmlinux查看内核镜像的所有段Section信息找到.text段、.init.text段等的地址和大小stext通常位于.head.text或.init.text段内。aarch64-linux-gnu-nm vmlinux | grep stext直接从符号表中查找stext的地址。这些工具能帮助我们在静态层面建立对代码布局的认知是动态调试前的重要准备。4. stext入口代码的逐行解析让我们以Linux 5.15内核在ARM64架构下的代码为例走进arch/arm64/kernel/head.S这个文件。这个汇编文件就是内核启动的“总剧本”。stext标签通常就在这个文件的开头部分。4.1 开场处理器状态检查与设置内核被加载到内存并开始执行时它对于当前处理器的状态知之甚少。stext的第一项工作就是进行一系列严格的检查和安全设置。// arch/arm64/kernel/head.S (简化示意) ENTRY(stext) // 1. 确保当前处于EL2虚拟化扩展或EL1操作系统异常等级。 // 如果从EL3安全监控态启动需要先降级到EL2/EL1。 mrs x0, CurrentEL cmp x0, #CurrentEL_EL3 b.eq init_el3 // 2. 禁用MMU和缓存。在建立自己的页表之前内核运行在物理地址上。 // 这通过设置系统控制寄存器SCTLR_EL1的相应位来完成。 mrs x0, sctlr_el1 bic x0, x0, #SCTLR_ELx_M // 清除M位禁用MMU bic x0, x0, #SCTLR_ELx_C // 清除C位禁用数据缓存 bic x0, x0, #SCTLR_ELx_I // 清除I位禁用指令缓存 msr sctlr_el1, x0 isb // 指令同步屏障确保设置生效为什么这么做内核需要从一个已知的、干净的状态开始。MMU和缓存的行为依赖于后续建立的页表在页表就绪前启用它们会导致不可预测的内存访问必然导致崩溃。isb指令确保之前的配置写入在后续指令执行前完成是ARM架构下重要的内存屏障。4.2 身份识别主核与从核的分流点接下来内核需要知道当前正在执行的是哪个CPU核心。这通过读取MPIDR_EL1寄存器实现。// 3. 获取当前CPU的ID (Affinity) mrs x0, mpidr_el1 and x0, x0, #MPIDR_AFF_MASK // 提取亲和性字段 // 检查是否是主核通常定义affinity为0的核为主核 cbz x0, primary_entry // 4. 如果是从核则进入等待循环holding pen // 主核会稍后来这里唤醒它 adr_l x1, secondary_holding_pen br x1 primary_entry: // 主核继续执行后续复杂的初始化流程关键点解析MPIDR_EL1寄存器编码了处理器在集群Cluster、核心Core层面的拓扑ID。primary_entry是主核专属的路径。从核则跳转到一个叫做secondary_holding_pen的地址那是一个由主核控制的循环或等待区域。这是一种经典的“主从式”启动同步模型。4.3 搭建舞台早期页表与内存映射这是stext阶段最复杂、也最核心的部分之一。内核要开启MMU从物理地址模式切换到虚拟地址模式但它自己还没有运行时内存堆栈来运行复杂的C代码。因此它需要先手工打造一个简单的、临时性的页表我们称之为“恒等映射Identity Mapping”或“早期页表”。// 5. 设置早期页表基地址寄存器TTBR0_EL1 // __idmap_pg_dir 是恒等映射页表的起始物理地址。 adrp x0, __idmap_pg_dir msr ttbr0_el1, x0 isb // 6. 创建恒等映射 // 将内核镜像所在的物理内存区域映射到相同的虚拟地址。 // 例如物理地址0x80080000映射到虚拟地址0x80080000。 // 这样在开启MMU的瞬间代码还能继续正确执行。 mov x0, xzr mov x1, #SWAPPER_MM_MMUFLAGS adrp x2, _text // 内核.text段起始物理地址 adrp x3, _end // 内核结束物理地址 bl __create_page_tables // 调用创建页表的子函数 // 7. 加载内存属性配置开启MMU adrp x0, idmap_pg_dir bl __cpu_setup // 配置缓存、TLB等 bl __enable_mmu // 这个函数内部最终会设置SCTLR_EL1的M位为1深度解读恒等映射的必要性想象一下CPU正在物理地址0x80080000处取指执行bl __enable_mmu这条指令。当MMU开启的瞬间CPU发出的下一个取指地址PC4会被MMU当作虚拟地址进行转换。如果没有恒等映射这个虚拟地址可能指向一个无效或随机的物理地址系统立刻崩溃。恒等映射保证了“开启MMU”这个动作本身及其后紧接着的几条指令能够平滑过渡。__create_page_tables函数这个函数用汇编实现它会填充__idmap_pg_dir开始的页表项。它通常使用“块映射”Block Map如ARM64的2MB大页来映射内核的代码、数据区效率很高。__cpu_setup这个函数根据CPU的型号通过读取MIDR_EL1寄存器来设置一些处理器特定的参数比如缓存策略、TLB失效操作等。实操心得调试早期页表错误非常棘手。一个常见的问题是内核解压地址如果使用了压缩内核Image.gz或加载地址与内核链接地址vmlinux中的符号地址不匹配。这会导致恒等映射建立错误MMU一开就飞。务必确保引导加载程序如U-Boot的bootm命令将内核镜像放置到正确的物理地址这个地址需要与内核编译时链接脚本arch/arm64/kernel/vmlinux.lds.S中定义的_text符号的物理地址预期一致。4.4 切换世界跳转到虚拟地址空间的高端恒等映射只是临时桥梁。Linux内核通常运行在虚拟地址空间的高端区域例如0xffff_0000_0000_0000这是ARM64的VA_BITS配置决定的常见48位。在开启MMU后内核需要立即跳转到这个高端的虚拟地址去继续执行。// 8. 计算内核在虚拟地址空间中的入口点并跳转过去。 adrp x0, _text // 获取_text的物理地址当前仍在恒等映射视图下 add x0, x0, #PAGE_OFFSET // PAGE_OFFSET是内核虚拟地址的起始如0xffff_0000_0000_0000 br x0 // 绝对跳转从此进入内核的虚拟地址世界。 // 跳转目标例如 __primary_switched 标签 __primary_switched: // 此时CPU已经运行在高位虚拟地址上了。 // 可以安全地清理掉临时的恒等映射了某些实现会这么做。这个“跳转”动作是理解内核地址空间切换的钥匙。br x0指令执行后程序计数器PC载入的是一个高位的虚拟地址如0xffff8000080080000。由于MMU已经开启并且内核已经建立了从该虚拟地址到正确物理地址的映射这是在__create_page_tables中建立的另一套映射不同于恒等映射所以CPU能够继续取指执行。从此内核正式运行在其设计的、完整的虚拟内存环境中。4.5 环境初始化为C语言世界铺路跳转到高位地址后内核仍然运行在汇编环境。接下来要做的是为调用第一个C函数start_kernel准备必要的运行时环境。__primary_switched: // 9. 初始化BSS段全部清零。 // BSS段存放未初始化的全局/静态变量根据C语言标准必须初始化为0。 adr_l x0, __bss_start adr_l x1, __bss_stop sub x1, x1, x0 bl __pi_memset // 调用一个简单的内存清零函数可能是汇编实现 // 10. 设置栈指针SP。 // 栈是函数调用、局部变量存放的基础。每个CPU核心都需要自己的栈。 adr_l x0, init_thread_union // 获取init进程的线程信息union地址 add x0, x0, #THREAD_SIZE // 栈是向下生长的所以栈顶是 union起始地址 栈大小 mov sp, x0 // 11. 保存设备树BlobDTB的地址。 // 引导加载程序会将DTB的物理地址存放在寄存器X0中根据ARM64启动协议。 // 内核需要将这个地址保存到一个全局变量如__fdt_pointer供后续解析。 adr_l x1, __fdt_pointer str x0, [x1] // 12. 最后跳转到C语言的主函数 start_kernel b start_kernel为什么是这些步骤BSS清零这是C程序启动的常规操作。如果不做未初始化的全局变量将是随机值导致程序行为不可预测。设置栈没有栈就无法进行函数调用无法保存返回地址和局部变量。init_thread_union是内核为0号进程swapper进程准备的线程信息块其中包含了该进程的内核栈。主核使用这个栈来启动。保存DTB设备树是现代ARM Linux硬件描述的标准方式。内核需要知道内存布局、外设地址等信息这些都来自DTB。遵循启动协议引导程序通过寄存器传递这个关键指针。至此stext汇编部分的使命基本完成。它将一个“裸”的CPU初始化为一个具备了虚拟内存、干净数据段、有效调用栈的初级执行环境然后潇洒地将控制权交给了C语言编写的start_kernel()函数。操作系统内核的宏大叙事从此正式拉开帷幕。5. 从核启动路径解析前面我们聚焦于主核CPU0的启动路径。在多核系统中从核CPU1, CPU2...的启动是一个协同过程。它们的入口点也是stext但走的是另一条“快速通道”。5.1 从核的等待与唤醒当主核执行到stext通过mpidr_el1判断自己不是主核时会跳转到secondary_holding_pen。这是一个由主核控制的同步点。// 从核的入口简化 secondary_holding_pen: wfe // 等待事件Wait For Event进入低功耗状态 ldr x0, secondary_holding_pen_release ldr x0, [x0] // 读取释放标志 cbz x0, secondary_holding_pen // 如果为0继续等待 br x0 // 如果不为0跳转到释放地址即secondary_startup从核在这里执行wfe指令休眠直到主核完成必要的全局初始化如内存系统、时钟源、中断控制器并准备好唤醒它们。主核在start_kernel函数的某个阶段通常是smp_prepare_cpus()中会设置secondary_holding_pen_release这个变量的值为从核真正应该跳转的地址例如secondary_startup的物理地址然后向从核发送一个处理器间中断IPI如“SEV”事件唤醒它们。5.2 从核的简化初始化从核被唤醒后跳转到secondary_startup。它的初始化流程比主核简单得多禁用中断避免在初始化完成前被中断打扰。设置从核自身的栈指针每个CPU核心必须有自己独立的内核栈通常是从一个叫做secondary_data的结构体中获取。启用MMU直接使用主核已经建立好的全局页表swapper_pg_dir无需自己创建。跳转到高位虚拟地址类似主核跳转到虚拟地址空间继续执行。调用C函数最终会调用secondary_start_kernel()这个C函数进行该CPU核心特有的初始化比如初始化本地定时器、注册该CPU到调度器最后调用cpu_startup_entry()进入空闲循环等待调度器分配任务。设计精髓这种设计避免了从核重复执行复杂的、全局性的初始化操作如创建页表、解析设备树极大地简化了从核启动流程缩短了多核系统的整体启动时间。所有全局资源由主核一次性初始化从核“坐享其成”。6. 常见问题与调试技巧实录分析或调试stext及相关启动代码时会遇到一些典型问题。以下是我在实践中总结的排查思路和技巧。6.1 问题一内核启动卡在“Starting kernel...”之后这是最经典的启动失败现象。串口输出到此为止系统无任何反应。排查步骤检查引导加载程序参数首先确认U-Boot传递给内核的参数是否正确特别是bootm命令加载内核的地址loadaddr和设备树地址fdtaddr是否与内核编译时的链接地址匹配。使用U-Boot的bdinfo和iminfo命令核对。启用早期调试输出内核在stext的最最早期串口可能还没初始化。但ARM64内核支持“早期控制台”Earlycon。在U-Boot的bootargs中添加earlycon参数并指定正确的串口硬件地址。例如对于PL011串口earlyconpl011,0x9000000。这样在printk初始化之前就能通过这个简单驱动输出信息。使用QEMUGDB单步调试这是最强大的手段。# 终端1启动QEMU并等待GDB连接 qemu-system-aarch64 -machine virt -cpu cortex-a57 -kernel ./arch/arm64/boot/Image -append consolettyAMA0 earlycon -nographic -s -S # 终端2启动GDB并连接 aarch64-linux-gnu-gdb ./vmlinux (gdb) target remote localhost:1234 (gdb) b stext # 在入口点设断点 (gdb) c # 继续执行会立刻停在stext (gdb) si # 单步执行汇编指令通过单步你可以精确观察寄存器info registers和内存的变化判断是在执行mrs/msr设置寄存器时出错还是在创建页表时计算错了地址。6.2 问题二开启MMU后立刻发生异常崩溃现象是代码执行到__enable_mmu附近或之后系统挂起或进入异常处理。排查思路核对恒等映射问题几乎肯定出在早期页表。检查__create_page_tables函数看它映射的内存范围是否覆盖了当前执行流。确保它映射了从_text到_end的整个内核镜像区域并且映射属性是正确的可执行、可读。检查TTBR0设置确认加载到ttbr0_el1寄存器的地址确实是页表基地址__idmap_pg_dir的物理地址。在MMU开启前所有地址都是物理地址。验证CPU设置__cpu_setup函数会根据CPU ID配置一些架构特定的寄存器如TCR_EL1, MAIR_EL1。如果这些配置与你的模拟器或真实硬件不符也可能导致MMU转换错误。对比QEMUvirt机器的默认配置与内核代码中的配置值。使用QEMU内存访问检查在GDB中在跳转到高位地址br x0之前手动检查页表内容。(gdb) x /10gx __idmap_pg_dir # 查看页表前几项内容你需要理解ARM64页表描述符的格式检查其输出的物理地址和属性位是否正确。6.3 问题三从核无法启动或启动后不稳定主核启动正常但从核始终卡住或者启动后系统运行异常。排查步骤检查从核唤醒机制确认主核是否正确地设置了secondary_holding_pen_release变量并发送了唤醒事件SEV。可以在主核代码smp_prepare_cpus()中加打印或使用GDB观察该内存地址的值。核对从核的栈和ID从核的栈地址是通过secondary_data结构体传递的。确保主核正确填充了这个结构体并且从核读取到了正确的栈指针和CPU ID。检查内存一致性主核和从核在开启各自的MMU后必须看到一致的内存视图。确保它们使用的页表swapper_pg_dir是同一个并且相关的缓存维护操作如cache cleaning和TLB invalidation在适当的时候被执行。在多核启动中缓存一致性操作失误是常见的疑难杂症。关注核间同步从核在初始化自己的本地资源如本地中断控制器GIC时可能需要与主核同步。查看secondary_start_kernel函数中是否有自旋锁spinlock或原子操作检查是否发生了死锁。6.4 调试技巧利用汇编宏和标签内核的启动汇编代码中充满了宏如adr_l,str_l和条件编译。阅读时建议在编译后查看实际生成的汇编文件arch/arm64/kernel/head.o的反汇编或者直接使用objdump -d vmlinux查看stext附近的最终代码这样能绕过宏展开看到最直接的指令流。在GDB中你可以直接对汇编标签如primary_entry,__enable_mmu下断点即使它们不是C函数。这比计算指令偏移量要方便得多。分析stext的过程就像在显微镜下观察生命的起源。它揭示了操作系统如何从一片混沌的硬件状态中构建出秩序与逻辑的基础。这份理解是你在进行深度系统定制、性能极限优化或棘手问题调试时最坚实的底气。每一次对底层代码的追踪都是对计算机系统理解的一次升华。
ARM64 Linux内核启动入口stext深度解析：从汇编到C环境的构建
1. 项目概述从开机到内核的第一行代码按下电脑的电源键屏幕上闪过一行行启动信息最终进入我们熟悉的操作系统界面。这个看似简单的过程背后隐藏着一系列精密而复杂的交接仪式。对于Linux内核开发者或系统底层爱好者而言理解这个过程尤其是内核自身如何“苏醒”并接管整个硬件世界是通往系统核心的必经之路。今天我们就来深入剖析这个启动交响乐中最关键的第一个音符——stext段。stext这个名字听起来有些神秘它其实是Linux内核镜像中一个特定代码段的标签全称是“start text”即“起始文本段”。在ARM64架构的Linux内核中它被标记为内核执行的绝对入口点。简单来说当引导加载程序如U-Boot完成它的使命将CPU的控制权移交给内核时CPU的程序计数器PC跳转到的第一个地址就是stext标签所在的位置。这行代码是内核世界对硬件世界说出的第一句“Hello, World!”。理解stext不仅仅是知道一个符号地址。它意味着我们要拆解内核启动最早期、最底层的初始化流程。这个阶段内核运行在一个非常“原始”的环境中内存管理单元MMU可能还没开启虚拟地址和物理地址是等同的多核处理器中只有一个核心通常是CPU0在活跃工作C语言运行环境尚未建立大部分代码需要用汇编语言编写。分析stext就是跟随内核的引导核心一步步搭建起能让复杂操作系统运行起来的基石。无论你是从事嵌入式开发、内核驱动编写还是单纯对计算机如何从零启动充满好奇这段旅程都将为你揭开系统最神秘的面纱。2. 核心需求与场景解析为什么必须深入stext2.1 解决启动“黑盒”问题对于绝大多数应用开发者操作系统启动是一个完全透明的“黑盒”。但当你的工作涉及到底层——比如定制一款嵌入式设备路由器、物联网终端、工控主板编写一个需要在内核启动早期就介入的驱动程序如时钟、中断控制器或者进行系统级的性能优化与安全加固时——这个“黑盒”就必须被打开。启动失败是嵌入式开发中最令人头疼的问题之一。板子上电后毫无反应串口只打印到“Starting kernel...”就再无下文。此时问题很可能就出在stext及其后续的早期初始化阶段。可能是内存初始化不对可能是处理器状态设置错误也可能是设备树DTB传递的地址有误。如果不理解stext在做什么排查这类问题就像在黑暗中摸索。通过分析stext你能清晰地知道内核在每一个步骤期望硬件处于什么状态从而精准定位是硬件配置问题、引导程序传递参数问题还是内核镜像本身的问题。2.2 掌握多核启动的同步原语现代处理器几乎都是多核SMP或众核的。内核如何唤醒并管理这些沉睡的核心答案的起点就在stext。在ARM64架构中主核CPU0从stext开始执行而其他从核CPU1, CPU2...在上电后则处于一个等待状态。主核在stext的执行路径中会进行一系列关键设置然后通过处理器间中断IPI或者设置特定的内存地址例如secondary_holding_pen来“唤醒”从核。从核被唤醒后同样会跳转到stext入口但通过检查自己的CPU ID会进入一条不同的、简化的初始化路径最终与主核汇合。理解这个过程对于编写高性能的多线程程序、调试多核间的竞争条件、甚至设计自己的调度算法都有深远意义。你会明白cpu_online_mask这个位图是如何被初始化的也会理解为什么在内核启动完成前不能随意假设其他CPU核心是可用的。2.3 构建安全与可信计算的基石在安全领域特别是可信启动Trusted Boot和机密计算Confidential Computing中系统启动初期的完整性至关重要。安全模块如ARM TrustZone中的安全监控模式调用的初始化、内存加密区域的建立、对内核镜像完整性的度量这些操作往往需要在操作系统完全启动之前在尽可能早的阶段完成。stext阶段由于还没有复杂的调度和内存管理是执行这些关键安全操作的理想时机。分析stext代码你可以看到内核如何与固件如UEFI或ATF交互如何准备安全扩展如ARMv8.4-A的指针认证PAC的运行环境。这对于从事固件安全、系统安全研究的工程师来说是不可或缺的基础知识。3. 环境准备与工具链选型要分析stext你不需要一块真实的开发板。一个能调试的模拟环境加上得心应手的工具就能开启探索之旅。3.1 核心工具交叉编译工具链由于我们分析的是ARM64内核但开发环境很可能在x86的PC上所以交叉编译工具链是必需品。推荐使用Linaro或Arm官方发布的GCC工具链。选择时要注意与目标内核版本的兼容性较新的内核可能需要支持特定架构扩展的工具链。# 例如安装aarch64-linux-gnu工具链在Ubuntu上 sudo apt-get install gcc-aarch64-linux-gnu验证安装aarch64-linux-gnu-gcc --version。确保它能正常工作。3.2 模拟与调试环境QEMU GDBQEMU是一个功能强大的开源模拟器可以模拟包括ARM64在内的多种处理器架构。用它来运行内核比在真机上方便无数倍尤其是单步调试。# 安装QEMU系统模拟器以Ubuntu为例 sudo apt-get install qemu-system-arm qemu-system-aarch64调试是理解代码执行流的关键。我们需要配置GDB进行远程调试。内核需要编译时开启调试符号CONFIG_DEBUG_INFOyQEMU启动时加入-s -S参数-S表示启动时暂停-s表示在1234端口开启GDB服务。3.3 内核源码获取与配置从 kernel.org 或你使用的芯片厂商的Git仓库获取内核源码。选择一个稳定的版本开始例如5.10或5.15 LTS版本它们代码结构清晰社区资料丰富。配置内核是第一步也是容易踩坑的地方。对于我们的分析目的最小化配置即可这样可以减少编译时间也让生成的镜像更简洁。# 进入内核源码目录 cd linux-5.15 # 导出交叉编译环境变量 export ARCHarm64 export CROSS_COMPILEaarch64-linux-gnu- # 使用默认的defconfig生成基础配置 make defconfig # 进入图形化配置界面确保打开调试信息 make menuconfig在menuconfig中确保以下选项被启用Kernel hacking-Compile-time checks and compiler options-Compile the kernel with debug info (CONFIG_DEBUG_INFO)为了简化可以关闭不必要的驱动和文件系统支持。注意在真机调试时你的内核配置必须匹配硬件特别是设备树DTB。在QEMU中我们可以使用它内置的virt机器模型它模拟了一个通用的ARM64虚拟机有标准化的硬件省去了适配具体硬件的麻烦。3.4 辅助分析工具objdump与readelf编译好的内核镜像是一个ELF文件。objdump和readelf是分析二进制文件的瑞士军刀。aarch64-linux-gnu-objdump -d vmlinux反汇编整个内核生成汇编代码。我们可以从中找到stext标签对应的汇编指令序列。aarch64-linux-gnu-readelf -S vmlinux查看内核镜像的所有段Section信息找到.text段、.init.text段等的地址和大小stext通常位于.head.text或.init.text段内。aarch64-linux-gnu-nm vmlinux | grep stext直接从符号表中查找stext的地址。这些工具能帮助我们在静态层面建立对代码布局的认知是动态调试前的重要准备。4. stext入口代码的逐行解析让我们以Linux 5.15内核在ARM64架构下的代码为例走进arch/arm64/kernel/head.S这个文件。这个汇编文件就是内核启动的“总剧本”。stext标签通常就在这个文件的开头部分。4.1 开场处理器状态检查与设置内核被加载到内存并开始执行时它对于当前处理器的状态知之甚少。stext的第一项工作就是进行一系列严格的检查和安全设置。// arch/arm64/kernel/head.S (简化示意) ENTRY(stext) // 1. 确保当前处于EL2虚拟化扩展或EL1操作系统异常等级。 // 如果从EL3安全监控态启动需要先降级到EL2/EL1。 mrs x0, CurrentEL cmp x0, #CurrentEL_EL3 b.eq init_el3 // 2. 禁用MMU和缓存。在建立自己的页表之前内核运行在物理地址上。 // 这通过设置系统控制寄存器SCTLR_EL1的相应位来完成。 mrs x0, sctlr_el1 bic x0, x0, #SCTLR_ELx_M // 清除M位禁用MMU bic x0, x0, #SCTLR_ELx_C // 清除C位禁用数据缓存 bic x0, x0, #SCTLR_ELx_I // 清除I位禁用指令缓存 msr sctlr_el1, x0 isb // 指令同步屏障确保设置生效为什么这么做内核需要从一个已知的、干净的状态开始。MMU和缓存的行为依赖于后续建立的页表在页表就绪前启用它们会导致不可预测的内存访问必然导致崩溃。isb指令确保之前的配置写入在后续指令执行前完成是ARM架构下重要的内存屏障。4.2 身份识别主核与从核的分流点接下来内核需要知道当前正在执行的是哪个CPU核心。这通过读取MPIDR_EL1寄存器实现。// 3. 获取当前CPU的ID (Affinity) mrs x0, mpidr_el1 and x0, x0, #MPIDR_AFF_MASK // 提取亲和性字段 // 检查是否是主核通常定义affinity为0的核为主核 cbz x0, primary_entry // 4. 如果是从核则进入等待循环holding pen // 主核会稍后来这里唤醒它 adr_l x1, secondary_holding_pen br x1 primary_entry: // 主核继续执行后续复杂的初始化流程关键点解析MPIDR_EL1寄存器编码了处理器在集群Cluster、核心Core层面的拓扑ID。primary_entry是主核专属的路径。从核则跳转到一个叫做secondary_holding_pen的地址那是一个由主核控制的循环或等待区域。这是一种经典的“主从式”启动同步模型。4.3 搭建舞台早期页表与内存映射这是stext阶段最复杂、也最核心的部分之一。内核要开启MMU从物理地址模式切换到虚拟地址模式但它自己还没有运行时内存堆栈来运行复杂的C代码。因此它需要先手工打造一个简单的、临时性的页表我们称之为“恒等映射Identity Mapping”或“早期页表”。// 5. 设置早期页表基地址寄存器TTBR0_EL1 // __idmap_pg_dir 是恒等映射页表的起始物理地址。 adrp x0, __idmap_pg_dir msr ttbr0_el1, x0 isb // 6. 创建恒等映射 // 将内核镜像所在的物理内存区域映射到相同的虚拟地址。 // 例如物理地址0x80080000映射到虚拟地址0x80080000。 // 这样在开启MMU的瞬间代码还能继续正确执行。 mov x0, xzr mov x1, #SWAPPER_MM_MMUFLAGS adrp x2, _text // 内核.text段起始物理地址 adrp x3, _end // 内核结束物理地址 bl __create_page_tables // 调用创建页表的子函数 // 7. 加载内存属性配置开启MMU adrp x0, idmap_pg_dir bl __cpu_setup // 配置缓存、TLB等 bl __enable_mmu // 这个函数内部最终会设置SCTLR_EL1的M位为1深度解读恒等映射的必要性想象一下CPU正在物理地址0x80080000处取指执行bl __enable_mmu这条指令。当MMU开启的瞬间CPU发出的下一个取指地址PC4会被MMU当作虚拟地址进行转换。如果没有恒等映射这个虚拟地址可能指向一个无效或随机的物理地址系统立刻崩溃。恒等映射保证了“开启MMU”这个动作本身及其后紧接着的几条指令能够平滑过渡。__create_page_tables函数这个函数用汇编实现它会填充__idmap_pg_dir开始的页表项。它通常使用“块映射”Block Map如ARM64的2MB大页来映射内核的代码、数据区效率很高。__cpu_setup这个函数根据CPU的型号通过读取MIDR_EL1寄存器来设置一些处理器特定的参数比如缓存策略、TLB失效操作等。实操心得调试早期页表错误非常棘手。一个常见的问题是内核解压地址如果使用了压缩内核Image.gz或加载地址与内核链接地址vmlinux中的符号地址不匹配。这会导致恒等映射建立错误MMU一开就飞。务必确保引导加载程序如U-Boot的bootm命令将内核镜像放置到正确的物理地址这个地址需要与内核编译时链接脚本arch/arm64/kernel/vmlinux.lds.S中定义的_text符号的物理地址预期一致。4.4 切换世界跳转到虚拟地址空间的高端恒等映射只是临时桥梁。Linux内核通常运行在虚拟地址空间的高端区域例如0xffff_0000_0000_0000这是ARM64的VA_BITS配置决定的常见48位。在开启MMU后内核需要立即跳转到这个高端的虚拟地址去继续执行。// 8. 计算内核在虚拟地址空间中的入口点并跳转过去。 adrp x0, _text // 获取_text的物理地址当前仍在恒等映射视图下 add x0, x0, #PAGE_OFFSET // PAGE_OFFSET是内核虚拟地址的起始如0xffff_0000_0000_0000 br x0 // 绝对跳转从此进入内核的虚拟地址世界。 // 跳转目标例如 __primary_switched 标签 __primary_switched: // 此时CPU已经运行在高位虚拟地址上了。 // 可以安全地清理掉临时的恒等映射了某些实现会这么做。这个“跳转”动作是理解内核地址空间切换的钥匙。br x0指令执行后程序计数器PC载入的是一个高位的虚拟地址如0xffff8000080080000。由于MMU已经开启并且内核已经建立了从该虚拟地址到正确物理地址的映射这是在__create_page_tables中建立的另一套映射不同于恒等映射所以CPU能够继续取指执行。从此内核正式运行在其设计的、完整的虚拟内存环境中。4.5 环境初始化为C语言世界铺路跳转到高位地址后内核仍然运行在汇编环境。接下来要做的是为调用第一个C函数start_kernel准备必要的运行时环境。__primary_switched: // 9. 初始化BSS段全部清零。 // BSS段存放未初始化的全局/静态变量根据C语言标准必须初始化为0。 adr_l x0, __bss_start adr_l x1, __bss_stop sub x1, x1, x0 bl __pi_memset // 调用一个简单的内存清零函数可能是汇编实现 // 10. 设置栈指针SP。 // 栈是函数调用、局部变量存放的基础。每个CPU核心都需要自己的栈。 adr_l x0, init_thread_union // 获取init进程的线程信息union地址 add x0, x0, #THREAD_SIZE // 栈是向下生长的所以栈顶是 union起始地址 栈大小 mov sp, x0 // 11. 保存设备树BlobDTB的地址。 // 引导加载程序会将DTB的物理地址存放在寄存器X0中根据ARM64启动协议。 // 内核需要将这个地址保存到一个全局变量如__fdt_pointer供后续解析。 adr_l x1, __fdt_pointer str x0, [x1] // 12. 最后跳转到C语言的主函数 start_kernel b start_kernel为什么是这些步骤BSS清零这是C程序启动的常规操作。如果不做未初始化的全局变量将是随机值导致程序行为不可预测。设置栈没有栈就无法进行函数调用无法保存返回地址和局部变量。init_thread_union是内核为0号进程swapper进程准备的线程信息块其中包含了该进程的内核栈。主核使用这个栈来启动。保存DTB设备树是现代ARM Linux硬件描述的标准方式。内核需要知道内存布局、外设地址等信息这些都来自DTB。遵循启动协议引导程序通过寄存器传递这个关键指针。至此stext汇编部分的使命基本完成。它将一个“裸”的CPU初始化为一个具备了虚拟内存、干净数据段、有效调用栈的初级执行环境然后潇洒地将控制权交给了C语言编写的start_kernel()函数。操作系统内核的宏大叙事从此正式拉开帷幕。5. 从核启动路径解析前面我们聚焦于主核CPU0的启动路径。在多核系统中从核CPU1, CPU2...的启动是一个协同过程。它们的入口点也是stext但走的是另一条“快速通道”。5.1 从核的等待与唤醒当主核执行到stext通过mpidr_el1判断自己不是主核时会跳转到secondary_holding_pen。这是一个由主核控制的同步点。// 从核的入口简化 secondary_holding_pen: wfe // 等待事件Wait For Event进入低功耗状态 ldr x0, secondary_holding_pen_release ldr x0, [x0] // 读取释放标志 cbz x0, secondary_holding_pen // 如果为0继续等待 br x0 // 如果不为0跳转到释放地址即secondary_startup从核在这里执行wfe指令休眠直到主核完成必要的全局初始化如内存系统、时钟源、中断控制器并准备好唤醒它们。主核在start_kernel函数的某个阶段通常是smp_prepare_cpus()中会设置secondary_holding_pen_release这个变量的值为从核真正应该跳转的地址例如secondary_startup的物理地址然后向从核发送一个处理器间中断IPI如“SEV”事件唤醒它们。5.2 从核的简化初始化从核被唤醒后跳转到secondary_startup。它的初始化流程比主核简单得多禁用中断避免在初始化完成前被中断打扰。设置从核自身的栈指针每个CPU核心必须有自己独立的内核栈通常是从一个叫做secondary_data的结构体中获取。启用MMU直接使用主核已经建立好的全局页表swapper_pg_dir无需自己创建。跳转到高位虚拟地址类似主核跳转到虚拟地址空间继续执行。调用C函数最终会调用secondary_start_kernel()这个C函数进行该CPU核心特有的初始化比如初始化本地定时器、注册该CPU到调度器最后调用cpu_startup_entry()进入空闲循环等待调度器分配任务。设计精髓这种设计避免了从核重复执行复杂的、全局性的初始化操作如创建页表、解析设备树极大地简化了从核启动流程缩短了多核系统的整体启动时间。所有全局资源由主核一次性初始化从核“坐享其成”。6. 常见问题与调试技巧实录分析或调试stext及相关启动代码时会遇到一些典型问题。以下是我在实践中总结的排查思路和技巧。6.1 问题一内核启动卡在“Starting kernel...”之后这是最经典的启动失败现象。串口输出到此为止系统无任何反应。排查步骤检查引导加载程序参数首先确认U-Boot传递给内核的参数是否正确特别是bootm命令加载内核的地址loadaddr和设备树地址fdtaddr是否与内核编译时的链接地址匹配。使用U-Boot的bdinfo和iminfo命令核对。启用早期调试输出内核在stext的最最早期串口可能还没初始化。但ARM64内核支持“早期控制台”Earlycon。在U-Boot的bootargs中添加earlycon参数并指定正确的串口硬件地址。例如对于PL011串口earlyconpl011,0x9000000。这样在printk初始化之前就能通过这个简单驱动输出信息。使用QEMUGDB单步调试这是最强大的手段。# 终端1启动QEMU并等待GDB连接 qemu-system-aarch64 -machine virt -cpu cortex-a57 -kernel ./arch/arm64/boot/Image -append consolettyAMA0 earlycon -nographic -s -S # 终端2启动GDB并连接 aarch64-linux-gnu-gdb ./vmlinux (gdb) target remote localhost:1234 (gdb) b stext # 在入口点设断点 (gdb) c # 继续执行会立刻停在stext (gdb) si # 单步执行汇编指令通过单步你可以精确观察寄存器info registers和内存的变化判断是在执行mrs/msr设置寄存器时出错还是在创建页表时计算错了地址。6.2 问题二开启MMU后立刻发生异常崩溃现象是代码执行到__enable_mmu附近或之后系统挂起或进入异常处理。排查思路核对恒等映射问题几乎肯定出在早期页表。检查__create_page_tables函数看它映射的内存范围是否覆盖了当前执行流。确保它映射了从_text到_end的整个内核镜像区域并且映射属性是正确的可执行、可读。检查TTBR0设置确认加载到ttbr0_el1寄存器的地址确实是页表基地址__idmap_pg_dir的物理地址。在MMU开启前所有地址都是物理地址。验证CPU设置__cpu_setup函数会根据CPU ID配置一些架构特定的寄存器如TCR_EL1, MAIR_EL1。如果这些配置与你的模拟器或真实硬件不符也可能导致MMU转换错误。对比QEMUvirt机器的默认配置与内核代码中的配置值。使用QEMU内存访问检查在GDB中在跳转到高位地址br x0之前手动检查页表内容。(gdb) x /10gx __idmap_pg_dir # 查看页表前几项内容你需要理解ARM64页表描述符的格式检查其输出的物理地址和属性位是否正确。6.3 问题三从核无法启动或启动后不稳定主核启动正常但从核始终卡住或者启动后系统运行异常。排查步骤检查从核唤醒机制确认主核是否正确地设置了secondary_holding_pen_release变量并发送了唤醒事件SEV。可以在主核代码smp_prepare_cpus()中加打印或使用GDB观察该内存地址的值。核对从核的栈和ID从核的栈地址是通过secondary_data结构体传递的。确保主核正确填充了这个结构体并且从核读取到了正确的栈指针和CPU ID。检查内存一致性主核和从核在开启各自的MMU后必须看到一致的内存视图。确保它们使用的页表swapper_pg_dir是同一个并且相关的缓存维护操作如cache cleaning和TLB invalidation在适当的时候被执行。在多核启动中缓存一致性操作失误是常见的疑难杂症。关注核间同步从核在初始化自己的本地资源如本地中断控制器GIC时可能需要与主核同步。查看secondary_start_kernel函数中是否有自旋锁spinlock或原子操作检查是否发生了死锁。6.4 调试技巧利用汇编宏和标签内核的启动汇编代码中充满了宏如adr_l,str_l和条件编译。阅读时建议在编译后查看实际生成的汇编文件arch/arm64/kernel/head.o的反汇编或者直接使用objdump -d vmlinux查看stext附近的最终代码这样能绕过宏展开看到最直接的指令流。在GDB中你可以直接对汇编标签如primary_entry,__enable_mmu下断点即使它们不是C函数。这比计算指令偏移量要方便得多。分析stext的过程就像在显微镜下观察生命的起源。它揭示了操作系统如何从一片混沌的硬件状态中构建出秩序与逻辑的基础。这份理解是你在进行深度系统定制、性能极限优化或棘手问题调试时最坚实的底气。每一次对底层代码的追踪都是对计算机系统理解的一次升华。
