按下开发板的复位键,电源灯亮起,晶振开始起振。几十毫秒后,你的程序已经跑在 main() 里。但在这几十毫秒之前,CPU 没看过任何 C 代码,它只按固定的顺序做了几件事:取栈顶、取向量、执行启动代码、搬运数据、清零内存。MCU 和 Linux 的区别,只是这几件事由谁来完成、叠了多少层。
一、上电瞬间芯片到底在干什么
按下复位键后,芯片并不会立刻执行代码。它要先等电源和时钟稳定:
- 电源稳定:VCC 从 0V 上升到工作电压,芯片内部的 POR(Power-On Reset) 电路让 CPU 保持在复位状态。
- 晶振起振:外部晶振或内部 RC 振荡器开始输出稳定的时钟信号。在时钟稳定之前,CPU 不会取指。
- 复位释放:当时钟和电源都稳定后,复位信号被拉高,CPU 从复位状态退出。
要理解复位后发生了什么,先看两样东西:向量表和 MSP。
向量表是 CPU 的“通讯录”:一张放在 Flash 最开头的函数指针表,每个位置对应一种异常或中断的处理函数。Reset 时 CPU 只看前两个位置。
MSP 是主堆栈指针。C 函数调用时需要压栈保存返回地址和局部变量,所以 CPU 在执行任何代码之前,必须先知道栈顶在哪里。
复位释放的一瞬间,芯片厂商在硬件里定死了 CPU 的行为:自动从固定地址读取两个 32 位数,不需要软件干预。
// 上电/复位后,硬件自动完成这两步MSP = *(uint32_t *)0x00000000;// 地址 0x00:初始主堆栈指针PC = *(uint32_t *)0x00000004;// 地址 0x04:Reset_Handler 入口
Reset_Handler 更准确地说叫 Reset 异常处理入口:硬件直接把 PC 改成向量表里的这个地址。它不是普通函数调用,没有调用者,也没有返回地址。加载完成后,CPU 就开始从这里取指执行。
这时候的 CPU 只是一个按地址取指的机器。它不知道 main() 在哪里,也不关心你要做什么——它只认向量表。
二、MCU 启动:从 Reset_Handler 到 main
MCU 的启动链路很短。因为 Flash 和 RAM 都在芯片内部,上电后就能直接访问,启动文件一个人就能把环境准备好。
以 ARM CMSIS 风格启动文件为例,Reset_Handler 里通常长这样:
voidReset_Handler(void){// 1. 初始化时钟、Flash 等待态、FPU 等硬件 SystemInit();// 2. 把 .data 从 Flash 搬运到 RAM// _sidata/_sdata/_edata 这些符号由链接脚本生成for (uint32_t *pDst = &_sdata, *pSrc = &_sidata; pDst < &_edata; ) *pDst++ = *pSrc++;// 3. 把 .bss 清零for (uint32_t *pDst = &_sbss; pDst < &_ebss; ) *pDst++ =0;// 4. C++ 全局对象的构造函数(部分工具链在此处调用) __libc_init_array();// 5. 进入用户代码 main();// main 正常不应返回;若返回,停在这里while (1);}
这三件事是重点:
.data必须搬运,因为全局变量初始值存在 Flash,运行时要放在 RAM。.bss必须清零,C 标准规定未初始化的全局/静态变量默认是 0。
如果这三件事没做好就跳到 main(),程序大概率会 HardFault 或者读到脏数据。
三、Linux 启动:把 MCU 的每一步多拆几层
MCU 链路短,是因为硬件简单。Linux 运行的应用处理器不一样:它需要外部 DDR,需要页表,需要从硬盘或 Flash 加载内核。于是 MCU 里由启动文件一个人干完的活,在 Linux 这里被拆成了 ROM Code、SPL、U-Boot、Kernel 四层接力。
其中 SPL(Secondary Program Loader) 和 U-Boot 都来自 u-boot/u-boot 这个开源项目。SPL 体积很小,通常被放在内部 SRAM;它的主要任务是初始化 DDR,然后把完整的 U-Boot 加载到内存。U-Boot 再负责从 eMMC/SD/NAND/网络 读取 Kernel 镜像和设备树,把控制权交给 Linux。
Linux 内核入口在 init/main.c 的 start_kernel(),它做的是 MCU 世界里 SystemInit + 搬 data + 清 bss 的“放大版”:
voidstart_kernel(void){// 架构相关初始化:页表、设备树、内存映射 setup_arch();// 初始化内存管理、调度器、中断、时钟 mm_init(); sched_init(); init_IRQ(); timekeeping_init();// 控制台初始化后,你才能看到 printk 输出 console_init();// 创建 init 进程和 kthreadd rest_init();}
rest_init() 会创建两个内核线程:PID 1 的 kernel_init 和 PID 2 的 kthreadd。kernel_init 接着做驱动初始化(do_initcalls()),挂载根文件系统,最终执行 /sbin/init(也可能是 BusyBox 的 init 或 systemd)。
intkernel_init(void *unused){// 执行各驱动/子系统的 initcall do_initcalls();// 挂载根文件系统 prepare_namespace();// 启动用户态 1 号进程 run_init_process("/sbin/init");return0;// 正常不会走到这里}
到这一步,main() 还没有出现。真正的 main() 藏在用户态应用里,由 init 进程或 shell 在系统启动完成后才调用。
四、RTOS 的隐藏入口:main 之前还有一层操作系统初始化
不管是裸机 MCU 还是跑 Linux 的 Cortex-A,启动的本质都一样:先让硬件能跑,再让 C 环境就绪,最后把控制权交出去。RTOS 只是把这个过程又包了一层操作系统初始化。
以 RT-Thread 为例,启动文件做完 .data/.bss 准备后,会进入 rtthread_startup(),由它完成板级初始化、定时器、调度器、创建 main 线程,最后才切到用户 main()。
voidrtthread_startup(void){ rt_hw_board_init();// 板级初始化:时钟、串口、堆 rt_show_version();// 打印版本号 rt_system_timer_init();// 系统定时器 rt_system_scheduler_init();// 调度器 rt_application_init();// 创建 main 线程 rt_system_scheduler_start();// 启动调度}
所以 RTOS 下的 main() 往往已经是一个线程函数,不再是裸机里直接跑在 CPU 上的入口。排查“代码还没进 main 就挂了”时,先看启动文件和板级初始化,而不是盯着 main() 里的逻辑。
五、ARM 架构差异:Cortex-M 和 Cortex-A 的启动起点不同
同样是 ARM,MCU 和 Linux 常用的应用处理器在启动上有两个明显差异:
| | |
|---|
| | |
| | |
| | |
| | 3~5 层(SPL、U-Boot、TrustZone 等) |
| | |
简单记:Cortex-M 是“向量表直接启动”,Cortex-A 是“ROM Code + Bootloader 多级接力”。
六、常见问题:启动失败时该往哪看
| | |
|---|
| | |
| | |
| | |
提示 kernel panic - not syncing: VFS | | |
一个实用技巧:MCU 调试时,如果怀疑启动文件有问题,可以故意在 Reset_Handler 开头加一个 GPIO 翻转或死循环点灯,确认代码确实从这里开始执行。Linux 调试时,U-Boot 命令行下先用 printenv 看 bootcmd 和 bootargs,比直接追内核日志更快。
七、总结:main() 只是初始化链的最后一站
回到开头那个按下复位键的瞬间:几十毫秒后程序跑进了 main(),但在这几十毫秒里,芯片已经走完了从硬件复位到软件就绪的整条暗线。
复位后,CPU 都从固定地址取第一条指令;MCU 直接跳到启动文件的 Reset_Handler,Linux ARM 先跳到厂商 ROM Code,后面再接 SPL/U-Boot/Kernel。路径不同,但本质一样:先把运行环境从“一片空白”推进到“可以跑 C 代码”,最后才把控制权交出去。
MCU 由启动文件完成堆栈、data、bss 和时钟准备;Linux 则由 ROM Code、SPL、U-Boot、Kernel 层层接力,直到 init 进程拉起应用。程序能跑进 main(),说明背后一整套初始化已经跑通。
main() 从来不是起点,而是那条暗路的终点。