- On what hardware does Xenomai run?
- Is my embedded setup supported by Xenomai?
- What is this I-pipe thing? And what about Adeos? Are they related?
- Which I-pipe patch should I use with Xenomai version X on platform Y?
- What is a Xenomai skin?
- Can I still use GDB in a dual kernel configuration?
- How to compile a RTDM-based driver?
- Running scripts/bootstrap complains about LT_SYS_SYMBOL_USCORE
- Can I mirror Xenomai git repositories ?
- I ran into a technical issue which is not covered here
Embedded hardware, desktop, server. This said, Xenomai has a strong focus on embedded systems, and most Xenomai ports nowadays target those platforms.
See the embedded hardware list.
If your board is not listed above, you may want to get more information from the Xenomai mailing list.
If you are willing to port Xenomai to an ARM-based system, you may want to have a look at this document.
In Xenomai parlance, the I-pipe and Adeos both 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.
This code is a kernel patch applied to a regular Linux kernel, which among other services, guarantees delivery of external interrupts to Xenomai with very low latency.
|You need the I-Pipe only for running Xenomai in a dual kernel configuration, i.e. over the Cobalt core.|
Check there for an I-pipe patch which best fits your kernel.
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 ™, 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.
Yes, definitely. Debugging a Xenomai application in a dual kernel system is no different from debugging any regular application.
|The only side-effect of using GDB for debugging a Xenomai application is that breakpointing and single-stepping implies a switch to secondary mode (i.e. threads are automatically handed over the Linux kernel as soon as GDB regains control).|
$ cd xenomai-3 $ ./scripts/bootstrap ... configure.ac:93: error: possibly undefined macro: LT_SYS_SYMBOL_USCORE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1
On Debian-based systems like Ubuntu, you need to install the libltdl-dev package for building Xenomai from sources.
Please have a look at the knowledge base.