3. 启动流程与核间生命周期管理
STM32MP1 系列（如 STM32MP157）内部集成双核 Cortex-A7 与单核 Cortex-M4，A7 侧运行 Linux，M4 侧运行裸机或 RTOS 固件。两者并非同时上电即运行，而是由一条严格分级的启动链依次"唤醒"。理解这条链上每一级固件的位置、职责与交接方式，是掌握核间生命周期管理的前提——只有知道 M4 固件在何时、由谁、以什么方式被加载，才能正确设计 A7 与 M4 的启动、停止与重启协同逻辑。
一、启动链的五个阶段
STM32MP1 的启动过程可划分为五个阶段，每一级都从上一级手中接过执行权，并负责把下一级镜像搬到正确位置。
1. ROM Code（芯片内部固化）：上电复位后，A7 从芯片内部 ROM 的固定地址开始执行。ROM Code 会读取 BOOT 引脚（BOOT0/BOOT1/BOOT2）确定启动介质，依次尝试从 eMMC/SD 卡、NOR/NAND Flash、串口或 USB 下载模式加载 FSBL。它只识别 ST 定义的头部格式，把 FSBL 镜像搬入 SYSRAM（约 256KB）并校验签名，然后跳转执行。ROM Code 不涉及 M4，此时 M4 仍处于复位保持状态。
2. TF-A（Trusted Firmware-A）：TF-A 是 FSBL 的主体，运行在 A7 的安全态（EL3）。它完成 DDR 初始化、时钟树配置、电源域建立，并把后续镜像（U-Boot、OP-TEE、M4 固件）从启动介质加载到 DDR 指定地址。TF-A 阶段会解析 FIT 镜像或 ST 的 FIP 包，其中 fw_cfg 节点可声明 M4 固件的加载地址与入口。TF-A 结束后，通过 BL33 入口跳转到 U-Boot。
3. U-Boot：运行在 A7 的非安全态（EL2/EL1），负责加载 Linux 内核镜像（Image）、设备树（.dtb）与根文件系统，并准备启动参数。U-Boot 也可通过 bootm 或 ext4load 把 M4 固件（.elf 或 .bin）读入 DDR，但真正启动 M4 通常交给 Linux 侧的 remoteproc 框架完成。
4. Linux 内核：内核启动后，通过设备树中的 m4_rproc 节点与 stm32_rproc 驱动建立联系。驱动会申请 M4 使用的 DDR 区域、使能 M4 时钟、释放复位，并把固件镜像写入 M4 的 TCM 或 DDR 执行区。
5. M4 固件：由 remoteproc 触发 start 后，M4 从入口地址开始执行，通过 IPCC 邮箱与 A7 建立通信通道，进入正常协同工作状态。
二、M4 固件的加载与启动控制
Linux 侧通过 remoteproc 框架管理 M4 核。设备树中需要声明 M4 的寄存器基址、时钟、复位、内存区域与固件名称，例如：
m4_rproc: m4@0 {
compatible = "st,stm32mp1-m4";
reg = <0x00000000 0x00040000>; /* TCM 区域 */
memory-region = <&m4_ddr_region>;
st,syscfg = <&syscfg>;
st,syscfg-rcc = <&rcc>;
st,hold-boot = <0>;
firmware-name = "m4_firmware.elf";
status = "okay";
};驱动加载后，在 /sys/class/remoteproc/remoteproc0/ 下会出现 state、firmware、name 等属性。启动 M4 的典型操作序列为：
# 确认当前状态
cat /sys/class/remoteproc/remoteproc0/state
# 输出：offline
# 指定固件并启动
echo m4_firmware.elf > /sys/class/remoteproc/remoteproc0/firmware
echo start > /sys/class/remoteproc/remoteproc0/state
# 再次查看状态
cat /sys/class/remoteproc/remoteproc0/state
# 输出：running当 state 变为 running 时，说明 M4 已从入口地址开始执行。此时可通过 IPCC 邮箱发送第一条握手消息，确认 M4 固件已进入主循环并准备好接收任务。若 state 停留在 offline 或变为 crashed，应检查固件路径、DDR 保留区是否与设备树一致、M4 时钟是否使能。
三、停止与重启的协同逻辑
停止 M4 不能简单写 stop 了事。若 M4 正在访问共享内存或持有 IPCC 通道，直接复位会导致 A7 侧读到脏数据或邮箱状态错乱。正确的停止流程应遵循"先协商、后停止"：
- A7 通过 IPCC 向 M4 发送
SHUTDOWN_REQ消息； - M4 收到后完成当前任务、释放共享内存锁、回复
SHUTDOWN_ACK； - A7 收到 ACK 后，向
state写入stop，remoteproc 驱动拉低 M4 复位并关闭时钟； - 若需重新加载新固件，再次写入
firmware并start，M4 从复位状态重新初始化。
这一"请求—确认—停止"的三步握手，是核间生命周期管理中最容易出错的环节。常见故障包括：M4 固件未实现 ACK 回复导致 A7 侧超时；共享内存未加锁导致 stop 后数据不一致；以及重复 start 时未先 stop 造成资源冲突。建议在 M4 固件中为 IPCC 接收中断设置独立的消息队列，确保任何时刻都能响应 A7 的控制命令。