tokenpocket最新版官网|xenomai

作者： tokenpocket最新版官网

2024-03-13 23:49:44

实时系统Preempt RT与Xenomai之争！谁更主流，谁更实时？ - 知乎

实时系统Preempt RT与Xenomai之争！谁更主流，谁更实时？ - 知乎首发于嵌入式专栏切换模式写文章登录/注册实时系统Preempt RT与Xenomai之争！谁更主流，谁更实时？创龙科技Tronlong国内领先的嵌入式产品平台提供商选择争论一直存在大家知道EtherCAT是实时现场总线技术，当我们开发一款支持EtherCAT总线的控制器时，实时操作系统的选择不仅对于产品本身是最重要的一部分，而且对产品研发的整个过程也影响深远。根据EtherCAT主站提供商Acontis公司对全球新客户的情况统计，选择实时Linux系统的客户比重在过去10年逐年增加，Acontis公司2019年所有新客户中采用实时Linux作为控制器操作系统的比例已超过60%。从近几年的经验中，我们注意到一些客户对实时性的理解存在偏差和误区。此外，对于实时Linux系统的选择，主要是采用Preempt RT还是Xenomai存在大量争论。结合我们在以往项目中的经验以及实时Linux系统专家Jan Altenberg 2015年在Embedded Linux会议上的讲演，我们整理出此文。希望可以帮助大家理解实时性，同时对在Preempt RT和Xenomai之间做出合适的选择提供参考。什么是“实时性”我们在和客户的交流中注意到，部分工程师会把实时性与执行速度或性能相混淆。Altenberg在讲演中特别强调：实时性与执行速度和性能无关！无论是实时操作系统还是实时现场总线，实时性的含义不是越快越好，而是在规定的时间内完成任务的确定性(Determinism and Timing Guarantees)。如果我们给实时性下定义，那么实时性就是关于时间的确定性。实时性的一个重要特点，是在规定的时间段内完成规定的任务。在技术讨论中，有时客户对EtherCAT协议不存在对错误数据自动重传的机制有疑问，很显然是忽略了实时性的这一特性。EtherCAT主站的工作原理，是按时间段（循环周期）发送数据。每个循环周期内的过程数据(Process Data)，只在这个周期内到达从站才有意义，因此EtherCAT在协议层面不会自动在后续周期重新发送之前周期发送失败的过程数据。在Embedded Linux会议讲演中，Altenberg还表述了一个很有趣的观点，他希望大家忘掉“软实时”（即Soft Real Time的提法），只存在实时和非实时的、确定性和非确定性的区别。能保证确定性，那就是“硬实时”(Hard Real Time)。Xenomai和Preempt RT实现原理目前，对实时Linux方案的选择主要在Xenomai和Preempt RT之间。Xenomai是在Linux Kernel外增加独立的微内核的双内核方案，而Preempt RT是标准的单内核实时方案。Xenomai的实时应用运行在微内核中，而把Linux系统作为微内核的一个低优先级任务。与RTAI不同，Xenomai实时性在用户空间实现。当高优先级的实时应用程序不在微内核运行时，Linux才有可能获得运行时间。下图是以Xenomai为代表的双内核方案的原理图。图 1 Xenomai双内核方案原理图Altenberg认为双内核实时方案有几个明显不足。首先，维护工作量大。由于Linux不是直接在硬件上运行，因此Xenomai在维护微内核的同时还需要维护硬件抽象层HAL层，这导致Xenomai的更新速度通常会比主线Linux落后一步。其次，不能使用标准C库。Xenomai实时应用的开发需要特殊的工具和库以及单独的API。主流的实时Linux方案是基于Preempt RT的单内核方案，通过最大限度地提高Linux内核中的可抢占部分，使Linux本身具备实时性。下图为Premept RT单内核原理图。图 2 Preempt RT单内核方案原理图由于大约80%的Preempt RT功能已经融合进Linux主线，因此任何Linux开发者都可以使用Preempt RT的Linux内核组件。Preempt RT不仅仅把Linux变成实时系统，同时提高了Linux的稳定性。Preempt RT被广泛接受并拥有庞大的社区，开发者不需要深入了解Preempt RT，而是使用标准C库开发实时应用。开发者不需要深入了解Preempt RT，而是使用标准C库开发实时应用。Preempt RT就是Linux系统，Preempt RT的实时应用也是Linux的应用。随着剩下的20%功能逐渐融入Linux主线，未来有可能不需要在Linux安装补丁程序而直接使用Preempt RT。Xenomai和Preempt RT性能对比实时性能最重要的指标是延时的大小。网上有不少流传很广的文章，表示Xenomai在延迟方面有优势。Altenberg并不认同这种观点，他认为之所以得出这样的结论，是对Preempt RT的错误配置造成的。为了确切证实，他们的团队分别找了Xenomai和Preempt RT专家，在相同的硬件平台上进行了测试。测试对象是高负载下Xenomai和Preempt RT在延时Latency和抖动Jitter两个方面的表现情况。Altenberg强调了两点，第一是测试的最坏结果才有意义。另外一点是系统拿到中断后，在用户空间的应用响应延时是对应用最有意义的。在用户空间的测试结果，Xenomai和Preempt RT最坏延时都在90-95微秒左右。当在Linux系统中只使用单核测试时，Preempt RT最坏的延时只有大约80微秒，结果优于Xenomai。在Kernel空间延时的测试结果，Xenomai最高延时在30微秒，单核运行Preempt RT的最高延时60微秒。如果使用FIQ快速中断的话，Preempt RT的最坏延时也可达到30微秒，平均延时甚至到达10微秒。专家观点盟通指出：测试表明，对于开发人员最有意义的用户空间内最坏延时方面，两种实时方案在该性能指标上展示出近乎相同的数据。但是Preempt RT几乎已经和Linux内核主线合并，从系统的开发和维护角度，Preempt RT的工作量与标准Linux相同。这使Preempt RT与Xenomai相比具备更多优势，例如工程师开发更简单、产品生命周期更长、系统维护工作更容易等。实时系统工业平台，尽在创龙科技创龙科技很多ARM嵌入式处理器平台已支持Preempt RT与Xenomai实时拓展，主要平台如下。更多型号或细节内容，欢迎在评论区留言~图 3 创龙科技Linux实时系统平台支持列举版权声明：本文主要内容基于“北京盟通科技有限公司”授权提供的文件，由“创龙科技”进行整理得出。感谢“盟通科技”的慷慨支持，让更多人了解Linux系统的“实时拓展”选择知识。编辑于 2023-06-19 10:56・IP 属地广东LinuxLinux 开发赞同 111 条评论分享喜欢收藏申请转载文章被以下专栏收录嵌入式专栏嵌入式DSP、ARM、FPGA多核技

Xenomai概述及实时化AMR64 Linux实践 - 知乎

Xenomai概述及实时化AMR64 Linux实践 - 知乎首发于足式仿生机器人 DIY手帐切换模式写文章登录/注册Xenomai概述及实时化AMR64 Linux实践cjrcl北京航空航天大学凝聚态物理硕士近日一个Key Project在硬件和软件两方面皆需推翻重来，因为我们生产的系统在CAN通讯和UART通讯上存在速率、频率和实时性的不足。于是在硬件组采用的新方案中通讯芯片保险起见将配以芯片厂商的驱动程序，我看了其说明发现它有适配RTAI或者Xenomai修饰过的Linux操作系统的版本。这两者都是用来实时化Linux操作系统的，而这也正是应用软件方面需要的，所以开始吧。看了RTAI的网站https://www.rtai.org/有如下文字：RTAI supports:

x86 (with and without FPU and TSC)

x86_64

ARM (obsolete support; it is being reworked)那么去看Xenomai吧，因为要运行的应用程序是ARM64的。Xenomai 3的主页是https://source.denx.de/Xenomai/xenomai/-/wikis/home，在此可见Xenomai是支持ARM64架构的，还有它包含两个部分Cobalt Core跟Interrupt Pipeline。同时此页面提到了未来的Xenomai 4，并给出了其主页https://evlproject.org/，我发现这里把实时化Linux操作系统讲得相当地全面，而且Xenomai 4的两个部分EVL Core跟Dovetail Interface与上述Xenomai 3的两个部分一一对应，于是就研读这个主页吧。在简体中文互联网我没有发现对实时化Linux操作系统比较系统性的概述，找到的基本都是操作步骤的罗列，甚至都没有讲到应用程序如何去利用实时特性，而这里是需要稍稍修改应用程序源代码的。在讲Xenomai 4之前，有必要提及Preempt-RT此另一类实时化Linux的代表。可参考https://wiki.linuxfoundation.org/realtime/rtl/blog页面的Preempt-RT history一节的起始部分，我转述如下：实时化Linux有两条路线，一、双内核，即以一个微内核为实时内核，在其上以idle task的形式运行通用Linux内核——也就是说只有当实时内核上的关键任务不繁忙时通用内核才能够占用剩余CPU资源，RTAI和Xenomai都属于这一类；二、核内实时，即修改Linux内核本身以使之具有实时特性，Preempt-RT属于这一类。前一类的拥趸认为没有必要强加实时特性于整个内核逻辑，而将有实时性要求的任务运行于一个自治(autonomous)的实时微内核里在性能上和成本上有优势。在操作上最简单的是Preempt-RT，基本是下载Linux内核源码，配置内核参数，编译、安装这四步，这里不做讨论。下面先按其EVL Core跟Dovetail Interface两个部分概述Xenomai 4，然后叙述用Xenomai 3实时化ARM64 Ubuntu 18.04的实际操作。Xenomai 4概述计算机中的实时指的是对请求的响应时间是非常短且有界的(very short and bounded)。EVL Core关键应用程序和驱动程序在EVL Core上运行，在多CPU系统中EVL Core可独占一个或多个CPU，在单CPU系统中EVL Core和通用操作系统内核跑在同一个CPU上。运行于EVL Core上的任务享有绝对的高优先级，可以抢占(preempt)通用操作系统内核上即使是处在临界区(critical section)的任务。临界区是指同一时间内不可以有超过一个进程在其中执行的指令序列，这种抢占在即使是Preempt-RT的Linux中是不可能的。EVL Core程序的编程遵循一般Linux编程模型(common Linux programming model)，EVL Core提供libevl让EVL进程调用。一个EVL进程包含一个或多个EVL线程以及任意数量的并行的常规POSIX线程。EVL线程是由调用pthread_create()或main()生成的常规POSIX线程再发出evl_attach_self()系统调用而生成的，此系统调用将调用者绑定至EVL Core以使之可以利用EVL Core提供的实时、低延迟服务，直至它调用evl_detach_self()以脱离EVL Core或自行结束。若EVL线程必须满足实时性要求，则它只能依赖libevl提供的服务。如果此线程调用依赖通用操作系统内核服务的一般C库服务，那么EVL Core会把它降级到通用操作系统内核上，此时它便失去了实时性保证。像string()、strcpy()和memcpy()是不依赖通用操作系统内核服务的，在关键代码中可以放心调用，而在关键代码中直接或间接地调用malloc()或stdio中的函数是必须被禁止的。在关键工作循环中只能有阻塞型的EVL服务如evl_wait_flags()、evl_get_sem()、evl_poll()和oob_read()等。很明显我们需要修改应用程序代码以适应EVL Core，列如用oob_read()替换read()。对于应用程序有如此，对于驱动程序亦是如此。为Xenomai 3编写驱动程序需要全面修改常规驱动，为此Xenomai 3引入了一个编程模型RTMD (Real-Time Driver Model, https://xenomai.org/documentation/xenomai-3/html/xeno3prm/group__rtdm.html)，最终实时驱动代码库将成为与常规驱动代码库无法调和的一个分支。Xenomai 4做出了改变以避免旧方法带来的驱动程序代码的难以维护，它着眼实时驱动与常规驱动的主要区别，只在输入输出(I/O)方面为常规驱动添加实时功能，而保持设备检测、初始化和管理配置方面的代码不变。此I/O实时功能可为EVL Core所知晓和利用，常规I/O跟实时I/O是不会同时发生的。Dovetail Interface在双内核实时化方案中需要一个中介层来耦合自主实时核与通用核，这一中介层的原型实现是服务Xenomai 3 Cobalt Core的I-pipe，而Dovetail是其继任者。Dovetail为实时核引入了一个高优先级的执行级——out-of-band stage，这相对于通用核所在的in-band stage。Dovetail接管CPU硬件中断，使得所有的设备中断行为如不可屏蔽中断(NMI)，out-of-band stage的自主核优先处理中断，in-band stage的通用核的中断接收受Dovetail节制。中断请求(IRQ)从out-of-band执行级流向in-band执行级，似乎处在一个中断管线之中，此管线逻辑是直接整合进Linux内核IRQ层的。以Xenomai 3改造ARM64 Linux的实践(Part One)为什么是Part One？因为在走到这一步时我发现我一时野心太大了。用于替换手上ARM64 Linux操作系统内核的in-band内核基本上必须是编译用Xenomai 3修改过的ARM64 SoC硬件厂商提供的其自定义的内核源码而来的，不似在x86范畴内基本上从https://www.kernel.org/下载一份内核源码来修改，编译并安装就能成功。这是由于当前ARM平台的硬件还不够规范统一，或者说当前Linux内核还不能很好地兼容所有硬件厂商的平台，而需要硬件厂商的一定程度的自定义。没有恰好针对来自硬件厂商的内核源码的I-pipe，因此我先以Xenomai 3来改造x86 Linux吧。以Xenomai 3改造x86_64 Linux的实践对象操作系统是x86_64 Ubuntu 18.04，就在其上native编译还有安装。首先安装必须工具：sudo apt install make gcc libncurses-dev libssl-dev libelf-dev flex bison其次下载内核源码包、I-pipe和Xenomai 3：wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.4.77.tar.xz

wget https://xenomai.org/downloads/ipipe/v5.x/x86/ipipe-core-5.4.77-x86-2.patch

wget https://source.denx.de/Xenomai/xenomai/-/archive/v3.1.1/xenomai-v3.1.1.tar.bz2在这里可以看到对应某一Linux内核版本有特定的I-pipe。上述文件都在/home/user/Documents/下，余下的具体操作步骤是：1. 给内核源码打补丁cd /home/user/Documents/

tar -Jxf linux-5.4.77.tar.xz

tar -jxf xenomai-v3.1.1.tar.bz2

./xenomai-v3.1.1/scripts/prepare-kernel.sh --linux=/home/user/Documents/linux-5.4.77/ --ipipe=/home/user/Documents/ipipe-core-5.4.77-x86-2.patch --arch=x86_642. 配置内核参数cd linux-5.4.77/

make ARCH=x86_64 menuconfig现在是伪图形化配置，在图中可以看到Xenomai/Cobalt一项，其下有两个警告，为了消除它们我参考https://blog.csdn.net/qq_22654551/article/details/106038163做了如下配置（要按这里列出的顺序来）：General setup --->

Preemption Model (Preemptible Kernel (Low-Latency Desktop)) --->

(X) Low-Latency Desktop

Processor type and features --->

Processor family (Core 2/newer Xeon) --->

(X) Core 2/newer Xeon

[*] Multi-core scheduler support

[ ] CPU core priorities scheduler support

Power management and ACPI options --->

CPU Frequency scaling --->

[ ] CPU Frequency scaling

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

< > Processor

CPU Idle --->

[ ] CPU idle PM support

Memory Management options --->

[ ] Contiguous Memory Allocator

[ ] Transparent Hugepage Support

[ ] Allow for memory compaction

[ ] Page migration

[ ] Virtualization ----

Processor type and features --->

[ ] Linux guest support ----如此，便没有Warning啦。3. 编译先做两处文件修改：在/home/user/Documents/linux-5.4.77/arch/x86/kernel/process.h里加上对/home/user/Documents/linux-5.4.77/arch/x86/kernel/ipipe.c里定义的一个函数的声明void __ipipe_halt_root(int use_mwait);还有将/home/user/Documents/linux-5.4.77/.config（这是一个隐藏文件）中CONFIG_SYSTEM_TRUSTED_KEYS="debian/canonical-certs.pem"一行双引号内的内容去掉。随后make -j 4 vmlinux modules bzImage至于其中vmlinux、modules和bzImage的意义，看make help的输出就知道啦。后来会出现这个错误：ERROR: "__ipipe_dispatch_irq" [drivers/pinctrl/intel/pinctrl-intel.ko] undefined!链接生成pinctrl-intel.ko内核模块失败。因为实际中我们用不着它，所以解决办法很简单，去除它就行啦，只要注释掉/home/user/Documents/linux-5.4.77/drivers/pinctrl/Kconfig中的source "drivers/pinctrl/intel/Kconfig"一行和/home/user/Documents/linux-5.4.77/drivers/pinctrl/Makefile中的obj-$(CONFIG_X86) += intel/一行，最后再试即会最终完成。4. 安装很直观，有两步：sudo make modules_install以安装内核模块到/lib/modules/；sudo make install以安装内核，生成initramfs还有设置grub引导。5. 结尾提醒一下，这种自己编译的内核是会被EFI的Secure Boot机制禁止的，因此记得关Secure Boot。进/home/user/Documents/xenomai-v3.1.1/目录编译、安装libcobalt等的小任务我想就不必赘述了。上图：有了在x86_64平台的经验，可以去接触ARM64啦。编辑于 2022-08-03 14:49Linux 内核实时操作系统赞同 268 条评论分享喜欢收藏申请转载文章被以下专栏收录足式仿生机器人 DIY手帐该专栏将介绍我学习制作仿生足式机器人学习的相

【原创】xenomai内核解析之xenomai初探 - 沐多 - 博客园

会员

周边

新闻

博问

AI培训

云市场

所有博客

当前博客

我的博客

我的园子

账号设置

简洁模式 ...

退出登录

沐多

博客园

首页

新随笔

联系

管理

【原创】xenomai内核解析之xenomai初探

目录xenomai初探一、xenomai 3组成结构1.1 xenomai 31.2 xenomai3 结构二、 xenomai 3源码介绍1.1 编译构建相关文件与目录1.2 官方应用示例1.3 测试工具1.4 应用库和内核源码1.5 系统工具三、xenomai实时性测试1.1 latency和jitter1.2 串口实时性测试1.3 GPIO实时性测试四、xenomai各种接口应用编译1.1 编译参数获取1.2 链接参数获取五、xenomai proc文件信息介绍1.1 实时外设中断信息ipipedovetail1.2 查看实时核信息xenomai调度cpu硬件timer与延迟信息faultsheapregistry1.3 调度与任务状态线程状态系统统计信息参考链接

xenomai初探

前两篇文章介绍了实时linux几种方案，并完成xenomai系统构建安装，下面我们更进一步认识一下xenomai，本文先介绍xenomai组成结构和源码，然后在ti am335x平台上，通过硬件外设来测试xenomai系统的实时性，最后介绍xenomai运行时proc文件系统内容，方便查看系统和实时任务运行状态信息。更多xenomai相关信息，见本博客其他文章。

一、xenomai 3组成结构

xenomai历史概况：

xenomai3于2015年正式发布，由于嵌入式设备、工业设备操作系统更新迭代比较慢，可能还有很多设备运行xenomai2操作系统，xenomai2已经过时，在此不再介绍。xenomai3由xenomai2演变而来，其原理相通，所以明白xenomai3再去看xenomai2也能很快上手。

1.1 xenomai 3

xenomai3于2015年正式发布，从xenomai3开始支持两种方式构建linux实时系统，分别是cobalt 和 mercury。

cobalt ：添加一个实时内核核，双核结构。具有实时内核cobalt、实时驱动模型RTDM、实时应用POSIX接口库libcobalt，然后再基于libcobalt实现的其他API skins，如Alchemy API、VxWorks® emulator、pSOS® emulator等(具体查看应用编程接口文档https://xenomai.org/documentation/xenomai-3/html/xeno3prm)，即VxWorks、pSOS应用程序可稍微修改源码就可以在xenomai上编译运行。

需要说明的是Alchemy API是xenomai除posix外的官方编程接口，提供了更接近于传统RTOS编程方式的编程接口，对于不熟悉linux应用开发的MCU开发人员也能很快上手。在xenomai2上Alchemy API是xenomai的原生编程接口，性能最好，posix API是在Alchemy API上实现的skin。在xenomai3相反，Alchemy API、VxWorks、pSOS均基于posix接口实现，也正因为这样诞生了mercury方式。

mercury ：基于直接修改linux内核源代码的PREEMPT RT，应用空间在glibc之上，添加xenomai API库，如下图所示。可以在不支持cobalt内核时，可使用该方法运行xenomai应用；也就是说你还可以通过mercury方式在PREEMPT RT上编译运行VxWorks、pSOS等接口的应用程序。当然，也可不需要PREEMPT RT，直接使用linux，只是实时性就……

可以看出，xenomai社区开发者为保护用户煞费苦心，既方便基于VxWorks、pSOS等系统写的代码应用迁移到xenomai，也方便xenomai接口编写的程序迁移到PREEMPT RT运行。

1.2 xenomai3 结构

mercury只是在glibc上加了一层皮，不是接下来研究的对象。我们看cobalt ，从底层硬件驱动、内核空间到用户空间，保证了实时任务的实时性。其整体结构如图所示。

在内核空间，在标准linux基础上添加一个实时内核Cobalt，得益于基于ADEOS（Adaptive Domain Environment for Operating System)，使Cobalt在内核空间与linux内核并存，并把标准的Linux内核作为实时内核中的一个idle进程在实时内核上调度。

2000年，Karim发表了一篇名为《操作系统的自适应域环境》的论文（即Adeos,Adaptive Domain Environment of Operating System），该论文描述了一种简单而智能的方案，用于在同一系统上运行的多个内核之间共享公共硬件资源。他通过“pipeline”抽象来说明在x86硬件上共享中断的基本机制，根据整个系统给定的优先级，依次向每个内核传入中断。他倡导一种对硬件中断进行优先级排序的新方法，以便可以开发基于Linux内核的实时扩展，而无需使用当时已被某些专有RTOS供应商申请授予专利方法（这里的RTOS供应商和专利指的就是WindRiver和RTlinux使用的RTHAL技术）。

ADEOS (Adaptive Domain Environment for Operating System)，提供了一个灵活的环境，可以在多个操作系统之间或单个OS的多个实例之间共享硬件资源，从而使多个优先级域可以同时存在于同一硬件上。早期在xenomai 2上使用。

2005年6月17日，Philippe Gerum发布用于Linux内核的I-pipe，I-pipe基于ADEOS，但是I-pipe更精简，并且只处理中断，xenomai3使用I-pipe和后来改进的dovetail。

ADEOS ,其核心思想是Domain,也就是范围的意思，linux内核有linux内核的范围，cobalt内核有cobalt内核的范围。

两个内核管理各自范围内的应用、驱动、中断；

两个domain之间有优先级之分，cobalt内核优先级高于linux内核；

I-pipe优先处理高优先级域的中断，来保证高优先级域的实时性。

高优先级域可以通过I-pipe 向低优先级域发送各类事件等。

在用户空间，添加针对实时应用优化的库--libcobalt，libcobalt提供POSIX接口给应用空间实时任务使用，应用通过libcobalt让实时内核cobalt提供服务。

驱动方面，xenomai提供实时驱动框架模型RTDM（Real-Time Driver Model）,专门用于Cobalt内核，基于RTDM进行实时设备驱动开发，为实时应用提供实时驱动。RTDM将驱动分为2类：

•字符设备(open/close, read, write, ioctl)，如UART,UDD,SPI……

•协议设备(socket, bind, send, recv, etc)，如UDP/TCP,CAN,IPC,……

中断方面，I-Pipe(interrupt Pipeline)分发Linux和Xenomai之间的中断，并以Domain优先级顺序传递中断。I-Pipe传递中断如下图所示，对于实时内核注册的中断，中断产生后能够直接得到处理，保证实时性。对于linux的中断，先将中断记录在i-log，等实时任务让出CPU后，linux得到运行，该中断才得到处理。

实时内核cobalt与非实时内核linux相结合，既能提供工业级RTOS的硬实时性能，又能利用linux操作系统非常出色的生态、网络和图形界面服务，在产品的开发周期和成本控制方面都有巨大优势。

二、 xenomai 3源码介绍

xenomai源码目录如下：

$ tree -L 1

├── aclocal.m4

├── autom4te.cache

├── configure

├── configure.ac

├── CONTRIBUTING.md

├── debian

├── demo

├── doc

├── include

├── kernel

├── lib

├── README

├── scripts

├── testsuite

├── tracing

└── utils

1.1 编译构建相关文件与目录

debian目录将xenomai 应用库构建为debian软件包的包信息和脚本。

scripts目录和aclocal.m4、configure、configure.ac、Makefile.am xenomai库编译相关文件，在安装xenomai的文章中已使用，详见官方文档：https://source.denx.de/Xenomai/xenomai/-/wikis/Installing_Xenomai_3#library-install。

1.2 官方应用示例

demo目录中分别提供了posix和alchemy接口的应用示例：

posix接口应用示例：

cyclictest与linuxcyclictest基本一致的xenomai posix接口应用。xenomia与Preempt-RT实时性对比时，使用相同参数通过该工具进行测试对比。

bufp-label、bufp-readwrite、iddp-label、iddp-sendrecv：xenomai实时任务间通过本地socket 进行块数据、流数据通信示例。

xddp-label、xddp-echo、xddp-stream：xenomai实时应用与普通linux任务通信示例，其底层实现本博客有详细的文章分析介绍。

alchemy接口应用示例：

altency是实时性测试工具latency alchemy API实现版本，可对比POSIX与alchemy API接口的实时性能差异。

cross-link: alchemy接口实现的串口实时性测试工具，将本地的两个UART 外设RX-TX交差相连，应用通过向一路UART发送本地时间数据，另一路UART接时间数据来测试串口收发数据的抖动情况，后文会对该测试详细介绍。

1.3 测试工具

其中目录testsuite内是xenomai测试工具和 smokey单元测试用例，详细如下：

clocktest：cobalt内核与linux核之间时钟漂移测试工具。由于xenomai内核与linux共存，两个内核各自有时间子系统对时间进行度量，两个系统对时间的度量可能存在不一致的情况(漂移)，该工具用于测试该漂移，后面会专门有一篇文章介绍。

latency：实时性测试工具，通过它结合stress等压力工具，能测试xenomai在各种工况下的实时性能，该工具类似于linux下的实时性能测试工具cyclitest，下一节内容通过该工具进行实时性能测试;

spitest：SPI通讯延迟测试；

switchtest:上下文切换测试。创建各种类型的线程，并尝试在这些线程之间切换上下文，打印每秒切换上下文的计数。

xeno-test：运行Xenomai的基本测试/基准测试，先运行一些单元测试，然后在“load-command”生成的负载下运行latency测试;

gpiobench:通过gpio测试实时性，两种方式：

两个gpio硬件相连，从一个 gpio 输出引脚发送高电平脉冲，并从另一个 gpio 引脚接收中断，测量两个事件之间的时间，后文会对该测试详细介绍。

一个gpio 引脚接收中断后，从另一个gpio 输出确认信号，测量两个信号之间的延迟(可通过外部示波器等设备测量两个事件之间经过的时间)。

1.4 应用库和内核源码

kernel和lib分别存放了实时内核和应用库的源代码。

cobalt

kernel

├── cobalt

└── drivers

对于kernel部分源码结构与linux内核结构一致，其中cobalt就是xenomai的实时内核cobalt源码，包含了调度、rtdm实时驱动框架等。

drivers

一般嵌入式应用中，需要操作外设，或从外设获取数据，需要为操作系统编写硬件设备驱动。同样，xenomai需要要实时驱动配合才能发挥xenomai的实时性能。drivers中是官方提供的一些实时驱动和实时TCP/IP协议栈(rtnet)源码，其中包含了上面说到个一些测试工具的内核部分。

├── analogy #实时模拟数据处框架

├── autotune #延迟校准驱动，应用autotune使用

├── can #实时can协议栈、部分CAN控制器实时驱动

├── gpio #实时gpio驱动

├── gpiopwm #gpiopwm 驱动框架

├── ipc #实时应用间本地socket通讯机制

├── Kconfig

├── Makefile

├── net #实时以太网协议栈、部分实时网卡驱动

├── serial #实时串口驱动框架、部分实时串口驱动

├── spi #实时SPI驱动框架、部分master驱动

├── testing #用户态测试程序需要的内核态部分

└── udd #用户态实时IO驱动框架

我们可以看到xenomai官方驱动源码里支持的外设比较少，对于X86平台，得益于X86平台的兼容性，xenomai支持比较好，X86平台应用场合一般很少用到如SPI等低速设备，大部分用到的网卡驱动均具备。

但对于ARM，由于ARM IP核授权方式，各个芯片厂商不同芯片外设各式各样，如果需要使用xenomai，这就需要开发者投入资源，按照RTDM来开发使用到实时外设驱动。大家都习惯了linux主线或芯片厂商提供Linux SDK开箱即用的方便快速，这就劝退了大部分人。

主要原因是 RTOS应用于特定领域，芯片厂商未对其做支持，xenomai社区开发人员太少（意味着机会）无法代替芯片厂商支持这么多平台。另外xenomai开发有一定门槛，导致没有更多的开发者参与贡献，这就造成了恶性循环。

据了解，随着国产化替代推进，目前国内部分芯片厂商为了让自家的芯片能应用到这些特殊领域，开始关注和适配xenomai，比如龙芯。部分国产操作系统厂商也开始研究和引用xenomai技术，比如openEuler+xenomai的二进制镜像发布等。

说到这，那这里附上国内适配或使用 xenomai 的公司，不保证完全准确，仅供参考：

由官方发起支持 xenomai 的芯片厂商：龙芯、飞腾

使用 xenomai，基于或借鉴或copy xenomai 来发展自主操作系统内核的公司：华为庞加莱实验室、中科时代、中科航迈、国讯芯微、之江实验室、鹏城实验室、深圳伟创控制、深圳关维科技、亿嘉和、西控电气、深圳市大族智控、沈机（上海）智能系统研发设计、博朗特、先导智能、格力电器、 OPPO、周立功、深圳华讯达、深圳晗竣雅…

1.5 系统工具

针对实时内核，xenomai提供了多种系统工具，其源码位于 utils目录下，默认编译安装到/usr/xenomai/sbin/目录，其中：

autotune 是xenomai延迟调整工具，可调整中断延迟、内核调度延迟、用户调度延迟，内核中称为gravity，为什么需要调整延迟？如下图，一个实时任务定时10us，但操作硬件timer、中断响应、其他内核代码的执行等都需要时间，为了让用户态任务准时唤醒，设置硬件timer下一个中断唤醒时间时，需要将这些时间减去，才是应用程序真正的唤醒时间，这也是后文中latency测试时存在负值的原因，autotune就是用来调整这些时间的。

corectl为实时内核控制工具，通过该工具可控制实时内核的启动和停止。

rtps名字可以看出等同于linux的 ps，用于查看实时任务的状态，其输出结果是通过解析/proc/xenomai/sched/下的文件得到。

xenomai提供了实时TCP/IP 协议栈，其中一些工具如下：

rtcfg、rtnet：rtnet 配置工具

rtifconfig、rtping、rtroute、与linux ifocnfig、ping、route等等效.

三、xenomai实时性测试

硬件环境： TI AM335x Cortex-A8 600MHZ DDR2 128MB spiNorflash 16MB

软件环境：5.4.106 + xenomai 3.1

压力条件：stress -c 10 --vm 4 --vm-bytes 16M

以下数据基于该环境测试得出。

1.1 latency和jitter

事件预期发生与实际发生的时间之间的时间称为延迟(latency)，实际发生的最大时间与最小时间之间的差值称为抖动(Jitter)，两者均可表示实时性。根据实时性的定义，延迟必须是确定的，不能超过deadline，否则将会产生严重的后果。

在否决定使用一个实时系统时，需要结合具体应用场景来评估该实时系统是否符合，若不符合则需要考虑对现有系统优化优化或者更换方案。

中断延迟——中断触发和中断服务开始处理之间的时间。

唤醒延迟——从最高优先级任务被唤醒到它实际开始运行的时间。这也可以称为调度延迟。

优先级反转——高优先级线程必须等待低优先级线程拥有的资源的时间。

cyclitest仅提供用户态实时任务的抖动测试，xenomai官方测试程序latency分别提供了用户态、内核态实时任务和内核态软件 timer的测试，其中内核态timer近似的模拟中断的响应时间，因为一个软件timer的处理，底层是由硬件timer时间到期来触发中断处理的，其中用户态抖动测试原理如下图所示。

nostress

user-task ltaency(us)

kernel-task ltaency(us)

kernel-Timer(us)

最小值

-1.200

-3.360

-1.200

平均值

2.037

-0.606

1.693

最大值

27.120

13.880

14.600

抖动

28.32

17.24

15.8

stress

user-task ltaency(us)

kernel-task ltaency(us)

kernel-Timer(us)

最小值

3.629

-3.720

-1.360

平均值

9.346

-0.682

1.543

最大值

29.289

15.880

13.920

jitter

25.66

19.6

15.28

这里laten为负值，表示内核中默认中断gravity、内核调度gravity、用户调度gravity比实际值偏大，如果你的应用场景不允许任务提前唤醒，如何调整？在真实生产环境可通过运行autotune得出准确值后：

重新配置编译安装内核

-> Xenomai/cobalt (XENOMAI [=y])

-> Latency settings

(0) User scheduling latency (ns)

(0) Intra-kernel scheduling latency (ns)

(0) Interrupt latency (ns)

通过写/proc/xenomai/latency或/proc/xenomai/clock/coreclk动态修改，见后文。

1.2 串口实时性测试

源码简介中说到cross-link，cross-link是串口实时性测试工具，能反应系统整体实时性能，cross-link要求的硬件连接图如下：

UART1和UART2是xenomai RTDM驱动管理的两个设备，RX-TX交差相连，UART0是普通linux驱动管理的设备，这里作为终端使用。cross-link应用程序逻辑如下：

测试原理为，两个RT 线程 Task1和 Task2，各打开一路串口，Task1读取时间T1通过UART发送，Task2阻塞接收数据T_1，接收后读取此时系统时间T_2，计算T1与T2之间的差值就是，整个串口通讯的耗时。如果是操作系统是实时的，传输速率不变，那么这个差值T是一个确定的范围的值，在us级范围内波动，这个波动就能反映操作系统的实时性能。

linux stress -c 10 -m 2 ----vm-bytes 16MB压力下，波特率3.68Mbps，进行10W次收发测试，结果如下：

...

Nr | write->irq | irq->read | write->read |

-----------------------------------------------------------

1000 | 666440 |18446744073708932056 | 46880

2000 | 666120 |18446744073708932216 | 46720

3000 | 666480 |18446744073708932616 | 47480

4000 | 666480 |18446744073708932656 | 47520

5000 | 667680 |18446744073708934496 | 50560

6000 | 666280 |18446744073708932376 | 47040

7000 | 666440 |18446744073708932296 | 47120

8000 | 666160 |18446744073708932616 | 47160

9000 | 666120 |18446744073708932296 | 46800

.......

90000 | 666080 |18446744073708932136 | 46600

91000 | 666880 |18446744073708933136 | 48400

92000 | 667200 |18446744073708933736 | 49320

93000 | 666320 |18446744073708932576 | 47280

94000 | 666200 |18446744073708932096 | 46680

95000 | 666160 |18446744073708931776 | 46320

96000 | 665960 |18446744073708932096 | 46440

97000 | 666280 |18446744073708932096 | 46760

98000 | 666440 |18446744073708932376 | 47200

99000 | 666240 |18446744073708932176 | 46800

-----------------------------------------------------------

mini | 665680 |18446744073708931296 | 45360

max | 674700 |18446744073708946766 | 69850

Transfer size:8 Byte period:10000000 ns

main : delete write_task

main : delete read_task

需要说明的write->irq和irq->read值为什么比较大？该测试程序xenomai2中就存在，write->irq 表示Task1写数据时间T1到Uart2产生接收中断Tirq之间的时间差，由于T1是用户态调用alchemy接口读取的时间，而Tirq是内核态中断处理函数读取的时间，在xenomai3上用户态和内核态的读取的时间值存在一个固定的差值，xenomai2中没有该问题，irq->read同理，所以这两个数据差距比较大，这里看总时间write->read即可。

从测试数据可以看出，最小时间为45.360us,最大时间69.850us ，即 Task1写数据到内核态---RTDM驱动将数据写入Uart1控制器发送---线路传输---Uart2中断接收处理---唤醒 Task2---上下文切换Task2--数据拷贝到Task2用户态继续运行，整个流程时间抖动在24.49us内，与上面latency测试程序基本相符。

1.3 GPIO实时性测试

gpiobench:提供了两种通过实时gpio测试系统实时性的方式：

方式1

类似串口的方式，两个gpio口相连，从一个 gpio 输出引脚发送高电平脉冲，并从另一个 gpio 引脚接收中断，测量两个事件之间的时间；

gpiobench会记录两个时间T1和T2并在测试完成时打印，stress -c 10 -m 2 --vm-bytes 16M条件下，测试100W次，其中T1如下（单位us）：

root@xxxxx:/app/bin# ./gpiobench -o 19 -i 20 -l 100000 -q

----rt task, gpio loop, test run----

# Inner Loop Histogram

# Inner Loop latency is the latency in kernel space

# between gpio_set_value and irq handler

000000 000000

...

000009 128840

000010 047625

000011 014770

000012 004761

000013 002243

000014 001115

000015 000464

000016 000141

000017 000031

000018 000012

000019 000001

....

000099 000000

# Total: 000099999

# Min Latencies: 00009

# Avg Latencies: 9.551216

# Max Latencies: 00019

其中T2如下：

# Outer Loop Histogram

# Outer Loop latency is the latency in user space

# between write and read

# Technically, outer loop latency is inner loop latercy

# plus overhead of event wakeup

000000 000000

...

000017 000001

000018 124952

000019 029179

000020 019092

000021 012050

000022 004978

000023 003129

000024 002173

000025 001434

000026 001025

000027 000749

000028 000492

000029 000337

000030 000185

000031 000108

000032 000054

000033 000031

000034 000016

000035 000011

000036 000005

000037 000001

000038 000000

000039 000001

...

000099 000000

# Total: 000099999

# Min Latencies: 00017

# Avg Latencies: 18.956690

# Max Latencies: 00039

方式2

一个gpio 引脚接收中断后，从另一个gpio 输出确认信号，测量两个信号之间的延迟(可通过外部示波器等设备测量两个事件之间的时间)，在此就不再测试。

四、xenomai各种接口应用编译

1.1 编译参数获取

xenomai 3组成结构小节说到，xenomai库libcobalt提供了多种编程接口，这些接口编写的实时应用程序如何编译呢？xenomai提供了一个脚本工具xeno-config来生成各个接口的GCC编译链接参数：

$ /usr/bin/xeno-config --help

xeno-config --verbose

--core=cobalt

--version="3.2.1"

--cc="gcc"

--ccld="/usr/bin/wrap-link.sh gcc"

--arch="x86"

--prefix="/usr"

--library-dir="/usr/lib"

Usage xeno-config OPTIONS

Options :

--help

--v,--verbose

--version

--cc

--ccld

--arch

--prefix

--auto-init|auto-init-solib|no-auto-init

--mode-check|no-mode-check

--cflags

--ldflags

--lib*-dir|libdir|user-libdir

--core

--info

--compat

其中--[skin=]参数指定我们编译的应用程序是什么接口类型，例如编译一个POSIX接口的实时应用，指定接口(skin)--posix，同时使用参数--cflags来获取POSIX接口实时应用的编译参数：

$ /usr/bin/xeno-config --posix --cflags

-I/usr/include/xenomai/cobalt -I/usr/include/xenomai -D_GNU_SOURCE -D_REENTRANT -fasynchronous-unwind-tables -D__COBALT__ -D__COBALT_WRAP__

1.2 链接参数获取

获取链接参数，--ldflags得到链接参数：

$ /usr/bin/xeno-config --ldflags --posix

-Wl,--no-as-needed -Wl,@/usr/lib/cobalt.wrappers -Wl,@/usr/lib/modechk.wrappers /usr/lib/xenomai/bootstrap.o -Wl,--wrap=main -Wl,--dynamic-list=/usr/lib/dynlist.ld -L/usr/lib -lcobalt -lmodechk -lpthread -lrt

同样通过指定--[skin=]为vxworks、psos来编译VxWorks、psos实时应用程序到xenomai上运行。

五、xenomai proc文件信息介绍

1.1 实时外设中断信息

ipipe

ipipe为了xenomai与linux之间更好地结合，引入了虚拟中断。虚拟中断和常规softirq本质上不同，softirq只存在linux中，ipipe虚拟中断更近似于硬件中断，但不是硬件触发，由内核之间需要处理紧急任务时向另一个内核发送，ipipe处理虚拟中断与处理硬件中断流程一致，这些中断信息分为Llinux和xenomai，分别对应文件/proc/ipipe/Linux和/proc/ipipe/Xenomai。

双核下ipipe层linux中断信息：

__ipipe_do_IRQ为linux非实时中断处理入口，为了保证cobalt内核的实时性，这些irq对于的中断必须延迟处理。

__ipipe_flush_printk虚拟中断，为了避免cobalt内核的打印输出影响实时性，打印时通过向linux内核发送虚拟中断来进行打印输出。

__ipipe_do_work虚拟中断，是为cobalt内核实时上下文需要linux非实时上下文处理一些任务时提供的通知机制，一些应用如下：

实时上下文运行的任务需要调linux的非实时服务时，用于将该任务从cobalt kernel切换到linux kernel；

实时应用close实时设备时，需要linux清理task文件描述符fd；

实时网卡驱动中 watchdog_timer中断需要linux处理等等。

apc_dispatch与__ipipe_do_work类似，比如实时与非实时通讯时，从实时上下文唤醒等待的linux任务等；

以上是ipipe层的中断信息，linux具体的外设中断信息还是通过/proc/interrupts文件查看，没有变化。

下图为ipipe层xenomai实时中断信息：

更具体有哪些实时驱动设备注册了中断，通过/proc/xenomai/irq来查看：

dovetail

dovetail区别与ipipe，它是在已有linux中断管理代码上进行扩展，为实时核提供与ipipe相同的功能。所以/proc/interrupts就包含了ipipe层和xenomai实时中断信息。

其中inband表示非实时域中断，oob表示实时域中断。与ipipe一样，需要注意的是，这里的一些中断不是硬件触发的，是dovetail模拟的中断，只有触发源头不同，软件处理流程与硬件中断处理流程一致。

1.2 查看实时核信息

xenomai内核相关信息均为位于/proc/xenomai/目录下：

xenomai调度cpu

ubuntu@work-host:/proc/xenomai$ cat /proc/xenomai/affinity

000000ff

/proc/xenomai/affinity中是一组掩码，每一个bit表示系统中的一个CPU，该源码表示cobalt内核管理的CPU集，若实时应用程序中没有设置affinity，那么该实时会调度在该掩码下的任意一个CPU上。当我们需要将指定cpu给cobalt调度的时候，可以通过添加内核参数xenomai.supported_cpus=0x06来修改，这通常结合linux参数isolcpus来优化实时性能。

硬件timer与延迟信息

/proc/xenomai/clock/coreclk包含了系统的硬件timer和gravity信息。

root@xxxxx:/proc/xenomai# cat clock/coreclk

gravity: irq=1880 kernel=6880 user=6880

devices: timer=timer2, clock=ipipe_tsc

watchdog: off

setup: 1880

ticks: 230615579053 (0035 b1c279ad)

gravity在前文autotune工具部分已经解释，它的值可通过autotune 命令来重新测量调整：

root@xxxxx:/proc/xenomai# autotune

== auto-tuning started, period=1000000 ns (may take a while)

irq gravity... 2880 ns

kernel gravity... 4320 ns

user gravity... 7200 ns

== auto-tuning completed after 38s

root@xxxxx:/proc/xenomai# cat clock/coreclk

gravity: irq=2880 kernel=4320 user=7200

devices: timer=timer2, clock=ipipe_tsc

watchdog: off

setup: 1880

ticks: 25641430824 (0005 f8592f28)

如果latency测试后只修user gravity， echo xxxx > /proc/xenomai/latency即可:

root@xxxxx:/proc/xenomai# echo 6680 > latency

root@xxxxx:/proc/xenomai# cat clock/coreclk

gravity: irq=2880 kernel=4320 user=6680

devices: timer=timer2, clock=ipipe_tsc

watchdog: off

setup: 1880

ticks: 28659743127 (0006 ac40f997)

若三者都需要修改，可通过 echo irq=xxxx kernel=xxxx user=xxxx> /proc/xenomai/clock/coreclk修改:

root@xxxxx:/proc/xenomai# echo irq=0 kernel=0 user=0 > clock/coreclk

root@xxxxx:/proc/xenomai# cat clock/coreclk

gravity: irq=0 kernel=0 user=0

devices: timer=timer2, clock=ipipe_tsc

watchdog: off

setup: 1880

ticks: 32430637968 (0007 8d044390)

faults

文件/proc/xenomai/faults提供了cobalt内核实时上下文产生的fault统计信息，为什么需要关注CPU fault？回到实时性，如果我们的实时任务真正进行关键的行为，此时产生了异常，异常必须解决才能继续运行，这就导致了结果输出的不确定性，即影响实时性。这也是为什么我们在xenomai应用编程时不能通过glibc库进行动态内存分配的原因，因为linux内存的惰性内存分配机制，只有在应用访问分配的虚拟内存地址时才产生缺页异常(Page fault)进行物理内存分配，同时linux在内存水位过低时也会进行内存回收，需要考虑。这也是为什么VxWorks等RTOS很少使用MMU的原因。

该文件只统计cobalt内核管理的CPU且在实时调度上下产生的异常，因此，若你运行的实时任务抖动比较大，建议查看一下文件，是否是受到异常的影响。

X86下各类异常如下：

ubuntu@work-host:/proc/xenomai$ cat faults

TRAP CPU0 CPU1

0: 0 0 (Divide error)

1: 0 0 (Debug)

3: 0 0 (Int3)

4: 0 0 (Overflow)

5: 0 0 (Bounds)

6: 0 0 (Invalid opcode)

7: 0 0 (FPU not available)

8: 0 0 (Double fault)

9: 0 0 (FPU segment overrun)

10: 0 0 (Invalid TSS)

11: 0 0 (Segment not present)

12: 0 0 (Stack segment)

13: 0 0 (General protection)

14: 0 0 (Page fault)

15: 0 0 (Spurious interrupt)

16: 0 0 (FPU error)

17: 0 0 (Alignment check)

18: 0 0 (Machine check)

19: 0 0 (SIMD error)

heap

ubuntu@work-host:/proc/xenomai$ cat heap

TOTAL FREE NAME

4194304 4192256 system heap

262144 262016 shared heap

该文件显示了xenomai heap的信息。前面说到，为避免实时性受到影响，实时应用运行过程中不能使用linux的惰性内存分配接口，在内核里也是一样，一是linux内核内存分配算法的不确定性，二是linux内核惰性分配原则。所以xenomai的解决机制是，xenomai内核初始化时预先分配一大片内存，并一一读写访问来建立虚拟内存与物理内存的映射，再通过自己的内存分配算法进行管理，该分配算法时间是确定的，xenomai自己管理的内存称为xnheap，xenomai运行过程中的动态内存分配均从xnheap中分配，为避免多个子系统同时访问一个xnheap，xenomai内核内有多个heap，这些heap的大小可通过内核参数xenomai.sysheap_size=配置，或内核编译时配置：

[*] Xenomai/cobalt --->

Sizes and static limits --->

(512) Number of registry slots

(4096) Size of system heap (Kb)

(512) Size of private heap (Kb)

(512) Size of shared heap (Kb)

关于xnheap内存分配管理算法，有单独的文章介绍。

registry

什么是registry？与内存资源类似，在操作系统管理应用程序或为应用程序提供服务的实时，需要管理很多对象。

举个例子，有两个xenoami实时任务，它们使用semaphore做同步互斥，任务1创建一个名为/test-sem的semaphore，任务2打开这个semaphore并使用该semaphore，思考下面两个问题：

问题1：任务1创建的这个semaphore是如何管理的？

问题2：任务2又是如何通过name找到它的？

这里例子中的semaphore在操作系统内核中可以一种内核对象，registry提供了一个机制，用于保存xenomai全局内核对象。这些对象分为两种，一种有name，常用于两个及以上进程间，可以通过name来找到同一对象。另一种没有name，常用于同一进程空间。

registry的大小和heap一样预先分配，xenomai运行过程中直接获取，一是全局方便查找降低实现复杂度，二避免内存分配导致系统heap竞争。默认大小为512个条目。

ubuntu@work-host:/proc/xenomai$ cat registry/usage

10/512

若你运行在xenomai上的软件比较庞大和复杂，512个不够使用，可重新配置编译内核：

-> Xenomai/cobalt (XENOMAI [=y])

-> Sizes and static limits

(512) Number of registry slots

关于registry内核对象的管理机制，会有单独的文章介绍。

1.3 调度与任务状态

下面看最重要的部分，xenomai内核和实时任务运行状态信息在/proc/xenomai/sched下：

其中/proc/xenomai/sched/rt/threads与/proc/xenomai/sched/threads,前者仅包括优先级大于0的xenomai任务信息，后者包括所有xenomai调度的任务信息，比如我们在运行latency时，只有sampling线程是有优先级的，主线程和display线程优先级均为0。

线程状态

root@xxxxx:/proc/xenomai/sched# cat threads

CPU PID CLASS TYPE PRI TIMEOUT STAT NAME

0 0 idle core -1 - R [ROOT]

0 265 rt core 98 - W [rtnet-stack]

0 266 rt core 0 - W [rtnet-rtpc]

0 281 rt core 0 - W [rtnetproxy]

0 380 rt cobalt 0 - X latency

0 382 rt cobalt 0 - W display-380

0 383 rt cobalt 99 - Wt sampling-380

root@xxxxx:/proc/xenomai/sched# cat rt/threads

CPU PID PRI PERIOD NAME

0 265 98 - rtnet-stack

0 383 99 - sampling-380

CPU 表示该实时任务在哪个CPU的调度队列上。

CLASS 表示该任务的调度类

TYPE 中core表示该任务是内核态任务，cobalt用户态任务

'S' -> 强制暂停(suspended)

'w'/'W' -> 等待资源，有或没有超时

'D' -> 延迟(Delayed)（没有其他等待条件）

'R' -> 可运行(在就绪队列中)

'U' -> 未启动或休眠

'X' -> Relaxed shadow(linux内核调度中)

'H' -> 紧急情况下保持(Held in emergency线程保持以处理紧急情况)

'b' -> 优先级提升进行中

'T' -> 被跟踪并停止(单步调试中)

'l' -> 锁定调度

'r' -> 进行循环调度(Undergoes round-robin)

't' -> 通知运行时模式错误(检测到错误时发出SIGDEBUG信号)

'L' -> 捕获死锁

PRI 表示任务优先级

STAT 表示任务所处状态

系统统计信息

下面看cobalt内核统计信息/proc/xenomai/sched/stat，这对我们查找实时问题时有帮助，以latency运行为例，输出如下：

root@xxxxx:/proc/xenomai/sched# cat stat

CPU PID MSW CSW XSC PF STAT %CPU NAME

0 0 0 40051 0 0 00018000 99.1 [ROOT]

0 265 0 2 0 0 00000042 0.0 [rtnet-stack]

0 266 0 2 0 0 00020042 0.0 [rtnet-rtpc]

0 282 0 2 0 0 00020042 0.0 [rtnetproxy]

0 329 1 1 5 0 000600c0 0.0 latency

0 331 40 80 44 0 00060042 0.0 display-329

0 332 2 40003 40046 0 0004c042 0.6 sampling-329

0 0 0 44791 0 0 00000000 0.3 [IRQ16: [timer]]

0 0 0 0 0 0 00000000 0.0 [IRQ46: 4a100000.ethernet]

0 0 0 0 0 0 00000000 0.0 [IRQ47: 4a100000.ethernet]

它统计了cobalt内核线程、用户态线程、中断的信息，这些信息包括：

CPU 运行的CPU和PID

MSW 域上下文切换。xenomai是双内核结构，xenomai应用可以无缝使用linux提供的服务，但这是有风险的，因为使用linux服务需要切换到linux非实时调度上下文，无法保证任务的实时性。MSW表示的就是实时域与非实时域之间的切换次数。

latency是主线程，它创建完高优先级线程sampling-329和负责结果打印的低优先级线程display-329后，等待SIGTERM等结束信号。间隔执行cat stat发现display-329的MSW会不断增大，是因为打印输出需要使用linux提供的服务进行终端打印；而高优先级sampling-329的MSW没有变化，因为该线程创建后，没有调用任何linux服务全程在实时内核上下文运行。为什么sampling-329 MSW为2？因为xenomai实时线程的创建是通过linux来完成的。

因此，如果你的实时任务会出现大的抖动，那么请通过该文件观察，是否因为不经意调用了linux的服务，切换到linux域引起的。

CSW xenomai内核上下文切换次数。

XSW 切换到linux域后，由linux内核调度的上下文切换次数。

PF 为Page fault产生次数。

STAT 运行状态掩码

%CPU CPU使用率，需要额外说明的是，[ROOT]表示的是cobalt内核调度下的linux，双核下linux已经退化为cobalt内核调度的一个任务。

解析系统调用是了解内核架构最有力的一把钥匙，后续文章会以xenomai POSIX接口（libcobalt ）为入口，解析xenomai内核的内部机制。

参考链接

https://xenomai.org/documentation/xenomai-3.1/html/xeno3prm

http://www.cs.ru.nl/lab/xenomai/

https://source.denx.de/Xenomai/xenomai/-/wikis

ADEOS

Adaptive Domain Environment for Operating Systems

ELC-2018-Xenomai

Xenomai 3 – An Overview of the Real-Time Framework for Linux

Real-Time Linux Testbench on Raspberry Pi 3 using Xenomai

2004年10月Philippe Gerum专访

作者：wsg1100

出处：http://www.cnblogs.com/wsg1100/

本文版权归作者和博客园共有，欢迎转载，但必须给出原文链接，并保留此段声明，否则保留追究法律责任的权利。

posted @

2020-05-05 22:00

沐多

阅读(9593)

编辑

会员力量，点亮园子希望

刷新页面返回顶部

公告

xenomai3+linux 构建linux实时操作系统-基于X86_64和arm-CSDN博客

xenomai3+linux 构建linux实时操作系统-基于X86_64和arm

置顶

沐多

已于 2024-01-16 19:18:26 修改

阅读量1w

112

点赞数

分类专栏：

xenomai内核解析

文章标签：

linux

rtos

xenomai

于 2020-05-10 16:42:28 首次发布

本文为博主原创文章，转载请注明出处https://blog.csdn.net/qq_22654551。如有问题，欢迎指正。

本文链接：https://blog.csdn.net/qq_22654551/article/details/106038163

版权

xenomai内核解析

专栏收录该内容

29 篇文章

95 订阅

订阅专栏

文章目录

一、概要二、环境准备1.1 安装内核编译工具1.2 准备内核及补丁文件

三、内核安装流程3.1 打ipipe补丁3.2 打dovetail补丁3.3 添加xenomai内核3.4 xenomai 内核配置3.4.1 ipipe xenomai 内核配置3.4.2 dovetail xenomai 内核配置

3.4 内核编译与安装a) 编译构建xenomai内核debian安装包b) 分步编译内核并安装

四、安装xenomai库4.1 编译安装实时库libcobalta) 编译构建xenomai库debian安装包b) 分步编译安装xenomai库

五、X86 平台xenomai实时性测试六、arm架构安装xenomai七、ARM 平台xenomai实时性测试7.1 IRQ-timer handler7.2 内核态任务7.3 用户态任务

八、arm64架构安装xenomai参考链接:

最近接触实时系统Xenomai，该文章整理记录X86 ubuntu环境下xenomai 内核编译、xenomai应用环境搭建步骤，其他硬件架构（如arm、arm64）类似，先在X86上安装好环境才能更好的开发验证xenomai程序吧，更多信息见文末参考链接，希望对你有所帮助。

一、概要

xenomai是众多inux实时性解决方案中的一种，通过在linux的基础上添加一个RTOS内核cobalt，来提高linux的实时性。实时内核cobalt与非实时内核linux相结合，既能提供工业级RTOS的硬实时性能，又能利用linux操作系统非常出色的网络和图形界面服务，在产品的开发周期和成本控制方面都有巨大优势，结构如下：

主要有3部分，xenomai的移植构建也是围绕这三部分来进行：

用户空间中的实时应用程序库libcobalt；内核空间中的实时内核Cobalt；硬件架构与Linux内核版本相关层 ipipe-core或dovetail。

libcobalt和Cobalt的源码随xenomai更新，位于同一源码包内，ipipe-core和dovetail则与硬件架构和具体linux版本相关，以补丁的方式提供，需要单独下载；

由于一些ipipe维护困难的关系，从linux5.4以上版本不再提供ipipe，ipipe由dovetail替代。

所以如果你的linux内核版本在5.4以上版本的话需要使用dovetail。

总的来说，ipipe-core和dovetail实现必要功能的同时，也是xenomai与硬件架构、linux版本间的解耦层，社区提供了常见架构下各linux版本的补丁。xenomai的移植步骤如下：

准备好ipip-core或dovetail补丁，对linux5.4以下版本使用ipipe-core，linux5.4以上版本需要dovetail替代。打cobalt内核补丁，编译构建内核。libcobalt库编译安装，设置环境变量。

步骤1中的源码文件也可直接从xenomai维护分支直接拉取，直接对拉取的代码进行步骤2、3即可。

ipip-core:

ARM: https://xenomai.org/gitlab/ipipe-arm

ARM64: https://xenomai.org/gitlab/ipipe-arm64

PPC32: https://xenomai.org/gitlab/ipipe-ppc32

x86: https://xenomai.org/gitlab/ipipe-x86

dovetail: https://source.denx.de/Xenomai/linux-dovetail 可以看到dovetail已经不区分ARM、X86了，dovetail区别与ipipe，ipipe是与linux中断管理分离，linux中断管理在其之上，ipipe部分需要大量直接对接arch部分的代码，这样主线内核代码的不断变化会导致社区开发人员需要对每个linux主线版本做适配和支持，这也就是为什么我们在构建xenomai系统时需要ipipe与linux版本匹配的原因，同时也可以看到，ipipe支持的版本总是落后于linux主线版本（大家应该联想到逐步合入主线的PREEMT-RT了吧）。 dovetail区别与ipipe，它是在已有linux中断管理代码上进行扩展，为实时核提供与ipipe相同的功能，这样可以随着主线发展，与架构相关的代码大大减少，大大降低了社区维护工作量，同时linux主线稳定版本确定后能第一时间进行支持，对它们的对比介绍详情可见xenomai官网和EVL project。

注意：文章中内核版本、ipipe版本仅作为构建步骤说明，不保证编译正常，笔者示例是做一些额外修复完成构建的，请根据文章提示，选择适合你需求的版本

二、环境准备

xenomai的几个长期支持版：

ipipe: linux 4.4、linux-4.19、linux 5.4dovetail: linux 5.10、linux 5.15 其中xenomai 3.2只支持linux 4.19以上版本，ipipe最终会被废弃尽量使用支持dovetail的长期支持版，另外Xenomai 3.1支持的最后一个内核版本是5.4==

1.1 安装内核编译工具

编译Linux内核需要的工具包如下，可能不全，可根据编译时的错误提示安装缺少的工具。

sudo apt-get install gcc libncurses-dev flex bison openssl-dev libssl-dev dkms fuse libelf-dev libudev-dev libpci-dev libiberty-dev build-dep findutils autotools-dev autoconf automake libtool pkg-config libltdl-dev

1.2 准备内核及补丁文件

内核：下载linux源码，linux内核源码网址：https://www.kernel.org/。

对于需要使用ipipe补丁文件的内核版本：下载与linux版本对应的ipipe-core补丁，最好先浏览https://xenomai.org/downloads/ipipe/v4.x/看xenomai提供了哪些linux版本的补丁，再去下载对应linux内核源码。

对于5.4以上的内核版本：https://xenomai.org/downloads/dovetail/?C=M;O=A 中选取对应内核版本的dovetail补丁。

xenomai内核源码包：到xenomai官网下载最新xenomai源码包。

对于ipipe，本文选用以下版本作为示例：

linux kernel:linux-4.19.114.tar.xz

ipip-core：ipipe-core-4.19.114-cip24-x86-12.patch

xenomai：xenomai-3.1.tar.bz2

一般来说，如果没有找到与你使用的内核版本一致的ipipe-core补丁，linux相近版本linux-4.19.zzz，只要版本zzz跨度不大，也可使用相近的补丁代替，但是不能保证与指定版本一致，可能有bug，若对xenomai地层不熟悉，用于生产环境最好还是指定版本。

对于dovetail，由于使用的ubuntu环境内核为linux 5.13，使用社区的仓库中的dovetail 5.13分支(或者读者下载内核源码和与之匹配的dovetail补丁也是可以的，这里只是示例，不建议使用5.13，详见3.2 打dovetail补丁小节)，示例如下：

linux kernel:linux-5.13.0.tar.xz

dovetail：patch-5.13-dovetail1.patch

xenomai：xenomai-3.2.1.tar.bz2

说明：笔者将上面的文件，统一放到了/home/work/xenomai(家目录~)目录下。文中涉及绝对路径时，还请读者注意。

三、内核安装流程

3.1 打ipipe补丁

设置针对5.4版本以下内核使用ipipe的配置示例，如果你使用的是dovetail请看3.2小结。

解压linux内核源码：

$tar -xvf linux-4.19.114.tar.xz

进入linux内核源码目录打ipipe补丁：

$cd linux-4.19.114

$patch -p1 < ../ipipe-core-4.19.114-cip24-x86-12.patch

3.2 打dovetail补丁

先克隆社区dovetail仓库：

git clone https://source.denx.de/Xenomai/linux-dovetail.git

切换到5.13分支：

git chech v5.13-dovetail-rebase

注：对于5.13只有v5.13-dovetail-rebase分支，最好选择长期支持版本LTS，否则编译等都有问题。

这样就可以了，等会在该仓库进行xenomai内核编译。

或者与3.1一样，下载内核源码与之对应的dovetail补丁https://xenomai.org/downloads/dovetail/patch-5.13-dovetail1.patch.bz2，进行：

解压linux内核源码：

注：这里使用的ubuntu发新版内核。

$tar -xvf linux-source-5.13.tar.bz2

进入linux内核源码目录打ipipe补丁：

$cd linux-5.13

$patch -p1 < ../patch-5.10.76-dovetail1.patch

3.3 添加xenomai内核

解压xenomai源码包:

$tar -xvf xenomai-3.1.tar.bz2

进入xenomai源码目录xenomai-3.1/scripts,使用脚本prepare-kernel.sh对linux内核源码打cobalt内核补丁；

$cd xenomai-3.1/scripts

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

$ ./prepare-kernel.sh --help

usage: prepare-kernel --linux= --ipipe= [--arch=] [--outpatch= [--filterkvers=y|n] [--filterarch=y|n]] [--forcelink] [--default] [--verbose]

其中主要参数为：

--linux=指定linux源码的绝对路径；

--ipipe=指定ipipe补丁。如果已经手动对linux源码打ipipe补丁，则不需要指定该参数。

--arch=指定硬件架构，x86_64、arm、arm64

outpatch=指定输出xenomai patch（绝对路径）。默认情况下如果不使用该参数，prepare-kernel.sh打cobalt内核补丁时，只会在linux源码目录建立与cobalt源码的软连接文件，这样的话，如果xenomai源码移动了就会有很多问题，所以推荐使用该参数生成xenomai内核的补丁，再去对linux使用该补丁。这样linux源码内的cobalt内核相关源码文件就不是链接文件了，今后再次构建时也直接使用该补丁，省事。

我们在上一个步骤已经对linux源码打了ipipe补丁，这里就只使用prepare-kernel.sh生成cobalt内核的补丁cobalt-core-3.1-4.19.114.patch，再对linux内核源码使用该补丁。

$./prepare-kernel.sh --linux=/home/work/xenomai/linux-4.19.114 --arch=x86_64 --outpatch=/home/work/xenomai/cobalt-core-3.1-4.19.114.patch

回到linux源码目录使用补丁：

$cd /home/work/xenomai/linux-4.19.114

$patch -p1 < ../cobalt-core-3.1-4.19.114.patch

到此，内核源码已经制作完毕。下面开始配置编译内核。

3.4 xenomai 内核配置

xenomai基于linux，xenomai作为一个小的实时核存在，许多硬件配置是linux 驱动掌管的，比如内存、电源管理，所以必须让linux配置好，给xenomai提供一个好的软硬件环境。

3.4.1 ipipe xenomai 内核配置

设置针对5.4版本以下内核使用ipipe的配置示例，如果你使用的是dovetail请看3.4.2小结。

这里示范使用的是内核默认的x86_64_deconfig文件。

注意：使用默认config文件，会包很多无用的驱动，编译会占用很多时间，然而裁剪驱动需要对内核各模块熟悉，且需要大量时间。对于新手来说，快捷的办法是找一个发行版(如Ubuntu)，从相近版本内核安装包中提取config文件，在该config基础上进行xenomai配置，这样比较好。

$makeolddefconfig

$make menuconfig

进入menuconfig界面，会看影响xenomai实时性的警告信息：

*** WARNING! Page migration (CONFIG_MIGRATION) may increase ***

*** latency. ***

*** WARNING! At least one of APM, CPU frequency scaling, ACPI 'processor' ***

*** or CPU idle features is enabled. Any of these options may ***

*** cause troubles with Xenomai. You should disable them. ***

依次进行如下配置：

General setup --->

Preemption Model (Preemptible Kernel (Low-Latency Desktop)) --->

(X) Low-Latency Desktop

(-xeno-3.2.1)Local version - append to kernel release

Processor type and features --->

Processor family (Core 2/newer Xeon) --->

(X) Core 2/newer Xeon

[*] Multi-core scheduler support

[ ] CPU core priorities scheduler support

Power management and ACPI options --->

CPU Frequency scaling --->

[ ] CPU Frequency scaling

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

< > Processor

CPU Idle --->

[ ] CPU idle PM support

Memory Management options --->

[ ] Contiguous Memory Allocator

[ ] Transparent Hugepage Support

[ ] Allow for memory compaction

[ ] Page migration

Microsoft Hyper-V guest support --->

< > Microsoft Hyper-V client drivers

说明：设置LOCALVERSION 是为了启动时好分辨是xenomai内核还是普通linux内核。

到此内核基本配置完毕，要充分发挥xenomai的实时性的配置远不止于此，还需要对linux进行深度配置，那是优化的事情，以后再说，下面开始进行内核编译。

3.4.2 dovetail xenomai 内核配置

由于ubuntu内核也是5.13，这里复用ubuntu自带内核的config文件，在此文件上进行xenomai内核配置文件。

cp /boot/config-5.13.0-30-generic ./.config

注意：使用挨默认config文件，会包很多无用的驱动，编译会占用很多时间，然而裁剪驱动需要对内核各模块熟悉，且需要大量时间。对于新手来说，快捷的办法是找一个发行版(如Ubuntu)，从相近版本内核安装包中提取config文件，在该config基础上进行xenomai配置，这样比较好。

$make menuconfig

配置过程与3.4.1 小节一致。

3.4 内核编译与安装

对于ipipe或者dovet，后面的步骤是一样的，不再重复说明。

a) 编译构建xenomai内核debian安装包

对于基于debian衍生的发行版(如debian、Ubuntu、elementary、OpenGEU，Linux Mint等)来说，内核编译安装比较简单，使用以下命令，可直接编译生成用于安装的debian包(.deb)，安装过程也无需额外设置，若读者使用的不是Ubuntu系统，请看后面的分步安装内核。

$ CONCURRENCY_LEVEL=$(nproc) make-kpkg --rootcmd fakeroot --initrd --revision=1.0.0 kernel_image kernel_headers

如果仓库内没有make-kpkg的话可以使用来编译debian安装包：

make deb-pkg -j$(nproc)

编译时间取决于主机配置，编译完成后会在源码目录的上级目录生成内核安装包，笔者这里如下：

$ls

linux-headers-4.19.114_1.0.0_amd64.deb linux-image-4.19.114_1.0.0_amd64.deb

使用dpkg命令安装内核(需要超级权限)：

$sudo dpkg -i linux-headers-4.19.114_1.0.0_amd64.deb linux-image-4.19.114_1.0.0_amd64.deb

安装后直接重启，grub高级选项中选择新安装的内核启动即可。

若不想使用deb的方式安装，也可通过如下步骤安装：

编译：

$make -j$(nproc)

使用-j启动多线程编译，其中命令nproc得到机器逻辑CPU核数。编译后编译内核模块：

$make modules_install

安装：

$sudo make install

$sudo mkinitramfs -o /boot/initrd.img-4.18.14

$sudo update-initramfs -c -k 4.18.14

配置grub引导：

$sudo update-grub

b) 分步编译内核并安装

上面的步骤只适用于基于debian衍生的X86系统，其中诸如命令update-grub其实是对原始的装步骤的脚本封装，更为原始的内核编译安装步骤如下，理论上支持所有x86系统。

编译

$make -j$(nproc)

使用-j启动多线程编译，其中命令nproc得到机器逻辑CPU核数。编译后编译内核模块：

$make modules_install

安装

拷贝内核到/boot目录

$sudo cp -iv arch/x86/boot/bzImage /boot/vmlinuz-4.19.114-xenomai-3.1

拷贝内核符号文件System.map（可省略）：

$sudo cp -iv System.map /boot/System.map-4.19.114-xenomai-3.1

拷贝.config文件（可省略）：

$sudo cp -iv .config /boot/config-4.19.114-xenomai-3.1

安装内核文档（可省略）:

$sudo install -d /usr/share/doc/linux-4.19.114

$sudo cp -r Documentation/* /usr/share/doc/linux-5.5.3

配置grub引导：

$sudo grub-mkconfig -o /boot/grub/grub.cfg

安装后直接重启，grub高级选项中选择新安装的内核启动即可，下面编译安装用户空间实时库libcobalt。

四、安装xenomai库

4.1 编译安装实时库libcobalt

同样，如果你使用的是Ubuntu系统的话，xenomai库可直接编译生成安装包，否则的话需要一步一步配置编译、安装、设置环境变量。

a) 编译构建xenomai库debian安装包

进入xenomai源码目录：

$cd /home/work/xenomai/xenomai-3.1

编译

直接执行debain包编译命令：

$debuild -us -uc

若找不到该命令则需要安装

$sudo apt-get install devscripts

编译后同样会在上级目录生成debian安装包如下：

$ ls xenomai*.deb

libxenomai1_2.99.0_amd64.deb xenomai-kernel-source_2.99.0_all.deb

libxenomai-dev_2.99.0_amd64.deb xenomai-runtime_2.99.0_amd64.deb

libxenomai1_2.99.0_amd64.deb：Xenomai的共享库；

xenomai-kernel-source_2.99.0_all.deb：xenomai内核源码；

libxenomai-dev_2.99.0_amd64.deb ：xenomai头文件和静态库；

xenomai-runtime_2.99.0_amd64.deb：xenomai运行时组件；

对于开发环境，需要安装xenomai-kernel-source_2.99.0_all.deb和libxenomai-dev_2.99.0_amd64.deb，对于生产系统，只需要安装xenomai-runtime_2.99.0_amd64.deb和libxenomai1_2.99.0_amd64.deb。

安装

直接使用dpkg安装：

sudo dpkg -i ibxenomai1_2.99.0_amd64.deb xenomai-kernel-source_2.99.0_all.deb libxenomai-dev_2.99.0_amd64.deb xenomai-runtime_2.99.0_amd64.deb

这种方法安装的xenomai库与b)方法安装的位置不同，不需要额外设置环境变量,因为debian包安装的时候已经通过hook脚本自动设置了，感兴趣可以使用dpkg-deb -R将libxenomai1_2.99.0_amd64.deb解包,查看其hook脚本。进入xenomai测试程序目录/usr/lib/xenomai/testsuite/(该目录没有在环境变量内，所以需要进入目录后执行），运行latency，测试xenomai实时任务定时延迟。

/usr/lib/xenomai/testsuite$ ./latency

== Sampling period: 100 us

== Test mode: periodic user-mode task

== All results in microseconds

warming up...

RTT| 00:00:11 (periodic user-mode task, 100 us period, priority 99)

b) 分步编译安装xenomai库

对于非基于debian的发行版或是嵌入式系统，需要一步一步配置、编译、安装、配置环境变量来完成。

进入xenomai源码目录：

$cd /home/work/xenomai/xenomai-3.1

配置:

./configure --enable-pshared --enable-smp --with-core=cobalt

通过./configure --help可查看配置帮助，配置说明更多参考xenomai官方安装文档，这里不再说明。

创建一个临时安装目录

mkdir -p build

编译安装到这个目录：

make -j$(nproc) DESTDIR=`pwd`/build install

编译安装后，xenomai库等文件在build/目录下，将build文件夹下所有内容拷贝到rootfs(目标根文件系统)中即可。临时安装到build目录的目的是，如果需要在其他机器上部署，可不用再次编译，直接将该目录内容拷贝到目标文件系统根目录即可。

$sudo cp -R build/* rootfs/usr/

也可以直接编译安装到系统中：

make -j$(nproc) install

配置环境变量：

在目录/etc/profile.d/下创建文件xenomai环境变量文件xenomai.sh，文件内容如下：

#fix paths for xenomai

export XENOMAI_ROOT_DIR=/usr/xenomai

export XENOMAI_PATH=/usr/xenomai

export PATH=$PATH:$XENOMAI_PATH/bin:$XENOMAI_PATH/sbin

export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$XENOMAI_PATH/lib/pkgconfig

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$XENOMAI_PATH/lib

export OROCOS_TARGET=xenomai

#add some aliases convenient for xenomai

alias xeno-stat="cat /proc/xenomai/sched/stat"

alias xeno-threads="cat /proc/xenomai/sched/threads"

alias xeno-rt-threads="cat /proc/xenomai/sched/rt/threads"

alias xeno-interrupts="cat /proc/xenomai/irq"

alias xeno-version=/usr/xenomai/sbin/version

alias xeno-autotune=/usr/xenomai/sbin/autotune

alias xeno-latency=/usr/xenomai/bin/latenc

前半部分是xenomai环境变量，后半部分是常用的命名别名(快捷命令)，具体含义后面的文章会介绍到；

由于xenomai实时任务是在linux软实时任务基础上创建的，而linux实时任务的创建需要权限，所以还需要配置用户组允许非root用户运行实时任务。创建用户组xenomai，并将当前非root用户与root用户加入用户组xenomai。

$sudo addgroup xenomai --gid 1234

$sudo addgroup root xenomai

$sudo usermod -a -G xenomai $USER

配置grub配置文件/etc/default/grub，在linux命令行参数中添加用户组信息xenomai.allowed_group=1234,其中1234表示用户组ID，如下：

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash xenomai.allowed_group=1234"

更新grub:

$sudo grub-mkconfig -o /boot/grub/grub.cfg

或

$sudo update-grub

重新启动选择xenomai内核，进入系统打开终端,直接执行latency测试xenomai实时性。

$ latency

== Sampling period: 100 us

== Test mode: periodic user-mode task

== All results in microseconds

warming up...

RTT| 00:00:11 (periodic user-mode task, 100 us period, priority 99)

注如果还是提示普通用户没有权限的话:

0"000.000| WARNING: [main] cannot open RTDM device /dev/rtdm/memdev-private: Permission denied

0"000.000| WARNING: [main] cannot map private umm area: Permission denied

0"000.000| BUG in init_bind(): [main] (CONFIG_DEVTMPFS_MOUNT not enabled?)

将/etc/udev/xenomai.rules 拷贝到目录etc/udev/rules.d/下，或者直接新建文件etc/udev/rules.d/xenomai.rules，保存后重启，内容如下:

# Don't let udev mess with our special network names

KERNEL=="vnic*|rteth*|rtlo", NAME="$env{INTERFACE_NAME}"

# Xenomai real-time devices

SUBSYSTEM=="rtdm", MODE="0660", GROUP="xenomai"

五、X86 平台xenomai实时性测试

下面是笔者一台工控板上的测试数据，供大家参考。

使用的环境如下：

CPUintel 赛扬 3865U@1.8GHZKernelLinux 4.4.200操作系统Ubuntu 16.04内存8GB DDR3-1600 双通道存储64GB EMMC

测试条件：一个QT应用程序绘制2维曲线图，只有QT CPU占用率就达到99%，在此基础上使用stress添加压力，创建10个CPU密集型任务（不断计算平方根），4个内存压力任务（不断的执行内存分配-赋值-读取校验-释放操作，每次分配内存大小为256MB，每次赋值间隔4096字节，意味着每次赋值都产生缺页异常）。

stress -c 10 -m 4

测试时间：211:04:55 测试命令：

latency -t0 -p 100 -P 99 -h -g result.txt

测试应用空间程序，优先级99，任务周期100us，测试结果输出到文件result.txt。经过接近10天的测试后，文件result.txt中latency分布结果如下：

# 211:04:55 (periodic user-mode task, 100 us period, priority 99)

# 0.343| 1.078| 23.110| 0| 0|

# Xenomai version: Xenomai/cobalt v3.1

# Linux 4.19.114-xeno

......

# I-pipe releagese #20 detected

# Cobalt core 3.1 detected

# Compiler: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.12)

# Build args: --enable-smp --enable-pshared --enable-tls

PKG_CONFIG_PATH=:/usr/xenomai/lib/pkgconfig:/usr/xenomai/lib/pkgconfig0 1

0.5 1599357037

1.5 1621130106

2.5 56618753

3.5 4386985

4.5 3848531

5.5 3556704

6.5 3353649

7.5 3033218

8.5 2560133

9.5 2035075

10.5 1516866

11.5 1038989

12.5 680815

13.5 417124

14.5 224296

15.5 115165

16.5 58075

17.5 27669

18.5 11648

19.5 4648

20.5 1646

21.5 467

22.5 38

23.5 1

其中第一列数据表示latency的值，第二列表示该值与上一个值之间这个范围的latency出现的次数，最小0.343us，平均latency 1.078us，最大23.110us。系统高负载情况下还能有这么好的表现，可见xenomai的实时性还是挺不错的。

这还只是xenomai应用空间任务的实时性表现，如果使用内核空间任务会更好。当然这只能说明操作系统能提供的实时性能，具体的还要看应用程序的设计等等。此外，X86平台实时性与BIOS有很大关系，通常BIOS配置CPU具有更高的吞吐量，例如超线程等，毕竟BIOS不是普通开发者能接触到的，如果能让BIOS对CPU针对实时系统配置的话，实时性会更好。比如下图所示：平均抖动几乎在100纳秒以内。注意⚠️：不要一昧追求该指标，要根据具体应用场景而定！！！

六、arm架构安装xenomai

主要是事先移植linux内核和u-boot,它们跑起来后才能进行xenomai实时性改造。其他的就与上面步骤大同小异。步骤如下：

a)对移植好的linux内核打ipipe补丁。

b)打xenomai cobalt内核补丁。

c)交叉编译（普通嵌入式内核编译）

d)安装zImage，若有内核模块安装内核模块

e)交叉编译xenomai库，这里以cortex-A8为例：

配置 cd xenomai-3.1

./configure CFLAGS="-march=armv7-a -mtune=cortex-a8 -mfloat-abi=hard -mfpu=neon -ffast-math" --host=arm-linux-gnueabihf --with-core=cobalt --enable-smp

--host=参数指定交叉编译工具链，CFLAGS=指定目标架构，是否使用硬浮点等。创建一个临时安装目录

mkdir -p build-arm

编译安装到build-arm目录：

make -j$(nproc) DESTDIR=`pwd`/build-arm install

编译安装后，xenomai库等文件在$(pwd)/build/xenomai目录下，将xenomai文件夹拷贝到rootfs/usr中即可。

sudo cp -R build-arm/xenomai rootfs/usr/

或者将xenomai文件夹进行压缩，然后需要时直接解压到rootfs /usr中,这种方式便于后续安装。

cd build

sudo tar -czpvf xenomai-arm-3.1.tar.gz xenomai

解压到rootfs：

cd rootfs

sudo tar -xpvf xenomai-arm-3.1.tar.gz -C usr/

f)配置环境变量

与上面一样，在目录/etc/profile.d/下创建文件xenomai环境变量文件xenomai.sh，文件内容如下：

#fix paths for xenomai

export XENOMAI_ROOT_DIR=/usr/xenomai

export XENOMAI_PATH=/usr/xenomai

export PATH=$PATH:$XENOMAI_PATH/bin:$XENOMAI_PATH/sbin

export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$XENOMAI_PATH/lib/pkgconfig

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$XENOMAI_PATH/lib

export OROCOS_TARGET=xenomai

#add some aliases convenient for xenomai

alias xeno-stat="cat /proc/xenomai/sched/stat"

alias xeno-threads="cat /proc/xenomai/sched/threads"

alias xeno-rt-threads="cat /proc/xenomai/sched/rt/threads"

alias xeno-interrupts="cat /proc/xenomai/irq"

alias xeno-version=/usr/xenomai/sbin/version

alias xeno-autotune=/usr/xenomai/sbin/autotune

alias xeno-latency=/usr/xenomai/bin/latenc

也可将这些内容直接放到/etc/profile中。

g)配置linux命令行参数

arm嵌入式系统一般都是root用户，不需要设置用户组，如果不是，请如上文所示建立用户组。修改u-boot向内核传递内核参数，或者修改设备树节点，添加内核参数属性并赋值。

更多参考：http://wiki.csie.ncku.edu.tw/embedded/xenomai

七、ARM 平台xenomai实时性测试

CPU双核cortex-A15@1.5GHZKernelLinux 4.19.85 + xenomai 3.1内存2GB DDR3存储4GB EMMC

以下均在压力stress -c 10 -m 4下测试,时间2小时，定时周期100us，优先级99。

7.1 IRQ-timer handler

# 02:00:00 (in-kernel timer handler, 100 us period, priority 99)

# 0.325| 0.768| 6.859| 0| 0|

# Xenomai version: Xenomai/cobalt v3.1

.....

0 1

0.25 979922

0.75 69023222

1.25 1468209

1.75 314001

2.25 118087

2.75 52695

3.25 9272

3.75 2163

4.25 5333

4.75 2638

5.25 18381

5.75 5633

6.25 18

6.75 15

7 1

7.2 内核态任务

# 01:33:21 (in-kernel periodic task, 100 us period, priority 99)

# -0.282| 0.643| 10.519| 0| 0|

# Xenomai version: Xenomai/cobalt v3.1

....

0 1

0.25 37403654

0.75 5725957

1.25 5300392

1.75 3143282

2.25 2329224

2.75 1360290

3.25 511552

3.75 135384

4.25 37234

4.75 42208

5.25 18950

5.75 4495

6.25 532

6.75 295

7.25 172

7.75 43

8.25 13

8.75 6

9.25 1

9.75 3

10.25 1

10.75 2

11 1

7.3 用户态任务

# 02:00:00 (periodic user-mode task, 100 us period, priority 99)

# 0.422| 3.605| 13.328| 0| 0|

# Xenomai version: Xenomai/cobalt v3.1

.....

0 1

0.25 2

0.75 44

1.25 137

1.75 1540

2.25 13471

2.75 1943224

3.25 38106382

3.75 19789463

4.25 6749386

4.75 2940300

5.25 1812680

5.75 549134

6.25 47176

6.75 18063

7.25 16545

7.75 9921

8.25 1391

8.75 389

9.25 132

9.75 97

10.25 104

10.75 46

11.25 18

11.75 21

12.25 6

12.75 4

13.25 2

13.5 1

基于arm平台xenomai与VxWorks 实时性能对比，可参见本博客其他文章。

八、arm64架构安装xenomai

最近[2020.11.11]入手一个树莓派4B，想看看xenomai在树莓派上的实时性表现，就搞了一下，便更新文章记录下来.

这里用树莓派4b来说明，具体步骤以上类似，需要注意的是，选择内核的时候尽量使用与ipipe支持版本相近的分支来打补丁,目前ipipe还不支持5.x的内核，所以这里使用分支rpi-4.19.y，ipipe使用ipipe-core-4.19.124-cip27-arm64-07.patch。

git clone --depth=1 --branch rpi-4.19.y https://github.com/raspberrypi/linux

打ipipe补丁的时候有一些小冲突，自己对着源码手动补充一下就行。树莓派4B还有一些中断控制器未进行ipipe修复，可参见https://blog.csdn.net/chensong_2000/article/details/106556100

接下了的步骤与上面一致，如果嫌麻烦的朋友可以直接克隆：

git clone https://gitlab.com/wsg199600/rpi-xenomai.git

配置

make bcm2711_xenomai_defconfig

树莓派内核构建参见 Kernel building

参考链接:

xenomai官方安装文档

https://gitlab.denx.de/Xenomai/xenomai/wikis/home

https://gitlab.denx.de/Xenomai/xenomai/wikis/Start_Here

关注博主即可阅读全文

优惠劵

沐多

关注

踩

112

觉得还不错?

一键收藏

打赏

知道了

xenomai3+linux 构建linux实时操作系统-基于X86_64和arm

文章目录一、概要一、环境准备1. 安装内核编译工具2. 准备内核及补丁文件4. 打ipipe补丁5. 添加xenomai内核6. xenomai 内核配置7.内核编译与安装a) 编译构建xenomai内核debian安装包b) 分步编译内核并安装8.编译安装实时库libcobalta) 编译构建xenomai库debian安装包b) 分步编译安装xenomai库9.xenomai实时性测试10.arm架构安装xenomai参考链接:最近接触实时系统Xenomai，该文章整理记录X86环境下xenomai

复制链接

扫一扫

专栏目录

基于ARM的Linux+Xenomai实时系统搭建及igh主站配置

09-21

基于ARM的Linux+Xenomai实时系统搭建及igh主站配置

Linux5.10内核：linux-dovetail-v5.10.76-dovetail3.tar.gz

05-10

Xenomai官方做好的内核源码，用于在Linux中搭建Xenomai实时内核

23 条评论

您还未登录，请先

后发表或查看评论

基于Xenomai的实时嵌入式Linux操作系统的构建.pdf

09-06

基于Xenomai的实时嵌入式Linux操作系统的构建.pdf

基于X86核心的Linux+Xenomai系统构建+igh主站移植

Xenomai :: Xenomai

Home

✉ Mailing list

Xenomai 3

Xenomai 4

Dovetail

Linux Real-time 介绍 - 知乎

Linux Real-time 介绍 - 知乎首发于机器人控制系统技术切换模式写文章登录/注册Linux Real-time 介绍陈鑫 JasonChen康复机器人、外骨骼机器人控制系统研发写作说明：- 本文写作出于对现有市面上的大部分 Linux 的实时操作系统补丁做比较，用于选择合适的实时操作系统补丁。同时也是用于个人做一个总结，加速后续的开发。- 本文主要用于比较了 Xenomai, RTAI, Vxworks。实时系统一般嵌入式系统分为两种：前后台系统和实时系统。1. 前后台系统早期嵌入式开发没有嵌入式操作系统的概念，直接操作裸机，在裸机上写程序，比如用51单片机基本就没有操作系统的概念。通常把程序分为两部分：前台系统和后台系统。简单的小系统通常是前后台系统，这样的程序包括一个死循环和若干个中断服务程序：应用程序是一个无限循环，循环中调用API函数完成所需的操作，这个大循环就叫做后台系统。中断服务程序用于处理系统的异步事件，也就是前台系统。前台是中断级，后台是任务级。Back-fore Ground System Work Flow2. RTOS 系统RTOS全称为：Real Time OS，就是实时操作系统，强调的是：实时性。实时操作系统又分为硬实时和软实时。硬实时要求在规定的时间内必须完成操作，硬实时系统不允许超时。在软实时里面处理过程超时的后果就没有那么严格。在实时操作系统中，我们可以把要实现的功能划分为多个任务，每个任务负责实现其中的一部分，每个任务都是一个很简单的程序，通常是一个死循环。RTOS操作系统：FreeRTOS，UCOS，RTX，RT-Thread，DJYOS等。RTOS操作系统的核心内容在于：实时内核。2.1 可剥夺型内核RTOS的内核负责管理所有的任务，内核决定了运行哪个任务，何时停止当前任务切换到其他任务，这个是内核的多任务管理能力。多任务管理给人的感觉就好像芯片有多个CPU，多任务管理实现了CPU资源的最大化利用，多任务管理有助于实现程序的模块化开发，能够实现复杂的实时应用。可剥夺内核顾名思义就是可以剥夺其他任务的CPU使用权，它总是运行就绪任务中的优先级最高的那个任务。Real-time System Work Flow3. 各个实时补丁比较参考文献：目前给 Linux 打实时补丁，主要有两个开源的 Linux 扩展：RTAI[1][2] 和 Xenomai[3]。这两个开源补丁使用类似的设计思想，通过添加一个额外的插件来跟 Linux 一起工作。下面是两个实时补丁的架构图。The Structure of Xenomai and RTAI两者都是基于 ADEOS 这个微内核（nanokernel）[4][5]进行的开发。ADEOS 将 Linux 的硬件层抽象出来，提供了统一的接口。同时，ADEOS 也对系统的中断进行了统一的管理。因而，Xenomai 和 RTAI 可以使用这个 ADEOS 作为一个通信的媒介，完成对 Linux 的硬件的控制。不同于 Xenomai 的是，RTAI 把中断的处理主导权放在自身，而 Xenomai 是使用 ADEOS 的中断处理。文中对 VxWorks, Xenomai, RTAI, Linux 使用 acqloop() 做了比较，并得出以下结果：思考：- 可以看到，RTAI 和 Xenomai 的性能还是很强的，延时基本在 us 级，在实际使用时，可以根据具体需要进行选择。4. RTAI 安装参考：参考^RTAI Home page, [Online]. Available: http:// www.rtai.org^ P. Cloutier, P. Mantegazza, S. Papacharalambous, I. Soanes, S. Hughes, and K. Yaghmour, in DIAPM-RTAI position paper, Nov. 2000, RTSS 2000—Real Time Operating System Workshop, 2000.^ Xenomai home page, [Online]. Available: http://www.Xenomai.org.^ ADEOS home page, [Online]. Available: http://www.adeos.org.^Karim Yaghmour Opersys Inc., Adaptive Domain Environment for Operating Systems, 2001. [Online]. Available: http://www.opersys.com/ ftp/pub/Adeos/adeos.ps.编辑于 2020-06-11 16:54Linux实时系统机器人赞同 603 条评论分享喜欢收藏申请转载文章被以下专栏收录机器人控制系统技术机器人控制系统搭建技

Xenomai 概述-腾讯云开发者社区-腾讯云

mai 概述-腾讯云开发者社区-腾讯云ZC_Robot机器人技术Xenomai 概述原创关注作者腾讯云开发者社区文档建议反馈控制台首页学习活动专区工具TVP最新优惠活动文章/答案/技术大牛搜索搜索关闭发布登录/注册首页学习活动专区工具TVP最新优惠活动返回腾讯云官网ZC_Robot机器人技术首页学习活动专区工具TVP最新优惠活动返回腾讯云官网社区首页 >专栏 >Xenomai 概述Xenomai 概述原创ZC_Robot机器人技术关注修改于 2020-09-09 13:50:395.2K0修改于 2020-09-09 13:50:39举报文章被收录于专栏：机器人技术与系统Robot机器人技术与系统Robot1 Xenomai 概述Xenomai 是RTOS-to-Linux的可移植框架实时系统框架主要包含： As co-kernel extension for patched linux As libraries for native linux including preempt-RTXenomai 1.0•2001年宣布-作为RTOS应用程序的可移植性框架•开发Linux和RTAI的ADEOS层•与RTAI合并=> RTAI / fusion Xenomai 2.0•2005年脱离RTAI –不兼容的设计目标 •从ADEOS到I-pipe层的演进（也被RTAI使用）•移植到6种架构Xenomai 3.0•经过5年的开发，于2015年发布•内核核心（现在以POSIX为中心）的返工•支持本机Linux2 Xenomai 2 的双内核的架构如下所示RTDM包括Goals and principles • Provide environment for co-kernel real-time drivers • Service interface towards applications and other drivers • Low-level primitives from implementing drivers• Reuse Linux for non-RT purposes (setup / shutdown, resource discovery and claiming, etc.) Two types of RTDM devices• Character device (open/close, read, write, ioctl)• Protocol device (socket, bind, send, recv, etc.) Device profiles• Character: UART, UDD (analogous to UIO), Memory, ... • Protocol: UDP/TCP (RTnet), CAN, IPC, ..3 Xenomai 3 for native linux Xenomai3在内核中只有一个cobalt core，并没有POSIX/native/VxWorks等等的封装，内核的代码本来就不易于调试，也就不易于维护（保持正确性），减少内核代码就有利于代码的稳定性。最重要的是只有一个cobalt，大大减轻了维护人员的工作。编译mercury核比较简单的，内核可以不做任何修改，只需要编译用户空间库涉及到rtdm驱动需要基于cobalt核从xenomai3开始支持两种方式构建linux实时系统，分别是cobalt 和 mercury。cobalt ：添加一个实时核，双核结构,具有实时内核cobalt、实时驱动模型RTDM、实时应用POSIX接口库libcobalt,基于libcobalt的其他API skins，如Alchemy API、VxWorks® emulator、pSOS® emulator等。mercury ：基于直接修改linux内核源代码的PREEMPT RT，应用空间在glibc之上，添加xenomai API库，如下图所示。在不支持cobalt内核时，可使用该方法运行xenomai应用；Cobalt – Co-kernel variant of Xenomai 3 Mercury – Native Linux variant of Xenomai 3 Alchemy – Xenomai-own real-time API Copperplate – Library layer for building RTOS APIs Boilerplate – Internal utility Library Trank – Library to support porting from Xenomai 2 to 3 RTDM – Real-Time Driver Model, kernel API that enables RT drivers, specifically for Cobalt Analogy – RTDM drivers for digital/analogue converters Adeos – Original interrupt pipeline for Linux, used by early Xenomai 2 versions I-pipe – Evolution and simplification of Adeos Dovetail – New architecture of Linux extensions to hook Xenomai 3 into Linux原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。如有侵权，请联系 cloudcommunity@tencent.com 删除。机器人原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。如有侵权，请联系 cloudcommunity@tencent.com 删除。机器人评论登录后参与评论0 条评论热度最新登录后参与评论推荐阅读LV.关注文章0获赞0目录1 Xenomai 概述2 Xenomai 2 的双内核的架构如下所示3 Xenomai 3 for native linux 领券社区专栏文章阅读清单互动问答技术沙龙技术视频团队主页腾讯云TI平台活动自媒体分享计划邀请作者入驻自荐上首页技术竞赛资源技术周刊社区标签开发者手册开发者实验室关于社区规范免责声明联系我们友情链接腾讯云开发者扫码关注腾讯云开发者领取腾讯云代金券热门产品域名注册云服务器区块链服务消息队列网络加速云数据库域名解析云存储视频直播热门推荐人脸识别腾讯会议企业云CDN加速视频通话图像分析MySQL 数据库SSL 证书语音识别更多推荐数据安全负载均衡短信文字识别云点播商标注册小程序开发网站监控数据迁移Copyright © 2013 - 2024 Tencent Cloud. All Rights Reserved. 腾讯云版权所有深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 深公网安备号 44030502008569腾讯云计算（北京）有限责任公司京ICP证150476号 | 京ICP备11018762号 | 京公网安备号11010802020287问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档Copyright © 2013 - 2024 Tencent Cloud.All Rights Reserved. 腾讯云版权所有登录后参与评论00

:: Xenomai 3

• Overview

• Installation

• Application setup

• Troubleshooting

• Hardware

• Tips

◦ Porting POSIX applications

◦ Finding spurious relaxes

◦ Configuring for x86

Kernel configuration

Dealing with shared IRQs

Dealing with SMIs

◦ Running as regular user

◦ Xenomai on VirtualBox

◦ Serial 16550A driver

◦ Resolving errno codes

◦ Building Debian packages

◦ Getting Help

• Real-time ethernet

◦ Configuration

◦ Setup

◦ Programming

• Legacy

◦ Installing Xenomai 2

• Migrating to Xenomai 3

API & Commands

Xenomai 3 :: Xenomai 3

• Overview

• Installation

• Application setup

• Troubleshooting

• Hardware

• Tips

◦ Porting POSIX applications

◦ Finding spurious relaxes

◦ Configuring for x86

Kernel configuration

Dealing with shared IRQs

Dealing with SMIs

◦ Running as regular user

◦ Xenomai on VirtualBox

◦ Serial 16550A driver

◦ Resolving errno codes

◦ Building Debian packages

◦ Getting Help

• Real-time ethernet

◦ Configuration

◦ Setup

◦ Programming

• Legacy

◦ Installing Xenomai 2

• Migrating to Xenomai 3

API & Commands

Overview :: Xenomai 4

• Get Started

• Real-time core

Building EVL

Runtime settings

Running tests

Commands

Benchmarking

Caveat

◦ Application interface

Function index

Initialization

Thread

Mutex

Read/write lock

Event

Flags

Semaphore

Clocks

Timer(fd)

Observable

Cross-buffer

File proxy

Polling file descriptors

Out-of-band I/O services

Scheduling

Memory heap

Misc. services

API revisions

◦ Real-time I/O drivers

DMA

SPI

GPIO

◦ Writing drivers

Function index

File description

Socket interface

Core thread

Kernel thread

Wait queue

Kernel mutex

Kernel semaphore

Kernel flag

EVL Spinlock

Clock device

Scheduling

Timer

Cross-buffer access

Managing IRQs

Stage exclusion lock

◦ Under the hood

ABI revisions

• Dovetail interface

◦ Interrupt pipeline

IRQ handling

Synthetic IRQs

IRQ injection

Interrupt protection

OOB stage installation

Stage escalation

Locking

Remote calls

◦ Porting Dovetail

Prerequisites

Interrupt flow

Atomic operations

Architecture bits

Tick devices

Clock sources

Syscall path

Serial debugging

Misc

Developer's Notes

Alternate scheduling

File tracking

Socket handling

Rules Of Thumb

• Ports

• Contributing

Home

RIOT channel

✉ Mailing list

⚖ License Terms

Xenomai 3

Xenomai 4 > Overview

When is a dual kernel architecture a good fit?

What does a dual kernel architecture require from your application?

Which APIs are available for implementing applications?

Which API is available for implementing real-time device drivers?

What is the dual kernel code footprint?

Porting Dovetail

Implementing your own companion core

Running the EVL core

Overview

A dual kernel architecture. Like its predecessors in the Xenomai

series, Xenomai 4 with EVL brings real-time capabilities

to Linux by embedding a companion core into the kernel, which

specifically deals with tasks requiring ultra low and bounded response

time to events. For this reason, this approach is known as a dual

kernel architecture, delivering stringent real-time guarantees to

some tasks alongside rich operating system services to others. In this

model, the general purpose kernel and the real-time core operate

almost asynchronously, both serving their own set of tasks, always

giving the latter precedence over the former.

In order to achieve this, the Xenomai 4 project works on four

components:

a piece of inner kernel code - aka Dovetail - which acts as an interface between the

companion core and the general purpose kernel. This layer introduces a

high-priority execution stage on which tasks

with real-time requirements should run. In other words, with the

Dovetail code in, the Linux kernel can plan for running out-of-band

tasks in a separate execution context which is not subject to the

common forms of serialization the general purpose work has to abide by

(e.g. interrupt masking, spinlocks).

a compact and scalable real-time core, which is intended to serve as a reference implementation for

other dual kernel systems based on Dovetail.

a C library known as libevl, which gives C/C++ applications access to the real-time core

services.

a Rust crate called revl,

which gives Rust applications access to the real-time core

services as well.

Originally, the Dovetail code base forked off of the

I-pipe interface back in

2015, mainly to address fundamental maintenance

issues

with respect to tracking the most recent kernel releases. In parallel,

a simplified variant of the Cobalt

core

once known as ‘Steely’ was implemented in order to experiment freely

with Dovetail as the latter significantly departed from the I-pipe

interface. At some point, Steely evolved into an SMP-scalable, easier

to grasp and maintain real-time core which now serves as the reference

implementation for Dovetail, known as the EVL core. The EVL core is at the heart of Xenomai 4.

When is a dual kernel architecture a good fit?

A dual kernel system should keep the functional overlap between the

general purpose kernel and the companion core minimal, only to hand

over the time-critical workload to a dedicated component which is

simple and decoupled enough from the rest of the system for you to

trust. Typical applications best-served by such infrastructure have to

acquire data from external devices with only small jitter within a few

tenths of microseconds (absolute worst case) once available, process

such input over POSIX threads which can meet real-time requirements by

running on the high-priority stage, offloading any non-(time-)critical work to common

threads. Generally speaking, such approach like the EVL core

implements may be a good fit for the job in the following cases:

if your application needs ultra-low response times and/or strictly

limited jitter in a reliable fashion. Reliable as in « not

impacted by any valid kernel or user code the general purpose kernel

might run in parallel in a way which could prevent stringent

real-time deadlines from being met ». Valid code in this case

meaning not causing machine crashes; the companion core of a dual

kernel system is not sensitive to slowdowns which might be induced

by poorly written general purpose drivers. For instance, a low

priority workload can put a strain on the CPU cache subsystem,

causing delays for the real-time activities when it resumes for

handling some external event:

if this workload manipulates a large data set continuously,

causing frequent cache evictions. As the outer cache in the

hierarchy is shared between CPUs, a ripple effect does exist on

all of them, including the isolated ones.

if this workload involves many concurrent threads causing a high

rate of context switches, which may get even worse if those

threads belong to different processes (i.e. having distinct

address spaces).

The small footprint of the dedicated core helps in this case,

since less code and data are involved in managing the real-time

system as a whole, lowering the impact of unfavorable cache

conditions. In addition, the small core does not have to abide by

the locking rules imposed on the general purpose kernel code when

scheduling its threads. Instead, it may preempt it at any time,

based on the interrupt pipelining technique Dovetail

implements. This piece of information describes typical

runtime situations when the general purpose workload is putting

pressure on the overall system, regardless of the relative priority

of its tasks.

if your application system design requires the real-time execution

path to be logically isolated from the general purpose activities by

construction, so as not to share critical subsystems like the common

scheduler.

if resorting to CPU isolation in order to

mitigate the adverse effect the non real-time workload might have on

the real-time side is not an option, or once tested, is not good

enough for your use case. Obviously, using such trick with low-end

hardware on a single-core CPU would not fly since at least one

non-isolated CPU must be available to the kernel for carrying out

the system housekeeping duties.

What does a dual kernel architecture require from your application?

In order to meet the deadlines, a dual kernel architecture requires

your application to exclusively use the dedicated system call

interface the real-time core implements. With the EVL core, this API

is libevl, or any other

high-level API based on it which abides by this rule. Any regular

Linux system call issued while running on the high-priority stage

would automatically demote the caller to the low priority stage,

dropping real-time guarantees in the process.

This rule has consequences when using C++ for instance, which

requires to define the set of usable classes and runtime features

which may be available to the application.

This said, your application may use any service from your favorite

standard C/C++ library outside of the time-critical context.

Generally speaking, a clear separation of the real-time workload from

the rest of the implementation in your application is key. Having such

a split in place should be a rule of thumb regardless of the type of

real-time approach including with native preemption, it is crucial

with a dual kernel architecture. Besides, this calls for a clear

definition of the (few) interface(s) which may exist between the

real-time and general purpose tasks, which is definitely the right

thing to do.

The basic execution unit the EVL core recognizes for delivering its

services in user space is the thread, which commonly translates as

POSIX threads

in user space.

Which APIs are available for implementing applications?

A C language API also

known as libevl is available for programming real-time applications

which need to call the EVL core services.

A Rust crate is available for the same

purpose.

Which API is available for implementing real-time device drivers?

The EVL core exports a kernel API for writing drivers, extending the

Linux device driver interface so that applications can benefit from

out-of-band services delivered from the high-priority execution stage.

The basic execution unit the EVL core recognizes for delivering its

services in kernel space is the kthread, which is a common Linux

kthread on EVL steroids.

What is the dual kernel code footprint?

All figures reported in the charts below below have been determined by

CLOC, only retaining C and

assembly source files in the comparisons.

Dovetail footprint on kernel code. The code footprint of the

Dovetail interface is 7.8 Kloc added to the kernel as of v5.7-rc5.

Most changes happen in the generic kernel and driver code, which amount

for 73% of the total. The rest is split into ARM, arm64 and x86-specific code.

An architecture-specific port represents less than 10% of the total on

average.

EVL core footprint on kernel code. The EVL core on top of

Dovetail is 15.2 Kloc. 97% of this code is architecture-agnostic. Each

architecture port amounts for 1% of the rest, which is 163 lines of

code on average. This shows that Dovetail is actually responsible for

the overwhelming majority of the architecture-specific support a

companion core should need.

Overall dual kernel code footprint. The overall footprint of

the EVL dual kernel system amounts to 26 Kloc, which includes Dovetail,

the EVL core and its out-of-band capable drivers so far. This is 0.13% of

the total kernel code base as of v5.7-rc5.

Comparing I-pipe and Dovetail footprints. These figures compare

the latest I-pipe implementation

available to date based on kernel

v4.19.x with Dovetail for v5.7-rc5. Dovetail provides additional core

services such as built-in out-of-band task scheduling support which,

as a consequence companion cores don’t have to implement for each CPU

architecture. The ARM-specific code is notably smaller

for Dovetail, thanks to a better integration of the

interrupt pipeline logic

within the mainline kernel.

Comparing Xenomai 3 Cobalt and Xenomai 4 EVL core footprints. These figures

compare Cobalt 3.1 with the EVL core for kernel v5.7-rc5. The drastic

reduction of the code footprint the EVL core shows is mainly due to focusing on

a simpler yet flexible feature set

and reusing the common driver

model. Besides, most of

the architecture-specific code is handled by Dovetail, unlike Cobalt

which still has to deal with the nitty-gritty details of task

switching, like FPU management.

Porting Dovetail

If you intend to port Dovetail to:

some arbitrary kernel flavor or release.

an unsupported hardware platform.

another CPU architecture.

Then you could make good use of the following information:

first of all, the EVL development process is described in this

document. You will need this

information in order to track the EVL development your own work is

based on.

detailed information about porting the Dovetail interface to another

CPU architecture for the Linux kernel is given here.

the current collection of « rules of thumb » when it

comes to developing software on top of EVL’s dual kernel

infrastructure.

Implementing your own companion core

If you plan to develop your own core to embed into the Linux kernel

for running POSIX threads on the high-priority stage Dovetail

introduces, you can use the EVL core implementation as a reference

code with respect to interfacing your work with the general purpose

kernel. To help you further in this task, you can refer to the

following sections of this site:

all documentation sections mentioned earlier about porting Dovetail.

a description of the so-called alternate scheduling scheme, by which Linux kernel threads

and POSIX threads may gain access to the high-prority execution

stage in order to benefit from the real-time scheduling guarantees.

a developing series of technical documents which navigates you through the

EVL core implementation.

Running the EVL core

Recipe for the impatient

read this document about

building the EVL core and libevl.

boot your EVL-enabled kernel.

write your first application code using the libevl API. You may find the following bits

useful, particularly when discovering the system:

what does initializing an EVL application entail.

how to have POSIX threads run on the high-priority stage.

which is the proper calling context for each EVL service

from this API.

calibrate and

test the system.

For the rest of us

The process for getting the EVL core running on your target system can

be summarized as follows (click on the steps to open the related

documentation):

graph LR;

S("Build libevl") --> X["Install libevl"]

style S fill:#99ccff;

click S "/core/build-steps#building-libevl"

X --> A["Build kernel"]

click A "/core/build-steps#building-evl-core"

A --> B["Install kernel"]

style A fill:#99ccff;

B --> C["Boot target"]

style C fill:#ffffcc;

C --> U["Run evl check"]

style U fill:#ffffcc;

click U "/core/commands#evl-check-command"

U --> UU{OK?}

style UU fill:#fff;

UU -->|Yes| D["Run unit tests"]

UU -->|No| R[Fix Kconfig]

click R "/core/caveat"

style R fill:#99ccff;

R --> A

style D fill:#ffffcc;

click D "/core/testing#evl-unit-testing"

D --> L{OK?}

style L fill:#fff;

L -->|Yes| E["Test with 'hectic'"]

L -->|No| Z["Report upstream"]

style Z fill:#ff420e;

click E "/core/testing#hectic-program"

click Z "https://subspace.kernel.org/lists.linux.dev.html"

E --> M{OK?}

style M fill:#fff;

M -->|Yes| F["Calibrate timer"]

M -->|No| Z

click F "/core/runtime-settings#calibrate-core-timer"

style E fill:#ffffcc;

F --> G["Test with 'latmus'"]

style F fill:#ffffcc;

style G fill:#ffffcc;

click G "/core/testing#latmus-program"

G --> N{OK?}

style N fill:#fff;

N -->|Yes| O["Go celebrate"]

N -->|No| Z

style O fill:#33cc66;

Once the EVL core runs on your target system, you can go directly to

step #3 of the quick recipe above.

Last modified: Sun, 06 Aug 2023 19:45:25 +0200

Follow

tokenpocket最新版官网|xenomai

tokenpocket最新版官网|xenomai

实时系统Preempt RT与Xenomai之争！谁更主流，谁更实时？ - 知乎

Xenomai概述及实时化AMR64 Linux实践 - 知乎

【原创】xenomai内核解析之xenomai初探 - 沐多 - 博客园

xenomai3+linux 构建linux实时操作系统-基于X86_64和arm-CSDN博客

Xenomai :: Xenomai

Linux Real-time 介绍 - 知乎

Xenomai 概述-腾讯云开发者社区-腾讯云

:: Xenomai 3

Xenomai 3 :: Xenomai 3

Overview :: Xenomai 4

最近的新闻

您可能喜欢的文章

比特派官方app下载网站安卓|空难乘客

tokenpocket官网|hammer是什么意思中文

比特派钱包怎么查收

比特派怎么有病毒

怎么充值比特派钱包

比特派硬件怎么用

比特派软件怎么取款