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.
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
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
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 | Worst-case | Average latency | Worst-case | |
Standard | 4.625 | 41.311 | 5.120 | 1849.91 |
Patched with | 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.
Very interesting guide, but when I tried to boot the default compiled (with gcc-linaro-arm-linux-gnueabihf-4.8-2013.05_linux cross compiler) 3.8.1 linux kernel (the entry point is 0xfffffff2 not 0x22000000) I just got
** ext4fs_devread read error - block
** Can't read partition table on 0:0 **
** Invalid partition 1 **
data abort
MAYBE you should read doc/README.arm-unaligned-accesses
pc : [<4ff6d43c>] lr : [<4ff5d004>]
sp : 4f357c98 ip : 4f3598cb fp : 4ffa22f8
r10: 00000000 r9 : 4f357f38 r8 : 4f3598e4
r7 : 0000070f r6 : fffffff2 r5 : 00000003 r4 : fffffff2
r3 : 00000000 r2 : 00000010 r1 : 00000000 r0 : fffffff2
Flags: nZCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
Any suggestion about what I misconfigured would be appreciated...
Thanks in advance Luca
The I-pipe patches shipped with Xenomai do support SMP.