Real-time Linux easier than ever now

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

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.

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.)