ZYNQ 7020双核AMP实战：共享内存与SGI中断实现微秒级实时控制

简介本资源面向嵌入式开发工程师与ZYNQ学习者聚焦ZYNQ 7020平台上的dual_core_amp驱动实现基于Xilinx SDK完成双核并行任务分配、中断处理、同步机制与设备驱动模型等核心开发工作适合具备一定ARM与Linux驱动基础的中高级开发者参考实践。压缩包共1164个文件约29.92MB以254个h头文件、203个c源文件为主辅以Vivado工程v/vhdl文件、makefile构建脚本、tcl与xdc约束、bit与hdf硬件描述文件及elf可执行文件覆盖从硬件平台配置到驱动编译下载的完整链路。目前已有126人学习下载。资源内含初始化代码、驱动注册、设备操作函数与中断服务例程等模块可帮助读者理解双核AMP架构下的任务划分与核间通信思路并借助SDK调试工具完成源码级验证为嵌入式高性能方案提供可复用的工程参考。1. ZYNQ 7020 双核 AMP 到底在解决什么问题单核跑 Linux 时你肯定遇到过这种场景电机控制环路要求 50 微秒内必须响应但 Linux 调度器一抖动就是几百微秒PLC 协议栈的周期任务被内核抢占搞得时快时慢。ZYNQ 7020 这颗芯片给了你两个 Cortex-A9 硬核如果只跑一个 Linux另一个核闲着那真是浪费。dual_core_amp 要干的事就是让 CPU0 跑 Linux 处理网络、文件系统、HMI 这些“慢活”CPU1 裸跑或跑 RTOS 处理硬实时任务两边通过共享内存和中断通信。这套方案在工业伺服、电力保护、车载网关里非常常见SDK 驱动包通常包含裸核工程、Linux 侧内核模块、共享内存地址定义和中断配置。适合已经能跑通 ZYNQ 最小系统、想进一步榨干双核性能的嵌入式工程师。下面从选型、内存划分、SDK 工程搭建到联调排错一步步拆开讲。2. AMP 架构选型与 ZYNQ 7020 内存划分策略2.1 为什么选 AMP 而不是 SMPSMP 让 Linux 同时管理两个核任务可以在任意核上迁移好处是负载均衡坏处是实时性完全不可控。Linux 内核的 spinlock、调度延迟、中断线程化都会让一个“实时任务”的响应时间从微秒级跳到毫秒级。AMP 则是把两个核彻底分开各自跑独立的软件栈互不干扰。CPU1 上你写一个 while(1) 循环只要关掉中断响应时间就是确定的几十个时钟周期。代价是两边不能直接调用对方的函数必须通过共享内存和 IPI核间中断通信。常见做法是 CPU0 跑 Linux 负责非实时任务CPU1 跑裸机或 FreeRTOS 跑实时控制。选 AMP 的判断标准很简单如果你的任务有硬性 deadline且 deadline 小于 100 微秒就别犹豫直接 AMP。2.2 ZYNQ 7020 的地址空间怎么切ZYNQ 7020 的 DDR 通常挂 512MB 或 1GB两个核看到的是同一片物理内存。AMP 的关键是给两个核划分不重叠的区域。Linux 侧通过设备树 reserved-memory 节点预留一块物理地址连续的内存CPU1 的链接脚本把代码段、数据段、堆栈都放到这块区域里。典型划分如下区域起始地址大小用途Linux 系统内存0x00000000480MBLinux 内核、文件系统、应用共享内存0x1E00000016MB双向数据缓冲、环形队列CPU1 代码/数据0x1F00000016MB裸核程序、堆栈、全局变量CPU1 外设寄存器0xF8000000-直接映射不走 DDR共享内存放在 0x1E000000 是为了避开 Linux 的常规内存管理同时保证两个核的 MMU 配置都能访问。CPU1 的链接脚本里要显式指定 .text、.data、.bss 的加载地址和运行地址避免和 Linux 冲突。如果地址重叠现象是 Linux 启动到一半挂死或者 CPU1 跑飞调试起来非常痛苦。2.3 中断与 IPI 的分配两个核之间通知对方“数据写好了”靠的是软件生成中断SGI。ZYNQ 的 GIC 支持 16 个 SGI通常选 SGI 0 给 CPU0 发给 CPU1SGI 1 给 CPU1 发给 CPU0。Linux 侧用irqchip驱动注册 SGI 处理函数裸核侧直接操作 GIC 的 ICDSGR 寄存器。注意 SGI 的中断号是 0~15配置时不要和 PPI、SPI 搞混。另外共享内存的读写顺序要用内存屏障指令保证否则编译器优化和 CPU 乱序执行会让对方读到旧数据。3. SDK 驱动包结构解析与裸核工程搭建3.1 拿到 zip 包后先看什么一个典型的 dual_core_amp SDK 驱动包解压后通常包含这几个目录linux_driver/放内核模块源码和 Makefilebaremetal_cpu1/放 CPU1 的裸核工程shared_mem/放共享内存结构体定义的头文件dts/放设备树片段scripts/放编译和打包脚本。先别急着编译打开shared_mem/里的头文件看清楚共享内存的基地址、大小、数据结构布局。这个头文件是两个核共用的Linux 侧和裸核侧都 include 它保证结构体偏移一致。如果包里没有这个头文件或者两个核各自定义了一份那大概率会踩到对齐和字节序的坑。3.2 在 Xilinx SDK 里创建 CPU1 裸核工程打开 SDKFile → New → Application Project选择 CPU1OS Platform 选 standalone。模板选 Empty Application然后手动添加源文件。关键步骤是修改链接脚本lscript.ld把 DDR 的起始地址改成你划分给 CPU1 的区域。比如# 在 lscript.ld 中修改 MEMORY 段 MEMORY { ps7_ddr_0 : ORIGIN 0x1F000000, LENGTH 0x1000000 ps7_ram_0 : ORIGIN 0x00000000, LENGTH 0x30000 ps7_ram_1 : ORIGIN 0xFFFF0000, LENGTH 0xFE00 }ORIGIN 必须和 Linux 设备树里 reserved-memory 的 reg 属性完全一致LENGTH 不要超过预留大小。改完链接脚本后在main.c里初始化 GIC、注册 SGI 处理函数、初始化共享内存指针。裸核程序不要调用printf因为串口可能被 Linux 占用调试信息通过共享内存回传。3.3 共享内存数据结构设计共享内存里放什么直接决定通信效率。常见做法是定义一个环形队列加一个状态标志区// shared_mem.h #define SHM_BASE 0x1E000000 #define SHM_SIZE 0x1000000 typedef struct { volatile uint32_t head; volatile uint32_t tail; uint8_t buf[4096]; } ring_queue_t; typedef struct { volatile uint32_t cpu1_ready; volatile uint32_t cpu0_ready; ring_queue_t cmd_queue; // CPU0 - CPU1 ring_queue_t resp_queue; // CPU1 - CPU0 } shm_layout_t; #define SHM ((shm_layout_t *)SHM_BASE)volatile防止编译器把读写优化掉head和tail用uint32_t保证原子性。两个核各自只写自己的 head读对方的 tail避免竞争。队列满时 CPU0 可以轮询等待或直接返回错误取决于你的实时性要求。注意结构体里不要放指针因为两个核的虚拟地址映射可能不同指针值没有意义。4. Linux 侧内核模块与用户空间接口实现4.1 设备树里预留内存和注册中断Linux 侧第一步是在设备树里声明 reserved-memory告诉内核这块物理内存不要动reserved-memory { #address-cells 1; #size-cells 1; ranges; cpu1_shm: cpu1_shm1E000000 { reg 0x1E000000 0x1000000; no-map; }; };no-map表示内核不建立页表映射驱动里用ioremap自己映射。然后在驱动 probe 函数里解析这个节点拿到物理地址和大小。中断方面SGI 不需要在设备树里描述直接在驱动里调用irq_create_mapping或使用request_percpu_irq注册。注意 SGI 是 per-CPU 的要确保中断发到正确的核上。4.2 内核模块的字符设备接口用户空间要读写共享内存最直接的方式是注册一个字符设备实现read、write、ioctl。mmap也可以但需要把物理内存映射到用户空间安全性和可控性差一些。字符设备驱动里write把用户数据拷贝到共享内存的 cmd_queue然后触发 SGI 通知 CPU1read从 resp_queue 取数据如果队列空就阻塞等待或返回-EAGAIN。关键代码片段static ssize_t amp_write(struct file *filp, const char __user *buf, size_t len, loff_t *off) { shm_layout_t *shm (shm_layout_t *)amp_dev-shm_virt; uint32_t head shm-cmd_queue.head; uint32_t tail shm-cmd_queue.tail; uint32_t space sizeof(shm-cmd_queue.buf) - (head - tail); if (len space) return -ENOSPC; copy_from_user(shm-cmd_queue.buf[head % sizeof(shm-cmd_queue.buf)], buf, len); wmb(); // 写内存屏障保证数据先写入 shm-cmd_queue.head head len; amp_send_ipi(CPU1_IPI_NUM); // 触发 SGI return len; }wmb()不能省否则 CPU1 可能先看到 head 更新再看到数据读到脏数据。amp_send_ipi里写 GIC 的 ICDSGR 寄存器目标核选择 CPU1。4.3 用户空间测试程序驱动加载后/dev/amp0就是通信接口。写一个简单的测试程序发一条命令等 CPU1 回复int fd open(/dev/amp0, O_RDWR); char cmd[] GET_STATUS; write(fd, cmd, sizeof(cmd)); char resp[64]; int n read(fd, resp, sizeof(resp)); printf(CPU1 replied: %s\n, resp); close(fd);如果read一直阻塞检查 CPU1 是否收到了 SGI以及 CPU1 的 resp_queue 写入逻辑是否正确。可以在驱动里加printk打印 head/tail 的变化定位是发送失败还是接收失败。5. 联调避坑双核 AMP 调试中常见的 5 个翻车现场5.1 Linux 启动挂死串口无输出现象加载了 AMP 驱动或修改设备树后Linux 启动到 “Starting kernel ...” 就卡住。原因reserved-memory 的地址和大小与 CPU1 链接脚本不一致Linux 内核或根文件系统被加载到了 CPU1 的区域CPU1 一上电就跑飞把 Linux 的数据覆盖了。解决用dumpimage或readelf确认 CPU1 的 .text 段起始地址和/proc/device-tree/reserved-memory/下的 reg 属性逐字节对比。另外检查 U-Boot 的 bootargs 里有没有mem参数限制 Linux 可用内存范围。5.2 CPU1 收不到 SGI 中断现象Linux 侧write返回成功但 CPU1 的计数器不动。原因GIC 的 SGI 目标核配置错误或者 CPU1 没有使能中断。ZYNQ 的 GIC 在 CPU1 上电后需要初始化调用XScuGic_CfgInitialize并设置XScuGic_SetPriorityTriggerType。SGI 的触发类型必须是边沿触发优先级不要设成 0。解决在 CPU1 的 GIC 初始化代码里加一句XScuGic_Enable然后检查ICDIPTR寄存器里 SGI 对应的目标核位是否置位。5.3 共享内存数据错位或乱码现象CPU1 读到的命令字符串缺字符或完全对不上。原因两个核编译时结构体对齐方式不同或者编译器优化导致volatile读写顺序被重排。解决在共享内存头文件里加#pragma pack(1)强制单字节对齐所有共享变量声明为volatile写完后加dmb指令。另外确认两个核的字节序都是小端ZYNQ 的 A9 默认小端一般不用改。5.4 驱动加载时报 “Unknown symbol”现象insmod amp_driver.ko失败dmesg 显示Unknown symbol ioremap或Unknown symbol request_irq。原因内核模块编译时使用的内核头文件版本和运行的内核不一致或者 Makefile 里的KERNELDIR指向了错误路径。解决用uname -r确认运行内核版本然后make -C /lib/modules/$(uname -r)/build M$(pwd) modules重新编译。如果是交叉编译确保ARCHarm和CROSS_COMPILE设置正确。5.5 CPU1 跑一段时间后死机现象系统运行几分钟到几小时CPU1 无响应Linux 侧read超时。原因CPU1 的堆栈溢出或者共享内存队列的 head/tail 溢出回绕。裸核程序的堆栈大小默认可能只有几 KB递归调用或大局部变量会踩内存。解决在链接脚本里把_stack段调大到 16KB 以上队列的 head/tail 用uint32_t并定期检查差值超过缓冲区大小就复位。另外 CPU1 的看门狗要打开死机后自动复位。6. 用共享内存回传调试日志与性能验证裸核程序没有串口输出调试信息只能通过共享内存回传。我一般会在共享内存里单独划一个 4KB 的日志区CPU1 用snprintf把关键变量格式化进去Linux 侧用户程序定期读取并打印。这样既不影响实时性又能看到 CPU1 内部的运行状态。日志区的写入用环形方式覆盖旧数据避免写满后阻塞。性能验证方面最直接的指标是往返延迟。Linux 侧发一条命令CPU1 收到后立刻回一条Linux 侧记录时间差。用clock_gettime(CLOCK_MONOTONIC)测典型值在 20~50 微秒之间取决于 SGI 响应速度和共享内存拷贝量。如果超过 100 微秒检查是不是在中断处理里做了太多事情或者共享内存映射到了非缓存区域。把共享内存映射为ioremap默认是非缓存的每次读写都走总线速度慢。如果数据量小可以改用ioremap_cache或dma_alloc_coherent拿缓存内存但要注意缓存一致性写完加flush_cache或使用dma_sync_single_for_cpu。还有一个技巧在 CPU1 的 SGI 处理函数里翻转一个 GPIO用示波器测 Linux 写命令到 GPIO 翻转的时间这是最硬的延迟数据。我习惯在板子上留一个测试点每次调 AMP 都先量一下这个波形确认中断路径没有额外延迟。踩过几次坑之后现在拿到任何 AMP 方案第一件事就是看共享内存地址和链接脚本是否对齐第二件事就是量 SGI 延迟。希望帮到你。本文还有配套的精品资源点击获取