FAQs
From Xenomai
On what kind of hardware does Xenomai run?
Desktop, server, embedded hardware. This said, Xenomai has a strong bias toward embedded systems, and most Xenomai ports nowadays target embedded platforms.
Is my embedded setup supported by Xenomai?
See there.
If your board is not listed above, you may want to get more information from the Xenomai mailing lists.
What is this I-pipe thing? And what about Adeos? Are they related?
Running as a dual kernel system, Xenomai needs special kernel support to deliver fast and deterministic response time to external interrupts, and also provide real-time services highly integrated with the standard Linux kernel.
This support is provided by a real-time enabling code layer born within the Adeos project, in the form of a kernel patch you have to apply against a vanilla Linux kernel tree, before you attempt to compile the Xenomai codebase against the latter kernel.
Adeos implements an interrupt pipeline at its core to dispatch events in a prioritized manner, including interrupts, which we commonly call the I-pipe. In Xenomai parlance, the I-pipe and Adeos always refer to the very same code, that makes a Linux kernel able to host a secondary kernel exhibiting real-time properties (e.g. Xenomai), on the same hardware.
Which I-pipe patch should I use with Xenomai version X on platform Y?
I-pipe patches available from any given Xenomai version in the ksrc/arch/*/patches directory have been used to validate that particular Xenomai release, so picking one of them is always a safe bet.
This said, you may use earlier patches from the Adeos/I-pipe project, since we try hard to maintain backward compatibility. For instance, Xenomai v2.4.4 works over 2.4.25/ppc and 2.6.29.4/powerpc; the same way, you may use any I-pipe patch for any kernel version ranging from 2.4.35/i386 to 2.6.29.4/x86. Of course, I-pipe patches are regularly updated with bug fixes, so you likely want to use the latest patch available for your architecture. In any case, have a look at the README file available from the ksrc/arch/<your_arch>/patches directory; it should give you more details regarding how the interrupt pipeline layer is supported on your architecture.
What is a Xenomai skin?
To understand that, you should first know that Xenomai is some sort of Chameleon RTOS at its core, which can export multiple real-time APIs to applications, all built over the Xenomai nucleus. A Xenomai API can impersonate an existing traditional RTOS interface such as VxWorks (tm), or provide an original programming interface for some particular purpose, such as RTDM. Basically, each API makes Xenomai look a different RTOS albeit all of them are based on the same common core. This is the reason why we call an implementation of such API, a Xenomai skin.
What is the Xenomai nucleus?
This is basically a set of building blocks available from a kernel module, over which Xenomai skins are built. The nucleus provides a common set of generic RTOS services to all Xenomai skins. If you plan to implement a new Xenomai skin, you may want to have a look at the nucleus API documentation here.
What are the differences between Xenomai and RTAI?
There is actually a long list of differences, though both projects share a few ideas and support the RTDM layer. The major differences derive from the goals the projects aim for, and from their respective implementation. While RTAI is focused on lowest technically feasible latencies, Xenomai also considers clean extensibility (RTOS skins), portability, and maintainability as very important goals. Xenomai's path towards PREEMPT_RT support is another major difference compared to RTAI's objectives.
One Xenomai developer once expressed his point of view on this comparison in the following posting: Xenomai vs. RTAI.
You may also want to have a look at the Xenomai Project History to learn more about the past relationships between RTAI and Xenomai.
Tips and tricks setting up your x86 kernel
Which kernel settings should be tried in case of problems?
- CONFIG_XENO_HW_SMI_WORKAROUND
This tries to disable System Management Interrupts on Intel chipsets. These interrupts run at higher priority than Xenomai core code or even the I-pipe layer. So they can cause high latencies to the real-time jobs (up to miliseconds). ATTENTION: On some systems, SMI may be involved in thermal throttling of the CPU. Thus, switching it off can cause hardware damage in overheat situations.
- Optimised CPU and platform settings
By tuning your kernel settings close to the real hardware, you can avoid unneeded overhead (e.g. CONFIG_SMP on non-SMP systems) or suboptimal code generation. For instance, picking CONFIG_M586 or earlier requires Xenomai to emulate the on-chip TSC for timing duties, even if your CPU actually provides this special hardware counter; unfortunately, emulating a TSC is slow, and this clearly has a negative impact on the worst-case latency figures, albeit your hardware may perform much better with proper kernel configuration. Therefore, rule #1 on x86 used as a real-time platform, is not to trust blindly the configuration of the should-work-everywhere default kernel shipped by your favorite distro-maker, but rather adapt this configuration to your real hardware.
Which kernel settings should be avoided?
Note that Xenomai will warn you about known invalid combinations during kernel configuration.
- CONFIG_CPU_FREQ
This allows the CPU frequency to be modulated with workload, but many CPUs change the TSC counting frequency also, which makes it useless for accurate timing when the CPU clock can change. Also some CPUs can take several milliseconds to ramp up to full speed.
- CONFIG_APM
The APM model assigns power management control to the BIOS, and BIOS code is never written with RT-latency in mind. If configured, APM routines are invoked with SMI priority, which breaks the rule that adeos-ipipe must be in charge of such things. CONFIG_XENO_HW_SMI_WORKAROUND_* doesn't help here.
- CONFIG_ACPI_PROCESSOR
For systems with ACPI support in the BIOS, this ACPI sub-option installs an 'idle' handler that uses ACPI C2 and C3 processor states to save power. The CPU must 'warm-up' from these sleep states, increasing latency in ways dependent upon both the BIOS's ACPI tables and code. You may be able to suppress the sleeping with 'idle=poll' boot-arg, test to find out. With recents versions of Linux (probably starting around Linux 2.6.21), the acpi processor module disables the local APIC when loaded. This will cause Xenomai timer initialization to fail. This makes a second reason for disabling this option.
- CONFIG_INPUT_PCSPKR' (only if i386 && kernel 2.6 && no TSC available)
Collides with Xenomai's TSC emulation on oldish x86 systems.
What can I do if Xenomai and Linux devices share the same IRQ?
IRQ sharing between RT (Xenomai) and non-RT (Linux) domains is fragile - regardless of the CPU architecture, can easily destroy determinism on the RT side, and should therefore be avoided whenever possible. Sharing IRQs between RT devices is not problematic, but still comes with additional overhead compared to dedicated IRQ lines. The following approaches exist to untangle devices IRQ-wise:
- If at least one of the devices is a PCI card, try to flip its position on the motherboard.
- PC104+ cards sometimes have jumpers (yeah, they still exist) to change the IRQ line. Otherwise, their ordering in the PC104 stack also influences the IRQ line
- Some (but not many) PC and notebook BIOSes allow to change the IRQ assignment.
- Disable the conflicting Linux device (e.g. in the BIOS) or simply don't load its driver.
- Disable some other on-board device that is unneeded. Sometimes this helps to persuade the system to avoid shared IRQs.
- Enable CONFIG_PCI_MSI, if some hardware supports MSI and the driver is written to use MSI, the driver will use the MSI.
- Enable CONFIG_X86_LOCAL_APIC or CONFIG_X86_IO_APIC, it increases the number of IRQs and may help (though nobody ever reported success with this).
- Ask you board vendor about possibilities to untangle IRQ lines -- or beat some engineer from your hardware design team if it is a homegrown problem.
- In case nothing works, and for a given configuration, you may modify the non real-time driver which shares an IRQ with a real-time driver as indicated in the following post:
https://mail.gna.org/public/xenomai-core/2008-07/msg00025.html
How can GDB be used?
The usual way. Debugging Xenomai-based userland application is no different from debugging non real-time applications. The only thing to keep in mind is that breakpointing and single-stepping a Xenomai real-time application over GDB implies a switch to secondary mode (i.e. your application is automatically handed over the Linux kernel as soon as GDB regains control over it).
Anywhere I could find out the Xenomai system status?
Start here: /proc/xenomai. E.g. /proc/xenomai/sched
What may cause a freeze or machine lockup?
- Stack space overflow issue now biting some real-time kernel thread?
- Spurious delay/timeout values computed by the application (specifically: too short).
- A case of freeze is a system call called in a loop which fails without its return value being properly checked.
- Software memory corruption (eg. dangling pointers).
On x86, whenever the nucleus watchdog does not trigger, you may want to try disabling CONFIG_X86_UP_IOAPIC while keeping CONFIG_X86_UP_APIC, and arm the kernel NMI watchdog on the LAPIC (nmi_watchdog=2). You may be lucky and have a backtrace after the freeze. Maybe enabling all the nucleus debug options would catch something too.
