简介本资源是面向嵌入式开发工程师与ZYNQ平台学习者的双核AMPAsymmetric 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跑LinuxCPU1跑裸机实时任务并通过共享内存等方式高效通信。这个“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引导启动 共享内存通信”的经典架构。具体分工如下CPU0Master Core作为主核心负责系统初始化最早期的工作包括配置时钟、初始化DDR内存控制器、加载CPU1的程序镜像到指定内存地址然后释放CPU1使其从该地址开始执行。之后CPU0通常会运行一个相对复杂的系统比如Linux负责文件系统、网络协议栈、人机交互等非实时任务。CPU1Slave Core作为从核心在CPU0将其“唤醒”之前它处于等待状态WFI。一旦被释放它就从预设地址开始执行裸机程序专注于电机控制、数据采集、通信协议解析等对时序要求苛刻的实时任务。两个核心之间的“对话”通过共享内存Shared Memory完成。我们会在DDR内存中划出一块区域例如从地址0x100000开始作为公共邮箱。双方通过读写这块内存中的特定数据结构如标志位、数据缓冲区来交换信息和数据。为了避免冲突通常需要配合简单的软件信号量或硬件自旋锁机制。这个方案的优势是直观、高效延迟低是嵌入式领域最常用的核间通信方式之一。3. 开发环境搭建与工程创建工欲善其事必先利其器。首先需要准备好开发环境我使用的是Vivado 2019.1和配套的Xilinx SDKVitis的前身。虽然新版本Vitis是趋势但SDK在裸机开发方面依然稳定且资料丰富。硬件平台是一块搭载XC7Z020芯片的开发板。3.1 Vivado硬件工程配置第一步是在Vivado中创建硬件平台重点在于正确配置ZYNQ Processing SystemPSIP核。创建工程与添加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_FFFF1GB。我们决定将0x1000001MB偏移之后的一块区域例如2MB专门分配给CPU1的程序运行。虽然地址编辑器主要管理从PS到PL的地址映射但这里的概念是软件规划。我们更关键的操作是在后续的Linker Script链接脚本中体现。实际上更常见的做法是在FSBLFirst 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 CPU0Master链接脚本配置双击打开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起始地址设置为0x001000001MB处。这意味着编译器会把CPU0的程序代码和数据从1MB地址开始存放。那么0x00000000到0x000FFFFF这1MB空间就被我们“预留”出来了。这块预留空间用途很关键前64KB或更小区域可能用于FSBL或BootROM。紧接着的区域例如0x100000 - 0x1FFFFF我们计划用来存放CPU1的二进制镜像。CPU0的任务之一就是把cpu1_app编译生成的.bin文件加载到这里。再往后的某个区域例如0x200000 - 0x20FFFF规划为共享内存区。ps7_ram_0和ps7_ram_1这是片上内存OCM速度极快但容量小总共256KB。通常把栈、堆或需要快速访问的关键数据放在这里。在SECTIONS部分确保.text代码、.data初始化数据等段都位于ps7_ddr_0内存区域内。这样CPU0的应用程序就被链接到了DDR的高地址区域为低地址区域留出了空间。4.2 CPU1Slave链接脚本配置打开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也可以配置使用一部分OCMps7_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主程序启动流程与唤醒CPU1CPU0的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 i0; iIMAGE_SIZE_WORDS; i) { // dest_addr[i] read_from_flash(src_addr i); // } // 然后需要执行缓存刷新确保数据写入DDR而非缓存 // Xil_DCacheFlushRange(CPU1_IMAGE_START_ADDR, IMAGE_SIZE_BYTES);5.3 释放CPU1Slave 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子视图中你应该能看到两个CPUps7_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复位的那行代码之后设置一个断点。然后按F8Resume让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的.elfFSBL会识别出它是针对ps7_cortexa9_1的并将其加载到ELF文件中指定的加载地址即我们链接脚本中设置的0x00100000。生成BOOT.bin打开XSCTXilinx 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 SemaphoreZYNQ PS内部提供了硬件信号量模块用于实现原子化的核间同步比软件标志位更可靠。可以通过Xil_Semaphore相关的API来使用。使用中断进行核间通知除了轮询共享内存标志位还可以配置CPU私有定时器中断或软件生成中断SGI来通知对方。这能降低CPU占用率提高实时性。需要在GIC通用中断控制器中配置中断分配和路由。精细化的内存管理除了共享内存可以为每个核心划分独立的DDR区域避免任何意外的内存越界访问。可以通过MMU或MPU内存保护单元设置内存保护属性。性能优化对于频繁通信的数据可以考虑使用OCM作为共享内存因为它的访问速度远快于DDR。但需要仔细规划OCM的分区避免冲突。混合系统Linux Baremetal更复杂的场景是CPU0运行LinuxCPU1运行裸机程序。此时需要在Linux的设备树Device Tree中为CPU1预留内存区域使用reserved-memory节点并可能编写一个Linux内核驱动来管理CPU1的加载和启动。通信机制可能升级为使用RPMsg框架。这个“ZYNQ 7020实现dual_core_amp驱动”项目包就是从这些基础步骤到进阶思考的完整记录。从硬件的地址规划到软件的链接脚本、启动代码、通信协议每一步都需要耐心和细致的调试。当你第一次看到串口里交替打印出两个核心的问候信息或者共享内存里的数据如预期般跳动时那种成就感就是对之前所有折腾的最好回报。多核开发就像让两个大脑协同工作规划好各自的“领地”和“沟通方式”它们就能发挥出远超单核的性能。本文还有配套的精品资源点击获取 
长河君 · 2026/9/3 1:46:08 · 阅读 1.2k ZYNQ 7020双核AMP开发实战：从内存规划到核间通信
简介本资源是面向嵌入式开发工程师与ZYNQ平台学习者的双核AMPAsymmetric 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跑LinuxCPU1跑裸机实时任务并通过共享内存等方式高效通信。这个“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引导启动 共享内存通信”的经典架构。具体分工如下CPU0Master Core作为主核心负责系统初始化最早期的工作包括配置时钟、初始化DDR内存控制器、加载CPU1的程序镜像到指定内存地址然后释放CPU1使其从该地址开始执行。之后CPU0通常会运行一个相对复杂的系统比如Linux负责文件系统、网络协议栈、人机交互等非实时任务。CPU1Slave Core作为从核心在CPU0将其“唤醒”之前它处于等待状态WFI。一旦被释放它就从预设地址开始执行裸机程序专注于电机控制、数据采集、通信协议解析等对时序要求苛刻的实时任务。两个核心之间的“对话”通过共享内存Shared Memory完成。我们会在DDR内存中划出一块区域例如从地址0x100000开始作为公共邮箱。双方通过读写这块内存中的特定数据结构如标志位、数据缓冲区来交换信息和数据。为了避免冲突通常需要配合简单的软件信号量或硬件自旋锁机制。这个方案的优势是直观、高效延迟低是嵌入式领域最常用的核间通信方式之一。3. 开发环境搭建与工程创建工欲善其事必先利其器。首先需要准备好开发环境我使用的是Vivado 2019.1和配套的Xilinx SDKVitis的前身。虽然新版本Vitis是趋势但SDK在裸机开发方面依然稳定且资料丰富。硬件平台是一块搭载XC7Z020芯片的开发板。3.1 Vivado硬件工程配置第一步是在Vivado中创建硬件平台重点在于正确配置ZYNQ Processing SystemPSIP核。创建工程与添加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_FFFF1GB。我们决定将0x1000001MB偏移之后的一块区域例如2MB专门分配给CPU1的程序运行。虽然地址编辑器主要管理从PS到PL的地址映射但这里的概念是软件规划。我们更关键的操作是在后续的Linker Script链接脚本中体现。实际上更常见的做法是在FSBLFirst 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 CPU0Master链接脚本配置双击打开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起始地址设置为0x001000001MB处。这意味着编译器会把CPU0的程序代码和数据从1MB地址开始存放。那么0x00000000到0x000FFFFF这1MB空间就被我们“预留”出来了。这块预留空间用途很关键前64KB或更小区域可能用于FSBL或BootROM。紧接着的区域例如0x100000 - 0x1FFFFF我们计划用来存放CPU1的二进制镜像。CPU0的任务之一就是把cpu1_app编译生成的.bin文件加载到这里。再往后的某个区域例如0x200000 - 0x20FFFF规划为共享内存区。ps7_ram_0和ps7_ram_1这是片上内存OCM速度极快但容量小总共256KB。通常把栈、堆或需要快速访问的关键数据放在这里。在SECTIONS部分确保.text代码、.data初始化数据等段都位于ps7_ddr_0内存区域内。这样CPU0的应用程序就被链接到了DDR的高地址区域为低地址区域留出了空间。4.2 CPU1Slave链接脚本配置打开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也可以配置使用一部分OCMps7_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主程序启动流程与唤醒CPU1CPU0的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 i0; iIMAGE_SIZE_WORDS; i) { // dest_addr[i] read_from_flash(src_addr i); // } // 然后需要执行缓存刷新确保数据写入DDR而非缓存 // Xil_DCacheFlushRange(CPU1_IMAGE_START_ADDR, IMAGE_SIZE_BYTES);5.3 释放CPU1Slave 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子视图中你应该能看到两个CPUps7_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复位的那行代码之后设置一个断点。然后按F8Resume让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的.elfFSBL会识别出它是针对ps7_cortexa9_1的并将其加载到ELF文件中指定的加载地址即我们链接脚本中设置的0x00100000。生成BOOT.bin打开XSCTXilinx 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 SemaphoreZYNQ PS内部提供了硬件信号量模块用于实现原子化的核间同步比软件标志位更可靠。可以通过Xil_Semaphore相关的API来使用。使用中断进行核间通知除了轮询共享内存标志位还可以配置CPU私有定时器中断或软件生成中断SGI来通知对方。这能降低CPU占用率提高实时性。需要在GIC通用中断控制器中配置中断分配和路由。精细化的内存管理除了共享内存可以为每个核心划分独立的DDR区域避免任何意外的内存越界访问。可以通过MMU或MPU内存保护单元设置内存保护属性。性能优化对于频繁通信的数据可以考虑使用OCM作为共享内存因为它的访问速度远快于DDR。但需要仔细规划OCM的分区避免冲突。混合系统Linux Baremetal更复杂的场景是CPU0运行LinuxCPU1运行裸机程序。此时需要在Linux的设备树Device Tree中为CPU1预留内存区域使用reserved-memory节点并可能编写一个Linux内核驱动来管理CPU1的加载和启动。通信机制可能升级为使用RPMsg框架。这个“ZYNQ 7020实现dual_core_amp驱动”项目包就是从这些基础步骤到进阶思考的完整记录。从硬件的地址规划到软件的链接脚本、启动代码、通信协议每一步都需要耐心和细致的调试。当你第一次看到串口里交替打印出两个核心的问候信息或者共享内存里的数据如预期般跳动时那种成就感就是对之前所有折腾的最好回报。多核开发就像让两个大脑协同工作规划好各自的“领地”和“沟通方式”它们就能发挥出远超单核的性能。本文还有配套的精品资源点击获取