Katapult 引导程序链接脚本深度解析armcm_link.lds.S 与向量表重定位的设计秘密【免费下载链接】katapultConfigurable bootloader for Klipper项目地址: https://gitcode.com/gh_mirrors/ka/katapultKatapult 是一个面向 ARM Cortex-M 微控制器的可配置引导程序Bootloader最初为 Klipper 3D 打印器的 CAN 节点设计现已支持 CAN、USB 和 UART 三种通信接口。本文带你深入 Katapult 的链接脚本src/generic/armcm_link.lds.S看懂它是如何用不到 80 行脚本完成 Flash/RAM 内存布局、启动符号定义以及 Cortex-M 向量表重定位VTOR这套隐藏设计的。一、Katapult 引导程序是什么为什么需要它 Katapult前身为 CanBoot是 Klipper 生态中的固件搬运工刷入 MCU 后常驻 Flash 前部应用固件如 Klipper放在它后面的地址空间通过 CAN / USB / UART 接收上位机发来的固件并写入 Flash支持 LPC176x、STM32、RP2040 三大芯片家族配置全部由 Kconfigmake menuconfig驱动。对嵌入式新手来说引导程序的灵魂就是链接脚本——它决定了二进制文件中每一段代码、每一块数据落在芯片内存的哪个位置。Katapult 的通用 Cortex-M 链接脚本就是src/generic/armcm_link.lds.S.S后缀表示它先经过预处理能用#if读取 Kconfig 生成的autoconf.h宏。二、链接脚本总览MEMORY 内存布局打开 armcm_link.lds.S最核心的是开头的MEMORY块rom (rx) : ORIGIN CONFIG_FLASH_START , LENGTH CONFIG_FLASH_SIZE ram (rwx) : ORIGIN CONFIG_RAM_START , LENGTH CONFIG_RAM_SIZE只有两条却包含三个设计要点地址来自 KconfigCONFIG_FLASH_START引导程序起始地址和CONFIG_RAM_START由make menuconfig选择芯片后自动推导。比如 STM32 系列在src/stm32/Kconfig中提供从0x8000000到0x8020200的一长串默认 Flash 起点对应Bootloader 偏移量这一菜单选项。权限位显式声明rom (rx)表示 Flash 只能读和执行ram (rwx)可读可写可执行链接器会把只放代码的段放进rx区域。一个脚本通用全部芯片LPC176x 通过src/lpc176x/下的配置复用同一份脚本RP2040 则在src/rp2040/rpxxxx_link.lds.S中做了分段PHDRS增强STM32 直接用通用版。三、SECTIONS 逐段拆解Katapult 的空间排布 整个SECTIONS可以归纳为一张内存地图段名落点作用.textFlash向量表 全部代码 只读数据.data加载地址在 Flash运行时在 RAM有初值的全局变量.bssRAMNOLOAD未初始化变量启动时清零.stackRAM 顶端NOLOAD主栈大小由CONFIG_STACK_SIZE决定.reservedRAMNOLOAD预留 8 字节对齐空隙3.1 栈为什么紧贴 RAM 顶端_stack_start CONFIG_RAM_START CONFIG_RAM_SIZE - CONFIG_STACK_SIZE - 8;栈向下生长因此放在 RAM 最高处是最安全的位置末尾的-8再留出 8 字节余量配合.reserved段防止栈在极端情况下顶到dynmem动态内存区的边界。动态内存的起止点正是armcm_boot.c中的dynmem_start()/dynmem_end()返回的就是_bss_end和_stack_start——链接脚本产出的符号直接划定了运行时内存分配器的边界。3.2 .data加载地址LMA≠ 运行地址VMA这是链接脚本最精妙的部分之一.data : AT ( _data_flash ) { ... } ramAT(_data_flash)是典型的 LMA/VMA 分离写法LMA加载地址.data的初始值紧跟在.text之后存进 Flash起点符号为_data_flashVMA运行地址程序运行时这些变量必须位于 RAMFlash 不能写且初始化速度远慢于 RAM。启动代码 armcm_boot.c 的reset_handler_stage_two()正是靠这组符号完成搬运uint32_t count (_data_end - _data_start) * 4; boot_memcpy(_data_start, _data_flash, count);注意这里用的是手写内联boot_memcpy/boot_memset而非标准库函数——因为启动早期 C 库尚未就绪连函数调用都要避免。.bss段随后被同样的方式清零。这就是链接脚本负责画地图启动汇编负责按地图搬家的经典分工。3.3 /DISCARD/引导程序如何瘦身 /DISCARD/ : { *(.init) *(.fini) *(.ARM.extab) *(.ARM.exidx) }.init/.fini是 C 库构造函数入口异常表是 C 异常机制的元数据——对一个只有几 KB 的引导程序而言纯属累赘直接丢弃。这种断舍离是 Bootloader 保持最小 footprint 的常见手法也让 Katapult 能塞进很多芯片的 Flash 前 4K~8K。四、核心秘密向量表重定位的设计 4.1 为什么向量表位置如此敏感Cortex-M 上电复位后硬件会无条件地从Flash 绝对地址0x00000000读取初始 SP 和复位向量。这意味着如果你的固件起始地址不是0x00000000比如 STM32F0 上 Katapult 被配置在0x08000000之后复位后 CPU 读到的是别家数据——系统直接跑飞。Katapult 的链接脚本因此把向量表放在.text段的最前面并用KEEP锁定.text : { KEEP(*(.vector_table)) *(.text .text.*) *(.rodata .rodata*) } romKEEP的必要性Bootloader 是无人调用一切的程序若向量表被优化器当死代码裁掉整个中断体系就塌了。KEEP告诉链接器无论引用与否这段必须原样保留。前后打桩_text_vectortable_start/_text_vectortable_end两个符号像路标一样标出向量表的起止后续搬家全靠它们计算长度。向量表的具体内容并非手写的数组而是构建系统扫描各源码中的DECL_ARMCM_IRQ宏定义见 armcm_boot.h由scripts/buildcommands.py自动生成——每加一个中断处理函数向量表自动多一项。4.2 CONFIG_ARMCM_RAM_VECTORTABLE把向量表搬进 RAM当固件起始地址不是0x00000000或不是芯片 VTOR 支持的合法基址时唯一可靠的办法是启动时把向量表从 Flash 复制到 RAM再把系统控制寄存器SCB-VTOR指向 RAM 副本。链接脚本为此预留了条件段#if CONFIG_ARMCM_RAM_VECTORTABLE .ram_vectortable (NOLOAD) : { _ram_vectortable_start .; . . ( _text_vectortable_end - _text_vectortable_start ); _ram_vectortable_end .; } ram #endifNOLOAD 占位这个段不占 Flash只在 RAM 里虚占一块与 Flash 中向量表等长的空间。#if则让同一份脚本在无重定位需求时零开销。Kconfig 侧的联动很能体现 Katapult 的可配置哲学——src/stm32/Kconfig 中config ARMCM_RAM_VECTORTABLE bool default y if MACH_STM32F0 FLASH_APPLICATION_ADDRESS ! 0x8000000即 STM32F0 只要应用起始地址偏离 Flash 基址就自动启用 RAM 向量表用户无需理解 VTOR 也能得到正确行为。运行时的搬家逻辑只有寥寥几行以 src/rp2040/main.c 为例src/stm32/stm32f0.c中有一模一样的实现__builtin_memcpy(_ram_vectortable_start, _text_vectortable_start, count); barrier(); SCB-VTOR (uint32_t)_ram_vectortable_start;先拷贝、再内存屏障、最后改 VTOR三步缺一不可漏掉屏障缓存/流水线可能让 CPU 在新旧向量表之间读到撕裂数据。RP2040 的链接脚本src/rp2040/rpxxxx_link.lds.S更进一步用PT_LOAD FLAGS(6)显式给ram_vectortable_segment段指定了程序头保证生成的 ELF 布局可被上位机工具精确解析。 一句话总结这个设计秘密链接脚本负责占位NOLOAD 段 起止符号Kconfig 负责决策何时启用启动 C 代码负责执行memcpy VTOR三者各司其职一份脚本通吃所有需要/不需要重定位的芯片。五、配套机制deployer 链接脚本的地址偏移 Katapult 还有一个部署器deployer允许用新引导程序覆盖旧引导程序。它的脚本 armcm_deployer.lds.S 与通用版几乎相同但有两处关键差异rom的起点改为CONFIG_FLASH_APPLICATION_ADDRESS——deployer 本体被加载在应用区避免覆盖引导区向量表之后有一段动态填充#if CONFIG_LAUNCH_APP_ADDRESS CONFIG_FLASH_APPLICATION_ADDRESS . CONFIG_LAUNCH_APP_ADDRESS - CONFIG_FLASH_APPLICATION_ADDRESS; #endif它用链接位置计数器.强行把后续代码推到应用入口地址使向量表仍出现在 Flash 偏移 0 处。这样复位后无论 CPU 从哪个物理地址取向量结构都自洽——这是链接脚本语法位置计数器算术在 Bootloader 场景下的高阶应用。六、启动流程串讲链接脚本符号如何被消费 把前面所有符号串起来Katapult 的启动链路是复位CPU 从向量表首项取 SP、第二项跳ResetHandlerStage Onearmcm_boot.c关中断用mov sp, %0显式装载链接脚本算好的_stack_end——注意这里不依赖 C 启动默认值而是主动用脚本符号重置栈以摆脱前级 Bootloader 的残留状态Stage Two清中断与优先级寄存器 → 按_data_flash → _data_start拷贝初值 → 按_bss_start/_bss_end清零 → 调用板级armcm_main()板级初始化RP2040/STM32F0 在此调用enable_ram_vectortable()完成向量表重定位。可以看到armcm_link.lds.S定义的每一个符号_data_flash、_stack_end、_ram_vectortable_start……都有明确的消费者没有一个是多余的。七、总结这份链接脚本值得借鉴的 5 个技巧 ✅#技巧对应位置1用#include autoconf.h让链接脚本吃 Kconfig 宏一份脚本适配全部芯片文件头部2KEEP(*(.vector_table))防止向量表被裁剪并置于.text首位.text段3AT(_data_flash)分离 LMA/VMA配合启动代码完成 RAM 初始化.data段4NOLOAD占位段 条件编译实现可选的 RAM 向量表.ram_vectortable段5栈顶对齐 .reserved预留空隙为动态内存划定安全边界.stack段如果你想动手实验完整构建流程见 README.mdgit clone仓库后执行make menuconfig切换Bootloader 偏移量等选项再对比out目录产物与本文分析的段布局Katapult 的每一个设计细节都会变得一目了然。【免费下载链接】katapultConfigurable bootloader for Klipper项目地址: https://gitcode.com/gh_mirrors/ka/katapult创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考