嵌入式操作系统uCLinux

勇敢的心-1351

1　引言?
　　嵌入式操作系统是嵌入式系统的灵魂，而且在同一个硬件平台上可以嵌入不同的嵌入式操作系统。比如ARM7TDMI内核，可以嵌入Nucleus、VxWorks、uClinux等操作系统。在此主要对uClinux的进行介绍，嵌入式uClinux操作系统主要有三个基本部分组成：引导程序、uClinux内核（由内存管理、进程管理和中断处理等构成）和文件系统。uClinux可以通过定制使内核小型化，还可以加上GUI(图形用户界面)和定制应用程序，并将其放在ROM、RAM、FLASH或Disk?On?Chip中启动。由于嵌入式uClinux操作系统的内核定制高度灵活性，开发者可以很容易地对其进行按需配置，来满足实际应用需要。又由于uClinux是源代码公开，因此开发人员只有了解内核原理就可以自己开发部分软件，例如增加各类驱动程序。下面将详细分析嵌入式操作系统uClinux。

　　2?嵌入式uCinux内核结构

　　uClinux内核结构如图1所示：

　图1代表了内核的功能结构，与Linux基本相同，不同的只是对内存管理和进程管理进行改写，以满足无MMU处理器的要求。uClinux是Linux?操作系统的一种，是由Linux2.0内核发展来的，是专为没有MMU的微处理器（如ARM7TDMI、Coldfire?等）设计的嵌入式Linux操作系统。另外,由于大多数内核源代码都被重写，uClinux的内核要比原Linux?2.0内核小的多,?但保留了Linux?操作系统的主要优点：稳定性，优异的网络能力以及优秀的文件系统支持。

　　3?uClinux的内存管理

　　uClinux同标准Linux的最大区别就在于内存管理。标准Linux是针对有MMU的处理器设计的。在这种处理器上，虚拟地址被送到MMU，MMU把虚拟地址映射为物理地址。通过赋予每个任务不同的虚拟—物理地址转换映射，支持不同任务之间的保护。对于uCLinux来说，其设计针对没有MMU的处理器，不能使用处理器的虚拟内存管理技术。

　　uClinux不能使用处理器的虚拟内存管理技术（应该说这种不带有MMU的处理器在嵌入式设备中相当普遍）。

　　uClinux仍采用存储器的分页管理，系统在启动时把实际存储器进行分页。在加载应用程序时程序分页加载。但是由于没有MMU管理，所以实际上uClinux采用实存储器管理策略(real?memeory?management)。这一点影响了系统工作的很多方面。

　　uClinux系统对于内存的访问是直接的，（它对地址的访问不需要经过MMU，而是直接送到地址线上输出），所有程序中访问的地址都是实际的物理地址。操作系统对内存空间没有保护（这实际上是很多嵌入式系统的特点），各个进程实际上共享一个运行空间（没有独立的地址转换表）。?

　　一个进程在执行前，系统必须为进程分配足够的连续地址空间，然后全部载入主存储器的连续空间中。与之相对应的是标准Linux系统在分配内存时没有必要保证实际物理存储空间是连续的，而只要保证虚存地址空间连续就可以了。此外磁盘交换空间也是无法使用的，系统执行时如果缺少内存将无法通过磁盘交换来得到改善。

　　uClinux对内存的管理减少同时就给开发人员提出了更高的要求。如果从易用性这一点来说，uClinux的内存管理是一种倒退，退回了到了UNIX早期或是Dos系统时代。开发人员不得不参与系统的内存管理。从编译内核开始，开发人员必须告诉系统这块开发板到底拥有多少的内存（假如你欺骗了系统，那将在后面运行程序时受到惩罚），从而系统将在启动的初始化阶段对内存进行分页，并且标记已使用的和未使用的内存。系统将在运行应用时使用这些分页内存。

　　由于应用程序加载时必须分配连续的地址空间，而针对不同硬件平台的可一次成块（连续地址）分配内存大小限制是不同（目前针对EZ328处理器的uClinux是128k，而针对Coldfire处理器的系统内存则无此限制），所以开发人员在开发应用程序时必须考虑内存的分配情况并关注应用程序需要运行空间的大小。另外由于采用实存储器管理策略，用户程序同内核以及其它用户程序在一个地址空间，程序开发时要保证不侵犯其它程序的地址空间，以使得程序不至于破坏系统的正常工作，或导致其它程序的运行异常。

　　从内存的访问角度来看，开发人员的权利增大了（开发人员在编程时可以访问任意的地址空间），但与此同时系统的安全性也大为下降。此外，系统对多进程的管理将有很大的变化，这一点将在uClinux的多进程管理中说明。

　　4?uClinux的多进程处理

　　uClinux没有MMU管理存储器，在实现多个进程时（fork调用生成子进程）需要实现数据保护。由于uClinux的多进程管理是通过vfork来实现，因此fork等于vfork。这意味着uClinux系统fork调用完成后，要么子进程代替父进程执行（此时父进程已经sleep）直到子进程调用exit退出；要么调用exec执行一个新的进程，这个时候将产生可执行文件的加载，即使这个进程只是父进程的拷贝，这个过程也不能避免。当子进程执行exit或exec后，子进程使用wakeup把父进程唤醒，使父进程继续往下执行。

　　uClinux的这种多进程实现机制同它的内存管理紧密相关。uClinux针对没有mmu处理器开发，所以被迫使用一种flat方式的内存管理模式，启动新的应用程序时系统必须为应用程序分配存储空间，并立即把应用程序加载到内存。缺少了MMU的内存重映射机制，uClinux必须在可执行文件加载阶段对可执行文件reloc处理，使得程序执行时能够直接使用物理内存。

　　5　?uCLinux针对实时性的解决方案

　　uClinux本身并没有关注实时问题，它并不是为了Linux的实时性而提出的。另外有一种Linux：RT－Linux关注实时问题。RT-Linux执行管理器把普通Linux的内核当成一个任务运行，同时还管理了实时进程。而非实时进程则交给普通Linux内核处理。这种方法已经应用于很多的操作系统用于增强操作系统的实时性，包括一些商用版UNIX系统，Windows?NT等等。这种方法优点之一是实现简单，且实时性能容易检验。优点之二是由于非实时进程运行于标准Linux系统，同其它Linux商用版本之间保持了很大的兼容性。优点之三是可以支持硬实时时钟的应用。uClinux可以使用RT-Linux的patch，从而增强uClinux的实时性，使得uClinux可以应用于工业控制、进程控制等一些实时要求较高的应用。

　　6　?uClinux的开发环境

　　1，GNU开发套件

　　GNU开发套件作为通用的Linux开放套件，包括一系列的开发调试工具。主要组件：
　　Gcc：?编译器，可以做成交叉编译的形式，即在宿主机上开发编译目标上可运行的二进制文件。
　　Binutils：一些辅助工具，包括objdump（可以反编译二进制文件），as（汇编编译器），ld（连接器）等等。
　　Gdb：调试器，可使用多种交叉调试方式，gdb-bdm（背景调试工具），gdbserver（使用以太网络调试）。

　　2，?Clinux的打印终端

　　通常情况下，uClinux的默认终端是串口，内核在启动时所有的信息都打印到串口终端（使用printk函数打印），同时也可以通过串口终端与系统交互。

　　uClinux在启动时启动了telnetd（远程登录服务），操作者可以远程登录上系统，从而控制系统的运行。至于是否允许远程登录可以通过烧写romfs文件系统时由用户决定是否启动远程登录服务。

　　3，?交叉编译调试工具

　　支持一种新的处理器，必须具备一些编译，汇编工具，使用这些工具可以形成可运行于这种处理器的二进制文件。对于内核使用的编译工具同应用程序使用的有所不同。在解释不同点之前，需要对gcc连接做一些说明：
ld（link?description）文件：ld文件是指出连接时内存映象格式的文件。

crt0.S：应用程序编译连接时需要的启动文件，主要是初始化应用程序栈。

pic：position?independence?code?，与位置无关的二进制格式文件，在程序段中必须包括reloc段，从而使的代码加载时可以进行重新定位。

　　内核编译连接时，使用ucsimm.ld文件，形成可执行文件映象，所形成的代码段既可以使用间接寻址方式（即使用reloc段进行寻址），也可以使用绝对寻址方式。这样可以给编译器更多的优化空间。因为内核可能使用绝对寻址，所以内核加载到的内存地址空间必须与ld文件中给定的内存空间完全相同。

　　应用程序的连接与内核连接方式不同。应用程序由内核加载（可执行文件加载器将在后面讨论），由于应用程序的ld文件给出的内存空间与应用程序实际被加载的内存位置可能不同，这样在应用程序加载的过程中需要一个重新地位的过程，即对reloc段进行修正，使得程序进行间接寻址时不至于出错。（这个问题在i386等高级处理器上方法有所不同）。

　　由上述讨论，至少需要两套编译连接工具：

　　1）?二进制工具（Binutils）

　　GNU?binutils包包括了汇编工具、链接器和基本的目标文件处理工具。对binutils包的设置定义了所需的目标文件的格式和字节顺序。Binutils包种的工具都使用了二进制文件描述符（BFD）库来交换数据。通过设置文件config.bfd，可以指定默认的二进制文件格式（例如elf?little?endian）和任何工具可用的格式，见例1。

　　例1?在config.bfd中添加的用来指定目标二进制格式的代码

arm-*-uClinux*?|?armel-*-uClinux*
tag_defvec=bfd_elf32_littlearm_vec
targ_selvecs=”bfd_elf32_bigarm_vec?armcoff_little_vec?armcoff_big_vec”

　　2）?C编译器

　　GNU编译器集GCC是通过使用一种叫做“寄存器转换语言”（RTL）的方式实现的。假定现在有一种基本的机器描述性文件，它已经能满足大家的需要。现在要做的仅仅是设置默认情况下使用的参数和如何将文件组合成可执行文件的方式。GNU的文档提供了所有必需的资料，使得用户可以为新型的处理器的指令集合提供支持。如果要针对体系的机器建立一个新的目标机器，那么就必须指定默认编译参数和定制系统的特定参数，见例2。对于特定的目标系统，可以使用TARGET_DEFAULT宏来在target.h文件中定义编译器的开关。目标t-makefile段指定了应该构建哪一个额外的例程和其编译的方式。

　　例2?使用uClinux-arm.h来指定默认的编译参数

＃undef?TARGET_DEFAULT
#define?TARGET_DEFAULT(ARM_FLAG_APCS_32|ARM_FLAG_NO_GOT)

　　4?可执行文件格式

　　先对一些名词作一些说明：

　　coff（common?object?file?format）：一种通用的对象文件格式
　　elf（excutive?linked?file）：一种为Linux系统所采用的通用文件格式，支持动态连接
　　flat：elf格式有很大的文件头，flat文件对文件头和一些段信息做了简化

　　uClinux系统使用flat可执行文件格式，gcc的编译器不能直接形成这种文件格式，但是可以形成coff或elf格式的可执行文件，这两种文件需要coff2flt或elf2flt工具进行格式转化，形成flat文件。当用户执行一个应用时，内核的执行文件加载器将对flat文件进行进一步处理，主要是对reloc段进行修正。以下对reloc段进一步讨论。

　　需要reloc段的根本原因是，程序在连接时连接器所假定的程序运行空间与实际程序加载到的内存空间不同。假如有这样一条指令：

jsr?app_start;

　　这一条指令采用直接寻址，跳转到app_start地址处执行，连接程序将在编译完成是计算出app_start的实际地址（设若实际地址为0x10000），这个实际地址是根据ld文件计算出来（因为连接器假定该程序将被加载到由ld文件指明的内存空间）。但实际上由于内存分配的关系，操作系统在加载时无法保证程序将按ld文件加载。这时如果程序仍然跳转到绝对地址0x10000处执行，通常情况这是不正确的。一个解决办法是增加一个存储空间，用于存储app_start的实际地址，设若使用变量addr表示这个存储空间。则以上这句程序将改为：
movl?addr,?a0;
jsr?(a0);

　　增加的变量addr将在数据段中占用一个4字节的空间，连接器将app_start的绝对地址存储到该变量。在可执行文件加载时，可执行文件加载器根据程序将要加载的内存空间计算出app_start在内存中的实际位置，写入addr变量。系统在实际处理时不需要知道这个变量的确切存储位置（也不可能知道），系统只要对整个reloc段进行处理就可以了（reloc段有标识，系统可以读出来）。处理很简单，只需要对reloc段中存储的值统一加上一个偏置（如果加载的空间比预想的要靠前，实际上是减去一个偏移量）。偏置由实际的物理地址起始值同ld文件指定的地址起始值相减计算出。这种reloc的方式部分是由uClinux的内存分配问题引起的。

　　7?总结

　　以上主要阐述了嵌入式操作系统uClinux的内核结构、、内存管理、多进程处理、针对实时性的解决方案和开发环境，先对uCLinux有一个深刻的认识，将有利于今后进一步研究开发。

cursor_2008

正在研究这个东西，感觉没那么容易上手，有点茫然。
革命尚未成功，我还得努力。

maxim-103559

了解了解