By Adam Taylor
In my last blog I introduced the concept of bare-metal Asymmetric Multiprocessing using both of the Zynq SoC’s ARM Cortex-A9 MPCore processors to execute bare metal programs. I hope you are sitting very comfortably as this blog may be a little long but by the end of it, we will have our AMP system up and running. While there are a few steps involved to get AMP up and running, it is actually very simple and straightforward process and certainly nothing to be afraid of.
The key aspect to getting AMP running on the Zynq SoC is a boot loader that looks for a second executable file after loading the first into the memory. Unfortunately the Vivado design suite I am using 2014.1 (I recently moved house and have no internet connection so have not been able to download the latest yet) does not support AMP when it generates an FSBL (first-stage boot loader). Therefore to get this example up and running I will be using the modified FSBL and modified standalone OS provided as part of Xilinx Application note XAPP1079. (The source files are available here http://www.xilinx.com/support/documentation/application_notes/xapp1079-amp-bare-metal-cortex-a9.pdf)
Having downloaded the zip file the first step is to extract the zipped files into your desired working directory and to rename the folder called SRC to design. These files contain both a modified FSBL and a modified, standalone OS. We need the SDK to be aware of these files so the next step is to update your SDK repository to make the SDK aware of their existence. Within SDK under the Xilinx tools menu, select repositories and then new, navigating to the directory location <your working directory>\app1079\design\work\sdk_repo as shown below:
Having added in the repositories the next stage is to generate the following :
We are going to generate a BSP (board support package) for each of these.
The first thing to do is create a new FSBL. Select file -> new application -> project, which enables us to create an FSBL project that supports AMP. This is no different to what we have done before, however we will be selecting the Zynq FSBL for AMP template in place of the of the Zynq FSBL template.
Following the creation of the AMP FSBL, we need to create the application for the first core. This again is very simple to do. We have done this many times before. Be sure to select Core 0 and the standalone OS and allow it to create its own BSP.
Once we have created this application we need to correctly define the location in DDR memory where the application will execute. To do this, we edit the linker script as below to show the DDR base address and size. This is important. If we do not correctly segment the DDR memory for Core 0 and Core 1 applications, we risk one inadvertently corrupting the other.
We can now write the application we wish to execute on Core 0. This is the core that will be in charge within the AMP system and it starts the execution of code on core 1. We will need to include the following section of code within the application. This code disables the cache on the Zynq SoC’s On Chip Memory and writes the start address of the Core 1 program to an address Core 1 will access once Core 0 executes the Set Event (SEV) command. The SEV command causes Core 1 to start executing its program.
The next step is to create a BSP for Core1. We want to use the modified standalone OS (standalone_amp), which prevents re-initialization of the PS Snoop Control Unit (SCU). Consequently, we cannot allow automatic generation of the BSP as we create the project like we did for Core 0. Be sure to select Core 1 in the CPU selection options.
Now that we have created the BSP for Core 1, we need to modify the settings of the BSP before we can progress to creating the application program we want to run on Core 1. This is very simple and requires the addition of an extra complier flag of –DUSE_AMP=1 to the configuration for drivers section of the BSP:
With this completed we are free to create the application for Core 1. Be sure to select Core 1 as the processor and use the BSP we just created:
Again, having created the new application, we need to again define the correct memory locations within the DDR memory from which the Core 1 program will execute. This is achieved by editing the linker script for the Core 1 application:
As with the first core within this application, we must also disable the cache on the On Chip Memory because we will be using this memory in later blogs to communicate between the two processors.
Once we have completed our applications and built the projects we should now be in possession of the following:
We now need a .bin file to enable the Zynq SoC to boot from your selected configuration memory. We also need a bif file, which defines the files to be used to create the bin file, and we need to define the order in which the files go.
Rather than use the created Zynq boot image within SDK we will be using an ISE command prompt and bat file provided as part of XAPP 1079 under directory\design\work\bootgen. This directory contains a bif file and a cpu1_bootvec.bin which is used as part of the modified FSBL to stop it from looking for more applications to load.
To generate the bin file, we copy the three generated ELF files to the bootgen directory and edit the BIF file to ensure the elf names within the bif file are correct.
We can now open an ISE command prompt, navigate to the bootgen directory, and run the createboot.bat, which will create the boot.bin file:
This file can then be downloaded into the non-volatile memory on your Zynq SoC. Booting the device will result in both cores starting and executing their respective programs.
In my next blog we will look a little more in detail into the software applications we just got running on the Zynq SoC’s two ARM Cortex-A9 MPCore processors.
Please see the previous entries in this MicroZed series by Adam Taylor: