ZYNQ 7020双核AMP开发实战：从内存规划到核间通信-开发者社区

简介：本资源是面向嵌入式开发工程师与ZYNQ平台学习者的双核AMP（Asymmetric Multi-Processing）驱动实战项目，聚焦ZYNQ 7020 SoC在Xilinx SDK环境下实现ARM Cortex-A9双核协同驱动开发，解决多核任务划分、中断隔离、核间同步及硬件资源访问等关键问题，适用于工业控制、实时图像处理等需性能与确定性兼顾的场景。压缩包共1164个文件，涵盖254个.h头文件（硬件抽象与API声明）、203个.c源文件（含初始化、ISR、驱动操作函数等核心逻辑）、70个Makefile（构建配置）、36个.tcl与.xdc约束脚本（软硬协同配置），以及.o、.elf、.bit、.hdf等编译与烧录必需文件，整体大小29.92MB。已有124人下载学习，资源结构完整，包含可直接导入SDK的工程框架、多线程调度示例、信号量同步机制实现、GPIO/SPI基础外设驱动模板，以及runme.bat一键运行脚本和__synthesis_is_complete__等构建状态标记，便于快速验证与二次开发。

1. 项目概述：ZYNQ 7020上的双核AMP驱动开发

最近在做一个基于ZYNQ 7020的嵌入式项目，核心需求是让它的两个ARM Cortex-A9核心（CPU0和CPU1）能真正“协同工作”，而不是一个干活一个围观。我们最终的目标是实现一个Dual-Core AMP（非对称多处理）的架构，简单说就是让两个核心各自运行独立的程序（比如CPU0跑Linux，CPU1跑裸机实时任务），并通过共享内存等方式高效通信。这个“ZYNQ 7020实现dual_core_amp驱动（SDK驱动）.zip”项目包，就是我整理出来的从零开始构建这套系统的完整工程、驱动代码和配置笔记。

对于刚接触ZYNQ多核开发的朋友来说，最大的困惑往往不是写代码，而是如何让两个核心“和平共处”并“顺畅交流”。Xilinx SDK（现在叫Vitis）虽然提供了基础框架，但关于内存划分、核间通信、启动流程等关键细节，官方文档往往散落在各处，实际配置时一不留神就会踩坑。这个项目就是把这些碎片化的知识串联起来，形成一个可复现的实操指南。无论你是想实现Linux+裸机的混合系统，还是纯粹的裸机双核AMP，这里面的思路和代码都能给你提供一个扎实的起点。

2. 核心思路与方案选型：为什么是AMP？如何分工？

在ZYNQ上实现多核，主要有SMP（对称多处理）和AMP两种模式。SMP模式下，两个核心运行同一个操作系统（如Linux），由操作系统统一调度任务，对开发者而言相对透明，但实时性难以保证，且两个核心耦合紧密。而AMP模式则更灵活，每个核心可以视为一个独立的“单片机”，运行不同的操作系统甚至裸机程序，特别适合需要硬实时响应、功能隔离（如一个核心处理控制算法，另一个核心处理网络通信）的场景。我们的项目选择了AMP，就是为了充分发挥ZYNQ PS（处理系统）双核的硬件潜力，实现确定性的实时任务处理。

方案选型上，我们采用了“CPU0引导启动 + 共享内存通信”的经典架构。具体分工如下：

CPU0（Master Core）：作为主核心，负责系统初始化最早期的工作，包括配置时钟、初始化DDR内存控制器、加载CPU1的程序镜像到指定内存地址，然后释放CPU1使其从该地址开始执行。之后，CPU0通常会运行一个相对复杂的系统，比如Linux，负责文件系统、网络协议栈、人机交互等非实时任务。
CPU1（Slave Core）：作为从核心，在CPU0将其“唤醒”之前，它处于等待状态（WFI）。一旦被释放，它就从预设地址开始执行裸机程序，专注于电机控制、数据采集、通信协议解析等对时序要求苛刻的实时任务。

两个核心之间的“对话”通过共享内存（Shared Memory）完成。我们会在DDR内存中划出一块区域（例如从地址0x100000开始），作为公共邮箱。双方通过读写这块内存中的特定数据结构（如标志位、数据缓冲区）来交换信息和数据。为了避免冲突，通常需要配合简单的软件信号量或硬件自旋锁机制。这个方案的优势是直观、高效，延迟低，是嵌入式领域最常用的核间通信方式之一。

3. 开发环境搭建与工程创建

工欲善其事，必先利其器。首先需要准备好开发环境，我使用的是Vivado 2019.1和配套的Xilinx SDK（Vitis的前身）。虽然新版本Vitis是趋势，但SDK在裸机开发方面依然稳定且资料丰富。硬件平台是一块搭载XC7Z020芯片的开发板。

3.1 Vivado硬件工程配置

第一步是在Vivado中创建硬件平台，重点在于正确配置ZYNQ Processing System（PS）IP核。

创建工程与添加IP：新建Vivado工程，选择对应的芯片型号。在Block Design中，添加ZYNQ7 Processing System IP核。
关键配置：
- DDR配置：根据你的开发板使用的DDR颗粒型号，在PS-PL Configuration -> DDR Configuration中选择正确的型号。这是后续程序能正确运行在DDR中的基础。
- 时钟配置：在Clock Configuration中，确保CPU的频率（如666MHz）和DDR控制器频率（如533MHz）设置正确且稳定。
- MIO配置：根据板载外设（如UART用于调试、QSPI Flash用于存储）配置好MIO引脚。通常至少需要使能UART0用于串口打印。
- 中断：如果双核间计划使用中断通知，需要在PS-PL Configuration -> Interrupts中使能Fabric Interrupts，并将中断连接到CPU1。
地址分配：这是AMP模式下的重中之重。在Address Editor标签页，我们需要为CPU1的代码预留一块不会被CPU0系统侵占的内存空间。
- 假设我们规划DDR的地址范围是0x0000_0000到0x3FFF_FFFF（1GB）。我们决定将0x100000（1MB偏移）之后的一块区域（例如2MB）专门分配给CPU1的程序运行。虽然地址编辑器主要管理从PS到PL的地址映射，但这里的概念是软件规划。我们更关键的操作是在后续的Linker Script（链接脚本）中体现。
- 实际上，更常见的做法是在FSBL（First Stage Bootloader）或CPU0的应用程序中，将CPU1的二进制文件加载到0x100000这个地址。因此，我们需要确保在CPU0运行的Linux或裸机程序的内存映射中，0x100000开始的这段地址空间是预留的、非占用的。
生成输出：配置完成后，生成HDL Wrapper，然后运行综合、实现、生成比特流。最后，导出硬件（Export Hardware），这一步一定要勾选“Include bitstream”，并将导出的.xsa文件（Vivado 2019.1后是.xsa，之前是.hdf）保存到指定位置。这个文件包含了完整的硬件信息，是启动SDK进行软件开发的桥梁。

注意：很多双核启动失败的问题，根源都在于硬件配置，尤其是DDR型号选错。务必对照开发板原理图或手册确认。另外，如果CPU1需要使用私有外设（如私有定时器），需要在PS配置中确保这些资源是分配给CPU1的。

3.2 SDK中创建AMP软件工程

打开Xilinx SDK，它通常会随Vivado启动或通过Launch SDK打开。

创建工作区与导入硬件：新建一个Workspace。通过菜单File -> New -> Application Project创建新工程。在第一个页面，Target Hardware下选择我们刚才导出的.xsa文件，这样SDK就能识别我们的硬件平台。
创建CPU0主工程：
- 工程名设为cpu0_boot（或类似）。
- 选择Target CPU为ps7_cortexa9_0。
- 在模板选择页面，为了简化，可以先选择Empty Application。后续我们会手动添加代码。
- 这个工程将负责最基础的硬件初始化和唤醒CPU1。
创建CPU1从工程：
- 同样File -> New -> Application Project。
- 工程名设为cpu1_app。
- 关键步骤：Target CPU必须选择ps7_cortexa9_1。
- 模板同样选择Empty Application。
- 这个工程就是CPU1上要运行的裸机任务程序。
工程结构预览：创建完成后，在SDK左侧的Project Explorer中，你会看到两个独立的工程。它们有各自的源代码目录src、编译设置和最重要的链接脚本（lscript.ld）。接下来，我们需要分别对这两个工程的链接脚本进行精细调整，这是确保双核程序在内存中“各就各位”不打架的核心。

4. 双核内存规划与链接脚本配置

内存规划是AMP成功的基石。目标很明确：CPU0和CPU1的代码、数据必须放在DDR中互不重叠的区域，并且要预留出共享内存区。

4.1 CPU0（Master）链接脚本配置

双击打开cpu0_boot工程下的lscript.ld文件。我们需要修改MEMORY部分。

MEMORY { ps7_ddr_0 : ORIGIN = 0x00100000, LENGTH = 0x3FF00000 ps7_ram_0 : ORIGIN = 0x00000000, LENGTH = 0x00030000 ps7_ram_1 : ORIGIN = 0xFFFF0000, LENGTH = 0x0000FE00 }

ps7_ddr_0：这是主DDR内存段。注意我将ORIGIN（起始地址）设置为0x00100000（1MB处）。这意味着编译器会把CPU0的程序代码和数据从1MB地址开始存放。那么0x00000000到0x000FFFFF这1MB空间就被我们“预留”出来了。这块预留空间用途很关键：
1. 前64KB或更小区域：可能用于FSBL或BootROM。
2. 紧接着的区域（例如0x100000 - 0x1FFFFF）：我们计划用来存放CPU1的二进制镜像。CPU0的任务之一就是把cpu1_app编译生成的.bin文件加载到这里。
3. 再往后的某个区域（例如0x200000 - 0x20FFFF）：规划为共享内存区。
ps7_ram_0和ps7_ram_1：这是片上内存（OCM），速度极快但容量小（总共256KB）。通常把栈、堆或需要快速访问的关键数据放在这里。

在SECTIONS部分，确保.text（代码）、.data（初始化数据）等段都位于ps7_ddr_0内存区域内。这样，CPU0的应用程序就被链接到了DDR的高地址区域，为低地址区域留出了空间。

4.2 CPU1（Slave）链接脚本配置

打开cpu1_app工程的lscript.ld文件。这里的配置是决定性的。

MEMORY { ps7_ddr_0 : ORIGIN = 0x00100000, LENGTH = 0x00100000 /* 仅分配1MB给CPU1 */ ps7_ram_0 : ORIGIN = 0x00000000, LENGTH = 0x00030000 ps7_ram_1 : ORIGIN = 0xFFFF0000, LENGTH = 0x0000FE00 }

ps7_ddr_0：起始地址ORIGIN必须设置为0x00100000，这必须和CPU0计划加载CPU1镜像的地址完全一致。长度LENGTH可以根据你的CPU1程序大小设定，比如1MB。这个配置告诉链接器：“CPU1的所有代码和数据都假设自己是从0x100000这个地址开始运行的。” 因此，CPU1程序中所有的函数指针、全局变量地址，都是基于这个基址计算的。
OCM配置：注意，即使CPU1也可以配置使用一部分OCM（ps7_ram_0/1），但需要小心。如果CPU0和CPU1都试图读写同一块OCM地址，会造成冲突。在典型的AMP设置中，我们可以将OCM分配给某个核心独占，或者划分区域使用。为了简单起见，在初始调试阶段，可以让CPU1只使用DDR，避免OCM冲突问题。

实操心得：链接脚本配置错误是导致CPU1跑飞的最常见原因。务必反复核对两个工程的ORIGIN地址。一个快速验证方法是：编译cpu1_app后，查看生成的.map文件（在Debug或Release文件夹下），检查Entry point和各个段的起始地址是否确实以0x00100000为基础。如果入口地址是0x00100000，那就对了；如果是0x00000000，说明链接脚本没生效，需要检查SDK工程设置中是否正确指定了此链接脚本。

5. CPU0主程序：启动流程与唤醒CPU1

CPU0的main.c需要完成几件关键事情：基础初始化、将CPU1的程序镜像加载到预定地址、释放CPU1。

5.1 基础初始化与共享内存定义

首先包含必要的头文件，并定义共享内存的结构。

#include <stdio.h> #include "platform.h" #include "xil_printf.h" #include "xil_io.h" #include "xil_mmu.h" #include "xscugic.h" #include "xscugic_hw.h" // 用于直接操作寄存器 // 定义共享内存结构体（示例：一个简单的邮箱） #define SHARED_MEM_BASE (0x200000) // 共享内存起始地址，位于预留空间内 typedef struct { volatile uint32_t message; // 传递的消息 volatile uint32_t flag; // 标志位，0为空闲，1为CPU0写入，2为CPU1写入 } shared_mailbox_t; shared_mailbox_t* mailbox = (shared_mailbox_t*)SHARED_MEM_BASE; // 定义CPU1应用程序在DDR中的加载地址 #define CPU1_IMAGE_START_ADDR 0x00100000

初始化部分主要是使能缓存、初始化UART用于打印调试信息。

int main() { init_platform(); // SDK提供的平台初始化函数，初始化了UART等基础外设 xil_printf("CPU0: Booting...\n"); // 可选：禁用缓存或配置MMU，确保对共享内存和CPU1加载区的访问是直达的（非缓存）。 // 对于简单的AMP，可以先不配置MMU，但需要小心缓存一致性问题。 // Xil_SetTlbAttributes(CPU1_IMAGE_START_ADDR, NORM_NONCACHE); // 示例：设置该区域为非缓存 // Xil_DCacheDisable(); // 或者直接禁用数据缓存（简单粗暴，初期调试可用） // 初始化共享内存区域 mailbox->message = 0; mailbox->flag = 0; xil_printf("CPU0: Shared mailbox initialized at 0x%08x\n", SHARED_MEM_BASE);

5.2 加载CPU1镜像

在真实的系统中，CPU1的镜像可能存储在QSPI Flash、SD卡等非易失存储器中，需要由CPU0（或更早的FSBL）读取并拷贝到DDR的CPU1_IMAGE_START_ADDR。为了简化，我们假设cpu1_app工程编译生成的.bin文件已经通过其他方式（比如JTAG直接下载，或由FSBL从Flash加载）放置在了正确位置。在SDK调试环境下，我们可以直接使用JTAG将两个程序分别加载到各自的内存区域。

因此，在CPU0的主程序中，我们通常不包含复杂的加载代码，而是直接进行“释放CPU1”的操作。但在生产代码中，你需要实现加载逻辑，例如：

// 伪代码：从Flash读取CPU1镜像到DDR // uint32_t* src_addr = (uint32_t*)QSPI_FLASH_CPU1_IMAGE_OFFSET; // uint32_t* dest_addr = (uint32_t*)CPU1_IMAGE_START_ADDR; // for(int i=0; i<IMAGE_SIZE_WORDS; i++) { // dest_addr[i] = read_from_flash(src_addr + i); // } // 然后需要执行缓存刷新，确保数据写入DDR而非缓存 // Xil_DCacheFlushRange(CPU1_IMAGE_START_ADDR, IMAGE_SIZE_BYTES);

5.3 释放CPU1（Slave Core）

这是最关键的一步。ZYNQ中，CPU1上电后处于等待事件（WFE）状态，停留在BootROM代码中。CPU0需要通过写系统级控制寄存器来释放它。

// 步骤1：设置CPU1的启动地址 // 将CPU1的启动地址写入SLCR寄存器 A9_CPU_RVBAR_ADDR Xil_Out32(0xF8F00204, CPU1_IMAGE_START_ADDR); // 对于ZYNQ 7000，该寄存器地址为0xF8F00204 xil_printf("CPU0: CPU1 reset vector set to 0x%08x\n", CPU1_IMAGE_START_ADDR); // 步骤2：确保CPU1处于等待状态（通常上电即如此） // 步骤3：执行SEV（发送事件）指令，唤醒CPU1 __asm__("sev"); // 步骤4：释放CPU1出复位状态 // 清除SLCR寄存器中的CPU1软件复位位 uint32_t reg = Xil_In32(0xF8F01000); // 读取SLCR_UNLOCK寄存器？不，直接操作SLCR寄存器 // 更准确的操作是：先解锁SLCR（如果需要），然后操作CPU_RST_CTRL寄存器 // 解锁SLCR (0xF8000000 + 0x8) Xil_Out32(0xF8000008, 0xDF0D); // 清除CPU1的复位位 (0xF8000000 + 0x244) 的bit [1] reg = Xil_In32(0xF8000244); reg &= ~(1 << 1); // 将bit1清零，释放CPU1复位 Xil_Out32(0xF8000244, reg); // 可选：重新锁定SLCR Xil_Out32(0xF8000004, 0x767B); xil_printf("CPU0: CPU1 released from reset and started.\n");

注意事项：上述寄存器地址和操作顺序是ZYNQ 7000系列的典型方法。不同版本或型号的ZYNQ（如UltraScale+）寄存器地址可能不同，务必查阅对应版本的《Zynq-7000 Technical Reference Manual (TRM)》的“System-Level Control Registers (SLCR)”和“Boot and Configuration”章节。错误的操作顺序可能导致CPU1无法启动。

5.4 CPU0主循环与通信示例

释放CPU1后，CPU0就可以进入自己的主循环，并通过共享内存与CPU1通信。

// CPU0主循环 while (1) { // 示例：CPU0向共享邮箱写入数据 if (mailbox->flag == 0) { // 邮箱空闲 static uint32_t counter = 0; mailbox->message = counter++; mailbox->flag = 1; // 标记为CPU0已写入 xil_printf("CPU0: Sent message %d\n", mailbox->message); } // 示例：CPU0读取CPU1发来的数据 if (mailbox->flag == 2) { // CPU1已写入 xil_printf("CPU0: Received from CPU1: %d\n", mailbox->message); mailbox->flag = 0; // 清空标志位 } // 延时或执行其他任务 for (volatile int i = 0; i < 1000000; i++); // 简单延时 } return 0; }

6. CPU1从程序：独立运行与核间通信

CPU1的程序main.c看起来就像一个标准的裸机程序，但它的链接地址是特殊的（0x100000）。它需要初始化自己的私有外设（如私有定时器），并参与共享内存通信。

6.1 CPU1程序入口与初始化

#include <stdio.h> #include "platform.h" // 注意：CPU1工程也需要这个头文件来使用xil_printf等（如果SDK支持） #include "xil_printf.h" #include "xil_io.h" #include "xscutimer.h" // 私有定时器头文件 // 声明共享内存结构（定义必须与CPU0一致） extern shared_mailbox_t* mailbox; // 或者在这里重新定义一遍 #define SHARED_MEM_BASE (0x200000) typedef struct { volatile uint32_t message; volatile uint32_t flag; } shared_mailbox_t; shared_mailbox_t* mailbox = (shared_mailbox_t*)SHARED_MEM_BASE; // 私有定时器实例 XScuTimer TimerInstance; int main() { // CPU1没有init_platform()，需要手动初始化必要的外设，最常用的是私有定时器。 xil_printf("CPU1: Application started successfully!\n"); // 初始化CPU1的私有定时器（示例） XScuTimer_Config* TimerConfig = XScuTimer_LookupConfig(XPAR_PS7_SCUTIMER_0_DEVICE_ID); XScuTimer_CfgInitialize(&TimerInstance, TimerConfig, TimerConfig->BaseAddr); XScuTimer_LoadTimer(&TimerInstance, 333000000); // 假设CPU频率666MHz，定时0.5秒 XScuTimer_Start(&TimerInstance); xil_printf("CPU1: Timer initialized.\n");

踩坑记录：在CPU1工程中直接使用xil_printf可能会失败，因为其底层依赖的UART驱动可能默认配置为CPU0所用。一种方法是重写一个简单的串口发送函数，直接操作UART寄存器（确保UART是共享外设且已由CPU0初始化好）。更稳妥的调试方式是在初期使用共享内存传递状态信息，由CPU0打印出来。

6.2 CPU1主循环与通信

while (1) { // 示例：CPU1响应CPU0的消息 if (mailbox->flag == 1) { // CPU0已写入 uint32_t received_msg = mailbox->message; mailbox->message = received_msg * 2; // 简单处理，返回双倍 mailbox->flag = 2; // 标记为CPU1已回复 // xil_printf("CPU1: Received %d, Sent back %d\n", received_msg, mailbox->message); // 谨慎使用打印 } // 示例：CPU1基于定时器执行周期性任务 if (XScuTimer_IsExpired(&TimerInstance)) { XScuTimer_ClearInterruptStatus(&TimerInstance); // 可以在此设置一些状态到共享内存，通知CPU0 // static int timer_tick = 0; // mailbox->timer_count = timer_tick++; } // 其他裸机任务... } return 0; }

7. 编译、加载与调试实战

配置好代码后，接下来就是编译和调试，这是验证双核AMP是否成功的关键步骤。

7.1 分别编译两个工程

在SDK中，分别右键点击cpu0_boot和cpu1_app工程，选择Build Project。确保编译没有错误。
编译后，在各自的Debug或Release文件夹下，会生成.elf（可执行与链接格式）文件。我们最终需要的是.bin（纯二进制）文件，用于加载到内存。SDK通常会自动生成.bin文件。如果没有，可以在工程属性C/C++ Build -> Settings -> ARM v7 gcc linker -> Miscellaneous中，勾选Generate binary image。

7.2 使用JTAG进行双核调试（SDK环境）

在开发初期，使用JTAG同时加载和调试两个核心是最方便的方式。

创建调试配置：在SDK中，右键cpu0_boot工程 ->Debug As->Launch on Hardware (Single Application Debug)。这会打开调试透视图，并自动将cpu0_boot.elf加载到CPU0，但程序可能不会运行。
加载CPU1程序：在调试界面，找到Xilinx System Debugger视图。在Debug子视图中，你应该能看到两个CPU：ps7_cortexa9_0和ps7_cortexa9_1。
- 右键点击ps7_cortexa9_1->Connect（如果未连接）。
- 右键点击ps7_cortexa9_1->Load Application-> 浏览并选择cpu1_app.elf文件。关键一步：在加载对话框中，取消勾选“Reset entire system”和“Run after load”。我们只加载，不运行。
- 点击OK。此时，CPU1的程序被加载到0x00100000地址（由链接脚本决定）。
设置CPU0断点并运行：回到源代码视图，在CPU0的main.c中，在__asm__("sev");或释放CPU1复位的那行代码之后设置一个断点。然后按F8（Resume）让CPU0运行。
观察CPU1启动：当CPU0执行了SEV指令并清除了CPU1的复位位后，CPU1就应该开始运行了。你可以在CPU1的main.c入口处设置断点，然后切换到CPU1的上下文（在Debug视图中选择ps7_cortexa9_1），按F8继续，看是否能命中CPU1的断点。如果能，恭喜你，双核启动成功！
同时调试：你可以在两个核心的代码中分别设置断点，调试器会在断点处暂停当前核心，另一个核心可能继续运行（取决于外设访问冲突）。通过串口助手观察两个核心的打印输出（如果都配置了打印），或者观察共享内存变量的值（通过Expressions视图添加mailbox->flag等变量），可以直观地看到核间通信是否正常。

7.3 脱离JTAG：生成BOOT.bin从Flash启动

要让系统上电自启动，需要制作一个BOOT.bin文件。

准备文件：
- FSBL (First Stage Bootloader)：在SDK中新建一个FSBL工程（选择Zynq FSBL模板），用它来初始化硬件并加载后续镜像。编译生成fsbl.elf。
- CPU0程序：cpu0_boot.elf。
- CPU1程序：cpu1_app.elf。
- 比特流文件：Vivado生成的design_1_wrapper.bit（可选，如果用了PL部分）。
创建BIF文件：新建一个文本文件bootimage.bif，内容如下：
```
the_ROM_image: { [bootloader] fsbl.elf design_1_wrapper.bit cpu0_boot.elf cpu1_app.elf }
```
注意顺序：FSBL -> 比特流 -> CPU0应用 -> CPU1应用。FSBL会按照这个顺序加载后续镜像。对于CPU1的.elf，FSBL会识别出它是针对ps7_cortexa9_1的，并将其加载到ELF文件中指定的加载地址（即我们链接脚本中设置的0x00100000）。
生成BOOT.bin：打开XSCT（Xilinx Software Command-Line Tools）或Vitis终端，导航到文件所在目录，执行命令：
```
bootgen -image bootimage.bif -arch zynq -o BOOT.bin -w
```
烧录与启动：将生成的BOOT.bin文件放入SD卡（FAT32格式）根目录，开发板设置为SD卡启动；或者通过编程器烧写到QSPI Flash中。上电后，系统应能自动启动双核程序。通过串口观察CPU0的打印信息，可以判断启动流程是否成功。

8. 常见问题排查与进阶技巧

在实际操作中，你几乎一定会遇到各种问题。下面是一些常见坑点和解决思路。

8.1 问题排查速查表

现象	可能原因	排查思路与解决方案
CPU1完全不启动，无任何迹象。	1. CPU1启动地址设置错误。 2. CPU1程序未正确加载到该地址。 3. CPU1复位未释放或SEV指令未执行。 4. CPU1链接脚本起始地址与加载地址不一致。	1. 检查CPU0代码中写入`0xF8F00204`寄存器的值是否为`0x00100000`。 2. 在调试器中，查看内存`0x00100000`处的内容，是否与`cpu1_app.bin`文件开头一致。 3. 单步调试CPU0，确保执行了SEV和清除复位位的操作。查看SLCR相关寄存器值。 4. 对比`cpu1_app.elf`的加载地址（Load Address）和链接地址（Link Address），在`.map`文件中查看。
CPU1启动后立即跑飞，进入Undefined Instruction或Prefetch Abort。	1. CPU1的代码/数据地址与链接脚本不符，访问了非法地址。 2. 缓存一致性问题：CPU0在加载CPU1镜像后，数据可能在缓存中，未写入DDR。 3. CPU1使用了未初始化或配置错误的外设（如堆栈指针设置错误）。	1. 确认CPU1链接脚本中内存区域定义正确，且程序确实链接到了该区域。检查中断向量表是否在正确位置。 2. 在CPU0加载完CPU1镜像后，调用`Xil_DCacheFlushRange()`刷新缓存。或者直接禁用数据缓存进行测试。 3. 在CPU1程序最开始，用汇编设置好堆栈指针（SP）指向一段安全的内存（如OCM中分配给CPU1的区域）。
双核都能启动，但共享内存通信不正常（数据读不到或乱码）。	1. 缓存一致性问题：一个核写了缓存，另一个核直接从DDR读的是旧数据。 2. 共享内存地址未对齐或结构体定义不一致。 3. 对共享变量的访问不是原子的，被中断打断。	1. 将共享内存区域设置为非缓存（Non-cacheable）。在CPU0/1中，使用`Xil_SetTlbAttributes(SHARED_MEM_BASE, NORM_NONCACHE)`。或者使用软件维护一致性：写方刷新缓存，读方无效化缓存。 2. 确保两个工程中`shared_mailbox_t`结构体定义完全一致，使用相同的编译器和编译选项（避免结构体对齐差异）。 3. 对`flag`等同步变量的操作使用原子操作或关中断保护。
使用`xil_printf`在CPU1中打印导致系统卡死。	UART外设驱动未考虑多核并发访问，或CPU1没有正确初始化UART所需资源（如时钟、引脚）。	1. 初期调试避免在CPU1中使用`xil_printf`。改用共享内存传递调试信息，由CPU0统一打印。 2. 如果必须用，确保UART驱动是线程安全/核安全的，或者使用独立的UART实例（如果硬件支持）。
从Flash启动后，只有CPU0运行，CPU1不运行。	1.`BOOT.bin`制作顺序错误，FSBL未能识别或加载CPU1的ELF。 2. CPU1的ELF文件在链接时指定了错误的加载地址。	1. 检查`bootimage.bif`文件中`cpu1_app.elf`的位置，确保在CPU0的elf之后。用`bootgen`命令时加`-log info`查看详细处理日志。 2. 使用`readelf -l cpu1_app.elf`命令查看程序头（Program Headers），确认`LOAD`段的地址是否正确。

8.2 进阶技巧与优化建议

使用硬件信号量（HW Semaphore）：ZYNQ PS内部提供了硬件信号量模块，用于实现原子化的核间同步，比软件标志位更可靠。可以通过Xil_Semaphore相关的API来使用。
使用中断进行核间通知：除了轮询共享内存标志位，还可以配置CPU私有定时器中断或软件生成中断（SGI）来通知对方。这能降低CPU占用率，提高实时性。需要在GIC（通用中断控制器）中配置中断分配和路由。
精细化的内存管理：除了共享内存，可以为每个核心划分独立的DDR区域，避免任何意外的内存越界访问。可以通过MMU或MPU（内存保护单元）设置内存保护属性。
性能优化：对于频繁通信的数据，可以考虑使用OCM作为共享内存，因为它的访问速度远快于DDR。但需要仔细规划OCM的分区，避免冲突。
混合系统（Linux + Baremetal）：更复杂的场景是CPU0运行Linux，CPU1运行裸机程序。此时，需要在Linux的设备树（Device Tree）中为CPU1预留内存区域（使用reserved-memory节点），并可能编写一个Linux内核驱动来管理CPU1的加载和启动。通信机制可能升级为使用RPMsg框架。

这个“ZYNQ 7020实现dual_core_amp驱动”项目包，就是从这些基础步骤到进阶思考的完整记录。从硬件的地址规划，到软件的链接脚本、启动代码、通信协议，每一步都需要耐心和细致的调试。当你第一次看到串口里交替打印出两个核心的问候信息，或者共享内存里的数据如预期般跳动时，那种成就感就是对之前所有折腾的最好回报。多核开发就像让两个大脑协同工作，规划好各自的“领地”和“沟通方式”，它们就能发挥出远超单核的性能。

本文还有配套的精品资源，点击获取