芯耀
633
欢迎各位朋友关注“郝旭帅电子设计团队”公众号，本公众号会定时更新相关技术类资料、软件等等，感兴趣的朋友可以浏览一下本公众号的其他“模块”，希望各位朋友都能在本公众号获得一些自己想要的“东西”。
本篇主要是讨论zynq的启动过程
Zynq 的启动过程是一个精心设计的、多阶段的过程，因为它涉及到处理系统（PS） 和可编程逻辑（PL） 两部分的协同启动。理解这个过程对于进行系统设计和调试至关重要。
Zynq 的启动过程可以概括为以下四个主要阶段，下图清晰地展示了其工作流程与分工：
第一阶段：片上 BootROM（硬件自动执行）
这是芯片上电后完全硬件自动执行的阶段，用户无法修改。
上电复位：芯片通电并释放复位信号。
执行 BootROM：
CPU 的 Cortex-A9 核心 开始执行芯片内部 ROM 中固化的代码。
BootROM 代码是只读的、受信任的根代码。
硬件初始化：初始化最基本的硬件，如 ARM 核心、MMU、缓存和芯片的引脚。
探测启动模式：
BootROM 读取 "模式引脚" 的状态，确定从哪里加载下一阶段的启动代码（第一阶段引导加载程序，FSBL）。
常见的启动设备包括：
Quad-SPI Flash
SD 卡
JTAG（主要用于调试）
加载 FSBL：
BootROM 从指定的启动设备中寻找并加载 FSBL 到芯片的片上内存（OCM）中。
FSBL 映像文件有一个特定的头部格式，BootROM 会对其进行校验和验证。如果失败，它会尝试回退到其他启动设备。
此阶段结束状态：FSBL 代码被加载到 OCM 中，CPU 开始执行 FSBL。
第二阶段：第一阶段引导加载程序（FSBL）
FSBL 是用户需要创建的第一个软件组件，通常使用 AMD Vitis 工具生成。
FSBL 执行：CPU 开始在 OCM 中运行 FSBL 代码。
PS 进一步初始化：完成 BootROM 未完成的硬件初始化，例如：
初始化更多 PS 端的外设（如 UART、Ethernet 等）。
可选的 PL 配置：这是 Zynq 启动的关键步骤之一。
FSBL 从启动设备（如 QSPI、SD卡）中读取 比特流文件。
通过 PCAP 接口，使用 DDR 内存作为缓冲区，将比特流配置到 PL 中。
此步骤是可选的。如果系统不需要 PL，可以跳过。
加载第二阶段代码：
FSBL 从启动设备中加载下一阶段的代码（用户应用程序）到 DDR 内存 中（因为 OCM 容量有限）。
这个“第二阶段代码”可以是：
裸机应用程序：直接跳转到其入口地址执行。
U-Boot：一个复杂的引导加载程序，用于启动像 Linux 这样的操作系统。
此阶段结束状态：PL 已被配置（如果比特流存在），用户应用程序被加载到 DDR 中，CPU 控制权转移给用户应用程序。
第三阶段：用户应用程序执行
此时，PS 端已经准备就绪，PL 端（如果配置了的话）也已完成编程。系统开始运行用户的实际应用代码。
根据 FSBL 加载的内容，这个阶段有不同的分支：
场景 A：裸机应用程序
应用程序直接控制硬件，无需操作系统。
这是最简单、延迟最低的场景，适用于实时控制应用。
场景 B：操作系统（如 Linux）
FSBL 通常会加载一个更强大的引导加载程序，如 U-Boot。
U-Boot 的任务：
进一步初始化硬件。
从文件系统（如在 SD 卡上）加载 设备树 blob 和 Linux 内核映像 到内存中。
将必要的参数传递给内核，然后启动 Linux 内核。
最后，Linux 内核接管系统，启动用户空间程序。
启动镜像组成
为了完成启动，你需要创建一个 启动镜像 文件，它通常包含多个部分：
FSBL.elf：第一阶段引导加载程序。
Bitstream.bit：用于配置 PL 的比特流文件（可选）。
U-Boot.elf 或 Application.elf：第二阶段的引导加载程序或裸机应用程序。
设备树.dtb：描述系统硬件信息的文件（用于操作系统）。
使用 AMD Vitis 或 SDK 工具，可以将这些组件打包成一个单一的 BOOT.bin 文件，并将其放入启动设备（如 SD 卡）的 FAT32 分区中。
总结
Zynq 的启动过程是一个层次分明、分工明确的链条：
BootROM（硬件）：完成最底层的硬件初始化，确定启动源。
FSBL（用户提供）：初始化 DDR 和关键外设，配置 PL，加载下一阶段代码。
用户应用（用户提供）：
裸机程序：直接运行。
U-Boot + Linux：由 U-Boot 加载内核并启动完整的操作系统。
这种灵活的启动流程使得 Zynq 能够适应从简单的嵌入式控制到复杂的 Linux 应用等各种场景。
本篇内容中有部分资源来源于网络，如有侵权，请联系作者。
