简单AMP：在两个Cortex-A9处理器上运行裸机系统

需积分: 50 156 浏览量 2018-01-15 10:15:29 上传评论 1 收藏 4.53MB PDF 举报

在处理这篇文章时，我们首先需要理解Zynq-7000 All Programmable SoC（系统芯片）以及它如何在双处理器上运行裸机程序。Zynq-7000 APSoC是Xilinx公司推出的一款高度集成的可编程系统芯片，它结合了ARM双核Cortex-A9 MPCore处理器和Xilinx 7系列FPGA逻辑单元。这种独特的架构允许开发者在一块芯片上实现高性能处理与自定义逻辑功能。了解Zynq-7000 APSoC中的两个Cortex-A9处理器可以配置为独立运行各自的软件栈或可执行文件是至关重要的。简而言之，Asymmetric Multiprocessing（非对称多处理，AMP）机制允许两个处理器在不紧密耦合的情况下运行自己的操作系统或裸机应用程序，通过共享资源实现松散耦合。在文章的上下文中，介绍了如何在双Cortex-A9处理器上搭建双系统，即CPU0和CPU1都运行裸机程序，然后进一步描述了一个更复杂的场景：CPU0运行Linux系统，而CPU1继续运行裸机程序。这是在AMP环境下配置Zynq设备的两种典型用途之一。文档中的“XAPP1079(v1.0.1)January24,2014”指的是Xilinx的应用说明编号和版本信息，这是产品支持的重要部分。该说明文件还提供了一个完整的设计项目文件集，允许设计者检查和重建设计，或者以此为模板开始新的设计。此外，还提供了预构建和预实施的目标文件，这些文件针对的是Zynq-7000 ZC702演示平台，设计者如果愿意，可以选择跳过复制硬件、软件或启动文件的步骤。文章中提到的“Xilinx Platform Studio (XPS)”是Xilinx公司早期推出的用于Zynq设备的集成开发环境（IDE），而“Xilinx Software Development Kit (SDK)”则是该IDE配套的软件开发套件，提供用于编写、编译和调试Zynq设备上运行的应用程序的工具。接下来，文章描述了设计概览，其中包括两个Cortex-A9处理器（CPU0和CPU1）的配置，以运行各自独立的裸机应用程序。在这个AMP示例中，CPU0上的裸机应用程序作为系统的主人，负责系统初始化，控制CPU1的启动，与CPU1和CPU0通信以及共享UART接口。UART（通用异步收发传输器）是计算机和设备之间常用的串行通信接口。简单来说，这种设计允许两个处理器在一个松耦合的架构中运行。为了防止两个CPU在共享的硬件资源上发生冲突，设计中采用了谨慎的资源分配方法。此外，文章还概述了如何创建启动解决方案和如何调试两个CPU。文档中提到的设计方法为开发者提供了一种方式来配置启动两个处理器，这样它们每个都能运行自己的裸机软件应用程序，并且每个处理器都能通过共享内存与另一个处理器进行通信。这种能力对于执行实时任务和管理独立任务来说是非常重要的，同时提供了更高的系统灵活性和性能。为了实现上述目标，设计者需要在两个处理器之间建立通信机制，这通常涉及硬件和软件的仔细配置。在硬件层面上，可能需要实现共享内存和其他通信机制，如中断控制器。在软件层面上，需要编写代码来初始化硬件，启动另一个处理器，并在处理器之间建立通信协议。这种双处理器设计的关键优势之一是提高了系统的可靠性，因为两个处理器可以互相监督。如果一个处理器失败或遇到问题，另一个处理器可以执行故障转移操作，以确保系统持续运行。总结来说，这篇文章向我们展示了一个通过裸机程序在Zynq平台上实现双Cortex-A9处理器独立工作的过程。它涉及到软件和硬件的配置、处理器间通信以及启动机制的实现，并考虑到了资源管理和故障处理。这一过程对于追求高性能、高可靠性和灵活配置的嵌入式系统开发者具有很高的参考价值。

资源推荐

资源详情

资源评论

XAPP1079 (v1.0.1) January 24, 2014 www.xilinx.com 1

in the United States and other countries. ARM and Cortex are trademarks of ARM in the European Union and other countries. All other trademarks are the property of their

respective owners.

Summary The Zynq®-7000 All Programmable SoC contains two Cortex®-A9 processors that can be

configured to concurrently run independent software stacks or executables. This application

note describes a method of starting up both processors, each running its own bare-metal

software application, and allowing each processor to communicate with the other through

shared memory.

Included

Systems

The design is created and built using Xilinx Platform Studio (XPS) 14.3 and includes software

built using the Xilinx Software Development Kit (SDK). A complete set of project files is

provided with this application note to allow the designer to examine and rebuild the design or

use the files as a template for starting a new design.

Pre-built and pre-implemented files targeting the Zynq-7000 ZC702 demonstration platform are

also provided if designer wants to skip the steps of reproducing hardware, software, or boot file

targets.

Introduction The Zynq-7000 AP SoC provides two Cortex-A9 processors that share common memory and

peripherals. Asymmetric multiprocessing (AMP) is a mechanism that allows both processors to

run their own operating systems or bare-metal applications with the possibility of loosely

coupling those applications via shared resources.

The reference design includes the hardware and software necessary to build a reference

design that runs both Cortex-A9 processors in an AMP configuration. Each CPU runs a

bare-metal application within its own standalone environment. Care has been taken to prevent

the CPUs from conflicting on shared hardware resources. This document also describes how to

create a bootable solution and how to debug both CPUs.

Design

Overview

In this reference design, each of the two Cortex-A9 processors (CPU0 and CPU1) is configured

to run its own bare-metal application. In this AMP example, the bare-metal application running

on CPU0 is the master of the system and is responsible for:

• System initialization

• Controlling CPU1 startup

• Communicating with CPU1

• Sharing the UART with CPU1

The bare-metal application running on CPU1 is responsible for:

• Communicating with CPU0

• Servicing interrupts from a core in the programmable logic (PL)

• Sharing the UART with CPU0

The Zynq SoC processing system (PS) includes resources that are private to each CPU and

shared by both CPUs. Care must be taken to prevent both CPUs from contending for these

shared resources when running the design in an AMP configuration. Refer to Zynq-7000 All

Application Note: Zynq-7000 AP SoC

XAPP1079 (v1.0.1) January 24, 2014

Simple AMP: Bare-Metal System Running on

Both Cortex-A9 Processors

Author: John McDougall

Design Overview

XAPP1079 (v1.0.1) January 24, 2014 www.xilinx.com 2

Programmable SoC Technical Reference Manual [Ref 1] for further information on shared

versus private resources. Though some of the approaches to managing these shared or private

resources are application specific, many of the resource management approaches used by this

reference design can fundamentally be reused as-is.

Examples of some of the private resources are:

• L1 cache

• Private peripheral interrupts (PPI)

• Memory management unit (MMU)

• Private timers

Examples of some of the shared resources are:

• Interrupt control distributor (ICD)

• DDR memory

• On-chip memory (OCM)

• Global timer

• Snoop control unit (SCU) and L2 cache

•UART0

In this example, CPU0 is treated as the master and controls the shared resources. If CPU1

were to require control of a shared resource, it would have to communicate the request to

CPU0 and let CPU0 control the resource. To keep the complexity of this reference design to a

minimum, the bare-metal application running on CPU1 has been modified to limit access to the

shared resources.

OCM is used by both processors to communicate to each other. When compared to DDR

memory, OCM provides very high performance and low latency access from both processors.

Deterministic access is further assured by disabling cache access to the OCM from both

processors.

Actions taken by this design to prevent problems with the shared resources include:

• DDR memory: CPU0 has only been made aware of memory at 0x00100000 to

0x001FFFFF. CPU1 uses memory from 0x00200000 to 0x002FFFFF for its bare-metal

application.

• L2 cache: CPU1 does not use L2 cache. L2 cache is a shared resource and CPU0 owns

this resource. If CPU1 used L2 cache, L2 cache flushes and invalidates would need to be

requested from CPU0 and CPU0 would exercise the action. It is beyond the scope of this

example design to include a communication channel that enables CPU1 to request L2

cache interactions.

• ICD: Interrupts from the core in PL are routed to the PPI controller for CPU1. By using the

PPI, CPU1 has the freedom to service interrupts without requiring access to the ICD.

• Timer: CPU1 uses a private timer.

• OCM: Accesses to OCM are handled very carefully by each CPU to prevent contention. A

single OCM address location is used as a flag to communicate between the two

processors. CPU0 initializes the flag to 0 before starting CPU1. When the flag is zero,

CPU0 owns the UART. When the flag is not zero, CPU1 owns the UART. Only CPU0 sets

the flag and only CPU1 clears it.

For demonstration purposes only, a custom embedded core included with this example design

is used to provide a simple interrupt source. An output from the ChipScope™ analyzer Virtual

Input/Output (VIO) core is connected to this core, enabling the user to generate interrupts

towards the PS at their leisure. Using the ChipScope analyzer VIO core provides more control

for when an interrupt occurs and therefore makes it easier to measure the latency of interrupts.

In a real-world design, however, this core would not exist. Instead, the interrupt would be

Design Overview

XAPP1079 (v1.0.1) January 24, 2014 www.xilinx.com 4

Software

The software can be broken down into three sections:

• First stage boot loader (FSBL)

• Bare-metal application for CPU0

• Bare-metal application for CPU1

FSBL

The FSBL always runs on CPU0 and is the first software application that is run after power-on

reset of the PS. The FSBL is responsible for programming the PL and copies both application

executable and linkable format (ELF) files to DDR memory. After loading the applications to

DDR memory, the FSBL then starts executing the first application that was loaded.

The version of FSBL included in the ISE® Design Suite 14.3 does not support multiple data or

ELF files. The current FSBL first looks for a bit file. If a bit file is found, the FSBL writes it to the

PL. Next, whether or not a bit file is found, the FSBL loads one application ELF into memory

and executes it. This operating sequence does not support such an AMP configuration, so the

FSBL must be modified.

Within this AMP example’s project files, the FSBL has been modified to continue searching for

files and loading them into memory until it detects a file that has a load address of

0xFFFFFFF0. Upon detection, the FSBL downloads this last file then jumps to the executable

address of the first non-bit or non-boot file found (which is the application for CPU0). For details

regarding how CPU1 starts up, refer to the Zynq-7000 All Programmable SoC Technical

Reference Manual [Ref 1].

Bare-Metal Application Code

The reference design has both CPU0 and CPU1 running their own bare-metal application code.

CPU0 is responsible for initializing shared resources and starting up CPU1.

The bare-metal board support package (BSP) named standalone_v3_07_a that is part of the

EDK 14.3 install includes support for the preprocessor defined constant USE_AMP. This

constant prevents the BSP from re-initializing the PS SCU that has previously been initialized

by CPU0. One caveat of using the USE_AMP constant is that the MMU mapping is adjusted to

create an alias of memory where the physical memory located at address 0x20000000 is

virtually mapped to 0x00000000. This remapping is done in the BSP boot file boot.S. The

re-mapping is not necessary for this design. A modified version of the BSP is included in the

reference design to remove the re-mapping when USE_AMP is set.

CPU0 Application

CPU0’s application is located in memory starting at address 0x00100000. The linker script is

used to set the starting address.

The CPU0 application does the following:

1. Configures the MMU to disable cache for OCM accesses in the address range of

0xFFFF0000 to 0xFFFFFFFF. The address mapping of the OCM is untouched, so OCM

exists at addresses 0x00000000 to 0x0002FFFF and addresses 0xFFFF0000 to

0xFFFFFFFF. Only the high 64 KB of OCM is used by the example design so cache is

disabled on addresses 0xFFFF0000 to 0xFFFFFFFF.

2. Initializes the ICD.

3. Starts CPU1.

4. Prints to the UART.

5. Sets a memory location in OCM that is used as a semaphore flag.

6. Waits for the memory location in OCM that is used as a semaphore flag to be cleared.

Reference Design

XAPP1079 (v1.0.1) January 24, 2014 www.xilinx.com 5

The CPU0 application repeats step 3 to step 6 indefinitely.

After the PS powers up and the internal boot ROM completes execution, CPU1 is redirected to

a small piece of code in OCM at 0xFFFFFE00. This piece of code is a continuous loop that

waits for an event, checks address location 0xFFFFFFF0 for a non-zero value, and then

continues the loop. If 0xFFFFFFF0 contains a non-zero value, CPU1 jumps to the fetched

address.

CPU0 starts CPU1 (both running bare-metal) by writing the value of 0x00200000 to address

0xFFFFFFF0 and then running the Set Event (SEV) command. SEV causes CPU1 to wake up,

read the value 0x00200000 from address 0xFFFFFFF0, and then jump to address

0x00200000. The FSBL is responsible for placing the CPU1 ELF at 0x00200000.

CPU1 Application

The CPU1 application is located in memory starting at address 0x00200000. The linker script

is used to set the starting address.

The CPU1 application performs the following:

1. Configures the MMU to disable cache for OCM accesses in the address range of

0xFFFF0000 to 0xFFFFFFFF. The address mapping of the OCM is untouched so OCM

exists at addresses 0x00000000 to 0x0002FFFF and addresses 0xFFFF0000 to

0xFFFFFFFF. Only the high 64 KB of OCM is used by this application note, so cache is

disabled on addresses 0xFFFF0000 to 0xFFFFFFFF.

2. Initializes the PPI interrupt controller and interrupt subsystem.

3. Waits for a memory location in OCM that is used as a semaphore flag to be set.

4. Prints to the UART. The string printed is chosen dependent on whether or not the interrupt

service routine incremented a global variable. If the global variable irq_count is not zero,

CPU1 sets the value to zero.

5. Clears the memory location in OCM that is used as a semaphore flag.

The CPU1 application repeats step 3 to step 5 indefinitely.

Inter-Processor Communication

The inter-processor communication in the example design is a semaphore flag. When the

semaphore is set, CPU1 owns the UART and when it is cleared by CPU1, CPU0 is free to use

the UART. This is a simple mechanism to share resources. The OCM memory is chosen

because it is a low latency, shared resource. Also, this area of OCM is not cached so the

memory accesses are deterministic.

If DDR memory were to be used for the semaphore, there would be a higher latency for

accesses during cache misses and less deterministic accesses due to background refresh

cycles. DDR memory accesses are also bursty in nature so time would be wasted as a write or

read burst occurs to access a single 32-bit value.

Reference

Design

The reference design files can be downloaded from:

https://secure.xilinx.com/webreg/clickthrough.do?cid=203247

The reference design matrix is shown in Tabl e 2.

Table 2: Reference Design Matrix

Parameter Description

General

Developer name John McDougall

剩余31页未读，继续阅读

评论收藏

内容反馈

飞鱼2085

粉丝: 2
资源: 9

简单AMP：在两个Cortex-A9处理器上运行裸机系统

ARM -cortex a9 Imx6 IAR裸机仿真调试

简单AMP：在ZYNQ SoC处理器上运行Linux和裸机系统

ucos2在cortex-a9上的移植

Cortex-A9 ARM 体系结构与接口技术

zynq7020（linux + 裸核流水灯）基于zturn board

cortex-A9官方手册

ARM Cortex A9处理器中文资料

ThreadX操作系统在ARM处理器上的移植

ARM裸机开发系列全套

ST cortex-A9 双核 MCU资料

AN319 – Using STM32MP1 Cortex-M with Keil MDK.pdf

ZYNQ双核AMP官方例程（双核分别跑Linux+裸机实现核间通信）

xapp1078-amp-linux-bare-metal 中文版

ZYNQ PL+PS双核AMP模式裸机烧写启动例程

适用于飞思卡尔IMX6UL系列CPU的专用交叉编译工具链，GCC版本5.4.0

Xilinx Zynq7000 嵌入式系统设计与实现 基于ARM Cortex A9双核处理器和Vivado的设计方法

Xilinx Zynq-7000 嵌入式系统设计与实现 基于ARM Cortex-A9双核处理器和Vivado的设计方法.pdf高清！！！！

Zedboard-XAPP1078双核实现文档

Zynq7000系列双核同时运行调试工程及文档说明

Altera Soc手册中文版-1硬核处理器系统的简介

巴克莱-美股-医疗保健行业-美国生命科学与诊断：AMP要点-7-34页.pdf

基于zedboard的双核AMP工程

zynq amp模式代码（基于官方1078、1079文档调试实现）

ARM Cortex-A9==ARM培训资料

uIP技术手册（1.0版本的）

xilinx-linux内核源码

基于KLD损失结合yolov7-tiny的旋转目标检测系统源码+详细使用说明+模型.zip

AMP Validator-1.3.0.zip

Altera版ARM DS-5工具包完美消除调试壁垒.pdf

最新资源

Xilinx Zynq7000 嵌入式系统设计与实现基于ARM Cortex A9双核处理器和Vivado的设计方法

Xilinx Zynq-7000 嵌入式系统设计与实现基于ARM Cortex-A9双核处理器和Vivado的设计方法.pdf高清！！！！