3.2编译Xenomai内核

原创于 2025-12-09 12:00:08 发布 · 695 阅读

17 ·

CC 4.0 BY-SA版权

文章标签：

#Xenomai #RTOS

Xenomai RTOS 编程与实践专栏收录该内容

13 篇文章

订阅专栏

3.2 编译Xenomai内核镜像

Xenomai代码仓库已经从 ·https://source.denx.de/Xenomai 迁移到 https://gitlab.com/Xenomai

2025/8/7 迁移公告: https://lore.kernel.org/xenomai/a1f7db9c-0422-4b1a-a762-d5ad2d9edf99@siemens.com/

Xenomai内核层的代码分为两大部分：Dovetail和Cobalt。

第一步，应用Dovetail的patch补丁到目标Linuxlinux-sdk内核代码树，得到linux-dovetail内核代码。

第二步，应用Cobalt的patch补丁到linux-dovetai内核代码，得到最终的linux-xenomai内核代码。

第三步，配置并编译linux-xenomai内核代码，构建出Linux镜像。

首先，检查Xenomai3硬件支持列表https://v3.xenomai.org/hardware/，如果你的硬件已经在Xenomai的硬件支持列表中，那么恭喜你省去了上述的第一步。这是最理想的状态，可以直接使用linux-dovetail内核，仓库地址为https://gitlab.com/Xenomai/linux-dovetail.git。

退而求其次，你可以搜索https://gitlab.com/Xenomai/legacy/download-archive。在这个网址中，发布了对应某些内核版本的patch文件，如果某个patch文件与你的目标内核完全匹配或接近，也是一种较好的选择。这些patch是使用git diff生成的，需要使用git apply或patch -p1来应用到你的目标内核上。

如果上述两种情况都不合适，那么就来到了最不理想的状况，你只能自己想办法生成patch，然后再移植dovetail到你的目标内核。

另外，需要考虑Dovetail和Cobalt的版本匹配问题。

Xenomai最新的稳定版本是v3.2.4，发布于2023-09-15。社区并没有提及与其匹配的Dovetail的版本。反观Dovetail，其本身没有版本号的概念，不断跟着内核版本向前迭代。以5.10.y内核为例，在代码树上可以发现，社区会定期为某些内核版本打tag，可以理解为可用版本。

Xenomai/Dovetail	版本号	日期
Xenomai v3.2.4	v3.2.4	2023-09-14
v5.10.191-dovetail1	v5.10.191	2023-08-14
v5.10.195-dovetail1	v5.10.195	2023-09-21
v5.10.199-dovetail1	v5.10.199	2023-11-05
v5.10.209-dovetail1	v5.10.209	2024-03-07
v5.10.214-dovetail1	v5.10.214	2024-04-10
v5.10.221-dovetail1	v5.10.221	2024-07-11

经过实践发现，Xenomai v3.2.4与v5.10.221-dovetail1的组合，编译会出错。原因在于Linux 5.10.220引入的6d256a904cd7 file: Rename __close_fd to close_fd and remove the files parameter。

本文选择Xenomai v3.2.4和v5.10.199-dovetail1的组合，来演示如何把Xenomai移植到目标Linux内核代码树。

演示的工作目录为/root/xenomai：

root/xenomai
├── linux-build     Linux构建输出目录，好处是将构建输出与源代码分离，保持源代码目录的整洁
├── linux-dovetail  Dovetail内核树
├── linux-sdk       目标内核树
└── xenomai-v3.2.4   Xenomai目录

3.2.1 应用Dovetail内核补丁

1. Dovetail软件仓库与分支

Dovetail软件仓库的地址为https://gitlab.com/Xenomai/linux-dovetail.git。

根据2025年1月16日社区邮件“Dovetail situation report”的讨论内容，Dovetail支持的SLTS/LTS内核版本包括v5.10.y，v6.1.y和v6.12.y。

LTS分支，跟随www.kernel.org更新：

v5.10.y
- v5.10.y-dovetail
- v5.10.y-dovetail-rebase
v6.1.y
- v6.1.y-dovetail
- v6.1.y-dovetail-rebase
v6.12.y
- v6.12.y-dovetail
- v6.12.y-dovetail-rebase

SLTS分支，跟随www.cip-project.org更新

v5.10.y-cip
- v5.10.y-cip-dovetail merging LTS branch for kernel 5.10
- v5.10.y-cip-dovetail-rebase rebasing LTS branch for kernel 5.10
v6.1.y-cip
- v6.1.y-cip-dovetail
- v6.1.y-cip-dovetail-rebase

其中，带有[-rebase]后缀的分支，代表此分支不断地git rebase到社区的内核；而不带[-rebase]后缀的分支，代表此分支不断地git merge到社区的内核。

在处理backport（将更改从较新版本的代码库移植到旧版本）时，git rebase和git merge是两种常用的Git操作，它们各有优缺点。

Git Rebase 可以创建一个更加线性的项目历史，使得理解项目的进展更为直观。由于rebase会重写提交历史，这可能会导致问题，特别是当这些提交已经被共享给其他开发者的时候。这样做可能会引起混乱，并需要所有团队成员重新同步他们的工作。

Git Merge 保持了原始的分支结构和提交历史，这对于理解特定变更为何被引入非常有用。使用merge会导致项目历史中出现大量的合并提交，有时会使项目历史看起来较为杂乱。在某些情况下，merge可能会导致更多的合并冲突，特别是当两个分支都有大量独立的改动时。

对于Dovetail的用户而言，从学习Dovetail的角度，应当选择git rebase分支，方便根据线性提交历史来一步一步学习；从产品的角度出发，总是希望可以保留完整的历史信息，方便连续的获取Dovetail的更新，应当选择使用git merge分支。

本文选择v5.10.y-dovetail分支，同时它也是linux-dovetail软件仓库的默认分支。

2. 拉取Dovetail源码

git clone https://gitlab.com/Xenomai/linux-dovetail.git

从中国拉取位于国际服务器上的Git仓库速度较慢且容易中断。为了改善这种情况，一般来说，可以尝试以下几种方法：

使用镜像服务：一些组织或社区会提供公共Git仓库的国内镜像，尝试搜索是否有该Git仓库的国内镜像地址可以使用。Xenomai虽然在Gitee建立国内镜像仓库https://gitee.com/xenomai，但是其中并不包含linux-dovetail。
分步克隆：如果仓库非常大，考虑使用浅克隆(git clone --depth=1)以减少需要下载的数据量，之后根据需要逐步加深历史记录。这是一个切实可行的方法，分步骤讲解一下。

（1）步骤 1：浅克隆

git clone --depth=1 https://gitlab.com/Xenomai/linux-dovetail.git

–depth ：指定克隆的深度，即从最新提交开始往回数的提交数目。例如，–depth 1 只会获取最新的那次提交，而不会获取更早的提交历史。
默认情况下只会获取默认分支（通常是v5.10.y-dovetail）的最新提交。如果你想切换到另一个分支，你需要首先确保那个分支的数据已经被获取到本地仓库中。

（2）步骤 2: 获取所有分支的信息

你需要更新本地仓库以了解远程的所有分支信息。

git remote set-branches origin '*' 
git fetch --depth=1
git branch -r

git remote set-branches origin '*'命令告诉Git你需要追踪远程仓库的所有分支。
git fetch --depth=1会以指定的深度（例如最近的一次提交）获取所有分支的信息。
git branch -r列出所有远程分支，方便找到你想要切换的那个分支。

（3）步骤 3: 切换到目标分支

找到你想切换的目标分支名称后（比如origin/v5.10.y-dovetail-rebase），可以使用checkout命令来创建并切换到该分支：

git checkout -b v5.10.y-dovetail-rebase origin/v5.10.y-dovetail-rebase

（4）步骤 4：拉取更深的提交记录

请注意，由于你最初是用--depth=1进行克隆的，所以每个分支只包含最新的提交。如果你需要更多历史记录，需要调整fetch命令中的深度值，或者在必要时取消浅克隆的限制（如使用git fetch --unshallow）。这样，你可以确保在切换分支后拥有足够的历史记录来进行后续操作。

一般来说，Dovetail包含大概300个左右的commit。

git fetch --depth=300

如果一次性获取–depth=300的深度，依然遇到网络中断的问题，可以减少每次拉取的深度，多次拉取，最终达到想要的深度。

（5）步骤 5：获取整个历史记录

如果你想获取整个历史记录，可以使用如下命令取消浅克隆的限制：

git fetch --unshallow

3. 生成`v5.10.y-dovetail-rebase`分支的patch与打patch

（1）切换到目标分支v5.10.y-dovetail-rebase

git checkout v5.10.y-dovetail-rebase

（2）找到Linux 5.10.199的tag信息

git tag | grep 5.10.199
v5.10.199
v5.10.199-dovetail1

（3） git format-patch生成patch set或单一patch文件

patch set

按commit的提交历史，生成各自的patch文件。

git format-patch -o /root/xenomai/linux-dovetail-5.10.199-patch/ v5.10.199..v5.10.199-dovetail1
../linux-dovetail-5.10.199-patch/0001-printk-introduce-raw-console-channel.patch
../linux-dovetail-5.10.199-patch/0002-ARM-introduce-raw-console-device.patch
../linux-dovetail-5.10.199-patch/0003-tty-pl011-add-raw-console-channel.patch
...snip...
../linux-dovetail-5.10.199-patch/0225-net-dovetail-introduce-net-struct-extension.patch
../linux-dovetail-5.10.199-patch/0226-arm64-dovetail-Fix-undefinstr-break-trap-handling.patch
../linux-dovetail-5.10.199-patch/0227-genirq-irq_pipeline-fix-state-irq-tracing-for-local_.patch

在目录linux-dovetail-5.10.199-patch下，总共生成了227个patch文件，对应于227个commit提交，能清晰地线性地展示dovetail的开发历史。

单一patch文件

git format-patch v5.10.199..v5.10.199-dovetail1 --stdout > /root/xenomai/linux-dovetail-5.10.199.patch

仅会生成一个patch文件，方便移植。

（4）打patch到目标内核

git format-patch生成的patch，可以使用git am来移植。假设你的目标内核所在目录为/root/xenomai/linux-sdk:

cd /root/xenomai/linux-sdk
git am --reject /root/xenomai/linux-dovetail-5.10.199.patch

当使用 git am 应用补丁时，如果某个补丁导致了冲突而无法自动应用，Git 默认会暂停整个应用过程，并要求用户手动解决冲突。然而，如果你使用了 --reject 选项，Git 将尝试尽可能多地应用补丁，并将那些无法应用的部分写入 .rej 文件中（即拒绝文件）。这样你就可以查看这些文件来了解哪些部分未能成功应用，并手动进行修正。

4. 生成`v5.10.y-dovetail`分支的patch文件与打patch

v5.10.y-dovetail分支是总是执行git merge，导致dovetail和kernel.org的commit提交信息按时间交错排列，建议使用git diff生成单一patch文件。

（1）切换到目标分支v5.10.y-dovetail

git checkout v5.10.y-dovetail

（2）找到Linux 5.10.199的tag信息

git tag | grep 5.10.199
v5.10.199
v5.10.199-dovetail1

（3）使用git diff生成单一patch文件

git diff v5.10.199 v5.10.199-dovetail1 > /root/xenomai/linux-dovetail-5.10.199.patch

（4）打patch到目标内核

git diff生成的patch文件，可以使用patch -p1或git apply来合并到待移植的内核，推荐使用git apply。假设你的目标内核所在目录为/root/xenomai/linux-sdk:

cd /root/xenomai/linux-sdk
patch -p1 < /root/xenomai/linux-dovetail-5.10.199.patch

cd /root/xenomai/linux-sdk
git apply --reject /root/xenomai/linux-dovetail-5.10.199.patch

当使用 git apply 应用一个补丁文件时，如果 Git 遇到了不能干净地应用的部分（即存在冲突），默认情况下它会停止操作，并报错提示哪些文件存在冲突。然而，通过使用 --reject 选项，Git 会尽可能多地应用补丁中的更改，并将那些无法应用的（发生冲突的）部分保存到 .rej 文件中。

这意味着，对于每个发生冲突的文件，都会生成一个对应的 .rej 文件，其中包含了未能成功应用的补丁内容。这样，你就可以手动检查并应用这些变更，而不需要从头开始解决整个冲突。

3.2.2 应用Xenomai Cobalt内核补丁

1. 下载

最新版本：邮件列表官宣下载链接

[ANNOUNCE] Xenomai 3.2.4 released：
https://lore.kernel.org/xenomai/dcdfa1d8-5ac2-4d6b-b059-e8cb37e522ff@siemens.com/T/#u

Download Xenomai 3.2.4：
https://source.denx.de/Xenomai/xenomai/-/archive/v3.2.4/xenomai-v3.2.4.tar.bz2

3.1及以前历史版本

3.1及以前历史版本归档链接：

https://gitlab.com/Xenomai/legacy/download-archive

2. 安装cobalt内核补丁

解压xenomai源码包，并进入源码目录

$ tar -xvf xenomai-v3.2.4.tar.bz2
$ cd xenomai-v3.2.4

使用脚本prepare-kernel.sh对linux内核源码打cobalt内核补丁

脚本prepare-kernel.sh使用帮助如下

$ ./scripts/prepare-kernel.sh --help
usage: prepare-kernel --linux=<linux-tree> [--dovetail=<dovetail-patch>]|[--ipipe=<ipipe-patch>] [--arch=<arch>] [--outpatch=<file> [--filterkvers=y|n] [--filterarch=y|n]] [--forcelink] [--default] [--verbose]

--linux=<linux-tree>: 指定需要打Xenomai补丁的目标Linux内核树的路径。
- 既可以使用绝对路径，也能使用相对路径。脚本会在后续处理过程中将相对路径转换为绝对路径。
- 若未指定，脚本会提示用户输入
- 如果使用了--defaut，则使用默认路径/lib/modules/$(uname -r)/source，不会提示用户输入
--dovetail=<dovetail-patch>: 指定 Dovetail 类型的 IRQ 管道补丁文件路径。
- 既可以使用绝对路径，也能使用相对路径。脚本会在后续处理过程中将相对路径转换为绝对路径。
- 本质上是调用patch -p1 -f -s < $pipeline_patch来应用指定的patch补丁文件
- 推荐提前手动对Linux内核源码应用Dovetail补丁，则不需要指定该参数。
- 此参数和--ipipe=<ipipe-patch>为二选一的关系，当前社区主推Dovetail。
--arch=<arch>: 指定目标内核的架构，如 x86、arm、arm64/aarch64 等。
- 若未指定，脚本会根据系统信息推断默认架构，并提示用户确认。
- 如果使用了--defaut，则直接使用根据系统信息推断的默认架构，不会提示用户确认。
- Dovetail已经放弃支持Powerpc

commit b184e36ca5489eac624ea6be5e503edc618221d1
Author: Jan Kiszka jan.kiszka@siemens.com
Date: Wed Dec 15 17:45:30 2021 +0100

Drop PowerPC architecture support

While this architecture served well in many use cases over a long time,
it’s time is over, new chip chips are no longer being released.

As Xenomai is moving its core completely over Dovetail, there is no
support in Dovetail for PowerPC and that is not going to change, it’s
time to drop this arch from the core in order to move forward.

This addresses the majority of artifacts, just few traces in drivers and
documentations are left for later cleanups.

Signed-off-by: Jan Kiszka jan.kiszka@siemens.com

--outpatch=<file>: 指定输出xenomai patch。
- 默认情况下如果不使用该参数，prepare-kernel.sh打cobalt内核补丁时，只会在linux源码目录建立与cobalt源码的软连接文件。
- 推荐使用该参数生成xenomai内核的补丁，再去对linux使用该补丁。
- 既可以输入绝对路径，也能输入相对路径，但是不能使用~，否则报错。
--filterkvers=y|n: 内核版本相关的补丁过滤选项。不推荐使用。
- y 表示忽略非内核版本特定的更改。
- n 表示忽略内核版本特定的更改
- 如果不指定，则脚本内部设为默认值b，表示不根据内核版本过滤。
--filterarch=y|n|b: 架构相关的补丁过滤选项。不推荐使用。
- y 表示忽略非架构特定的更改
- n 表示忽略架构特定的更改
- 如果不指定，则脚本内部设为默认值b，表示不根据架构过滤。
--forcelink: 强制创建符号链接，即使源文件和目标文件已经相同。不推荐使用。
--default: 自动使用默认值，无需用户交互输入。不推荐使用。
--verbose: 启用详细输出模式
- 脚本会在执行过程中输出更多信息，方便调试和查看进度。

最终总结一下推荐的使用方式：

提前手动对Linux内核源码应用Dovetail补丁，则避免使用--dovetail=<dovetail-patch>
避免使用默认值，总是显示地使用--linux=<linux-tree>、--dovetail=<dovetail-patch>、--outpatch=<file>
在失败的情况下，使用--verbose得到更多的输出信息。

假设你的目标内核所在目录为/root/xenomai/linux-sdk，且已经打上了Dovetail的patch。

首先，进入xenomai-v3.2.4目录，针对目标内核，生成一个Xenomai内核patch文件/root/xenomai/xenomai-v3.2.4.patch。

cd /root/xenomai/xenomai-v3.2.4
./scripts/prepare-kernel.sh --linux=/root/xenomai/linux-sdk --arch=arm64 --outpatch=../xenomai-v3.2.4.patch

其次，回到目标内核目录/root/xenomai/linux-sdk，使用patch -p1或git apply应用补丁：

cd /root/xenomai/linux-sdk
patch -p1 < /root/xenomai/xenomai-v3.2.4.patch

cd /root/xenomai/linux-sdk
git apply --reject /root/xenomai/xenomai-v3.2.4.patch

可能会报告一些关于whitespace的警告，可以忽略。也许你可以写一个patch去修复这些格式问题。

../xenomai.patch:190: trailing whitespace.
                hlist_for_each_entry_safe(ecurr, enext,
../xenomai.patch:568: trailing whitespace.
        hlist_for_each_entry(ecurr,
../xenomai.patch:3812: trailing whitespace.

../xenomai.patch:6228: space before tab in indent.
        if (cobalt_call_extension(timer_delete, &timer->extref, ret) && ret < 0)
../xenomai.patch:7653: trailing whitespace.

warning: squelched 232 whitespace errors
warning: 237 lines add whitespace errors.

3.2.3 配置Xenomai内核

以arm64平台为例，演示如何配置并编译内核镜像。

确保你已经进入linux-sdk目录：

1. 生成内核默认配置文件

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=../linux-build defconfig

ARCH=arm64 指定目标架构为 ARM64（AArch64）。
CROSS_COMPILE=aarch64-linux-gnu- 指定交叉编译工具链的前缀。
O=../linux-build 指定输出目录为 ../linux-build。
defconfig 基于arch/arm64/configs/defconfig生成默认的内核配置文件（.config）。

2. 配置内核

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=../linux-build menuconfig

menuconfig 是一个基于文本界面的内核配置工具，通过交互式菜单让用户启用、禁用或修改内核功能和模块。它依赖 ncurses 库提供用户友好的界面，方便开发者根据需求定制内核配置（如硬件支持、文件系统等），最终生成或更新 .config 文件。

在这里插入图片描述

如上图所示，在配置页面已经出现了[*] Xenomai/cobalt选项，并且默认处于选中状态。同时，其下方出现了警告信息。
这些警告信息来自于 Linux 内核配置过程，具体来说是在使用 menuconfig 工具进行内核配置时出现的提示。它们主要涉及的是几个特定的内核选项可能带来的影响。

关于页面迁移（Page Migration, CONFIG_MIGRATION）的警告

页面迁移功能允许操作系统在运行时动态地将物理内存页从一个节点迁移到另一个节点，这在多处理器或NUMA架构中特别有用。然而，这个过程可能会增加系统延迟，因为它涉及到内存管理操作。实时系统对延迟非常敏感，需要禁用此功能以减少潜在的延迟增加。

以关闭页面迁移CONFIG_MIGRATION为例，详细展开具体操作步骤：

(1) 在内核配置界面，按/打开搜索框，输入CONFIG_MIGRATION，按回车键搜索。

在这里插入图片描述

(2) 在搜索结果页面，每个匹配的结果前面都会有数字编号，例如下图中的(1) -> Memory Management options。按数字键1即可直接跳转到匹配的选项。

在这里插入图片描述

(3) 取消CONFIG_MIGRATION

在这里插入图片描述

CONFIG_MIGRATION是被CONFIG_CMA和CONFIG_COMPACTION所依赖的，需要全部关闭。但是三个配置项都处于不可取消状态：

-*- Allow for memory compaction
-*- Page migration
-*- Contiguous Memory Allocator

通过查看<Help>信息，发现有链式依赖关系，需要全部取消。

CONFIG_MIGRATION [=y] selected by
    CONFIG_COMPACTION [=y] selected by
        CONFIG_TRANSPARENT_HUGEPAGE [=y]
    CONFIG_CMA [=y] selected by
        DRM_ETNAVIV [=m]

最终，得以关闭页面迁移CONFIG_MIGRATION。

Device Drivers  --->
  Graphics support  --->
    < > ETNAVIV (DRM support for Vivante GPU IP cores)

Memory Management options  --->
  [ ] Allow for memory compaction
  [ ] Page migration 
  [ ] Transparent Hugepage Support
  [ ] Contiguous Memory Allocator

关于 APM、CPU频率调节、ACPI ‘processor’ 或 CPU空闲特性与Xenomai共存的警告

这里提到的APM（高级电源管理）、CPU频率调节（如Intel的SpeedStep）、ACPI 'processor’以及CPU空闲状态管理等功能主要用于节能和性能优化。但是，当与Xenomai一起使用时，可能会引发冲突或不稳定，因为这些功能可能会影响CPU的执行上下文或调度策略，进而干扰Xenomai提供的实时性保证。需要禁用上述功能以避免潜在的问题。

按照关闭CONFIG_MIGRATION相同的思路与操作方法，解决节能和性能优化相关的警告。

关闭APM（高级电源管理）

搜APM关键字，发现相关的配置项默认已经关闭，无需额外处理。

Symbol: APM_EMULATION [=n]

Symbol: APM_POWER [=n]

Symbol: INPUT_APMPOWER [=n]

Symbol: PMAC_APM_EMU [=n]

关闭ACPI ‘processor’

[*] ACPI (Advanced Configuration and Power Interface) Support  --->
  < >   Processor

关闭CPU频率调节和空闲状态管理

注意，因为依赖关系，需先关闭ACPI ‘processor’。

CPU Power Management  --->
  CPU Idle  --->
    [ ] CPU idle PM support
  CPU Frequency scaling  --->
    [ ] CPU Frequency scaling

解决上述所有警告之后，在内核配置界面的警告信息会消失，如下图所示：

在这里插入图片描述

选中配置界面下方的的<Save>，在弹出的窗口中，保持默认文件名.config，按回车保存。

在这里插入图片描述

回到配置界面后，正常退出即可。

3.2.4 编译Xenomai内核镜像

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=../linux-build -j all

以下是命令中每个参数的解释，每行一个：

ARCH=arm64: 指定目标架构为 ARM 64 位（aarch64）。
CROSS_COMPILE=aarch64-linux-gnu-: 设置交叉编译工具链前缀，用于生成目标平台的二进制文件。
O=../linux-build: 指定输出目录为 ../linux-build，所有生成的文件将存储在此目录中。
-j: 启用并行编译，加快构建速度，默认使用系统的所有 CPU 核心。可以通过 -jN 的形式明确指定并行任务的数量，例如 -j4 表示同时运行 4 个任务。
all: 构建目标，表示编译所有内容（通常是默认目标）。执行make help，可用发现all代表着会所有带有*前缀的目标都会被构建。

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- help

Other generic targets:
  all             - Build all targets marked with [*]
* vmlinux         - Build the bare kernel
* modules         - Build all modules

Devicetree:
* dtbs             - Build device tree blobs for enabled boards

Architecture specific targets (arm64):
* Image.gz      - Compressed kernel image (arch/arm64/boot/Image.gz)

3.2.5 Cobalt内核启动参数

Cobalt内核接受一组参数，这些参数应该由引导加载程序在内核命令行中传递。当内核启动后，可以在/sys/module/xenomai/parameters/中查看这些参数。

Cobalt支持的参数一直在演变，下表列出了当前支持的参数、说明及默认值。

参数名称	描述	默认值
`xenomai.supported_cpus`	实时CPU掩码。该掩码表示哪些CPU核心允许运行Xenomai的实时任务。	-1（=所有CPU核心）
`xenomai.allowed_group=<gid>`	只允许指定用户组的进程创建实时任务，其他用户组的进程无法使用 Xenomai 实时服务。是Linux用户组的ID，其成员应被Cobalt核心允许访问。	完全开放访问，所有用户组的进程都可以创建实时任务，没有任何组权限限制
`xenomai.sysheap_size=<kbytes>`	设置Cobalt核心用于分配运行时对象的内部内存堆大小。该值以千字节(kB)为单位表示。	4096 kB
`xenomai.state=<state>`	设置Cobalt核心在启动时的初始状态，可以是enabled（启用）、stopped（停止）或disabled（禁用）。有关这些状态的描述，请参阅关于corectl(1)工具的文档。	enabled（启用）
`xenomai.watchdog_timeout`	CONFIG_XENO_OPT_WATCHDOG=y启用看门狗功能，用于检测失控的Cobalt线程。启用后，当实时线程持续运行超过设定时间段且在此期间未与Linux交互时，看门狗将被触发。触发时当前线程会被移出实时域，并立即接收来自Linux内核的SIGDEBUG信号。看门狗的超时时间可通过CONFIG_XENO_OPT_WATCHDOG_TIMEOUT参数设置。	4秒
`xenomai.smi=<state>`	x86特有的：设置SMI补救的状态。可能的值有disabled（禁用）、detect（检测）和enabled（启用）。	detect（检测）
`xenomai.smi_mask=<source-mask>`	x86特有的：要在SMI控制寄存器中屏蔽的一组位。	1（=全局禁用）

另外，下述参数已经被删除，不再支持，避免误用。

xenomai.clockfreq=<hz-freq> 覆盖用于测量时间间隔的实际时间时钟频率。

commit 758b316321b06070eea627d2766eef5842da480b
Author: Philippe Gerum <rpm@xenomai.org>
Date:   Sun Jan 31 15:45:39 2021 +0100

    cobalt/init: ipipe: remove clock frequency override

    Regarding the frequency of the clock hardware, the kernel knows
    better. This parameter dates back to the dark ages when the kernel
    might not have detected variations in (per-CPU) clock frequency, which
    is no more an issue nowadays.

    Actually, we do want to rely on the non-trivial logic the kernel has
    to figure out that value dynamically for us.

    So let's drop the user override for this parameter.

    Signed-off-by: Philippe Gerum <rpm@xenomai.org>
    Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

xenomai.timerfreq=<hz-freq> 覆盖用于编程定时器触发的实际时间定时器频率。

commit 64289ae2d896f07c005881b3a349f4aae6f902be
Author: Philippe Gerum <rpm@xenomai.org>
Date:   Sun Jan 31 15:45:38 2021 +0100

    cobalt/machine: ipipe: drop timer frequency setting

    The only user of the timer frequency setting was the machine-specific
    timer calibration handler, which is now gone. Therefore we don't need
    to know the timer frequency anymore. As a consequence, we don't care
    about overriding its value as determined by the I-pipe either.

    Let's drop all of these antiquated bits.

    Signed-off-by: Philippe Gerum <rpm@xenomai.org>
    Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>