Zynq7000系列双核同时运行调试工程及文档说明_zynq双核调试,xapp1079资源-CSDN下载

共3个文件

zip：2个

pdf：1个

1星需积分: 50 17 浏览量 2018-11-22 10:07:39 上传评论 3 收藏 18.42MB RAR 举报

《Zynq7000系列双核同时运行调试工程及文档详解》 Zynq7000系列是Xilinx公司推出的可编程系统芯片（Programmable System on Chip，PSoC），集成了高性能的ARM Cortex-A9双核处理器与可编程逻辑单元，为嵌入式设计提供了强大的计算能力和灵活的硬件定制能力。本教程主要围绕Zynq7000系列的双核同时运行调试展开，结合xapp1079-xapp1078这两个Xilinx官方应用笔记，深入探讨如何实现双核协同工作。一、Zynq7000架构与双核并行处理 Zynq7000系列的核心部分是由两个ARM Cortex-A9核心组成的处理系统（Processing System，PS），它们可以独立运行，也可以通过共享的存储器进行通信。这种架构允许开发者在一个系统中执行多任务，提高系统的并行处理能力。在调试过程中，理解双核之间的数据交互和任务分配至关重要。二、xapp1078-amp-linux-bare-metal.pdf 该文档是Xilinx应用笔记xapp1078的PDF版本，主要讨论了在Zynq7000平台上实现异步多处理（Asynchronous Multi-Processor，AMP）的裸机操作系统。裸机意味着不依赖于任何操作系统，直接在硬件层面上编写代码。文档详述了如何配置硬件、建立双核间的通信机制以及如何在两个CPU上部署和调试应用程序。三、Zynq7000系列xapp1078.zip 这个压缩包包含了xapp1078应用笔记的源代码和其他相关资源，为开发者提供了实际操作的平台。源码中通常包含示例程序，这些程序展示了如何在双核上实现并行执行，以及如何处理中断和同步问题。通过分析和修改这些代码，开发者可以深入理解Zynq7000的双核并行处理机制。四、Zynq7000系列双核同时运行调试－xapp1079-xapp1078.zip 此压缩包包含xapp1079-xapp1078联合调试的详细资料。xapp1079是xapp1078的补充，提供了更高级别的调试技巧和策略，如性能监控、错误检测和故障恢复等。结合这两个应用笔记，开发者可以学习到如何有效地调试和优化双核系统，确保系统在并发执行时的稳定性和效率。总结，Zynq7000系列双核同时运行调试是一项复杂但极具价值的任务，它涉及到系统架构的理解、双核通信机制的设计、并行程序的开发以及高效的调试技术。通过研读xapp1078-amp-linux-bare-metal.pdf文档，分析和实践Zynq7000系列xapp1078.zip及Zynq7000系列双核同时运行调试－xapp1079-xapp1078.zip中的源码和调试方法，开发者能够掌握在Zynq7000平台上构建和优化双核应用的关键技能。

资源推荐

资源详情

资源评论

收起资源包目录

Zynq7000系列双核同时运行调试及文档说明－xapp1079-xapp1078.rar （3个子文件）

zynq7000系列xapp1078.zip 9.46MB

Zynq7000系列双核同时运行调试－xapp1079-xapp1078.zip 6.36MB

xapp1078-amp-linux-bare-metal(2018-11-20 17.04.24).pdf 4.98MB

XAPP1078 (v1.0) February 14, 2013 www.xilinx.com 1

United States and other countries. ARM and Cortex are trademarks of ARM in the EU and other countries. All other trademarks are the property of their respective owners.

Summary The Zynq™-7000 All Programmable SoC contains two ARM® 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

operating system and application, and allowing each processor to communicate with the other

through shared memory.

Included

Systems

The design is created and built using the Xilinx Platform Studio (XPS) 14.3. The design also

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 in case the 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. CPU0 runs Linux and CPU1 runs a bare-metal application. 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 is configured to run its own

software. CPU0 is configured to run Linux and CPU1 is configured to run a bare-metal

application.

In this AMP example, the Linux operating system running on CPU0 is the master of the system

and is responsible for:

• System initialization

• Controlling CPU1’s startup

• Communicating with CPU1

• Interacting with the user

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

• Managing a “heart beat” that can be monitored by Linux on CPU0

• Communicating with Linux on CPU0

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

• Communicating interrupt events to Linux running on CPU0

Application Note: Zynq-7000 AP SoC

XAPP1078 (v1.0) February 14, 2013

Simple AMP Running Linux and Bare-Metal

System on Both Zynq SoC Processors

Author: John McDougall

本页已使用福昕阅读器进行编辑。

仅供试用。

Design Overview

XAPP1078 (v1.0) February 14, 2013 www.xilinx.com 2

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

and shared by both CPUs. In running the design in an AMP configuration, care must be taken

to prevent both CPUs from contending for these shared resources. Refer to Zynq-7000 All

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

private resources.

Examples of some of the private resources are:

• L1 cache

• Private peripheral interrupts (PPIs)

• 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

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:

1. DDR memory: Linux has only been made aware of memory at 0x00000000 to

0x2FFFFFFF. CPU1 uses memory from 0x30000000 to 0x3FFFFFFF for its bare-metal

application.

2. L2 Cache: CPU1 does not use L2 cache.

3. 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.

4. Timer: CPU1 uses the private timer for the heart beat.

5. OCM: Accesses to OCM are handled very carefully by each CPU to prevent contention. In

the case of the heart beat, only CPU1 writes the location and CPU0 reads the location.

When data is sent from CPU1 to CPU0, only CPU1 writes the data value, then CPU1 sends

a flag by setting a different address location in OCM. CPU0 in turn detects the flag, reads

the data, and then clears the flag. Only CPU1 can set the flag, and only CPU0 can clear the

flag.

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 VIO core provides more control over 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 and instead, the interrupt would be

sourced by a truly functional piece of logic in the PL such as a direct memory access (DMA)

engine.

本页已使用福昕阅读器进行编辑。

仅供试用。

Design Overview

XAPP1078 (v1.0) February 14, 2013 www.xilinx.com 3

Hardware

The PL contains a custom, embedded core connected to a synchronous output of a ChipScope

analyzer VIO core (Figure 1). The VIO core provides a mechanism for a user to interact with

hardware from ChipScope analyzer.

In this design, when the VIO generates a pulse, the custom core forwards an interrupt to the PS

Core1_nIRQ pin. The core is also connected to the PS master general purpose port

(M_AXI_GP0) through an AXI Interconnect, allowing both CPU0 and CPU1 access to the

control register within the core. CPU1 accesses the control register to clear the interrupt

request (IRQ) during the interrupt service routine. CPU0 can optionally use the control register

to create an interrupt towards CPU1. The Core1_nIRQ pin connects directly to CPU1’s PPI

block so there is no need to modify the configuration of the shared ICD. A ChipScope analyzer

AXI monitor core is also included and allows the user to measure the latency of the IRQ being

serviced.

Address Map

In the PL, there is a single irq_gen embedded core that contains a single control register. The

control register.

X-Ref Target - Figure 1

Figure 1: PL Block Diagram

Table 1: IRQ_GEN Control Register

Bit Access Description

[31:1] R/W Unused. Value written can be read.

[0] R/W

IRQ Asserted

• 0: IRQ is not asserted towards the PS.

• 1: IRQ is asserted towards the PS. If the VIO_IRQ_TICK

pin is asserted (by the VIO), this bit is set. Also, the CPU

can set this bit. Only the CPU can write this bit to clear it.

ILA

VIO

AXI Interconnect

Core1_nIRQ

M_AXI_GP0

Irq_gen

pcore

X1078_01_011513

Design Overview

XAPP1078 (v1.0) February 14, 2013 www.xilinx.com 4

Software

The software can be broken down into three sections:

• First stage boot loader (FSBL)

• Linux operating system and applications for CPU0

• Bare-metal operating system and application for CPU1

FSBL

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

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

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

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

However, the version of FSBL included in the ISE® Design Suite 14.3 does not support multiple

data or ELF files. The 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 and 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 Zynq-7000 All Programmable SoC Technical Reference

Manual [Ref 1].

Linux

The easiest way to use Linux in an AMP configuration is to configure Linux as symmetric

multiprocessing (SMP) but restrict the number of available CPUs to 1. Such an approach

ensures that Linux configures the ICD and SCU correctly for a multiple CPU environment.

To create the Linux kernel, U-Boot, device tree, and the root file system ramdisk, refer to the

wiki pages at http://wiki.xilinx.com

. All generated files are available as part of the project files

accompanying this application note.

To instruct Linux to use only one CPU for SMP, the bootargs in the device tree is modified to add

maxcpus=1. By default, the Linux .config is already setup to use SMP on the ZC702

demonstration board.

The device tree is also modified to reduce the amount of memory available to Linux to provide

untouched memory space for CPU1’s application.

Linux Applications

Two Linux applications that run on CPU0 are provided to interact with CPU1 that is running the

bare-metal application. The first application, rwmem, provides a simple memory read and write

access from Linux to OCM. This rwmem application is used to peek and poke addresses in

OCM. As specific address locations are changed, CPU1 detects the changes and interacts in

a specific way. The second application, softUart, provides a UART-style communication

between Linux running on CPU0 and bare-metal running on CPU1 through predefined memory

locations in OCM.

After the PS powers up and the internal boot ROM completes execution, CPU1 will have been

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 will jump to the

fetched address.

本页已使用福昕阅读器进行编辑。

仅供试用。

Design Overview

XAPP1078 (v1.0) February 14, 2013 www.xilinx.com 5

CPU0 (running Linux) starts CPU1 (running bare-metal) by writing the value of 0x30000000 to

address 0xFFFFFFF0 using the included rwmem application. Normally, CPU0 would need to

run a set event (SEV) command to wake up CPU1. Because Linux, running on CPU0, is

constantly servicing interrupts (another source of events), an SEV command is not necessary.

When CPU1 wakes up, it reads the value 0x30000000 from address 0xFFFFFFF0 (written

using the rwmem command) and then jumps to address 0x30000000. Note that the FSBL

placed CPU1’s ELF at 0x30000000.

The softUart application, which is also included in the design files, is run as a background task

in Linux. When running, softUart continuously monitors shared OCM memory at locations

0xFFFF9000 (COMM_TX_FLAG_OFFSET) and 0xFFFF9004 (COMM_TX_DATA_OFFSET).

Whenever a 1 is present at COMM_TX_FLAG_OFFSET, softUart reads the value found at

COMM_TX_DATA_OFFSET and temporarily stores the value in a string array. When a value of

0x0A (\n) is received, the string array is displayed on STDOUT. Every time softUart reads a

value from COMM_TX_DATA_OFFSET, it clears the COMM_TX_FLAG_OFFSET content. This

clear signals to CPU1 that another character can be sent towards the softUart application

running on Linux.

Bare-Metal Application Code

The reference design has CPU1 running bare-metal application code. Linux, running on 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 define 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 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.

Within this AMP reference design, no Zynq UARTs are used by the bare-metal application.

Instead, the application running on CPU1 contains its own outbyte() function that is used to

communicate via OCM to a software UART running in a Linux application on CPU0. By adding

the outbyte() function, all stdout functionality of the standalone BSP is intact, allowing functions

such as xil_printf() to be used.

To prevent shared resource conflicts, the bare-metal application running on CPU1 must be

careful not to access resources such as the SCU. Linux disables cache access to the OCM.

However, the default standalone BSP would attempt to enable cache for OCM and therefore

conflict with Linux. When used in an AMP configuration, the function XIL_SetTlbAttributes() is

used in the CPU1’s main() application function to disable cache on OCM. The

XIL_SetTlbAttributes() function has been modified in the included source code such that it only

flushes L1 cache and leaves L2 cache untouched to prevent access to the SCU where L2

cache is controlled.

If the bare-metal code running on CPU1 requires control of L2 cache, a communications

channel must be created allowing the bare-metal code to request Linux to make the necessary

changes to the SCU. This action is beyond the scope or requirement for this example design so

care has been taken to prevent SCU access directly from the bare-metal code.

CPU1 Application

CPU1’s application is located in memory starting at address 0x30000000. The linker script is

used to set the starting address.

CPU1’s 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–0x0002FFFF and addresses

本页已使用福昕阅读器进行编辑。

仅供试用。

评论收藏

内容反馈

Tristone1217

2019-05-21

不太好不是我想要的

_Embedded_Soft

粉丝: 36

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

zynq 交叉调试说明

7系列zynq7000系列说明文档.zip

zynq7000双核AMP工程

ZYNQ_7000系列开发文档

Zynq7000系列之Zynq7000系列引脚功能综述.doc

xapp1079.zip

Zedboard-XAPP1078双核中文详细教程

xapp1078_2014.4_zybo:xapp1078的zybo实现，这是zynq的AMP示例。 CPU 0运行linux，CPU1运行裸机

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

使用VIvado14.1SDK配置ZYNQ7000双核无操作系统通讯

ZYNQ7000系列选型的依据及优势（中文版）

Zynq7000网络驱动调试笔记

Zynq7000系列PS部分各模块驱动（UART，FLASH，SD卡等）

ZYNQ7000 Partial Reconfiguration.docx

xapp1097 文档及工程

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

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

ZYNQ 7020 UART0 串口程序，全工程文件，可以直接使用

基于 ZYNQ 7020 的 FPGA + ARM 开发

ZYNQ-7000系列所有型号PFGA管脚分配表

Altium Zynq7000.zip

FPGA_Zynq7000AP_SoC_IEEE1588_PTP_design

ZYNQ7000烧写程序流程

zynq 7000详细手册

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

Zedboard-XAPP1078双核实现文档

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

xapp1167.zip

程序员必读的30本书

变量和属性的区别

最新资源

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

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