Board logo

标题: 嵌入式操作系统uCLinux [打印本页]

作者: yuchengze    时间: 2017-5-25 19:10     标题: 嵌入式操作系统uCLinux

摘要: 本文将分析嵌入式操作系统uClinux的内核结构、、内存管理、多进程处理、针对实时性的解决方案和开发环境,先对uCLinux有一个深刻的认识,将有利于今后进一步研究开发。 关键词: uCLinux,内存管理,多进程处理,RTLinux,开发环境 1 引言 嵌入式操作系统是嵌入式系统的灵魂,而且在同一个硬件平台上可以嵌入不同的嵌入式操作系统。比如ARM7TDMI内核,可以嵌入Nucleus、VxWorks、uClinux等操作系统。在此主要对uClinux的进行介绍,嵌入式uClinux操作系统主要有三个基本部分组成:引导程序、uClinux内核(由内存管理、进程管理和中断处理等构成)和文件系统。uClinux可以通过定制使内核小型化,还可以加上GUI(图形用户界面)和定制应用程序,并将其放在ROM、RAM、FLASH或Disk On Chip中启动。由于嵌入式uClinux操作系统的内核定制高度灵活性,开发者可以很容易地对其进行按需配置,来满足实际应用需要。又由于uClinux是源代码公开,因此开发人员只有了解内核原理就可以自己开发部分软件,例如增加各类驱动程序。下面将详细分析嵌入式操作系统uClinux。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




欢迎光临 电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/) Powered by Discuz! 7.0.0