One of the important features that differentiates Xenomai from other real-time Linux extensions is its ability to offer hard real-time support to user-space applications. Ease of use of the user-space programming model should outweigh any gain one could expect from running the application directly from kernel space. User-space applications are memory protected from other processes, thus cannot crash the kernel should something goes wrong.
Xenomai also provides generic building blocks for building different RTOS interfaces called skins, These skins imitates the different RTOS APIs thus allowing easy porting of existing applications to Xenomai.
Required software
1. The current BSP version for iMX6 from Freescale is 3.0.35 does not fully work with the latest version Xenomai because the accompanying I-pipe patch does not support SMP. To use the latest I-pipe patch, a newer Linux kernel is need. Grab the latest stable kernel:
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
$ cd ~/linux-stable
$ git branch -a
$ git checkout remotes/origin/linux-3.8.y -b linux-3.8.y
$ git checkout v3.8.1 -v v3.8.1
2. Configure the kernel. Make sure the kernel is built without any errors before patching it with Xenomai.
$ export ARCH=arm
$ export CROSS-COMPILE=arm-fsl-linux-gnueabi-
$ make imx_v6_v7_defconfig
$ make -j16 uImage
3. Note that this is a device-tree enabled kernel. You'll also need to generate the flattened device tree that U-Boot will pass to the kernel.
$ make imx6q-sabrelite.dtb
4. This step is not needed if your U-Boot supports device-tree kernel. Grab the latest U-Boot:
$ git clone git://git.denx.de/u-boot.git
$ cd u-boot/
$ make mx6qsabrelite_config
$ make -j16
5. The boot script will need to updated to load the device-tree into memory and pass it to the bootm command.
U-Boot > setenv bootcmd 'fatload mmc 1 0x22000000 uImage; fatload mmc 1 0x11000000 imx6q-sabrelite.dtb; bo otm 0x22000000 – 0x11000000'
6. Grab the latest I-pipe patch from Adeos
$ wget
http://download.gna.org/adeos/patches/v3.x/arm/ipipe-core-3.8- arm-1.patch
7. Grab the latest Xenomai
$ wget
http://www.xenomai.org/index.php/Xenomai:News#2013-10- 05_Xenomai_2.6.3
$ tar -xvjf xenomai-2.6.3.tar.bz2
Patching the kernel
1. Prepare the target kernel. This is to assume that the Linux kernel and I-pipe patch are located relatively to Xenomai.
$ cd xenomai-2.6.3
$ ./scripts/prepare-kernel.sh --linux=../linux-stable/ --adeos=../linux-stable/ipipe-core-3.8-arm-1.patch –arch=ARM
$ ./configure CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --host=arm-fsl-linux-gnueabi
2. Build and installation
$ make -j8
$ sudo root
$ export PATH=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/:$PATH
$ make DESTDIR=~/BSP/ltib/rootfs install
Testing the installation
1. Verifying the kernel. If everything works, the kernel boot logs should messages like:
I-pipe: head domain Xenomai registered.
Xenomai: hal/arm started.
Xenomai: scheduling class idle registered.
Xenomai: scheduling class rt registered.
Xenomai: real-time nucleus v2.6.2.1 (Day At The Beach) loaded.
Xenomai: debug mode enabled.
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.
2. Comparison of Xenomai and unpatched Linux kernel real-time performance. We ran a couple benchmarks on a Freescale I.MX6q Sabrelite board to do the comparison. The tests used default configurations and
fully stressed the system in order to measure scheduling jitter.
Linux
Kernel
Zero load
100% loaded
Average latency
(us)
Worst-case
latency (us)
Average latency
(us)
Worst-case
latency (us)
Standard
4.625
41.311
5.120
1849.91
Patched with
Xenomai
4.825
15.568
6.654
16.655
The tests measure the jitter relative to expected time on a periodic task running every 1 millisecond. Data show the Xenomai implementations stand out for having by far the smallest difference between light and full load in the worst case. Stock Linux fare much worse as the timers miss a lot wake ups.
