Changes

Jump to: navigation, search
no edit summary
|April 2018
|2.1.0
|Updated info for command erroswiki version
|}
Core #0:
* takes care of boot process
* once Linux gets control of processor, initializes core #1 in SMP mode
* stops core #1 and switches it to AMP mode
* loads binary image of FreeRTOS that is then executed by core #1
=== Inter-core communication ===
● takes care of boot process
● once Linux gets control of processor, initializes core #1 in SMP mode
● stops core #1 and switches it to AMP mode
● loads binary image of FreeRTOS that is then executed by core #1
Inter-core communication is based on RPMsg framework2. The adoption of a standardized and mainlined protocol improves dramatically the portability and the maintainability of the application code.
== XELK platform ==
AXEL Embedded Linux Kit (XELK for short) provides all the necessary components required to set up the developing environment for:
* building the second stage bootloader (U-Boot)* building and running Linux operating system on AXEL-based systems* building Linux applications that will run on the target
DAVE Embedded Systems provides all the customization required (in particular at bootloader and Linux kernel levels) to enable customers use the standard i.MX6 development tools for building all the firmware/software components that will run on the target system.
Please refer to the XELK Quick Start Guide for further details on XELK.
 
<b>N.B.: </b>this application note has been tested using XELK 2.0.0.
=== Prerequisities ===
* AXEL Embedded Linux Kit (please refer to XELK Quick Start Guide for further details) version 2.0.0* access to AXEL git repositories (see below)* an <code>arm-none-eabi-</code> toolchain for building FreeRTOS
=== Software components git repositories ===
The software components for this application note are provided as git repositories, so the user can immediately get access to the source trees and keep these components in sync and up to date with DAVE Embedded Systems repositories.
Assuming that a local repository has not been created, clone the remote AMP git repository: * cloning the <code>linux</code> git repository:<pre class="board-terminal">dvdk@dvdk:~/xelk$ git clone git@git.dave.eu:dave/axel/linux-2.6-imx.git</pre> * cloning the <code>FreeRTOS</code> repository:<pre class="board-terminal">dvdk@dvdk:~/xelk$ git@git.dave.eu :dave/axel/freertos.git</pre> * cloning the <code>latencystat</code> repository:<pre class="board-terminal">dvdk@dvdk:~/xelk$ git@git.dave.eu :dave/axel/latencystat.git</pre> == Building the software components ===
The following paragraphs describe how to build the software components required for this application. Please note that:
* the standard Linux infrastructure will be used to load the firmware for the second core Linux will start in SMP mode, running on both cores; then CPU1 will be shutdown and freeRTOS firmware
will be loaded and run
● The * the GPIO7_13 pin (JP10.9 of the AXEL EVB-LITE) is toggled during the ISR● The * the EIM_D19 signal (available on the R5 resistor on the AXEL EVB-LITE) is the output of the EPIT1 (which is the interrupt source)
The FreeRTOS application programs the EPIT1, which uses 66MHz as time-base (prescaler=1), setting FFFF.FFFF - 0x000F.4240 (1k tick) as the compare value. The timer starts a countdown from 0xFFFF.FFFF and, as it reaches the compare value, it triggers the ISR and toggles the EIM_D19 pin.
The ISR counts the number of ticks after the compare value and saves that information to return it to the Linux application for the histogram calculation.
 
== Downloading,configuring and building ==
 
Assuming that a local repository has not been created, clone the remote AMPgit repository (the <code>-b</code> option is used to automatically checkout the current branch):
 
<pre>
dvdk@dvdk:~/xelk$ git clone git@git.dave.eu:dave/axel/linux-2.6-imx.git
</pre>
* Enter the git directory
* Switch to AMP branch:
<pre>
dvdk@dvdk:~/xelk/linux-2.6-imx$ git checkout axel-feat-2.1.0-amp
</pre>
=== Build the Linux kernel ===
 
Set the correct environment '''sourcing''' the iMX6 toolchain:
<pre class="board-terminal">
dvdk@dvdk:~/xelk$ source env.sh
</pre>
Enter the <code>linux</code>directory and checkout the <code>amp-feat-2.1.0-amp</code> branch:<preclass="board-terminal">dvdk@dvdk:~/xelk/linux-2.6-imx$ source envgit checkout axel-feat-2.1.sh 0-amp
</pre>
Select the '''Axel''' board configuration:
 <preclass="board-terminal">
dvdk@dvdk:~/xelk/linux-2.6-imx$ make imx_v7_axel_defconfig
</pre>
build To run this example, Linux kernel must be rebuilt. Thus configure the Linux kernel using '''imx_v7_axel_defconfig''' as configuration file and enter the following command line, that changes the default load address of kernel and launches the XELK-L-S building of the kernel and device treeimages and the kernel modules:
<preclass="board-terminal">
dvdk@dvdk:~/xelk/linux-2.6-imx$ make UIMAGE_LOADADDR=0x18008000 imx6q-xelk-l.dtb uImage modules
</pre>
=== Build FreeRTOS ===The file arch/arm/boot/uImage is the binary image of the kernel that must be used to boot the system, together with the file arch/arm/boot/dts/imx6q-xelk-l.dtb, which is the binary image of the device tree with the XELK hardware configuration.
Clone The following kernel modules, resulting from the FreeRTOS repository and kernel build procedure, must be copied from the real-time OSbuilding directory to the root file system (usually into /lib/modules/<kernel version>/kernel, but any other directory can be used):
<pre>
dvdk@dvdk:~ LD [M] drivers/xelk$ git@gitremoteproc/remoteproc.daveko LD [M] drivers/remoteproc/mx6_remoteproc.eu :daveko LD [M] drivers/axelrpmsg/freertosrpmsg_freertos_statistic.gitkodvdk@dvdk:~ LD [M] drivers/rpmsg/xelk$ cd freertosvirtio_rpmsg_bus.ko LD [M] drivers/virtio/virtio.ko LD [M] drivers/virtio/virtio_ring.ko
</pre>
=== Build FreeRTOS ===
For building the FreeRTOS, a proper toolchain has to be used:
 <preclass="board-terminal">dvdk@dvdk:~/xelk$ cd freertos
dvdk@dvdk:~/xelk/freertos$ export PATH=<path to arm-eabi toolchain>/bin:$PATH
dvdk@dvdk:~/xelk/freertos$ export ARCH=arm
and then run <code>make</code> to build the RTOS binary image:
</pre> <pre class="board-terminal">
dvdk@dvdk:~/xelk/freertos$ make
</pre>
 
=== Building latencystat ===
 Just clone, enter Enter the <code>latecystat</code> directory and build with '''make''': <preclass="board-terminal">dvdk@dvdk:~/xelk$ git@git.dave.eu :dave/axel/latencystat.git
dvdk@dvdk:~/xelk$ cd latencystat
dvdk@dvdk:~/xelk/latencystat$ make
=== Running the AMP on the target ===
As stated before, this example shows a sophisticated approach that allows for:
* using a standardized communication channel between the two cores
* exploiting a standardized mechanism to load the firmware of second core
move the device tree binary load address (the default 0x18000000 conflicts the AMP kernel loadaddr, it must be moved to The example performs IRQ latency measurements on FreeRTOS side by using a higher address) hardware timer. These measures are collected by changing u-boot environment for example as:the counterpart application running on Linux side and shown on console.
Move the device tree binary load address (the default 0x18000000 conflicts the AMP kernel loadaddr, it must be moved to a higher address) by changing u-boot environment for example as:
<pre>
=> setenv fdtaddr 0x1c000000
</pre>
 
Once all the components are built, please boot the system and launch the following commands:
<pre class="board-terminal">
echo "now running with $(cat /proc/cpuinfo | grep processor | wc -l) processors"
 
echo "start remote proc AMP"
 
insmod virtio.ko
insmod virtio_ring.ko
insmod virtio_rpmsg_bus.ko
insmod remoteproc.ko
insmod mx6_remoteproc.ko
insmod rpmsg_freertos_statistic.ko
 
echo "everything done"
echo "now Linux is running with $(cat /proc/cpuinfo | grep processor | wc -l) processors"
</pre>
 
Then run the latencystat application as shown below. The typical output will look like this:
 
<pre class="board-terminal">
root@axel:~# ./latencystat -b
Linux FreeRTOS AMP Demo.
0: Command 0 ACKed
1: Command 1 ACKed
Waiting for samples...
2: Command 2 ACKed
3: Command 3 ACKed
4: Command 4 ACKed
-----------------------------------------------------------
Histogram Bucket Values:
Bucket 323 ns (36 ticks) had 38 frequency
Bucket 341 ns (38 ticks) had 299 frequency
Bucket 512 ns (57 ticks) had 1 frequency
Bucket 746 ns (83 ticks) had 1 frequency
-----------------------------------------------------------
Histogram Data:
min: 323 ns (36 ticks)
avg: 332 ns (37 ticks)
max: 746 ns (83 ticks)
out of range: 0
total samples: 339
-----------------------------------------------------------
</pre>
 
This application is extremely useful for evaluating how CPU load on first core affects IRQ latency. In case latency does not satisfy real-time requirements, it may be necessary to adjust arbitration priorities of processor's interconnect subsystem.
8,154
edits

Navigation menu