Adeneo Embedded - a whitepaper on integrating Xenomai on i.MX6 Linux

[#1]

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.

[#2]

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

[#3]

The I-pipe patches shipped with Xenomai do support SMP.