Bureaucrats, dave_user, Administrators
8,154
edits
Changes
no edit summary
{{Applies To Bora}}
{{Applies To BoraX}}
{{AppliesToBORA_AN}}
{{AppliesToBORA_Xpress_AN}}
{{InfoBoxBottom}}
{{WarningMessage|text=This application note was validated against specific versions of the kit only. It may not work with other versions. Supported versions are listed in the ''History'' section.}}
== History ==
== Introduction ==
This application note describes how to build the software components required to set up asymmetric multi-processing (AMP for short) configuration required to run Linux OS on the first Cortex-A9 core (also denoted as core #0) and FreeRTOS on the second Cortex-A9 core (also denoted as core #1) of the Zynq SOC.
Asymmetric Multiprocessing (AMP) allows a multiprocessor/multicore system to run multiple Operating Systems (OS) that are independent of each other. In other words, each CPU has its own private memory space, which contains the OS and the applications that are to run on that CPU. In addition, there can be some shared memory space that is used for multiprocessor communication. This is contrasted with Symmetric Multiprocessing (SMP), in which one OS runs on multiple CPUs using a public shared memory space. Thanks to AMP, developers can use open-source Linux and FreeRTOS operating systems and the RPMsg Inter Processor Communication (IPC) framework between the Zynq's two high-performance ARM® Cortex™-A9 processors to quickly implement applications that need to deliver deterministic, real-time responsiveness for markets such as automotive, industrial and others with similar requirements. For further information, please refer to this [http://www.wiki.xilinx.com/Multi-OS+Support+%28AMP+%26+Hypervisor%29 link].
A notable application where AMP configuration has been leveraged is described [[BRX-WP002:_Non-intrusive_continuous_multi-gigabit_transceivers_link_monitoring|here]].
PDF version of this Application Note can be downloaded [httphttps://www.dave.eu/siteslinks/defaultp/files/files/an-belk-001-amp-linux-freertos.pdf j1KrvnU3fd8PeCvX here].
==AMP on Bora==
* Vivado® Design Suite version 2013.3 with Xilinx SDK (Webpack license is minimum requirements)
* Python 2.7.x (C:\Python27 must be the installation directory on Windows)
* TBD [[Bora_Embedded_Linux_Kit_(BELK)#BELK_software_components|Bora Embedded Linux Kit version 2.0.0]] (BELK for short). Please refer to BELK Quick Start Guide for further details.
* BORA FreeRTOS repository (please refer to section [[#Importing the FreeRTOS repository into the SDK]]).
===Building the software components===
export PROJ_DIR=$(pwd)/../bora-build-YYYYMMDD-nobk
</pre>
Configure Vivado settings (1){{efn|In a 32 bit system, Vivado settings are configured with the following command <code>/opt/Xilinx/Vivado/2013.3/settings32.sh</code>.}}:
<pre>
. /opt/Xilinx/Vivado/2013.3/settings64.sh
</pre>
Launch Vivado with <code>build_project</code> script (2){{efn|Passing the <code>-tclargs "-bitstream"</code> parameters allows for automatic building of the FPGA bitstream.}}:
<pre>
vivado -mode tcl -source build_project.tcl -notrace -tclargs "-bitstream"
</pre>
====FSBL====
Once the Vivado project build is completed, the hardware configuration can be exported starting the SDK to build the FSBL. From the SDK GUI:
* JP17.4 – UART0_TX
* JP17.6 – UART0_RX
Please follow the steps listed below to build a HelloWorld application that prints a message on UART0 (via EMIO) on FreeRTOS running on Bora core #21.
* From the SDK GUI, create e new application project:
[[File:AN-BELK-001_01.jpg|600px|thumb|center]]
**:this is a brief description of these variables
***<code>program_fpga</code>: Loads FPGA binary from TFTP and programs the bitstream
***<code>load_freertos</code>: Loads freertos application binary from TFTP and writes application start address for core #2 1
***<code>mem=${kernel_memory}</code>: sets maximum kernel memory (1008M = 1024M - 16M)
***<code>maxcpus=${nr_cpus}</code>: sets maximum Linux cores to 1
====Example #2: RPMsg-based application====
As stated before, this example shows a more sophisticated approach that allows for:
* using a standardized communication channel between the two cores(RPMsg)
* exploiting a standardized mechanism to load the firmware of second core.
This approach determines a different initialization process with respect to example #1. In this case the initialization sequence is:
#linux kernel boots, enabling and using both cores
#RPMsg and virtio drivers (compiled as modules) are loaded
#core #1 is released
#FreeRTOS binary image is loaded
#core #1 is started.
In other words, boot process of core #1 is under the control of the Linux o.s. In principle this allows a dynamic use of the core #1 that can be allocated for FreeRTOS application only when it is actually needed.
The example performs IRQ latency measurements on FreeRTOS side by using a hardware timer. These measures are collected by the counterpart application running on Linux side and shown on console. Plese follow the steps listed below:
* Place all the binary files into the host tftp directory:
</pre>
* Reset the board to reboot with the new FSBL
* Add the following U-Boot environment variables{{efn|Please (please note that, when using the RPMsg mechanism, it's not required to set the <code>maxcpus=${nr_cpus}</code> variable.}}):
<pre>
setenv addcons 'setenv bootargs ${bootargs} console=${console},115200n8 cma=16M debug'
**:this a brief description of these variables
***:<code>program_fpga</code>: Loads FPGA binary from TFTP and programs the bitstream
***:<code>load_freertos</code>: Loads freertos application binary from TFTP and writes application start address for core #21
* Boot the system running the following command: <code>run net_nfs</code>
|-
|Bora Hardware Manual
|http[https://www.dave.eu/siteslinks/defaultp/files/files/bora-hm.pdf856kxHzE3c5Y5Y05 BORA HM]
|-
|BoraEVB page on DAVE Embedded Systems Developers Wiki
update_h=sf probe 0 0 0;sf erase ${header_base} 0x40000;sf write ${loadaddr} ${header_base} 0x40000
</pre>
-----
{{notelist}}
