深入uCLinux嵌入式操作系统.ppt

深入 嵌入式操作系统 老铁 lao_ Linux Source Learning Group /icsec Why 嵌入式Linux? 2000年9月份的调查。这项调查一直在延续着，截至2001年7 月30日，已经使用或将要使用嵌入式Linux的用户已达到 88.6%。 Why 嵌入式Linux? 未来24个月嵌入式操作系统的应用调查(2000.9) 嵌入式Linux分类 n第一类是在利用Linux强大功能的前提下，使它 尽可能的小，以满足许多嵌入式系统对体积的要 求，如uClinux()； n第二类是将Linux开发成实时系统尤其是硬/firm 实时系统，应用于一些关键的控制场合，如 Fsmlabs公司()的 RTLinux、MontaVista() 的Hard Hat Linux等； n第三类的产品就是将实时性和嵌入式方案结合起 来的方案，很多公司都这么做，并且提供集成化 的开发方案，如Lineo、TimeSys、合肥华恒等。 Why ? n全球每年生产的CPU的数量在二十亿颗左右，超过80%应 用于专用性很强的各类嵌入式系统。其中又有相当一部分 面向低端市场。为降低硬件成本及运行功耗，有一类CPU 在设计中取消了内存管理单元（Memory Management Unit，简称MMU）功能模块。如Motorola公司的M68328、 M68EN322 、MC68360、DragonBall系列如68EZ328、 68VZ328，ColdFire系列的如5272、5307，ARM7TDMI and MC68EN302、ETRAX、Intel i960、PRISMA、Atari 68k等 等。 n标准Linux针对有MMU的处理器设计。在这种处理器上， 虚拟地址被送到MMU，把虚拟地址映射为物理地址。通 过赋予每个任务不同的虚拟地址/物理地址转换映射，可 支持不同任务之间的保护。 最初，运行于这类没有MMU的CPU之上的都是 一些很简单的单任务操作系统，或者更简单的控制程 序，甚至根本就没有操作系统而直接运行应用程序。 在这种情况下，系统无法运行复杂的应用程序，或者 效率很低，而且，所有的应用程序需要重写，并要求 程序员十分了解硬件特性。这些都阻碍了应用于这类 CPU之上的嵌入式产品开发的速度。 然而，随着uCLinux的诞生，这一切都改变了。 Why ?(cont.) What is ? uCLinux是一个完全符合GNU/GPL公约的项目，完 全开放代码，现由Lineo公司支持维护。英文单 词中u表示Micro，小的意思，C表示Control，控 制的意思，所以uCLinux就是Micro-Control- Linux，字面上的理解就是“微控制领域中的 Linux系统”。它专门针对没有MMU的CPU，并专 为嵌入式系统做了许多小型化的工作，已支持前 面提到的多款CPU。官方主页在 。国内从事uclinux开发 有合肥华恒科技等几家公司 。 Embedded Linux/Microcontroller Project Kenneth Albanowski FOUNDING FATHERS D. Jeff Dionne 核心开发人员12人左右。To join, send mail to with the command “subscribe uclinux-dev“ in the body of the message. 已成功使用uCLinux的案例 n合肥华恒的基于coldfire 5272/5407的家庭网关Soho/Home/VPN Router、基于 68EZ328的PDA开发套件 nMaple 信号处理公司基于DragonBallVZ和TMS320C541xx DSP的DAQStick 系列嵌入式 信号处理板卡 n珠海万禾的基于VZ328的多串口设备Webport2000，基于68VZ328的PDA开发套件 nLineo 公司的uCsimm、uCdimm开发套件以及商业音乐媒体服务器BMMSMP3.COM采用 n西南交通大学电气检测与故障诊断信息研究室的嵌入式电力设备运行状态监测系统 nNetSilicon公司 NET+Works设备网络平台(基于ARM7TDMI)为Wireless Networks 公 司的BlueLAN 提供接入点 n东软的智能家庭网关产品 n爱立信的基于ARM7TDMI蓝芽BLIP无线通信设备 n基于ARM7TDMI的Aplio公司的voice-over-IP电话 nAXIS公司的AXIS2001网络数码相机 nAdomo公司的家庭机顶盒 nSnapsear的VPN安全设备 n瑞士洛桑的Smartdata公司的微型计算机Chipslice n 内存管理 uClinux同标准Linux的最大区别就在于内存管理 标准Linux使用的虚拟存储器技术 标准Linux是针对有内存管理单元的处理器设计的。虚拟地址被送到内存 管理单元（MMU），把虚拟地址映射为物理地址。采用分页的方式来载 入进程。实际存储器分割为相同大小的页面。 虚拟存储器由存储器管理机制及一个大容量的快速硬盘存储器支持。它的 实现基于局部性原理，当一个程序在运行之前，没有必要全部装入内存 ，而是仅将那些当前要运行的那些部分页面装入内存运行（copy-on- write），其余暂时留在硬盘上程序运行时如果它所要访问的页已存在， 则程序继续运行，如果发现不存在的页，操作系统将产生一个页失效异 常，导致操作系统把需要运行的部分加载到内存中。必要时操作系统还 可以把不需要的内存页交换到磁盘上。 通过赋予每个任务不同的虚拟-物理地址转换映射(页表)，还可支持不同 任务之间的保护、共享等。 对于多进程管理当处理器进行进程切换并执行一个新任务时，一个重要 部分就是为新任务切换页表。 标准Linux系统的内存管理功能 可以运行只加载了部分的程序，缩短了程序启动的时间 运行比内存还要大的程序。理想情况下应该可以运行任意大小的程序 可以使多个程序同时驻留在内存中提高CPU的利用率 可以运行重定位程序。即程序可以方于内存中的任何一处，而且可以 在执行过程中移动 写机器无关的代码。程序不必事先约定机器的配置情况 减轻程序员分配和管理内存资源的负担 可以进行程序代码共享 提供内存保护，进程不能以非授权方式访问或修改页面，内核保护单 个进程的数据和代码以防止其它进程修改它们。否则，用户程序可能会 偶然（或恶意）的破坏内核或其它用户程序 代价：内存管理需要地址转换表和其他一些数据结构，留给程序的内存 减少了。地址转换增加了每条指令的执行时间，而对于有额外内存操作 的指令会更严重。当进程访问不在内存的页面时，系统处理失效的磁盘 I/O操作极耗时间。 针对NOMMU的特殊处理 uClinux针对没有MMU的处理器设计，不能使用处理器的虚拟内存管理技 术,但出现简单和尽量靠拢标准Linux得需要，uClinux仍然沿用标准 Linux的分页内存管理结构，系统在启动时把实际存储器进行分页，但 实际上采用的是实存储器管理策略。 uClinux系统对于内存的访问是直接的，（它对地址的访问不需要经过 MMU，而是直接送到地址线上输出），所有程序中访问的地址都是实 际的物理地址。 操作系统对内存空间没有保护（这实际上是很多嵌入式系统的特点）， 各个进程实际上共享一个运行空间（没有独立的地址转换表）。 一个进程在执行前，系统必须为进程分配足够的连续地址空间，然后全 部载入主存储器的连续空间中。由于程序加载地址与预期（ld文件中 指出的）通常都不相同，这样relocation过程就是必须的。 磁盘交换空间无法使用的，系统执行时如果缺少内存将无法通过磁盘交 换来得到改善。 对开发人员提出的更高要求 从易用性来说，uClinux的内存管理实际上是一种倒退，退回了到了UNIX早 期或是Dos系统时代。开发人员不得不参与系统的内存管理。从编译内 核开始，开发人员必须告诉系统这块开发板到底拥有多少的内存。 由于应用程序加载时必须分配连续的地址空间，而针对可连续地址分配内 存大小是受限的，开发人员在开发应用程序时必须考虑内存的分配情况 并关注应用程序需要运行空间的大小。另外由于采用实存储器管理策略 ， 用户程序同内核以及其它用户程序在一个地址空间，程序开发时要保证不 侵犯其它程序的地址空间，以使得程序不至于破坏系统的正常工作，或 导致其它程序的运行异常。从内存的访问角度来看，开发人员的权利增 大了（开发人员在编程时可以访问任意的地址空间），但与此同时系统 的安全性也大为下降。 从嵌入式设备实现的功能来看，嵌入式设备通常在某一特定的环境下运行 ，只要实现特定的功能，其功能相对简单，内存管理的要求完全可以由 开发人员考虑。 内核加载方式 uCLinux的内核有两种可选的运行方式：可以在flash 上直接运行，也可以加载到内存中运行。后者可以 减少内存需要。 Flash运行方式(XIP)：把内核的可执行映像烧写 到flash上，系统启动时从flash的某个地址开始逐句 执行。这种方法实际上是很多嵌入式系统采用的方 法。 内核加载方式：把内核的压缩文件存放在flash上 ，系统启动时读取压缩文件在内存里解压，然后开 始执行，这种方式相对复杂一些，但是运行速度可 能更快（RAM的存取速率要比Flash高）。 根（root）文件系统 uCLinux系统采用romfs文件系统，这种文件系统相 对于一般的ext2文件系统要求更少的空间。空间的 节约来自于两个方面：首先内核支持romfs文件系 统比支持ext2文件系统需要更少的代码；其次 romfs文件系统相对简单，在建立文件系统超级块 （superblock）需要更少的存储空间。Romfs文件 系统不支持动态擦写保存，对于系统需要动态保存 的数据采用虚拟ram盘/JFFS的方法进行处理（ram 盘将采用ext2文件系统）。 应用程序库 nuCLinux小型化的另一个做法是重写了应用程序库 ，相对于越来越大且越来越全的glibc库，uClibc对 libc做了精简。 /uClibc.html nuClibm数学库 nuCLinux对用户程序采用静态链接的形式，这种做 法会使应用程序变大，但是基于内存管理的问题， 也就是基于没有MMU的特性，只能这样做，同时 这种做法也更接近于通常嵌入式系统的做法。 标准Linux系统系统数据段，代码段，堆和栈在虚存层面是连续的。堆向上 增长，栈向下增长，在堆底和栈顶之间有256MB的内存可供分配。uClinux 采用了实内存模式，各个内存段在物理内存层面是连续的，栈段在同数据 段在一起，堆有系统内存管理，所有进程共享，由于内存连续和保护的要 求，栈段，数据段，代码段都是在程序加载是分配。 这种内存空间布局阻碍了动态连接库的运用。栈段的大小固定（在生成应 用时可以指定栈段大小），开发人员在开发时不得不使用一些方法估计判 断栈段的大小，使其即能满足程序的需要，又不浪费内存。 可执行文件格式 uCLinux系统使用flat可执行文件格式，目前也支持 elf文件格式。先解释几种可执行文件格式。 coff（common object file format）：一种通 用的对象文件格式； elf（executive linked file）：一种为Linux系统 所采用的通用文件格式，支持动态连接和重定位； flat：elf格式有很大的文件头，flat文件对文件 头和一些段信息做了简化，可执行程序小。 可执行文件加载 当用户执行一个应用时，内核的执行文件加载器将对flat文件进 行进一步处理，主要是对reloc段进行修正（详见 fs/binfmt_flat.c）。 需要reloc段的根本原因是，程序在连接时连接器所假定的程序 运行空间与实际程序加载到的内存空间不同。假如有这样一条 指令： jsr app_start; 这一条指令采用直接寻址，跳转到app_start地址处执行，连接 程序将在编译完成是计算出app_start的实际地址（设若实际地 址为0x10000），这个实际地址是根据ld文件计算出来。但实际 上由于内存分配的关系，操作系统在加载时无法保证程序将按 ld文件加载。这时如果程序仍然跳转到绝对地址0x10000处执行 ，通常情况这是不正确的。 一个解决办法是增加一个存储空间，用于存储app_start的实 际地址，设若使用变量addr表示这个存储空间。则以上这句 程序将改为： movl addr, a0; jsr (a0); 增加的变量addr将在数据段中占用一个4字节的空间，连接 器将app_start的绝对地址存储到该变量。在可执行文件加载 时，可执行文件加载器根据程序将要加载的内存空间计算出 app_start在内存中的实际位置，写入addr变量。系统在实际 处理是不需要知道这个变量的确切存储位置（也不可能知道 ），系统只要对整个reloc段进行处理就可以了（reloc段有标 识，系统可以读出来）。处理很简单只需要对reloc段中存储 的值统一加上一个偏置（如果加载的空间比预想的要靠前， 实际上是减去一个偏移量）。偏置由实际的物理地址起始值 同ld文件指定的地址起始值相减计算出。 可执行文件加载 标准Linux 的多进程管理 fork创建的进程几乎是父进程的精确复制，从fork返回后，父子进程执行同样 的程序，有同样的数据和堆栈区，并从紧跟fork后的指令继续执行。 exec系统调用提供一个进程去执行另一个进程的能力，exec系统调用是采用 覆盖旧有进程存储器内容的方式，所以原来程序的堆栈、数据段与程序段都 会被修改。 fork的优化： (1)COW (写时拷贝)，首先由System V使用。不进行页面复制，父子进程共享 页面，页面置为只读，无论父进程还是子进程试图修改页时，发生页失效， 页失效处理程序进行页面复制，并清除只读标志。 (2)BSD采用的vfork，多数程序调用完成fork后会马上执行exec，因此vfork不 进行页面复制，父进程将地址空间租界给子进程，并将自己阻塞，直到子进 程将地址空间还给它。因此，子进程会一直使用父进程的地址空间直到它调 用exec或exit，内核再将地址空间返回给父进程并唤醒它。fork非常快，甚至 无需拷贝页表。它允许一个进程使用修改另一进程的地址空间。 uClinux NOMMU 但支持多进程 MMU不是支持多进程的必要条件，只是更好的支持了多进程 操作系统的实现。 uClinux没有MMU管理存储器，不支持COW的机制，因此fork 的优化只有采用vfork这一途径，并且由于不支持虚拟地址空 间，简单复制的fork实现也必须修正reloc段。 最终，uClinux的fork/vfork都用vfork实现。子进程要么代替 父进程执行（此时父进程已经sleep）直到子进程调用exit退 出，要么调用exec执行一个新的进程，这个时候将产生可执 行文件的加载，即使这个进程只是父进程的拷贝，这个过程 也不能避免。当子进程执行exit或exec后，子进程使用 wakeup把父进程唤醒，父进程继续往下执行。 多进程管理 经过如上各方面的小型化改造，就形成了一个高度优化的、代码紧凑的 嵌入式Linux，虽然它的体积很小，uCLinux仍然保留了Linux的大多数 的优点：稳定、良好的移植性、优秀的网络功能、完备的对各种文件 系统的支持、以及标准丰富的API。它的主要特征如下： 通用Linux API 内核体积 512 KB 内核 +文件系统900 KB 完整的TCP/IP 协议栈 支持大量其它的网络协议 支持各种文件系统，包括 NFS、ext2、ROMfs and JFFS、MS-DOS和 FAT16/32 开发环境 基于uCLinux的应用开发环境一般是由目标系统硬件开发板和宿主PC机所 构成。硬件开发板用于操作系统和目标系统应用软件的运行，而操作系统内 核的编译、应用软件的开发和调试则需要借助宿主PC机来完成。双方之间一 般通过串口建立连接关系。 建立交叉开发环境 在软件开发环境建立方面，由于uCLinux及相关工具集都是开放源码的项 目，所以大多数软件都可以从网络上下载获得。首先要在宿主机上安装标准 Linux发行版，比如Red-Hat Linux，接下来就可以建立交叉开发环境。 1.安装交叉编译工具 针对uCLinux目前有两套编译工具：m68k-coff和m68k-elf，它们都是GNU 组织开发的优秀的编译器GCC的不同应用版本。它们的区别在于形成最终flat 目标码之前的中间代码格式分别是coff和elf类型。elf格式的编译器比coff格式 的编译器有许多优越性，建议使用m68k-elf交叉编译器。编译工具包中除了交 叉编译器以外，还有链接器（ld）、汇编器（as）以及一些为了方便开发的二 进制处理工具，包括生成静态库工具（ar、ranlib）、二进制码察看工具（nm 、size）、二进制格式转换工具（objcopy）。这些都要安装在宿主机上。 2.安装uCLinux内核 利用已安装的交叉编译器编译生成运行与目标机上的uCLinux内核。与 标准Linux相同的是，uCLinux内核可以以配置的方式选择需要安装的模块， 而增加系统的灵活性。 3.安装应用程序库 用交叉编译器编译uC-libc和uC-libm源码，生成libc.a应用程序库和 libm.a数学库。 4.安装其他工具 用GCC编译elf2flt源码，生成格式转换工具elf2flt。用GCC编译genromfs 源码，得到生成romfs工具genromfs。 经过以上的准备工作之后，下面要针对特定应用所需要的设备编写或改 造设备驱动程序。有一些设备驱动，uCLinux本身就已经具有。即便没有， 因为uCLinux开放源码的特性，用户也可以很方便地把自己的驱动程序加入 内核。如果用户对系统实时性，特别是硬实时