上电≠跑 main()：MCU 和 Linux 启动前到底偷偷干了多少事？

PLC技术网抖音群

按下开发板的复位键，电源灯亮起，晶振开始起振。几十毫秒后，你的程序已经跑在  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);

}

这三件事是重点：

MSP 必须先有值，否则函数调用都没法压栈。

.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 常用的应用处理器在启动上有两个明显差异：

维度	Cortex-M（MCU）	Cortex-A（Linux 应用处理器）
第一条指令来源	向量表，硬件自动加载	通常从 ROM Code 开始，由芯片厂商固化
内存	片上 SRAM/Flash，上电即可用	需要外部 DDR，先由 SPL 初始化
MMU	一般没有或只有 MPU	必须建立页表后才能进入内核 C 代码
引导层数	1~2 层（可选 Bootloader）	3~5 层（SPL、U-Boot、TrustZone 等）
到 main 的距离	近，微秒级	远，秒级

简单记：Cortex-M 是“向量表直接启动”，Cortex-A 是“ROM Code + Bootloader 多级接力”。

六、常见问题：启动失败时该往哪看

现象	可能原因	排查方向
MCU 没进 main 就 HardFault	MSP 或向量表地址错误、时钟配置异常	检查链接脚本、启动文件、SystemInit
Linux 串口没输出	串口引脚/波特率配置错、printk 尚未注册	先看 U-Boot 阶段是否能打印
Linux 卡在内核启动中途	设备树不匹配、initcall 驱动报错	打开  initcall_debug  看具体阶段
提示  kernel panic - not syncing: VFS	根文件系统没挂好或 init 程序缺失	检查 bootargs 和根文件系统镜像

一个实用技巧：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()  从来不是起点，而是那条暗路的终点。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！