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 the embedded device support page.
If your board is not listed above, you may want to get more information from the Xenomai mailing list.
Or if your board is ARM based, and you are ready to do the port yourself, you may have a look at the HOWTO.
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 184.108.40.206/powerpc; the same way, you may use any I-pipe patch for any kernel version ranging from 2.4.35/i386 to 220.127.116.11/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.
How do I configure my x86 kernel for use with Xenomai?
Have a look at the X86 kernels configuration page. Read it carefully as this is an area that many people have trouble with.
Which kernel settings should be tried in case of problems?
Which kernel settings should be avoided?
This is detailed in the X86 kernels configuration page.
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_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 of 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:
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.