超过460,000+ 应用技术资源下载
pdf

简单的放大器运行Linux在Zynq SoC处理器的裸机系统

  • 1星
  • 日期: 2018-07-01
  • 大小: 5.43MB
  • 所需积分:1分
  • 下载次数:0
  • favicon收藏
  • rep举报
  • 分享
  • free评论
标签: LinuxSOC放大器处理器

Simple AMP Running Linux and Bare-Metal System on Both Zynq SoC Processors,在Xilinx的FPGA上面运行AMP双系统!

文档内容节选

Application Note Zynq7000 AP SoC Simple AMP Running Linux and BareMetal System on Both Zynq SoC Processors Author John McDougall XAPP1078 v10 February 14 2013 Summary Included Systems Introduction The Zynq7000 All Programmable SoC contains two ARM CortexA9 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 ea......

Application Note: Zynq-7000 AP SoC Simple AMP Running Linux and Bare-Metal System on Both Zynq SoC Processors Author: John McDougall XAPP1078 (v1.0) February 14, 2013 Summary Included Systems Introduction 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. 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. 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: (cid:129) (cid:129) (cid:129) (cid:129) System initialization Controlling CPU1’s startup Communicating with CPU1 Interacting with the user The bare-metal application running on CPU1 is responsible for: (cid:129) Managing a “heart beat” that can be monitored by Linux on CPU0 (cid:129) (cid:129) (cid:129) Communicating with Linux on CPU0 Servicing interrupts from a core in the programmable logic (PL) Communicating interrupt events to Linux running on CPU0 © Copyright 2013 Xilinx, Inc. Xilinx, the Xilinx logo, Artix, ISE, Kintex, Spartan, Virtex, Vivado, Zynq, and other designated brands included herein are trademarks of Xilinx in the 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. XAPP1078 (v1.0) February 14, 2013 www.xilinx.com 1 Design Overview 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 (cid:129) (cid:129) Private peripheral interrupts (PPIs) (cid:129) Memory management unit (MMU) (cid:129) Private timers Examples of some of the shared resources are: Interrupt control distributor (ICD) DDR memory (cid:129) (cid:129) (cid:129) On-chip memory (OCM) (cid:129) Global timer (cid:129) 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. XAPP1078 (v1.0) February 14, 2013 www.xilinx.com 2 Design Overview 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. X-Ref Target - Figure 1 ILA VIO Irq_gen pcore Core1_nIRQ PS AXI Interconnect M_AXI_GP0 Figure 1: PL Block Diagram X1078_01_011513 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 register is located at BASE + 0 (0x78600000). Table 1 contains a description of the IRQ_GEN control register. Table 1: IRQ_GEN Control Register Bit [31:1] Access Description R/W Unused. Value written can be read. [0] R/W IRQ Asserted (cid:129) 0: IRQ is not asserted towards the PS. (cid:129) 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. XAPP1078 (v1.0) February 14, 2013 www.xilinx.com 3 Design Overview Software The software can be broken down into three sections: (cid:129) (cid:129) (cid:129) 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. XAPP1078 (v1.0) February 14, 2013 www.xilinx.com 4 Design Overview 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 XAPP1078 (v1.0) February 14, 2013 www.xilinx.com 5
更多简介内容

评论


个人中心

意见反馈

求资源

回顶部

下载专区


TI最新应用解决方案

工业电子 汽车电子 个人电子

搜索下次设计所需的
TI 器件

● 目前在售器件有45,000款
● 6.99美元标准运费,不受时间和地点限制
● 无最低起订量要求

About Us 关于我们 客户服务 联系方式 器件索引 网站地图 最新更新 手机版

EEWorld电子技术资料下载——分享有价值的资料

北京市海淀区知春路23号集成电路设计园量子银座1305 电话:(010)82350740 邮编:100191

电子工程世界版权所有 京ICP证060456号 京ICP备10001474号 电信业务审批[2006]字第258号函 京公海网安备110108001534 Copyright © 2005-2018 EEWORLD.com.cn, Inc. All rights reserved
$(function(){ var appid = $(".select li a").data("channel"); $(".select li a").click(function(){ var appid = $(this).data("channel"); $('.select dt').html($(this).html()); $('#channel').val(appid); }) })