Installing Xenomai 2 | 糖醋鱼的小破站

type

Post

status

Published

date

Feb 24, 2025

slug

2025/02/24/Installing-Xenomai-2

summary

Introduction

Starting with version 2.1, Xenomai follows a split source model, decoupling the kernel space support from the user-space libraries used in accessing the former.

从 2.1 版开始，Xenomai 采用分离源模型，将内核空间支持与访问前者所用的用户空间库分离开来。

To this end, kernel and user-space Xenomai components are respectively available under the ksrc/ and src/ sub-trees.

为此，内核和用户空间的 Xenomai 组件分别位于 ksrc/ 和 src/ 子树下。

The ksrc/ sub-tree providing the kernel space support is seen as a built-in extension of the Linux kernel, and no more as a collection of separate out-of-tree modules. A direct benefit of such approach is the ability to build the Xenomai real-time subsystem statically into the target kernel, or as loadable modules as with earlier versions. therefore, the usual Linux kernel configuration process will be normally used to define the various settings for the Xenomai kernel components. Sections Preparing the target kernel and Configuring and building the kernel document the installation process of this kernel space support.

提供内核空间支持的 ksrc/ 子树被视为 Linux 内核的内置扩展，而不再是独立的树外模块集合。这种方法的一个直接好处是，可以在目标内核中静态构建 Xenomai 实时子系统，或像早期版本那样将其作为可加载模块。因此，通常会使用 Linux 内核配置过程来定义 Xenomai 内核组件的各种设置。准备目标内核和配置并构建内核两节记录了内核空间支持的安装过程。

The src/ sub-tree contains the various user-space libraries and commands provided by the Xenomai framework. This tree can be built separately from the kernel support, even if the latter is absent from the build system. Section Building the user-space support documents the installation process of this user-space support.

src/ 子树包含 Xenomai 框架提供的各种用户空间库和命令。这棵树可以与内核支持分开构建，即使构建系统中没有内核支持。构建用户空间支持部分记录了用户空间支持的安装过程。

If you are using a Debian based distribution, it is also possible to install, and even build Xenomai as a set of Debian packages. For further details, see this page .

如果你使用的是基于 Debian 的发行版，也可以将 Xenomai 作为一套 Debian 软件包来安装甚至构建。更多详情，请参阅此页面。

Installation steps

Preparing the target kernel

准备目标内核

Xenomai provides a real-time sub-system seamlessly integrated to Linux, therefore the first step is to build it as part of the target kernel. To this end, scripts/prepare-kernel.sh is a shell script which sets up the target kernel properly. The syntax is as follows:

Xenomai 提供了与 Linux 无缝集成的实时子系统，因此第一步就是将其作为目标内核的一部分来构建。为此，scripts/prepare-kernel.sh 是一个 shell 脚本，用于正确设置目标内核。语法如下


$ scripts/prepare-kernel.sh --linux=<linux-srctree>
[--adeos=<adeos-patch>] [--arch=<target-arch>]

-linux

specifies the path of the target kernel source tree. Such kernel tree being configured or not makes no difference and is valid either way.

指定目标内核源代码树的路径。内核树是否已配置没有区别，无论哪种方式都有效。

-adeos

specifies the path of the Adeos patch to apply against the kernel tree. Suitable patches are available with Xenomai under ksrc/arch/<target-arch>/patches. This parameter can be omitted if Adeos has already been patched in or the script shall suggest an appropriate one. In any case, the script will not try to apply it again whenever a former patch is detected.

指定要应用于内核树的 Adeos 补丁的路径。 Xenomai 可在 ksrc/arch/<target-arch>/patches 下提供合适的补丁。如果 Adeos 已经打上了补丁，则可以省略此参数，否则脚本会推荐一个合适的补丁。无论如何，只要检测到以前的补丁，脚本就不会再尝试应用。

-arch

tells the script about the target architecture. If unspecified, the build system architecture is detected and suggested as a reasonable default.

会告诉脚本有关目标架构的信息。如果未指定，则会检测并建议将构建系统架构作为合理的默认架构。

For instance, the following command would prepare the Linux tree located at /usr/src/linux-2.6.23-ipipe in order to include the Xenomai support:

例如，以下命令将准备位于 /usr/src/linux-2.6.23-ipipe 的 Linux 树，以便包含 Xenomai 支持：


$ cd xenomai-2.4
$ scripts/prepare-kernel.sh --linux=/usr/src/linux-2.6.23-ipipe

Note: The script will infer the location of the Xenomai kernel code from its own location within the Xenomai source tree. In other words, if /usr/src/xenomai-2.4/script/prepare-kernel.sh is executing, then Xenomai’s kernel support available from /usr/src/xenomai-2.4/ksrc will be bound to the target kernel.

注意：脚本将根据自己在 Xenomai 源代码树中的位置推断 Xenomai 内核代码的位置。换句话说，如果 /usr/src/xenomai-2.4/script/prepare-kernel.sh 正在执行，那么 /usr/src/xenomai-2.4/ksrc 中的 Xenomai 内核支持将绑定到目标内核。

Configuring and building the target kernel

配置和构建目标内核

Once the target kernel has been prepared, the kernel should be configured following its usual configuration procedure. All Xenomai configuration options are available from the “Real-time subsystem” toplevel menu.

准备好目标内核后，应按照通常的配置程序对内核进行配置。所有的 Xenomai 配置选项都可以在 “实时子系统”（Real-time subsystem）顶层菜单中找到。

There are several important kernel configuration options, some are documented in the Troubleshooting guide , others in the section illustrating the typical installation procedures for the architecture you are using.

有几个重要的内核配置选项，其中一些记录在故障排除指南中，其他的则在说明所使用架构的典型安装程序的章节中。

Once configured, the kernel should be built as usual.

配置完成后，内核就可以照常编译了。

If you want several different configs/builds at hand, you can reuse the same source by adding O=../build-<target> to each make invocation. See section Building for the PowerPC architecture for an example

如果需要多个不同的配置/构建，可以在每次调用 make 时添加 O=.../build-<target> 来重复使用相同的源代码。有关示例，请参阅 “为 PowerPC 架构构建 ”一节。

In order to cross-compile the Linux kernel, pass an ARCH and CROSS_COMPILE variable on make command line. See sections Building for the PowerPC architecture , Building for the Blackfin , Building for ARM and Building for NIOS II for examples.

为了交叉编译 Linux 内核，请在 make 命令行中传递 ARCH 和 CROSS_COMPILE 变量。请参阅 “为 PowerPC 体系结构编译”、“为 Blackfin 编译”、“为 ARM 编译 ”和 “为 NIOS II 编译 ”章节中的示例。

Building the user-space support

构建用户空间支持

A regular autoconf script is provided in order to prepare for building the user-space support. The options listed below can be passed to this script. Those options only affect the libraries compiled as part of Xenomai’s user-space support, but in any case, they never impact the kernel-based support.

为了准备构建用户空间支持，我们提供了一个常规的 autoconf 脚本。下面列出的选项可传递给该脚本。这些选项只影响作为 Xenomai 用户空间支持的一部分编译的库，但无论如何，它们都不会影响基于内核的支持。

Feature conflict resolution

解决功能冲突

Because of the strong decoupling between the kernel and user-space build procedures, Xenomai needs to make sure that all user-space options selected at configuration time will be consistent with the actual support the runtime libraries will get from the target kernel. For instance, enabling TSC support in user-space for x86 albeit the kernel has been compiled with CONFIG_X86_TSC disabled would certainly lead to runtime problems if uncaught, since Xenomai and the application would not agree on the high precision clock to use for their timings. Furthermore, most of these issues cannot be probed for during compilation, because the target generally has different features than the host, even when they are the same arch (ex 386 vs 686).

由于内核和用户空间编译过程之间的紧密解耦，Xenomai 需要确保在配置时选择的所有用户空间选项都与运行时库从目标内核获得的实际支持一致。例如，尽管内核在编译时禁用了 CONFIG_X86_TSC，但在用户空间为 x86 启用了 TSC 支持，这肯定会导致运行时问题（如果未被捕获），因为 Xenomai 和应用程序无法就定时所使用的高精度时钟达成一致。此外，这些问题大多无法在编译过程中探测到，因为目标机通常与主机具有不同的特性，即使它们是相同的架构（例如 386 与 686）。

In order to solve those potential issues, each Xenomai architecture port defines a set of critical features which is tested for consistency, each time a user-space application binds itself to a real-time interface in kernel space. Unresolvable conflicts are reported and the execution stops immediately in such a case.

为了解决这些潜在问题，Xenomai的每个架构移植都定义了一组关键特性，这些特性在每次用户空间应用程序与内核空间中的实时接口绑定时，都会进行一致性测试。如果检测到无法解决的冲突，系统将报告错误，并在这种情况下立即停止执行。

Options that need perfect matching between both sides are marked as “strong” in the following lists, others that may differ are marked as “weak”. The way Xenomai deals with tolerated discrepancies is decided on a case-by-case basis, depending on the option considered. When not applicable, the binding type remains unspecified.

在以下列表中，需要双方完全匹配的选项标记为 “强”，其他可能存在差异的选项标记为 “弱”。Xenomai 处理可容忍差异的方式视具体情况而定，取决于所考虑的选项。不适用时，绑定类型保持未指定。

在以下列表中，需要在双方之间实现完美匹配的选项被标记为“强”（strong），而允许存在差异的选项则被标记为“弱”（weak）。Xenomai 处理可容忍差异的方式会根据具体选项的不同而逐案决定。如果某个选项不适用，绑定类型保持未指定。

For instance, UP and SMP-enabled kernels can run either UP or SMP-enabled user-space applications indifferently, since the SMP option’s binding is weak. On the other hand, x86-based applications linked against Xenomai libraries which have been compiled with the x86-tsc option on, must run on a kernel built with CONFIG_X86_TSC set, since the x86-tsc option’s binding is strong.

例如，支持单处理器（UP）和对称多处理器（SMP）的内核可以无差别地运行支持 UP 或 SMP 的用户空间应用程序，因为SMP选项的绑定是“弱”的。另一方面，基于x86架构的应用程序如果链接了启用了 x86-tsc 选项编译的 Xenomai 库，则必须在启用了 CONFIG_X86_TSC 配置的内核上运行，因为x86-tsc 选项的绑定是强绑定。

Generic configure options

通用配置选项

NAME	DESCRIPTION	[BINDING,] DEFAULT
`--prefix`	Installation directory	`/usr/xenomai`
`--enable-debug`	Enable debug symbols (`-g`)	disabled
`--enable-smp`	Enable SMP support 1	weak, enabled
`--with-atomic-ops=`	Selects which implementation of atomic access operations shall be used within Xenomai libraries: 选择在Xenomai库中使用哪种原子访问操作的实现： `--with-atomic-ops=builtins` selects the GCC builtins, i.e. _sync() services. `--with-atomic-ops=builtins` 选择GCC内置函数，即 _sync() 服务。 `--with-atomic-ops=ad-hoc` selects the ad hoc Xenomai implementation. `--with-atomic-ops=ad-hoc` 选择Xenomai的特定实现。 When this switch is not specified, a conservative choice is made depending on the target architecture. 如果未指定此选项，则根据目标架构做出保守选择。 Unless the GCC toolchain is outdated (i.e. does not provide these operations) or broken, `--with-atomic-ops=builtins` should be used. 除非GCC工具链过时（即不提供这些操作）或存在问题，否则应使用 `--with-atomic-ops=builtins`。	arch-dependent

The SMP switch is used to tell the build system whether CPU synchronization instructions should be emitted in atomic constructs appearing in some Xenomai libraries, enabling them for SMP execution. This feature is turned on by default on all SMP-enabled architecture Xenomai supports, i.e. x86_32/64, powerpc_32/64 and ARM. One may override this default setting by passing -disable-smp explicitely for those architectures.

SMP开关用于告知构建系统是否应在某些 Xenomai 库中出现的原子构造中生成CPU同步指令，从而使其支持SMP执行。默认情况下，Xenomai支持的所有SMP架构（即 x86_32/64、powerpc_32/64 和 ARM）均启用此功能。对于这些架构，可以通过显式传递 --disable-smp 来覆盖此默认设置。

SMP-enabled userland code may run over SMP or UP kernels. However, Xenomai will deny running UP-only userland code (i.e. when --disable-smp is in effect) over an SMP kernel.↩︎

支持 SMP 的用户空间代码可以在 SMP 或 UP 内核上运行。然而，Xenomai 将拒绝在 SMP 内核上运行仅支持 UP 的用户空间代码（即当 --disable-smp 生效时）。

Arch-specific configure options

架构特定的配置选项

NAME	DESCRIPTION	[BINDING,] DEFAULT
`--enable-x86-sep`	Enable x86 SEP instructions for issuing syscalls. You will also need NPTL. 启用 x86 SEP 指令以进行系统调用。同时需要NPTL支持。	strong, enabled
`--enable-x86-tsc`	Enable x86 TSC for timings You must have TSC for this. 启用 x86 TSC 用于计时。必须具有TSC支持才能启用此选项。	strong, enabled
`--enable-arm-tsc`	Enable ARM TSC emulation. 1 启用ARM TSC模拟。	weak, kuser
`--enable-arm-quirks`	Enable quirks for specific ARM SOCs Currently sa1100 and xscale3 are supported. 启用针对特定 ARM SOC 的补丁。目前支持 sa1100 和 xscale3。	weak, disabled

In the unusual situation where Xenomai kernel support for the target SOC does not support the kuser generic emulation, pass this option to use another tsc emulation. See -help for a list of valid values.↩︎

在目标SOC的Xenomai内核支持不支持kuser通用模拟的特殊情况下，可以传递此选项以使用其他TSC模拟。请参阅 -help 获取有效值的列表。

Cross-compilation

交叉编译

In order to cross-compile Xenomai user-space support, you will need to pass a --host and --build option to the configure script. The --host option allow to select the architecture for which the libraries and programs are built. The --build option allows to choose the architecture on which the compilation tools are run, i.e. the system running the configure script.

为了交叉编译 Xenomai 的用户空间支持，您需要向 configure 脚本传递--host和--build选项。--host选项用于选择库和程序构建的目标架构。--build 选项用于选择运行编译工具的架构，即运行configure 脚本的系统。

Since cross-compiling requires specific tools, such tools are generally prefixed with the host architecture name; for example, a compiler for the power PC architecture may be named powerpc-405-linux-gnu-gcc.

由于交叉编译需要特定的工具，这些工具通常以目标架构名称作为前缀；例如，针对Power PC架构的编译器可能命名为powerpc-405-linux-gnu-gcc。

When passing the option --host=powerpc-405-linux-gnu to configure, configure will automatically use powerpc-405-linux-gnu- as a prefix to all compilation tools names and infer the host architecture name from this prefix. If configure is unable to infer the architecture name from the cross-compilation tools prefix, you will have to manually pass the name of all compilation tools using at least the CC and LD, variables on configure command line. See sections Building for the PowerPC architecture and Building for the Blackfin for an example using the CC and LD variable, or Building for ARM for an example using the --host argument.

当向 configure 传递--host=powerpc-405-linux-gnu选项时，configure 会自动使用 powerpc-405-linux-gnu-作为所有编译工具名称的前缀，并从此前缀推断目标架构名称。如果 configure 无法从交叉编译工具前缀推断出架构名称，您需要手动通过configure 命令行传递所有编译工具的名称，至少需要使用 CC 和 LD 变量。有关使用 CC 和 LD 变量的示例，请参阅为PowerPC架构构建和为Blackfin构建部分；有关使用--host参数的示例，请参阅为ARM构建部分。

The easiest way to build a GNU cross-compiler might involve using crosstool-ng, available here .

构建GNU交叉编译器的最简单方法可能是使用crosstool-ng，可在此处获取。

If you want to avoid to build your own cross compiler, you might if find easier to use the ELDK. It includes the GNU cross development tools, such as the compilers, binutils, gdb, etc., and a number of pre-built target tools and libraries necessary to provide some functionality on the target system. See here for further details.

如果您希望避免构建自己的交叉编译器，使用 ELDK 可能会更加方便。它包含了GNU交叉开发工具，例如编译器、binutils、gdb等，以及一些预构建的目标工具和库，这些工具和库在目标系统上提供必要的功能。更多详细信息请参见此处。

Some other pre-built toolchains:

其他一些预构建的工具链包括：

Mentor Sourcery CodeBench Lite Edition, available here ;

Linaro toolchain (for the ARM architecture), available here .

Typical installation procedures {x2-install-examples}

典型安装流程 {x2-install-examples}

The examples in following sections use the following conventions:

以下部分中的示例使用以下约定：

$linux_tree

path to the target kernel sources

目标内核源代码的路径

$xenomai_root

path to the Xenomai sources

Xenomai源代码的路径

$build_root

path to a clean build directory

用于存放构建文件的干净目录的路径

$staging_dir

path to a directory that will hold the installed file temporarily before they are moved to their final location; when used in a cross-compilation setup, it is usually a NFS mount point from the target’s root directory to the local build host, as a consequence of which running make DESTDIR=$staging_dir install on the host immediately updates the target system with the installed programs and libraries.

用于临时存放安装文件的目录路径，在将这些文件移动到最终位置之前使用；在交叉编译设置中，它通常是目标系统根目录到本地构建主机的 NFS 挂载点，因此在主机上运行 make DESTDIR=$staging_dir install 会立即将安装的程序和库更新到目标系统中。

Building for x86_32/64bit

Since Linux 2.6.24, x86_32 and x86_64 trees are merged. Therefore, building Xenomai for 2.6.24 or later is almost the same, regardless of the 32/64bit issue. You should note, however, that it is not possible to run xenomai libraries compiled for x86_32 with a kernel compiled for x86_64.

自Linux 2.6.24版本起，x86_32和x86_64的内核树已合并。因此，无论32位还是64位问题，为2.6.24或更高版本构建Xenomai的过程几乎相同。但需要注意的是，为x86_32编译的Xenomai库无法与为x86_64编译的内核一起运行。

Assuming that you want to build natively for a x86_64 system (x86_32 cross-build options from x86_64 appear between brackets), you would typically run:

假设您要为x86_64系统进行本地构建（x86_32的交叉构建选项在方括号中），通常可以运行以下命令：


$ $xenomai_root/scripts/prepare-kernel.sh --arch=x86 \
  --adeos=$xenomai_root/ksrc/arch/x86/patches/adeos-ipipe-2.6.29.4-x86-X.Y-ZZ.patch \
  --linux=$linux_tree
$ cd $linux_tree
$ make [ARCH=i386] xconfig/gconfig/menuconfig

…configure the kernel (see also the recommended settings here ).

...配置内核（另请参阅此处的推荐设置）。

Enable Xenomai options, then install as needed with:

启用Xenomai选项，然后根据需要安装：


$ make [ARCH=i386] bzImage modules
$ mkdir $build_root && cd $build_root
$ $xenomai_root/configure --enable-x86-sep \
  [--host=i686-linux CFLAGS="-m32 -O2" LDFLAGS="-m32"]
$ make install

Now, let’s say that you really want to build Xenomai for a Pentium-based x86 32bit platform running a legacy 2.6.23 kernel, using the native host toolchain; the typical steps would be as follows:

现在，假设您确实希望为基于Pentium的x86 32位平台构建Xenomai，该平台运行的是传统的2.6.23内核，并使用本地主机工具链；典型步骤如下：


$ $xenomai_root/scripts/prepare-kernel.sh --arch=i386 \
  --adeos=$xenomai_root/ksrc/arch/x86/patches/adeos-ipipe-2.6.23-i386-X.Y-ZZ.patch \
  --linux=$linux_tree
$ cd $linux_tree
$ make xconfig/gconfig/menuconfig

…configure the kernel (see also the recommended settings here ).

Enable Xenomai options, then install as needed with:

...配置内核（另请参阅此处的推荐设置）。

启用Xenomai选项，然后根据需要安装：


$ make bzImage modules
$ mkdir $build_root && cd $build_root
$ $xenomai_root/configure --enable-x86-sep
$ make install

Similarly, for a legacy kernel on a 64bit platform, you would use:

类似地，对于64位平台上的传统内核，您可以使用：


$ $xenomai_root/scripts/prepare-kernel.sh --arch=x86_64 \
  --adeos=$xenomai_root/ksrc/arch/x86/patches/adeos-ipipe-2.6.23-x86_64-X.Y-ZZ.patch \
  --linux=$linux_tree
$ cd $linux_tree
$ make xconfig/gconfig/menuconfig

…configure the kernel (see also the recommended settings here ).

Enable Xenomai options, then install as needed with:

...配置内核（另请参阅此处的推荐设置）。

启用Xenomai选项，然后根据需要安装：


$ make bzImage modules
$ mkdir $build_root && cd $build_root
$ $xenomai_root/configure
$ make install

Once the compilation has completed, /usr/xenomai should contain the user-space librairies and header files you would use to build applications that call Xenomai’s real-time support in kernel space.

编译完成后，/usr/xenomai目录应包含用户空间库和头文件，您可以使用这些文件来构建调用内核空间中Xenomai实时支持的应用程序。

The remaining examples illustrate how to cross-compile Xenomai for various architectures. Of course, you will have to install the proper cross-compilation toolchain for the target system first, in order to build Xenomai.

以下示例展示了如何为各种架构交叉编译Xenomai。当然，为了构建Xenomai，您首先需要为目标系统安装适当的交叉编译工具链。

Building for the PowerPC architecture

PowerPC has a legacy arch/ppc branch, and a newer, current arch/powerpc tree. Xenomai supports both, but using arch/powerpc is definitely recommended. To help the preparation script to pick the right one, you have to specify either --arch=powerpc (current) or --arch=ppc (legacy). Afterwards, the rest should be a no-brainer:

PowerPC有一个传统的arch/ppc分支和一个较新的、当前的arch/powerpc树。Xenomai支持两者，但强烈建议使用arch/powerpc。为了帮助准备脚本选择正确的分支，您需要指定--arch=powerpc（当前）或--arch=ppc（传统）。之后，其余部分应该非常简单。

A typical cross-compilation setup, in order to build Xenomai for a lite5200 board running a recent 2.6.29.4 kernel. We use DENX’s ELDK cross-compiler:

以下是为运行2.6.29.4内核的 lite5200 板构建 Xenomai 的典型交叉编译设置。我们使用 DENX 的 ELDK交叉编译器：


$ $xenomai_root/scripts/prepare-kernel.sh --arch=powerpc \
  --adeos=$xenomai_root/ksrc/arch/powerpc/patches/adeos-ipipe-2.6.29.4-powerpc-2.6-00.patch \
  --linux=$linux_tree
$ cd $linux_tree
$ make ARCH=powerpc CROSS_COMPILE=ppc_6xx- xconfig/gconfig/menuconfig

…select the kernel and Xenomai options, save the configuration

...选择内核和Xenomai选项，保存配置


$ make ARCH=powerpc CROSS_COMPILE=ppc_6xx- uImage modules

…manually install the u-boot image and modules to the proper location

...手动将u-boot镜像和模块安装到正确的位置


$ cd $build_root
$ $xenomai_root/configure --host=powerpc-unknown-linux-gnu \
  CC=ppc_6xx-gcc AR=ppc_6xx-ar LD=ppc_6xx-ld
$ make DESTDIR=$staging_dir install

Another cross-compilation setup, in order to build Xenomai for a powerpc64 PA-Semi board running a recent 2.6.29.4 kernel:

另一个交叉编译设置，用于为运行2.6.29.4内核的powerpc64 PA-Semi板构建Xenomai：


$ $xenomai_root/scripts/prepare-kernel.sh --arch=powerpc \
  --adeos=$xenomai_root/ksrc/arch/powerpc/patches/adeos-ipipe-2.6.29.4-powerpc-2.6-00.patch \
  --linux=$linux_tree
$ cd $linux_tree
$ make ARCH=powerpc CROSS_COMPILE=powerpc64-linux- xconfig/gconfig/menuconfig

…select the kernel and Xenomai options, save the configuration


$ make ARCH=powerpc CROSS_COMPILE=powerpc64-linux-

…manually install the vmlinux image and modules to the proper location


$ cd $build_root
$ $xenomai_root/configure --host=powerpc64-linux \
  CC=powerpc64-linux-gcc AR=powerpc64-linux-ar LD=powerpc64-linux-ld
$ make DESTDIR=$staging_dir install

Yet another cross-compilation setup, this time for building Xenomai for a PowerPC-405-based system running a legacy arch/ppc 2.6.14 kernel (we do support recent ones as well on this platform):

还有一个交叉编译设置，这次是为运行传统arch/ppc 2.6.14内核的基于PowerPC-405的系统构建Xenomai（我们在此平台上也支持较新的内核）：


$ $xenomai_root/scripts/prepare-kernel.sh --arch=ppc \
  --adeos=$xenomai_root/ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.5-*.patch \
  --linux=$linux_tree
$ mkdir -p $build_root/linux
$ cd $linux_tree
$ make ARCH=ppc CROSS_COMPILE=ppc_4xx- O=$build_root/linux xconfig/gconfig/menuconfig

…select the kernel and Xenomai options, save the configuration


$ make ARCH=ppc CROSS_COMPILE=ppc_4xx- O=$build_root/linux bzImage modules

…manually install the kernel image, system map and modules to the proper location


$ make $build_root/xenomai && cd $build_root/xenomai
$ $xenomai_root/configure --build=i686-pc-linux-gnu --host=ppc-unknown-linux-gnu \
  CC=ppc_4xx-gcc LD=ppc_4xx-ld
$ make DESTDIR=$staging_dir install

Building for the Blackfin

The Blackfin is an MMU-less, DSP-type architecture running uClinux.

Blackfin是一种无MMU的DSP类型架构，运行uClinux。


$ $xenomai_root/scripts/prepare-kernel.sh --arch=blackfin \
  --adeos=$xenomai_root/ksrc/arch/blackfin/patches/adeos-ipipe-bf53x-*.patch \
  --linux=$linux_tree
$ cd $linux_tree
$ make ARCH=blackfin CROSS_COMPILE=bfin-uclinux- xconfig/gconfig/menuconfig

…select the kernel and Xenomai options, then compile with:

...选择内核和Xenomai选项，然后编译：


$ make linux image

…then install as needed

...然后根据需要安装


$ cp images/linux /tftpboot/...

…build the user-space support

...构建用户空间支持


$ mkdir $build_root && cd $build_root
$ $xenomai_root/configure --host=blackfin-unknown-linux-gnu \
  CC=bfin-linux-uclibc-gcc AR=bfin-linux-uclibc-ar LD=bfin-linux-uclibc-ld
$ make DESTDIR=$staging_dir install

Xenomai uses the FDPIC shared library format on this architecture. In case of problem running the testsuite, try restarting the last two build steps, passing the --disable-shared option to the “configure” script.

Xenomai在此架构上使用 FDPIC 共享库格式。如果运行测试套件时遇到问题，请尝试重新执行最后两个构建步骤，并向 “configure” 脚本传递 --disable-shared 选项。

Building for ARM

Some ARM SOC Adeos patches are not part of the mainline Adeos tree, and are delivered separately, mainly because they usually target non-mainline kernels to which the mainline Adeos patch does not apply. To install these particular patches, typically a particular non mainline kernel must be obtained, then the patches applied in a certain order, then prepare-kernel.sh can be run as usual. prepare-kernel.sh will detect that the kernel already contains Adeos support and will skip the Adeos patch. For details on the particular Linux version and patches to use for a particular SOC, see ksrc/arch/arm/patches/README in Xenomai sources.

一些 ARM SOC 的 Adeos 补丁并不属于 Adeos 主线树的一部分，而是单独提供，主要是因为它们通常针对非主线内核，而主线Adeos补丁无法应用于这些内核。要安装这些特定的补丁，通常需要获取特定的非主线内核，然后按特定顺序应用补丁，之后可以像往常一样运行prepare-kernel.sh。prepare-kernel.sh会检测到内核已经包含Adeos支持，并跳过Adeos补丁。有关特定SOC使用的Linux版本和补丁的详细信息，请参阅Xenomai源代码中的ksrc/arch/arm/patches/README。

Using codesourcery toolchain named arm-none-linux-gnueabi-gcc and compiling for a CSB637 board (AT91RM9200 based), a typical compilation will look like:

使用名为 arm-none-linux-gnueabi-gcc 的CodeSourcery工具链并为CSB637板（基于AT91RM9200）编译时，典型的编译过程如下：


$ $xenomai_root/scripts/prepare-kernel.sh --arch=arm \
  --adeos=$xenomai_root/ksrc/arch/arm/patches/adeos-ipipe-2.6.20-arm-* \
  --linux=$linux_tree
$ cd $linux_tree
$ mkdir -p $build_root/linux
$ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- O=$build_root/linux \
  csb637_defconfig
$ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- O=$build_root/linux \
  bzImage modules

…manually install the kernel image, system map and modules to the proper location

...手动将内核镜像、系统映射和模块安装到正确的位置


$ mkdir $build_root/xenomai && cd $build_root/xenomai
$ $xenomai_root/configure CFLAGS="-march=armv4t" LDFLAGS="-march=armv4t" \
  --build=i686-pc-linux-gnu --host=arm-none-linux-gnueabi-
$ make DESTDIR=$staging_dir install

Starting with Xenomai 2.6.0, Xenomai no longer passes any arm architecture specific flags, or FPU flags to gcc, so, users are expected to pass them using the CFLAGS and LDFLAGS variables as demonstrated above, where the AT91RM9200 is based on the ARM920T core, implementing the armv4 architecture. The following table summarizes the CFLAGS and options which were automatically passed in previous revisions and which now need to be explicitely passed to configure, for the supported SOCs if the same configuration is wanted. Note that these options are not mandatory, not even recommended, this is in part the reason why they were removed. For instance, when using a toolchain such as CodeSourcery with soft-float ABI, you may want to add -mfloat-abi=soft to the -mfpu=vfp option.

从Xenomai 2.6.0开始，Xenomai不再向gcc传递任何ARM架构特定的标志或FPU标志，因此用户需要通过CFLAGS和LDFLAGS变量显式传递这些标志，如上所示，其中AT91RM9200基于ARM920T核心，实现了armv4架构。下表总结了在之前的版本中自动传递的CFLAGS和选项，如果希望保持相同的配置，现在需要显式传递给configure。请注意，这些选项并非强制性的，甚至不推荐使用，这也是它们被移除的部分原因。例如，当使用CodeSourcery等工具链并采用软浮点ABI时，您可能希望在-mfpu=vfp选项中添加-mfloat-abi=soft。

ARM configure options and compilation flags

ARM配置选项和编译标志

SOC	CFLAGS	configure options
at91rm9200	`-march=armv4t -msoft-float`	ㅤ
at91sam9x	`-march=armv5 -msoft-float`	ㅤ
imx1	`-march=armv4t -msoft-float`	ㅤ
imx21	`-march=armv5 -msoft-float`	ㅤ
imx31	`-march=armv6 -mfpu=vfp`	ㅤ
imx51/imx53	`-march=armv7-a -mfpu=vfp3`	ㅤ
imx6q	`-march=armv7-a -mfpu=vfp3`	ㅤ
ixp4xx	`-march=armv5 -msoft-float`	ㅤ
omap3	`-march=armv7-a -mfpu=vfp3`	ㅤ
omap4	`-march=armv7-a -mfpu=vfp3`	ㅤ
orion	`-march=armv5 -mfpu=vfp`	ㅤ
pxa	`-march=armv5 -msoft-float`	ㅤ
pxa3xx	`-march=armv5 -msoft-float`	`--enable-arm-quirks=xscale3`
s3c24xx	`-march=armv4t -msoft-float`	ㅤ
sa1100	`-march=armv4t -msoft-float`	`--enable-arm-quirks=sa1100`

ARM configure options and compilation flags

It is possible to build for an older architecture version (v6 instead of v7, or v4 instead of v5), if your toolchain does not support the target architecture, the only restriction being that if SMP is enabled, the architecture should not be less than v6.

Building for NIOS II

NIOS II is a softcore processor developped by Altera and is dedicated to the Altera’s FPGA circuits.

NIOS II with no MMU enabled is supported by the uClinux distribution.

Minimum hardware requirements

You have to start with a minimal system with at least:

A Nios II processor in f or s core version, with hardware multiplier, (f-core suggested, s-core is slower) and with no MMU enabled.

SDRAM (minimum requirement 8MB).

One full featured timer named sys_clk_timer used for uClinux.

A jtag/serial uart or a real serial uart (preferred).

Note in Linux, IRQ 0 means auto-detected, so you must not use IRQ 0 for ANY devices.

The Xenomai port for NIOS II uses extra hardware that you have to add in SOPC builder:

A full featured 32-bit Timer named hrtimer with a 1 microsecond period.

A full featured High Resolution 64-bit Timer named hrclock used for time stamping (1 microsecond period for example).

Please respect hrtimer and hrclock names, the Xenomai port depends on them!

You have to use Altera’s Quartus II version 9.0 at least for synthesis.

A good start for your design is to use reference design shipped with your target board.

For example, with an Altera’s board, you may use the standard design. Standard reference designs for Altera’s boards are available here .

Xenomai compilation for NIOS II

You should first verify that uClinux without Xenomai can run on the target board.

The typical actions for building the uClinux kernel for NIOS II (available here ) are:

If $uClinux-dist is the path of NIOS II uClinux release, for example:

/home/test/nios2-linux/uClinux-dist


$ cd $uClinux-dist
$ make menuconfig
$ make vendor_hwselect SYSPTF=<path to your system ptf>
$ make

If the NIOS II cross-compiler is called nios2-linux-gcc, a typical compilation will look like:


$ $xenomai_root/scripts/prepare-kernel.sh --arch=nios2 \
  --adeos=$xenomai_root/ksrc/arch/nios2/patches/adeos-ipipe-2.6.26-rc6-nios2-* \
  --linux=$linux_tree
$ $xenomai_root/configure --host=nios2-linux
$ make install DESTDIR=$uClinux-dist/romf
$ cd $uClinux-dist
$ make

Testing the installation

Testing the kernel

In order to test the Xenomai installation, you should first try to boot the patched kernel. The kernel boot logs should show messages like:


I-pipe: head domain Xenomai registered.
Xenomai: hal/<arch> started.
Xenomai: scheduling class idle registered.
Xenomai: scheduling class rt registered.
Xenomai: real-time nucleus v2.6.1 (Light Years Away) loaded.
Xenomai: debug mode enabled.
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.

Where <arch> is the architecture you are using. If the kernel fails to boot, or the log messages indicates an error status instead, see the Troubleshooting guide

Testing the user-space support

In order to test Xenomai user-space support, launch the latency test:


$ xeno latency

The latency test should display a message every second with minimal, maximal and average latency values, such as:


# xeno latency -T 25
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      1.615|      1.923|      9.846|       0|     0|      1.615|      9.846
RTD|      1.615|      1.923|      9.692|       0|     0|      1.615|      9.846
RTD|      1.538|      1.923|     10.230|       0|     0|      1.538|     10.230
RTD|      1.615|      1.923|     10.384|       0|     0|      1.538|     10.384
RTD|      1.615|      1.923|     11.230|       0|     0|      1.538|     11.230
RTD|      1.615|      1.923|      9.923|       0|     0|      1.538|     11.230
RTD|      1.615|      1.923|      9.923|       0|     0|      1.538|     11.230
RTD|      1.615|      1.923|     11.076|       0|     0|      1.538|     11.230
RTD|      1.615|      1.923|     10.538|       0|     0|      1.538|     11.230
RTD|      1.615|      1.923|     11.076|       0|     0|      1.538|     11.230
RTD|      1.615|      1.923|     10.615|       0|     0|      1.538|     11.230
RTD|      1.615|      1.923|     10.076|       0|     0|      1.538|     11.230
RTD|      1.615|      1.923|      9.923|       0|     0|      1.538|     11.230
RTD|      1.538|      1.923|     10.538|       0|     0|      1.538|     11.230
RTD|      1.615|      1.923|     10.923|       0|     0|      1.538|     11.230
RTD|      1.538|      1.923|     10.153|       0|     0|      1.538|     11.230
RTD|      1.615|      1.923|      9.615|       0|     0|      1.538|     11.230
RTD|      1.615|      1.923|     10.769|       0|     0|      1.538|     11.230
RTD|      1.615|      1.923|      9.153|       0|     0|      1.538|     11.230
RTD|      1.538|      1.923|     10.307|       0|     0|      1.538|     11.230
RTD|      1.615|      1.923|      9.538|       0|     0|      1.538|     11.230
RTT|  00:00:22  (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      1.615|      1.923|     11.384|       0|     0|      1.538|     11.384
RTD|      1.615|      1.923|     10.076|       0|     0|      1.538|     11.384
RTD|      1.538|      1.923|      9.538|       0|     0|      1.538|     11.384
---|-----------|-----------|-----------|--------|------|-------------------------
RTS|      1.538|      1.923|     11.384|       0|     0|    00:00:25/00:00:25
#

If the latency test displays an error message, hangs, or displays unexpected values, see the Troubleshooting guide .

If the latency test succeeds, you should try next to run a latency test under load to evaluate the latency test of your system, the xeno-test script allows doing that. see xeno-test(1) manual page for more details.

[1] Each option enabled by default can be forcibly disabled by passing --disable-<option> to the configure script

[2] Depending on the gcc versions the flag for armv7 may be -march=armv7-a or -march=armv7a