Bureaucrats, dave_user, Administrators
8,204
edits
Changes
no edit summary
{{AppliesToAxel}}
{{AppliesToAxelLite}}
{{AppliesToAXEL Lite AN}}
{{AppliesToSBCX}}
{{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.}}
|Update for XELK 2.0.0 release
|-
|[httphttps://www.dave.eu/siteslinks/defaultp/files/files/an-xelk-001-amp-linux-freertos.pdf 0qKejH20HFSu3oWn 0.9.3]
|April 2015
|2.0.0
|2.1.0
|Update for '''amp-feat-2.1.0-amp''' branch
|-
|1.0.1
|October 2018
|2.1.0
|Minor improvements
|-
|1.0.2
|October 2018
|2.1.0
|Added some details about <code>latencystat</code> test application
|}
This application note describes in detail the implementation of Linux/FreeRTOS asymmetric multiprocessing configuration on DAVE Embedded Systems AXEL LITE SoM. This configuration is a typical example about how to leverage AMP flexibility to combine, on one single piece of silicon, the versatility of Linux o.s. for general purpose computation, connectivity and HMI and the determinism of an RTOS to satisfy real-time constraints. Since AXEL family products are all based on Freescale i.MX6 processors, what is described here applies to AXEL ULTRA too.
As known, AMP allows a multicore system to run simultaneously[1] multiple Operating Systems (OS) that are independent of each other. In other words, each core has its own private memory space, which contains the OS and the applications that are to run on that core. In addition, there can be some shared memory space that is used for inter-core communication. This is in contrast to Symmetric Multiprocessing (SMP), in which one OS runs on multiple cores 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 to quickly implement applications that need to deliver deterministic, real-time responsiveness for markets such as automotive, industrial and others with similar requirements, while preserving the openness of Linux.
The following picture depicts the structure of the system.
[[File:XELK-amp-config.png|thumb|center|400px|AMP configuration]]
Core #0:
* takes care of boot process
* once Linux gets control of the 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
[1] This is true simultaneity because multiple instructions are executed at the same time.
=== Inter-core communication ===
=== Build FreeRTOS ===
For building the FreeRTOS, a proper toolchain has to be used, for example , the offical official arm linux Linux toolchain [https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads ref]. Specifically, the example here described was tested with the <code>7-2017-q4-major</code>, which is available for download [https://armkeil.blob.core.windows.net/developer/Files/downloads/gnu-rm/7-2017q4/gcc-arm-none-eabi-7-2017-q4-major-linux.tar.bz2 here]. To install it, just decompress the archive. Once the toolchain is downloaded and installed, then enter the following commandsto set up the cross-building environment accordingly:
<pre class="board-terminal">
</pre>
<pre class="board-terminal">
dvdk@dvdk:~/xelk/freertos$ make
</pre>
This command will build the FreeRTOS kernel and an example application, named <code>Rpmsg-Demo</code>.
=== Building latencystat ===
The resulting binary must be copied from the building directory to the root file system, e.g. on the <code>/home/root</code> directory of the root-file system.
=== Running the AMP example application on the target ===
As stated before, this example shows a sophisticated approach that allows for:
* using a standardized communication channel between the two cores
echo "now Linux is running with $(cat /proc/cpuinfo | grep processor | wc -l) processors"
</pre>
It is worth remembering that the previous commands load the required drivers to run the AMP configuration. Specifically, they:
*Release one of the Cortex A9 cores; the released core will be used to run the FreeRTOS-based example application
*Set up the RPmsg communication channel between the Linux kernel and the FreeRTOS kernel
*Load the code of the FreeRTOS-based example application into SDRAM memory (the code is retrieved from the <code>/lib/freertos</code> ELF file)
*Set up the devoted core to run the FreeRTOS-based example application.
<pre class="board-terminal">
-----------------------------------------------------------
Histogram Bucket Values:
Bucket 666 393 ns (44 26 ticks) had 135 1 frequency Bucket 681 409 ns (45 27 ticks) had 204 475 frequency Bucket 696 424 ns (46 28 ticks) had 335 1058 frequency Bucket 712 439 ns (47 29 ticks) had 371 57 frequency Bucket 727 681 ns (48 ticks) had 66 frequency Bucket 742 ns (49 ticks) had 81 frequency Bucket 757 ns (50 ticks) had 1 frequency Bucket 2075 ns (137 45 ticks) had 1 frequency
-----------------------------------------------------------
Histogram Data:
min: 666 393 ns (44 26 ticks) avg: 696 409 ns (46 27 ticks) max: 2075 681 ns (137 45 ticks)
out of range: 0
total samples: 11941592
-----------------------------------------------------------
</pre>
This application is extremely useful for evaluating measuring interrupt latency and for verifying how it is affected by relevant parameters such as the CPU load on the first core, memory bandwidth utilization, the amount/rate of interrupts to be processed by the first core affects IRQ , operating frequency, etc. For instance, the previous data refer to the following configuration:*[[FAQs_(Axel)#Q:_How_can_I_change_the_CPU_clock_frequency.3F|governor]]: <code>userspace</code>*nominal operating frequency: 800 MHz (actual: 792 MHz)*core #0 (running Linux) lightly loaded with minimal I/O activity. In general, it is strongly recommended to characterize the latencyon the basis of a '''realistic testbed that is as close as possible to the actual use case'''. In It is also worth remembering that, in case of latency does not satisfy the application's real-time requirements, it may be necessary is possible to adjust the arbitration priorities of processor's interconnect subsystemto reduce it.