Real-time Linux easier than ever now

By: Carsten Emde

Ever tried to apply RT patches to a 3.0 or 3.2 ARM vendor kernel?

A traditional way of automation industry to check out a new processor is to contact a vendor and to ask for an evaluation board. In case of an ARM processor, the vendor may deliver the board along with a BSP that is based on material obtained from the chip manufacturer. Typically (as of autumn 2013) it

• is not newer than kernel version 3.0 or 3.2, and
• does not provide real-time capabilities.

The latter is rather surprising, since often enough control systems in the automation industry rely on deterministic command execution. In consequence, one of the first actions is to obtain the closest RT patch and to import it into a quilt queue of the BSP's kernel source tree – not realizing that the delivered kernel is not a vanilla kernel but may have been modified with up to 2,500 patches. The innocent command

quilt push

will, therefore, produce myriads of complaints such as

...
patching file mm/Kconfig
Hunk #1 FAILED at 307.
1 out of 1 hunk FAILED -- rejects in file mm/Kconfig
patching file mm/filemap.c
Hunk #1 succeeded at 1922 (offset -125 lines).
patching file mm/memcontrol.c
Hunk #1 FAILED at 683.
Hunk #2 FAILED at 724.
2 out of 2 hunks FAILED -- rejects in file mm/memcontrol.c
patching file mm/page_alloc.c
Hunk #1 FAILED at 57.
Hunk #2 succeeded at 213 (offset -9 lines).
Hunk #3 succeeded at 648 with fuzz 1 (offset -7 lines).
...


so people normally will give up rather than get lost in patch clash hell. Furthermore, even if some gifted developers proceeded and finally managed to fix all fallouts, the problem would come back anytime later when bug fix, safety of security patches need to be applied.

Use mainline Linux whenever possible

But, wait, why use old vendor kernels, if mainline Linux (kernel versions 3.8 or 3.10) already may have merged most of the required components for many ARM processors? In addition, the real-time patch nowadays contains only very little arch-specific code, since most of the RT functionality became generic. Finally, low-cost ARM boards such as the Beagleboard may be good enough for evaluation purposes and already run a recent kernel version. Is patching now simpler than ever? Let's try it out and use an OMAP3 processor as example.

Take

• a Beagleboard-xM hardware
• an 8-GByte Micro SDHC flash card
• an Ubuntu 13.04 root file system for the Beagleboard as explained here
• the required development bits and pieces via apt-get
• the Linux kernel source tree linux-3.10.10
• the PREEMPT_RT patch patch-3.10.10-rt7.patch

We did so, and the Beaglebone-xM board is now sitting in rack #7/slot #6 of our QA Farm. After  importing the PREEMPT_RT patch into a quilt queue the command

quilt push

has to be executed as in the above vendor kernel scenario. This time, however, the patch – of course – applies smoothly without any error or warning, and the last output line simply says:

Now at patch patch-3.10.10-rt7.patch


Kernel compilation, therefore, is straight forward and after rebooting, voilà, the Beagleboard is running in real-time:

# uname -rv
3.10.10-rt7 #1 PREEMPT RT Sat Oct 4 13:14:36 CEST 2013

If you would like to do the same, simply let the OSADL website of the board profile produce the required script to install the patched kernel on your system by clicking on the button

that is located at the bottom of the page.

What comes next? If you are satisfied with the test results, contact appropriate vendors and let them offer an industrial CPU board that is based on the evaluated hardware. If you asked for a list of vendors, we certainly would refer to the hardware manufacturers and software service providers among OSADL members.

(Another way to avoid any hassle with computer hardware that is not yet well supported in mainline Linux is to use an x86-based system, if this is appropriate – but that's another story.)

---