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. 核心需求与场景解析：为什么必须深入stext？

2.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 + GDB

QEMU是一个功能强大的开源模拟器，可以模拟包括ARM64在内的多种处理器架构。用它来运行内核，比在真机上方便无数倍，尤其是单步调试。

# 安装QEMU系统模拟器（以Ubuntu为例） sudo apt-get install qemu-system-arm qemu-system-aarch64

调试是理解代码执行流的关键。我们需要配置GDB进行远程调试。内核需要编译时开启调试符号（CONFIG_DEBUG_INFO=y），QEMU启动时加入-s -S参数（-S表示启动时暂停，-s表示在1234端口开启GDB服务）。

3.3 内核源码获取与配置

从 kernel.org 或你使用的芯片厂商的Git仓库获取内核源码。选择一个稳定的版本开始，例如5.10或5.15 LTS版本，它们代码结构清晰，社区资料丰富。

配置内核是第一步，也是容易踩坑的地方。对于我们的分析目的，最小化配置即可，这样可以减少编译时间，也让生成的镜像更简洁。

# 进入内核源码目录 cd linux-5.15 # 导出交叉编译环境变量 export ARCH=arm64 export CROSS_COMPILE=aarch64-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发出的下一个取指地址（PC+4）会被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. 保存设备树Blob（DTB）的地址。 // 引导加载程序会将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。它的初始化流程比主核简单得多：

1. 禁用中断：避免在初始化完成前被中断打扰。
2. 设置从核自身的栈指针：每个CPU核心必须有自己独立的内核栈，通常是从一个叫做secondary_data的结构体中获取。
3. 启用MMU：直接使用主核已经建立好的全局页表（swapper_pg_dir），无需自己创建。
4. 跳转到高位虚拟地址：类似主核，跳转到虚拟地址空间继续执行。
5. 调用C函数：最终会调用secondary_start_kernel()这个C函数，进行该CPU核心特有的初始化，比如初始化本地定时器、注册该CPU到调度器，最后调用cpu_startup_entry()进入空闲循环，等待调度器分配任务。

设计精髓：这种设计避免了从核重复执行复杂的、全局性的初始化操作（如创建页表、解析设备树），极大地简化了从核启动流程，缩短了多核系统的整体启动时间。所有全局资源由主核一次性初始化，从核“坐享其成”。

6. 常见问题与调试技巧实录

分析或调试stext及相关启动代码时，会遇到一些典型问题。以下是我在实践中总结的排查思路和技巧。

6.1 问题一：内核启动卡在“Starting kernel...”之后

这是最经典的启动失败现象。串口输出到此为止，系统无任何反应。

排查步骤：

1. 检查引导加载程序参数：首先确认U-Boot传递给内核的参数是否正确，特别是bootm命令加载内核的地址（loadaddr）和设备树地址（fdtaddr），是否与内核编译时的链接地址匹配。使用U-Boot的bdinfo和iminfo命令核对。
2. 启用早期调试输出：内核在stext的最最早期，串口可能还没初始化。但ARM64内核支持“早期控制台”（Earlycon）。在U-Boot的bootargs中添加earlycon参数，并指定正确的串口硬件地址。例如，对于PL011串口：earlycon=pl011,0x9000000。这样，在printk初始化之前，就能通过这个简单驱动输出信息。
3. 使用QEMU+GDB单步调试：这是最强大的手段。

   # 终端1：启动QEMU并等待GDB连接 qemu-system-aarch64 -machine virt -cpu cortex-a57 -kernel ./arch/arm64/boot/Image -append "console=ttyAMA0 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附近或之后，系统挂起或进入异常处理。

排查思路：

1. 核对恒等映射：问题几乎肯定出在早期页表。检查__create_page_tables函数，看它映射的内存范围是否覆盖了当前执行流。确保它映射了从_text到_end的整个内核镜像区域，并且映射属性是正确的（可执行、可读）。
2. 检查TTBR0设置：确认加载到ttbr0_el1寄存器的地址，确实是页表基地址__idmap_pg_dir的物理地址。在MMU开启前，所有地址都是物理地址。
3. 验证CPU设置：__cpu_setup函数会根据CPU ID配置一些架构特定的寄存器（如TCR_EL1, MAIR_EL1）。如果这些配置与你的模拟器或真实硬件不符，也可能导致MMU转换错误。对比QEMUvirt机器的默认配置与内核代码中的配置值。
4. 使用QEMU内存访问检查：在GDB中，在跳转到高位地址（br x0）之前，手动检查页表内容。

   (gdb) x /10gx &__idmap_pg_dir # 查看页表前几项内容

   你需要理解ARM64页表描述符的格式，检查其输出的物理地址和属性位是否正确。

6.3 问题三：从核无法启动或启动后不稳定

主核启动正常，但从核始终卡住，或者启动后系统运行异常。

排查步骤：

1. 检查从核唤醒机制：确认主核是否正确地设置了secondary_holding_pen_release变量，并发送了唤醒事件（SEV）。可以在主核代码smp_prepare_cpus()中加打印，或使用GDB观察该内存地址的值。
2. 核对从核的栈和ID：从核的栈地址是通过secondary_data结构体传递的。确保主核正确填充了这个结构体，并且从核读取到了正确的栈指针和CPU ID。
3. 检查内存一致性：主核和从核在开启各自的MMU后，必须看到一致的内存视图。确保它们使用的页表（swapper_pg_dir）是同一个，并且相关的缓存维护操作（如cache cleaning和TLB invalidation）在适当的时候被执行。在多核启动中，缓存一致性操作失误是常见的疑难杂症。
4. 关注核间同步：从核在初始化自己的本地资源（如本地中断控制器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的过程，就像在显微镜下观察生命的起源。它揭示了操作系统如何从一片混沌的硬件状态中，构建出秩序与逻辑的基础。这份理解，是你在进行深度系统定制、性能极限优化或棘手问题调试时，最坚实的底气。每一次对底层代码的追踪，都是对计算机系统理解的一次升华。