Kernel configuration :: Xenomai 3 | 糖醋鱼的小破站

type

Post

status

Published

date

Feb 24, 2025

slug

2025/02/24/Kernel-configuration-Xenomai-3

summary

Typical configuration issues

x86 processor type

Pick the exact processor your x86 platform is sporting, at the very least the most specific model which is close to the target CPU, not a generic placeholder. For instance generic i586 implies that no TSC feature is available from the CPU, which in turn would require Xenomai to emulate a time stamp counter, leading to suboptimal performances.

请选择您的 x86 平台所使用的确切处理器，至少是最接近目标 CPU 的特定型号，而不是通用的占位符。例如，通用 i586 意味着 CPU 没有 TSC 功能，这反过来又要求 Xenomai 模拟时间戳计数器，从而导致性能不理想。

Xenomai 3 requires the hardware TSC feature from x86 CPUs.

Xenomai 3 需要 x86 CPU 的硬件 TSC 功能。

If you have to run Xenomai 2 on some low-end x86 platform lacking a hardware TSC with a legacy kernel predating 3.2, then make sure to disable CONFIG_INPUT_PCSPKR. With any later version, the appropriate settings are applied automatically.

如果必须在缺乏硬件 TSC 的低端 x86 平台上运行 Xenomai 2，且内核是 3.2 之前的旧版本，那么请确保禁用 CONFIG_INPUT_PCSPKR。之后的版本会自动应用相应的设置。

Power management

You should not disable power management globally, the only configuration options which should be disabled in this area are:

您不应该全局禁用电源管理，唯一应该在此区域禁用的配置选项是

CONFIG_APM

CONFIG_ACPI_PROCESSOR

In particular, keeping the ACPI enabled bears no risks of high latencies, whereas disabling it may prevent your system from booting correctly.

特别是，启用 ACPI 不会带来高延迟的风险，而禁用 ACPI 则可能导致系统无法正常启动。

USB

In the same vein, do not disable USB, but enable support for your USB host controller(s), as the host controller code, when starting, disables support for “legacy USB emulation”, which is a source of high latencies.

同样，不要禁用 USB，但要启用对 USB 主机控制器的支持，因为主机控制器代码在启动时会禁用对 "传统 USB 仿真 "的支持，这是造成高延迟的原因之一。

CPU Frequency scaling

Disable CONFIG_CPU_FREQ, this option creates issues with Xenomai timing code, as well as unpredictable run-time for your real-time threads, and possibly high latencies when CPU frequency is changed dynamically.

禁用 CONFIG_CPU_FREQ，该选项会导致 Xenomai 定时代码出现问题，实时线程的运行时间不可预测，CPU 频率动态变化时可能会出现高延迟。

Timing should be correct with recent processors having the constant_tsc flag though.

不过，采用 constant_tsc 标志的最新处理器的定时应该是正确的。

However, the ondemand governor cannot track Xenomai threads running in primary mode, i.e. under the control of the co-kernel. Such threads look suspended from its point of view, although they may be consuming CPU. Therefore, the governor won’t switch the CPU to a higher frequency although the real-time activity would justify it.

不过，按需调速器无法跟踪在主模式下运行的 Xenomai 线程，即受协核控制的线程。从调速器的角度看，这些线程处于暂停状态，尽管它们可能正在消耗 CPU。因此，调速器不会将 CPU 切换到更高的频率，尽管实时活动证明这样做是合理的。

Configuration Options

CONFIG_CPU_FREQ - Disable

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.

这使得 CPU 频率可随工作量而调节，但许多 CPU 也会改变 TSC 计数频率，因此当 CPU 时钟发生变化时，TSC 计数频率对精确计时毫无用处。此外，有些 CPU 可能需要几毫秒才能提升到全速。

CONFIG_CPU_IDLE - Disable

Allows the CPU to enter deep sleep states, increasing the time it takes to get out of these sleep states, hence the latency of an idle system. Also, on some CPU, entering these deep sleep states causes the timers used by Xenomai to stop functioning.

允许 CPU 进入深度睡眠状态，增加了从睡眠状态恢复的时间，从而增加了空闲系统的延迟。此外，在某些 CPU 上，进入深度睡眠状态会导致 Xenomai 使用的计时器停止工作。

CONFIG_CC_STACKPROTECTOR

This option may be enabled on x86_64 only with Xenomai 2, x86_64 and x86_32 indifferently with Xenomai 3.

只有 Xenomai 2 可以在 x86_64 上启用该选项，Xenomai 3 可以在 x86_64 和 x86_32 上启用该选项。

CONFIG_APM - Disable

The APM model assigns power management control to the BIOS, and BIOS code is never written with best latency in mind. If configured, APM routines are invoked with SMI priority, which bypasses the interrupt pipeline entirely. Resorting to the Xenomai workaround for SMI won’t help here.

APM 模式将电源管理控制分配给 BIOS，而 BIOS 代码的编写从未考虑过最佳延迟。如果配置了 APM，则会以 SMI 优先级调用 APM 例程，从而完全绕过中断流水线。使用 Xenomai 的 SMI 变通方法在这里无济于事。

CONFIG_ACPI_PROCESSOR - Disable

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.

对于 BIOS 中支持 ACPI 的系统，该 ACPI 子选项会安装一个空闲处理程序，使用 ACPI C2 和 C3 处理器状态来节省功耗。CPU 必须从这些睡眠状态中预热，从而增加了延迟，而延迟的方式取决于 BIOS 的 ACPI 表和代码。你也许可以使用 idle=poll boot-arg 来抑制睡眠状态，测试一下就知道了。在最近的 Linux 版本中（可能从 Linux 2.6.21 左右开始），acpi 处理器模块在加载时会禁用本地 APIC。这会导致 Xenomai 定时器初始化失败。这就是禁用该选项的第二个原因。

CONFIG_INTEL_IDLE - Disable

Just like CONFIG_ACPI_PROCESSOR, this idle driver sends the CPU into deep C states, also causing huge latencies because the APIC timer that Xenomai uses may not fire anymore.

与 CONFIG_ACPI_PROCESSOR 一样，这种空闲驱动程序会让 CPU 进入深 C 状态，也会导致巨大的延迟，因为 Xenomai 使用的 APIC 定时器可能不再启动。

CONFIG_INPUT_PCSPKR - Disable

CONFIG_PCI_MSI

This option may be enabled, provided the following operations on interrupt lines are always done from a mere Linux context, aka secondary mode, and never from the real-time mode:

可以启用该选项，条件是中断线路上的下列操作始终在纯 Linux 上下文（又称二级模式）下进行，而不是在实时模式下进行：

hooking/requesting

releasing

enabling/unmasking

disabling/masking

挂钩/请求

释放

启用/解除屏蔽

禁用/屏蔽

Practically, the requirement above translates into calling rtdm_irq_request(), rtdm_irq_free(), rtdm_irq_enable(), rtdm_irq_disable() exclusively from a non-rt handler in any RTDM driver. This includes the →open(), →close() and →ioctl_nrt() handlers.

实际上，上述要求意味着在任何 RTDM 驱动程序中，只能从非rt 处理程序调用 rtdm_irq_request()、rtdm_irq_free()、rtdm_irq_enable()、rtdm_irq_disable()。这包括 →open()、→close() 和 →ioctl_nrt() 处理程序。

Booting with or without an initramfs?

By default, distributions kernels boot using an initramfs. This means that the kernel needs no particular built-in support, anything can be built as a module. These modules are loaded in a first boot stage, from the initramfs, then the final root filesystem may be mounted and the kernel boot may continue normally.

默认情况下，发行版内核使用 initramfs 启动。这意味着内核不需要特定的内置支持，任何东西都可以作为模块构建。这些模块会在第一启动阶段从 initramfs 中加载，然后挂载最终的根文件系统，内核启动也会正常进行。

So, if you start from a distribution kernel, you will have to generate an initramfs containing the modules supporting the basic hardware needed to mount root filesystem. Eache distribution provides its way to generate an initramfs for a new kernel.

因此，如果从发行版内核启动，就必须生成一个 initramfs，其中包含支持挂载根文件系统所需基本硬件的模块。 Eache 发行版提供了为新内核生成 initramfs 的方法。

If, on the other hand, you want to boot without an initramfs, you will have to build inside the kernel, and not as a module, all the components necessary for mounting your root filesystem. This means: the disk controller support, the support for SCSI disks if this controller is an SCSI controller or is supported by a new style ATA controller, the support for IDE disks if this controller is supported by an old-style Parallel ATA controller, the support for your NIC if booting through network, and the support for the filesystem used by your root filesystem (e.g. EXT3, NFS, etc…).

另一方面，如果想在没有 initramfs 的情况下启动，就必须在内核中（而不是作为模块）构建挂载根文件系统所需的所有组件。这意味着：磁盘控制器支持、SCSI 磁盘支持（如果该控制器是 SCSI 控制器或受新式 ATA 控制器支持）、IDE 磁盘支持（如果该控制器受旧式并行 ATA 控制器支持）、网卡支持（如果通过网络启动）以及根文件系统使用的文件系统支持（如 EXT3、NFS 等）。

There is one thing for sure, however: you can not boot a kernel where everything is built as a module, without an initramfs.

但有一点是肯定的：如果没有 initramfs，就无法启动一切都以模块形式构建的内核。

Preposterous latency figures

If running the latency test shows definitely weird latency figures (i.e. hundreds of micro-seconds and more), the usual suspect on x86 is the System Management Interrupt .

如果运行延迟测试显示出绝对奇怪的延迟数字（即数百微秒或更多），在 x86 系统上通常会怀疑是系统管理中断。

Make sure to read the recommendations about tweaking the SMI configuration VERY CAREFULLY, otherwise you may damage your hardware.

请务必仔细阅读有关调整 SMI 配置的建议，否则可能会损坏硬件。

Optimized CPU and platform settings

By tuning your kernel settings close to the real hardware, you can avoid useless overhead (e.g. CONFIG_SMP on non-SMP systems) or suboptimal code generation.

通过调整内核设置使其接近真实硬件，可以避免无用的开销（如在非 SMP 系统上的 CONFIG_SMP）或次优代码生成。

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.

例如，选择 CONFIG_M586 或更早版本时，Xenomai 需要模拟芯片上的 TSC 来执行计时任务，即使 CPU 实际上提供了这种特殊的硬件计数器；不幸的是，模拟 TSC 的速度很慢，这显然会对最坏情况下的延迟数据产生负面影响，尽管如果内核配置得当，硬件性能可能会好得多。

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.

因此，在作为实时平台使用的 x86 平台上，第一条规则就是不要盲目相信你最喜欢的发行版制造商提供的 “随处可用 ”默认内核的配置，而是要根据实际硬件调整该配置。