3. PolarFire SoC 启动流程与引导机制

PolarFire SoC 的启动过程并不是“CPU 上电后直接跳到用户程序”这么简单。它是一条由硬件复位逻辑、片上 BootROM、HSS 固件、启动模式选择以及镜像加载共同构成的确定性链路。理解这条链路，是排查“板子上电无输出”“HSS 卡在等待”“Linux 起不来”等问题的前提。本节按真实启动顺序展开：从上电复位开始，经过 BootROM，进入 HSS，再由 HSS 根据启动模式选择加载下一级镜像。

上电复位与启动入口

当电源稳定、外部复位释放后，PolarFire SoC 内部的复位控制器会让 E51 监控核从固定的复位向量开始取指。这个入口地址由芯片硬件决定，指向片上 BootROM，而不是外部 Flash。此时 DDR、外设时钟、大部分 PLL 尚未由软件初始化，因此 BootROM 只能依赖内部 SRAM 和最基本的时钟源运行。U54 应用核在这一阶段通常保持复位或等待状态，由 E51 先行完成引导。

需要区分两类复位来源：冷启动（上电复位 POR）会走完整流程；而看门狗复位、软件复位可能保留部分状态。调试时若发现“复位后行为不一致”，应先确认复位类型，再判断是否与 BootROM 的入口条件有关。

BootROM 的职责

BootROM 是固化在芯片内的一段只读代码，它的核心任务是“把 HSS 拉起来”。典型动作包括：初始化最小运行环境、读取启动模式相关配置、从选定介质中定位 HSS 镜像、校验镜像完整性，然后跳转到 HSS 入口。BootROM 不负责加载 Linux，也不解析文件系统，它只关心“找到并验证 HSS”。

BootROM 会依据启动模式选择（如从 eNVM、QSPI Flash、SD 卡或通过 JTAG/调试接口加载）决定搜索路径。若镜像头、校验和或签名不匹配，BootROM 会停止引导或进入错误状态，此时串口通常没有 HSS 输出——这正是“上电无任何打印”的常见原因之一。

HSS 引导流程

HSS（Hart Software Services）是运行在 E51 上的固件，可理解为 PolarFire SoC 的“引导服务层”。它接管后，会初始化 DDR、时钟、外设，并负责加载 U-Boot、Linux 内核或裸机镜像。HSS 的关键特征是它同时承担引导与运行时服务：即使 Linux 已经启动，E51 仍可通过 HSS 提供 SBI 调用、IPI 消息和系统服务。

HSS 的引导阶段大致如下：首先完成自身运行环境与 DDR 初始化；然后解析启动镜像描述（如 HSS payload 配置），确定要加载的下一级镜像及其地址；接着把镜像搬运到目标内存并校验；最后释放 U54 核，跳转到 U-Boot 或内核入口。若使用 HSS 的“boot image”打包格式，镜像中会包含多个条目，HSS 按条目顺序加载。

启动模式选择与镜像加载机制

PolarFire SoC 通过一组启动模式引脚或 eNVM 中的配置位决定 BootROM 从何处获取 HSS。常见模式包括：从 eNVM 启动（适合量产固化）、从 QSPI Flash 启动（适合开发板）、从 SD 卡启动（便于替换镜像）、以及通过 JTAG 由调试器直接注入。模式选择在复位释放瞬间被采样，因此运行中改变引脚不会切换启动源。

镜像加载遵循“分级加载”原则：BootROM 加载 HSS，HSS 加载 U-Boot，U-Boot 再加载 Linux 内核与根文件系统。每一级都只信任上一级传递的信息，并做必要的校验。以 SD 卡启动为例，典型布局是：分区 1 存放 HSS 与 U-Boot 的打包镜像，分区 2 存放 Linux 内核与设备树，分区 3 为根文件系统。HSS 读取分区 1 的镜像头，按描述把 U-Boot 搬到 DDR 指定地址，再跳转执行。

实际观察与判断依据

在开发板上验证启动流程时，最直接的观察点是串口输出。正常顺序通常是：BootROM 无输出或极简输出 → HSS 打印版本与 DDR 初始化信息 → U-Boot 打印版本与加载日志 → 内核启动日志。若串口停在 HSS 之前，应优先检查启动模式引脚、镜像是否烧写到正确介质、镜像头是否匹配；若停在 HSS 之后、U-Boot 之前，则检查 HSS payload 配置与 DDR 参数；若 U-Boot 能起但内核不启动，则检查内核地址、设备树与根文件系统参数。

另一个实用手段是使用 JTAG 调试器连接 E51，在 BootROM 出口或 HSS 入口设置断点，观察 PC 是否到达预期地址。若 PC 始终停在 BootROM 内部循环，说明 BootROM 未找到有效 HSS 镜像，此时应回到启动模式与镜像完整性上排查，而不是怀疑 Linux 配置。