RTOS设备驱动向嵌人式Linux的移植
Linux暴风雨般占领了嵌入式系统市场。分析家指出，大约有1/3到1/2的32/64位新的嵌入式系统设计采用了Linux。嵌入式 Linux 已经在很多应用领域显示出优势，比如SOHO家庭网络和成像/多功能外设。在(NAS/SAN)存储，家庭数字娱乐(HDTV/PVR/DVR/STB)，和手持设备/无线设备，特别是数字移动电话更获得大幅度发展。
嵌入式Linux新应用不会凭空从开发者的头脑中冒出来，大部分项目都是由成千上万行，甚至数百万行的代码组成。成千上百的嵌入式项目已经成功地将现有的其它平台的代码移植到Linux下,比如Wind River VxWorks 和 pSOS, VRTX, Nucleus 和其它RTOS。这些移植工作有着重要的价值和现实意义。
到目前为止，大多数关于移植已有的RTOS应用到嵌入式Linux的文献，关注RTOS 接口（API）、任务、调度模式以及怎样将他们映射到相应得用户空间去。同样重要的是，在I/O调用密集的嵌入式程序中如何将RTOS的硬件接口代码移植到更加规范的Linux设备驱动程序中去。
本文将概述几种常用的经常出现于现有嵌入式应用中的内存映射I/O方法。它们涵盖的范围从对中断服务例程的特殊使用及用户线程对硬件访问到出现于有些ROTS中的半规范化驱动程序模型。这对于移植RTOS 代码到规范化的Linux设备启动程序具有一定启发作用，并且介绍了一些移植方法。特别地，本文会重点讨论RTOS和Linux中的内存映射，基于I/O调度队列的移植，将RTOS I/O重定义到Linux下的驱动程序和守护进程里。
RTOS I/O 概念
“不规范”是描述大多数RTOS系统I/O的最佳词语。多数RTOS是针对较早的无MMU的CPU而设计，所以忽略了内存管理部分，即使当MMU问世后也是这样：不区分物理地址和逻辑地址。大多数 RTOS还全部运行在特权模式，虽然表面上看来是增强了性能。全部的RTOS 应用和系统代码都能够访问整个地址空间、内存映射过的设备、以及其他I/O操作。这样，即使存在差别，也是很难把RTOS应用程序代码同驱动程序代码区分开来。
不规范的结构导致了I/O实现的特殊性。在很多情况下，缺乏设备驱动程序模型的认同。根据这种无层次的特性，回顾一下基于RTOS软件中使用的一些重要概念和习惯用法非常有指导意义。
内嵌的内存访问
上个世纪八十年代中期商业化的RTOS产品中，多数嵌入式软件都有一个对执行时间有严格需求的，采用I/O查询和中断服务例程的大循环。开发人员在项目采用RTOS和执行程序，主要为了加强并行性和多任务同步，绕开其它有碍实现该目标的程序结构。这样，即使RTOS提供了I/O 调用形式化方法，嵌入式程序员继续使用直接的I/O操作:
| #define DATA_REGISTER 0xF 00000F 5 char getchar(void) { return (*((char *) DATA_REGISTER)); /* read from port */ } void putchar(char c) { *((char *) DATA_REGISTER) = c; /* write to port */ } |
多数受过训练的开发者常会将这样的直接I/O代码从硬件代码中分离开来。但是我还是经常看到诸如此类的I/O调用代码。
当开始使用直接内存映射I/O的时候，新接触Linux的嵌入式开发人员总是想把这类代码移到用户空间，通过mmap()调用来替代定义寄存器地址的#define 语句。这种处理方法对于一些原型是可以的，但不能支持中断处理，限制了实时响应，特别不安全，不适合商业化产品的发布。
RTOS 中断服务例程
在 Linux里, 中断服务属于内核层; 在一个 RTOS里, 中断服务例程代码没有特殊规定且常与应用程序代码没什么区别（不外乎返回序列异同）。很多 RTOS提供系统调用或者宏来让代码自己检测它自己的切换状态（比如 Wind River VxWorks的 intContext()）。中断服务例程通常也使用标准的库函数，随之而来也有可重入性和移植性等问题。
大多数RTOS支持注册中断服务例程代码、中断判断和中断服务调用。一些简单的嵌入式程序，仅仅支持在硬件矢量表里插入中断服务例程的起始地址。
如果试图直接在用户程序空间执行读和写操作，你不得不将Linux中断服务例程放入内核程序空间。
RTOS I/O 子系统
大多数RTOS会提供一个定制的标准C运行库 (比如 pSOS 的pREPC),或者修改编译器提供商的C库(libc)或修改glibc。在尽量最小化情况下,多数的 RTOS支持标准C的I/O子集(open/close/read/write/ioctl). 大多数情况下,这些调用和从衍生出来的调用转化为基本I/O简单封装.有趣的是,因为大多数的 RTOS不支持文件系统,这些平台不提供针对flash和其他存储介质的文件存储,常采用完全不同的代码实现或者其他应用程序接口(API) (比如 pSOS 的pHILE).
Wind River VxWorks 在这方面比其它RTOS做得好些,它提供功能丰富的I/O子集,有效广泛集成网络接口及网络媒体。
延时处理
很多RTOS也支持一种叫”下半部 “("bottom half" )的机制, 把I/O处理放到可中断或者可抢占切换上下文中执行。其他RTOS提供类似机制比如中断嵌套来获得同样的效果.
典型RTOS应用的I/O架构
下面描述一个典型的I/O图解(仅输入)和它向主应用程序传递数据的路径，处理过程如下:
· 一个硬件中断触发一个中断服务例程执行。
· 中断服务例程做基本处理，完成本地输入操作,或者让RTOS调度延时处理。在一些情况下,延时处理过程由Linux里的用户进程来处理,在这里就是普通的RTOS任务。
· 当获取到数据(中断服务例程或者延时切换),准备好的数据被放进队列(RTOS中断服务例程能够访问应用程序队列通过应用程序接口(API)和其它进程间通信 ( IPC),请看下面的API表)。
· 一个或者多个应用任务从队列读消息取出数据
传统的RTOS和Linux的典型I/O比较
输出常常由类似的机制来完成-代替write()或者相似的系统调用,一个或者多个RTOS任务,将数据放进队列.队列中的数据由以下几种过程取出:一个I/O程序或者响应“准备好发送”中断的中断服务例程,一个系统时钟,或者其它阻塞在取数据队列中的应用任务,然后执行I/O操作(可以是轮询,也可以是通过 DMA).
将RTOS I/O 映射到 Linux中
上面描述的基于队列的生产者/消费者I/O模型,仅仅是传统多种设计中所采用的特别方法的一种。让我们继续用这个直接的例子,来讨论几种在嵌入式Linux下的实现方法:
大规模移植到用户空间
对于只是初步了解Linux设备驱动设计,或者没有经验的开发者,可能将大多数这种基于队列的程序原封不动地移植到用户空间。在这种驱动程序映射中,内存映射通过函数mmap()提供的指针可以在用户空间操作物理I/O接口。
| #include #define REG_SIZE 0x4 /* device register size */ #define REG_OFFSET 0xFA400000 /* physical address of device */ void *mem_ptr; /* de-reference for memory-mapped access */ int fd; fd=open("/dev/mem",O_RDWR); /* open physical memory (must be root) */ mem_ptr = mmap((void *)0x0, REG_AREA_SIZE, PROT_READ+PROT_WRITE, MAP_SHARED, fd, REG_OFFSET); /* actual call to mmap() */ |
一个进程下的用户线程运行类似RTOS的中断服务例程或延时任务一样的操作,然后使用SVR4进程间通信函数msgsnd()将消息放进队列,等待被另一个本地线程或者另一个进程利用函数msgrcv()获取。
这种快速缺乏技巧的处理方法是一种较好的原型,但同时给代码模型建立带来了巨大的挑战。首先重要的是要在用户空间扫描中断.象DOSEMU项目提供基于信号 的I/O中断方式,但用户空间的中断处理过程非常慢(一般毫秒级中断延时相较内核中断服务例程数十微秒中断延时).进一步讲,即使采用可抢占Linux内核,和实时调度策略，用户空间的切换调度不能保证I/O 线程100%的及时得到执行。
为使用Linux驱动程序重新设计
较可取的是应该至少写一个简单Linux驱动程序在内核层处理中断。一个基本的字符或者块驱动程序,能够在“上半部”直接处理中断数据,或者延时到任务队列或2.6内核新工作队列中作后续处理。一个或者多个应用线程/进程能够打开设备然后执行同步读操作,正像RTOS用队列实现同时调用一样。需注意的是,这种方法需要重写I/O线程读取，代替队列接收操作。
保留一个RTOS基于队列的I/O架构
为了减小移植到嵌入式Linux 后的影响,可以在保留基于队列的方案,添加额外的线程或者守护进程,在新创建的设备上等待I/O操作.当数据准备好以后,这些线程或者守护进程被唤醒 , 按队列重排由应用线程或进程读取的数据。
移植方法
将RTOS移植到嵌入式Linux 与商业应用程序移植概念上并无区别。当准备好移植的基础性工作：（创建make/build脚本和工具，编译器兼容性，指定所用的头文件等）之后,移植任务面临的是应用程序的结构和（API）使用问题。 为了便于下面的讨论，我们假设“应用”部分（除针对I/O以外的所有代码）会被从RTOS系统中移植到单独的一个Linux进程；RTOS任务映射到Linux线程，而任务的进程间通信（IPC）映射到Linux进程和线程相应通讯。 .
映射RTOS任务到Linux基于进程的线程 Process-based Threads
移植的基本概念容易理解，问题主要出现在细节上。最常见的是RTOS中的应用程序接口以及如何把它们保留到linux结构中继续使用。
整体分析―重构
假如项目时间要求不是很紧，并且为了将来项目的可重用和代码可移植性，你会化时间分析当前RTOS应用程序结构以及怎样将他们映射到Linux中去。对于RTOS应用，需要考虑将任务对应一一映射到Linux基于进程的线程中去，或者考虑将RTOS应用重分配到多个Linux进程中去。基于这些考虑，应该重新考虑将RTOS进程间通信（IPC）用合适的进程间或者进程内通讯来替代。
在驱动程序上，肯定要把不规范的内嵌式RTOS代码转化成相应的驱动程序。如果已有的应用程序已经很好划分，或者使用RTOS I/O应用程序接口，或者分隔在不同的层面，转化工作将非常容易进行。如果这类I/O代码分散于整个应用程序中，将面临巨大工作量。
基于API的方法
对于急于摆脱旧RTOS，或者尝试将原型综合在一起的开发者, 更倾向于将很多RTOS映射或者转化为相当Linux API。程序的接口几乎是透明的（兼容的API,IPC,系统数据类型等）。其余部分可以通过用#define 重新定义和使用宏来解决。剩下的部分需要重新编码，作为完整抽象层的一部分。
通过使用仿真库－很多商业嵌入式Linux都带有（比如我们公司的针对Wind River VxWorks 和 pSOS的仿真库），或者使用第三方公司提供的API映射包，比如MapuSoft，能够使你在移植基于API的程序时有良好的开端。
移植RTOS代码和API 到Linux的多叉方法
大多数项目采用混合的方法，映射所有兼容的或者容易转化的API,重新配置那些对运行速度有要求的部分，重新编写剩余的部分代码直到编译通过和可以运行为止。
在内核和用户空间适用的API
对于需要重新编写和其他API实现方法，你得重新分配RTOS应用程序和I/O代码和Linux内核/用户空间相对应。
有两个非常重要的区别：
· RTOS平等地让应用程序和I/O代码能够访问任何地址，几乎可以进行任意操作， Linux则更讲究应用级别和权限。
· 旧的RTOS代码能够（至少在链接时）“看见”每一个符号和系统的入口点，Linux 用户代码是分离的，内核程序和用户程序完全分开。
Linux分层权限访问的结果是，仅内核代码（驱动程序）能够访问物理内存，其它用户代码必须有根用户权限才能访问。
一般情况下，用户空间代码与Linux内核相隔离，只有当内核的信息出现在/proc/ksyms 时才能被直接“看见”。进一步讲，不能直接调用对于内核可见的系统调用，只能通过用户库函数调用。Linux这种分隔是有意用来加强稳定性和安全性。
相反的当写驱动程序的时，静态链接的驱动程序专属于整个内核名字空间（不是出口），但是对于基于进程的用户空间，符号和入口点完全不可见。并且，当驱动程序封装成可动态加载的模块时，程序在内核里面通过EXPORT_SYMBOL 宏来使用显示的接口。
网络驱动程序移植
如上面指出的，字符和块驱动程序移植到Linux下较为明了。而移植网络驱动程序则要困难得多。
Linux伴随TCP/IP一起成长，而大多数的RTOS 到90年代晚期才将添加网络支持。这些网络常常仅支持基本功能，比如只能处理单个会话或者同时只能访问一个端口，或者只能支持单一网络媒质的物理接口。在某些情况下网络结构，在允许多重接口和物理类型连接后，才能实现（比如Wind River VxWorks MUX代码）。
糟糕的是，你不得不重写大部分或者全部的RTOS中现有网络接口。好消息是，对于Linux网络重新划分不是太困难，而且有大量的开源网络设备驱动例子程序可供参考。
你的移植任务会是怎样用合适的封装格式和接口代码组装下图表中底部区域:
Linux 网络驱动程序框图
写网络驱动程序不是初学者的事。许多RTOS网络驱动程序实际上是从GPL的Linux接口演变而来，因此，你也许通过代码本身可以发现程序易用性。更进一步的，有大量、并且一直在增长的系统集成和咨询社区以合理的收费帮助嵌入式开发者将他们的应用移植到Linux中去。
总结
本文深入分析了将软件从原有的RTOS移植到Linux时，嵌入式开发者面临的挑战和得到的好处。寥寥几千字对于深入研究许多驱动程序移植的细节来说过于简单（总线接口的驱动API,地址转换等），但是现有的众多开源GPL驱动程序代码，可以作为移植的文档参考和模板。本文肯定对你的团队在移植RTOS到Linux的时候有所帮助，对重新规划代码、更好移入嵌入式Linux有所启发。