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 ==
Updated for BELK 2.0.0 release
|-
|12.70.0
|September 2015
|[[Bora_Embedded_Linux_Kit_(BELK)#BELK_software_components|3.0.0]]
|Migration to BELK 3.0.0<br>Added support for BoraX
|-
|}
== 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].
Two different examples are here provided. The first one – HelloWorld – shows basic functionalities while the second – RPMsg-based application – exploits more sophisticated techniques to handle inter-processors communication and synchronization. This latter configuration is based on RPMsg mechanism as described in Xilinx document UG978 (v2013.04, April 22, 2013).
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) version 2.0.0]].* BORA FreeRTOS repository (please refer to section TBD[[#Importing the FreeRTOS repository into the SDK]]).
===Building the software components===
====Vivado project====
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]]
Once the build process is completed, the executable file in .elf format will be generated (we suggest to name it freertos). Creating the .bin file is <u>not required</u>.
* Project name: <code>RPMsg_freeRTOS</code>* Hardware Platform: <code>hw_platform_0</code>* Processor: <code>ps7_cortexa9_1</code>* OS Plaftorm: <code>freertos_zynq</code>* Language: <code>C</code>* Board Support Package: <code>Create New</code>* Type: <code>FreeRTOS Latency AMP</code>To run this example, Linux kernel (1) {{efn|The kernel branch must be <code>bora</code>.}} must be rebuilt too {{efn|It is assumed that the development environment is already set up as described [[Build_system_(2BELK)|here]].}}. First of all copy the freertos executable file in .elf format (<code>freertos</code>) into the directory firmware of Linux kernel tree (3){{efn|The name of the binary file copied into the firmware directory must be <code>freertos</code>.}}. Then configure the kernel using <code>bora_amp_defconfig</code> as configuration file and enter the following command line, that changes the default load address of kernel and launches the building of both the kernel image and the modules:
<pre>
bash# make UIMAGE_LOADADDR=0x10008000 uImage modules
For further details on kernel modules, please refer to this [http://tldp.org/HOWTO/Module-HOWTO/ link].
===Linux Device Tree===
The Flattened Device Tree (FDT) is a data structure for describing the hardware in a system (for further information, please refer to http://elinux.org/Device_Tree). Both Example #1 and Example #2 requires some modifications to the standard Bora device tree (to initialiaze UART0 port and to properly initialize the RPMsg infrastructure, respectively). Please use the kernel branch <code>bora</code>, that already includes the aforementioned patches (for further details, please refer to the <code>arch/arm/boot/dts/bora.dts</code> file and commit descriptions on the Linux git repository). For detailed instructions on how to build the Linux kernel and the Device Tree, please refer to the [[Bora_Embedded_Linux_Kit_(BELK)#BELK_software_components|BELK Quick Start Guide TBD]].
===Running the demo applications===
====Example #1: HelloWorld application====
This section describes how to run freeRTOS HelloWorld example application on BORA using AMP (Linux + FreeRTOS). Plese follow the steps listed below:
* Place all the binary files into the host tftp directory:
** Kernel {{efn|The kernel must be built with the <code>UIMAGE_LOADADDR 0x8000</code> option. Please refer to [[Building_Linux_kernel_(1BELK)|this page]] for more details.}}: <code>uImage</code>
** Device Tree: <code>bora.dtb</code>
** First stage bootloader: <code>bora_FSBL.bin</code>
</pre>
* Reset the board to reboot with the new FSBL
* Add the following U-Boot environment variables (2):
<pre>
setenv addcons 'setenv bootargs ${bootargs} console=${console},115200n8 cma=16M debug maxcpus=${nr_cpus}'
setenv fpga_file BELK/bora_design_wrapper.bin
</pre>
<pre>
run net_nfs
</pre>
====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:
** KernelLinux kernel: <code>uImage</code>** Device Tree: <code>bora.dtb</code>** First stage bootloader: <code>bora_FSBL.bin</code>** FPGA bitstream: <code>bora_design_wrapper.bin</code>** FreeRTOS application: <code>freertos</code>
* Start the Bora system
* From the U-Boot shell, update the FSBL with the following commands:
</pre>
* Reset the board to reboot with the new FSBL
* Add the following U-Boot environment variables (1) (2please 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'
setenv fpga_file BELK/bora_design_wrapper.bin
</pre>
**: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 #1* Boot the system running the following command: <code>run net_nfs</code>
When booting, the Linux kernel will print out the following message to indicate it has been relocated to address 0x10000000:
</pre>
Linux kernel will print these messages, informing that the communication between the two cores has been established:
<pre>
[ 17.966158] NET: Registered protocol family 41
[ 18.036698] CPU1: shutdown
[ 18.124417] virtio_rpmsg_bus virtio0: creating channel rpmsg-timer-statistic addr 0x50
[ 18.151586] rpmsg_freertos_statistic rpmsg0: new channel: 0x400 -> 0x50!
</pre>
Then run the <code>latencystat</code> application as shown below. The typical output will look like this:
<pre>
</pre>
==Advanced debugging techniques for AMP Linux+FreeRTOS configuration==
===Introduction===
[[File:AN-BELK-001_10.png|600px|thumb|center]]
The SYnch settings are reported below:
* ''<code>Connect''</code>
** Establish a connection to the debugger attached to the defined communication port(s). Several debuggers ports can be specified, separated by space.
* ''<code>MasterGo ON''</code>
** If the program execution is started, the program execution for all other processors which have SlaveGo ON is also started.
* ''<code>MasterBrk ON''</code>
** If the program execution is stopped, the program execution for all other debuggers which have SlaveBrk ON is also stopped.
* ''<code>MasterStep ON''</code>
** If an asm single step is executed, all processors which have SlaveStep ON will also asm single step.
* ''<code>MasterSystemMode ON''</code>
** Invite other TRACE32 instances to perform system mode changes synchronously. System mode changes are typically performed by the commands SYStem.Mode <mode>
* ''<code>SlaveGo ON''</code>
** The program execution is started, if a processor with MasterGo ON starts its program execution.
* ''<code>SlaveBrk ON''</code>
** The program execution is stopped, if a processor with MasterBrk ON stops its program execution.
* ''<code>SlaveStep ON''</code>
** A asm single step is performed, if a processor with MasterStep On performs an asm single step.
* ''<code>SlaveSystemMode ON''</code>
** Synchronize with system mode changes in connected TRACE32 instances.
&core1 SYStem.CONFIG.CTI.Config CORTEXV1
</pre>
===Setting up the Linux debug configuration===
The symbolic information is useful for HLL debugging, or setting breakpoints, stepping through the code, viewing variables, and many other aspects of debugging. The compiler must be configured in order to generate debug symbols. The vmlinux file for the running kernel must be available, in order to load the kernel debug symbols.
|-
|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}}
