新聞中心

EEPW首頁 > 嵌入式系統(tǒng) > 設(shè)計應(yīng)用 > 嵌入式操作系統(tǒng)uCLinux詳解

嵌入式操作系統(tǒng)uCLinux詳解

作者: 時間:2010-04-19 來源:網(wǎng)絡(luò) 收藏

1 引言

本文引用地址:http://m.butianyuan.cn/article/257980.htm

嵌入式操作系統(tǒng)是嵌入式系統(tǒng)的靈魂,而且在同一個硬件平臺上可以嵌入不同的嵌入式操作系統(tǒng)。比如ARM7TDMI,可以嵌入Nucleus、VxWorks、等操作系統(tǒng)。在此主要對的進(jìn)行介紹,嵌入式操作系統(tǒng)主要有三個基本部分組成:引導(dǎo)程序、uClinux(由、進(jìn)程管理和中斷處理等構(gòu)成)和文件系統(tǒng)。uClinux可以通過定制使小型化,還可以加上GUI(圖形用戶界面)和定制應(yīng)用程序,并將其放在ROM、RAM、FLASH或Disk On Chip中啟動。由于嵌入式uClinux操作系統(tǒng)的內(nèi)核定制高度靈活性,開發(fā)者可以很容易地對其進(jìn)行按需配置,來滿足實際應(yīng)用需要。又由于uClinux是源代碼公開,因此開發(fā)人員只有了解內(nèi)核原理就可以自己開發(fā)部分軟件,例如增加各類驅(qū)動程序。下面將詳細(xì)分析嵌入式操作系統(tǒng)uClinux。

2 嵌入式uCinux內(nèi)核結(jié)構(gòu)

uClinux內(nèi)核結(jié)構(gòu)如圖1所示:

圖1代表了內(nèi)核的功能結(jié)構(gòu),與Linux基本相同,不同的只是對和進(jìn)程管理進(jìn)行改寫,以滿足無MMU處理器的要求。uClinux是Linux 操作系統(tǒng)的一種,是由Linux2.0內(nèi)核發(fā)展來的,是專為沒有MMU的微處理器(如ARM7TDMI、Coldfire 等)設(shè)計的嵌入式Linux操作系統(tǒng)。另外,由于大多數(shù)內(nèi)核源代碼都被重寫,uClinux的內(nèi)核要比原Linux 2.0內(nèi)核小的多, 但保留了Linux 操作系統(tǒng)的主要優(yōu)點:穩(wěn)定性,優(yōu)異的網(wǎng)絡(luò)能力以及優(yōu)秀的文件系統(tǒng)支持。

3 uClinux的

uClinux同標(biāo)準(zhǔn)Linux的最大區(qū)別就在于內(nèi)存管理。標(biāo)準(zhǔn)Linux是針對有MMU的處理器設(shè)計的。在這種處理器上,虛擬地址被送到MMU,MMU把虛擬地址映射為物理地址。通過賦予每個任務(wù)不同的虛擬—物理地址轉(zhuǎn)換映射,支持不同任務(wù)之間的保護(hù)。對于uCLinux來說,其設(shè)計針對沒有MMU的處理器,不能使用處理器的虛擬內(nèi)存管理技術(shù)。

uClinux不能使用處理器的虛擬內(nèi)存管理技術(shù)(應(yīng)該說這種不帶有MMU的處理器在嵌入式設(shè)備中相當(dāng)普遍)。

uClinux仍采用存儲器的分頁管理,系統(tǒng)在啟動時把實際存儲器進(jìn)行分頁。在加載應(yīng)用程序時程序分頁加載。但是由于沒有MMU管理,所以實際上uClinux采用實存儲器管理策略(real memeory management)。這一點影響了系統(tǒng)工作的很多方面。

uClinux系統(tǒng)對于內(nèi)存的訪問是直接的,(它對地址的訪問不需要經(jīng)過MMU,而是直接送到地址線上輸出),所有程序中訪問的地址都是實際的物理地址。操作系統(tǒng)對內(nèi)存空間沒有保護(hù)(這實際上是很多嵌入式系統(tǒng)的特點),各個進(jìn)程實際上共享一個運行空間(沒有獨立的地址轉(zhuǎn)換表)。

一個進(jìn)程在執(zhí)行前,系統(tǒng)必須為進(jìn)程分配足夠的連續(xù)地址空間,然后全部載入主存儲器的連續(xù)空間中。與之相對應(yīng)的是標(biāo)準(zhǔn)Linux系統(tǒng)在分配內(nèi)存時沒有必要保證實際物理存儲空間是連續(xù)的,而只要保證虛存地址空間連續(xù)就可以了。此外磁盤交換空間也是無法使用的,系統(tǒng)執(zhí)行時如果缺少內(nèi)存將無法通過磁盤交換來得到改善。

uClinux對內(nèi)存的管理減少同時就給開發(fā)人員提出了更高的要求。如果從易用性這一點來說,uClinux的內(nèi)存管理是一種倒退,退回了到了UNIX早期或是Dos系統(tǒng)時代。開發(fā)人員不得不參與系統(tǒng)的內(nèi)存管理。從編譯內(nèi)核開始,開發(fā)人員必須告訴系統(tǒng)這塊開發(fā)板到底擁有多少的內(nèi)存(假如你欺騙了系統(tǒng),那將在后面運行程序時受到懲罰),從而系統(tǒng)將在啟動的初始化階段對內(nèi)存進(jìn)行分頁,并且標(biāo)記已使用的和未使用的內(nèi)存。系統(tǒng)將在運行應(yīng)用時使用這些分頁內(nèi)存。

由于應(yīng)用程序加載時必須分配連續(xù)的地址空間,而針對不同硬件平臺的可一次成塊(連續(xù)地址)分配內(nèi)存大小限制是不同(目前針對EZ328處理器的uClinux是128k,而針對Coldfire處理器的系統(tǒng)內(nèi)存則無此限制),所以開發(fā)人員在開發(fā)應(yīng)用程序時必須考慮內(nèi)存的分配情況并關(guān)注應(yīng)用程序需要運行空間的大小。另外由于采用實存儲器管理策略,用戶程序同內(nèi)核以及其它用戶程序在一個地址空間,程序開發(fā)時要保證不侵犯其它程序的地址空間,以使得程序不至于破壞系統(tǒng)的正常工作,或?qū)е缕渌绦虻倪\行異常。

從內(nèi)存的訪問角度來看,開發(fā)人員的權(quán)利增大了(開發(fā)人員在編程時可以訪問任意的地址空間),但與此同時系統(tǒng)的安全性也大為下降。此外,系統(tǒng)對多進(jìn)程的管理將有很大的變化,這一點將在uClinux的多進(jìn)程管理中說明。

4 uClinux的多進(jìn)程處理

uClinux沒有MMU管理存儲器,在實現(xiàn)多個進(jìn)程時(fork調(diào)用生成子進(jìn)程)需要實現(xiàn)數(shù)據(jù)保護(hù)。由于uClinux的多進(jìn)程管理是通過vfork來實現(xiàn),因此fork等于vfork。這意味著uClinux系統(tǒng)fork調(diào)用完成后,要么子進(jìn)程代替父進(jìn)程執(zhí)行(此時父進(jìn)程已經(jīng)sleep)直到子進(jìn)程調(diào)用exit退出;要么調(diào)用exec執(zhí)行一個新的進(jìn)程,這個時候?qū)a(chǎn)生可執(zhí)行文件的加載,即使這個進(jìn)程只是父進(jìn)程的拷貝,這個過程也不能避免。當(dāng)子進(jìn)程執(zhí)行exit或exec后,子進(jìn)程使用wakeup把父進(jìn)程喚醒,使父進(jìn)程繼續(xù)往下執(zhí)行。

uClinux的這種多進(jìn)程實現(xiàn)機(jī)制同它的內(nèi)存管理緊密相關(guān)。uClinux針對沒有mmu處理器開發(fā),所以被迫使用一種flat方式的內(nèi)存管理模式,啟動新的應(yīng)用程序時系統(tǒng)必須為應(yīng)用程序分配存儲空間,并立即把應(yīng)用程序加載到內(nèi)存。缺少了MMU的內(nèi)存重映射機(jī)制,uClinux必須在可執(zhí)行文件加載階段對可執(zhí)行文件reloc處理,使得程序執(zhí)行時能夠直接使用物理內(nèi)存。

5 uCLinux針對實時性的解決方案

uClinux本身并沒有關(guān)注實時問題,它并不是為了Linux的實時性而提出的。另外有一種Linux:RT-Linux關(guān)注實時問題。RT-Linux執(zhí)行管理器把普通Linux的內(nèi)核當(dāng)成一個任務(wù)運行,同時還管理了實時進(jìn)程。而非實時進(jìn)程則交給普通Linux內(nèi)核處理。這種方法已經(jīng)應(yīng)用于很多的操作系統(tǒng)用于增強操作系統(tǒng)的實時性,包括一些商用版UNIX系統(tǒng),Windows NT等等。這種方法優(yōu)點之一是實現(xiàn)簡單,且實時性能容易檢驗。優(yōu)點之二是由于非實時進(jìn)程運行于標(biāo)準(zhǔn)Linux系統(tǒng),同其它Linux商用版本之間保持了很大的兼容性。優(yōu)點之三是可以支持硬實時時鐘的應(yīng)用。uClinux可以使用RT-Linux的patch,從而增強uClinux的實時性,使得uClinux可以應(yīng)用于工業(yè)控制、進(jìn)程控制等一些實時要求較高的應(yīng)用。

6 uClinux的開發(fā)環(huán)境

1,GNU開發(fā)套件

GNU開發(fā)套件作為通用的Linux開放套件,包括一系列的開發(fā)調(diào)試工具。主要組件:
Gcc: 編譯器,可以做成交叉編譯的形式,即在宿主機(jī)上開發(fā)編譯目標(biāo)上可運行的二進(jìn)制文件。
Binutils:一些輔助工具,包括objdump(可以反編譯二進(jìn)制文件),as(匯編編譯器),ld(連接器)等等。
Gdb:調(diào)試器,可使用多種交叉調(diào)試方式,gdb-bdm(背景調(diào)試工具),gdbserver(使用以太網(wǎng)絡(luò)調(diào)試)。

2, Clinux的打印終端

通常情況下,uClinux的默認(rèn)終端是串口,內(nèi)核在啟動時所有的信息都打印到串口終端(使用printk函數(shù)打印),同時也可以通過串口終端與系統(tǒng)交互。

uClinux在啟動時啟動了telnetd(遠(yuǎn)程登錄服務(wù)),操作者可以遠(yuǎn)程登錄上系統(tǒng),從而控制系統(tǒng)的運行。至于是否允許遠(yuǎn)程登錄可以通過燒寫romfs文件系統(tǒng)時由用戶決定是否啟動遠(yuǎn)程登錄服務(wù)。

3, 交叉編譯調(diào)試工具

支持一種新的處理器,必須具備一些編譯,匯編工具,使用這些工具可以形成可運行于這種處理器的二進(jìn)制文件。對于內(nèi)核使用的編譯工具同應(yīng)用程序使用的有所不同。在解釋不同點之前,需要對gcc連接做一些說明:
ld(link description)文件:ld文件是指出連接時內(nèi)存映象格式的文件。

crt0.S:應(yīng)用程序編譯連接時需要的啟動文件,主要是初始化應(yīng)用程序棧。

pic:position independence code ,與位置無關(guān)的二進(jìn)制格式文件,在程序段中必須包括reloc段,從而使的代碼加載時可以進(jìn)行重新定位。

內(nèi)核編譯連接時,使用ucsimm.ld文件,形成可執(zhí)行文件映象,所形成的代碼段既可以使用間接尋址方式(即使用reloc段進(jìn)行尋址),也可以使用絕對尋址方式。這樣可以給編譯器更多的優(yōu)化空間。因為內(nèi)核可能使用絕對尋址,所以內(nèi)核加載到的內(nèi)存地址空間必須與ld文件中給定的內(nèi)存空間完全相同。

應(yīng)用程序的連接與內(nèi)核連接方式不同。應(yīng)用程序由內(nèi)核加載(可執(zhí)行文件加載器將在后面討論),由于應(yīng)用程序的ld文件給出的內(nèi)存空間與應(yīng)用程序?qū)嶋H被加載的內(nèi)存位置可能不同,這樣在應(yīng)用程序加載的過程中需要一個重新地位的過程,即對reloc段進(jìn)行修正,使得程序進(jìn)行間接尋址時不至于出錯。(這個問題在i386等高級處理器上方法有所不同)。

由上述討論,至少需要兩套編譯連接工具:

1) 二進(jìn)制工具(Binutils)

GNU binutils包包括了匯編工具、鏈接器和基本的目標(biāo)文件處理工具。對binutils包的設(shè)置定義了所需的目標(biāo)文件的格式和字節(jié)順序。Binutils包種的工具都使用了二進(jìn)制文件描述符(BFD)庫來交換數(shù)據(jù)。通過設(shè)置文件config.bfd,可以指定默認(rèn)的二進(jìn)制文件格式(例如elf little endian)和任何工具可用的格式,見例1。

例1 在config.bfd中添加的用來指定目標(biāo)二進(jìn)制格式的代碼

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是通過使用一種叫做“寄存器轉(zhuǎn)換語言”(RTL)的方式實現(xiàn)的。假定現(xiàn)在有一種基本的機(jī)器描述性文件,它已經(jīng)能滿足大家的需要?,F(xiàn)在要做的僅僅是設(shè)置默認(rèn)情況下使用的參數(shù)和如何將文件組合成可執(zhí)行文件的方式。GNU的文檔提供了所有必需的資料,使得用戶可以為新型的處理器的指令集合提供支持。如果要針對體系的機(jī)器建立一個新的目標(biāo)機(jī)器,那么就必須指定默認(rèn)編譯參數(shù)和定制系統(tǒng)的特定參數(shù),見例2。對于特定的目標(biāo)系統(tǒng),可以使用TARGET_DEFAULT宏來在target.h文件中定義編譯器的開關(guān)。目標(biāo)t-makefile段指定了應(yīng)該構(gòu)建哪一個額外的例程和其編譯的方式。

例2 使用uClinux-arm.h來指定默認(rèn)的編譯參數(shù)

#undef TARGET_DEFAULT
#define TARGET_DEFAULT(ARM_FLAG_APCS_32|ARM_FLAG_NO_GOT)

4 可執(zhí)行文件格式

先對一些名詞作一些說明:

coff(common object file format):一種通用的對象文件格式
elf(excutive linked file):一種為Linux系統(tǒng)所采用的通用文件格式,支持動態(tài)連接
flat:elf格式有很大的文件頭,flat文件對文件頭和一些段信息做了簡化

uClinux系統(tǒng)使用flat可執(zhí)行文件格式,gcc的編譯器不能直接形成這種文件格式,但是可以形成coff或elf格式的可執(zhí)行文件,這兩種文件需要coff2flt或elf2flt工具進(jìn)行格式轉(zhuǎn)化,形成flat文件。當(dāng)用戶執(zhí)行一個應(yīng)用時,內(nèi)核的執(zhí)行文件加載器將對flat文件進(jìn)行進(jìn)一步處理,主要是對reloc段進(jìn)行修正。以下對reloc段進(jìn)一步討論。

需要reloc段的根本原因是,程序在連接時連接器所假定的程序運行空間與實際程序加載到的內(nèi)存空間不同。假如有這樣一條指令:

jsr app_start;

這一條指令采用直接尋址,跳轉(zhuǎn)到app_start地址處執(zhí)行,連接程序?qū)⒃诰幾g完成是計算出app_start的實際地址(設(shè)若實際地址為0x10000),這個實際地址是根據(jù)ld文件計算出來(因為連接器假定該程序?qū)⒈患虞d到由ld文件指明的內(nèi)存空間)。但實際上由于內(nèi)存分配的關(guān)系,操作系統(tǒng)在加載時無法保證程序?qū)磍d文件加載。這時如果程序仍然跳轉(zhuǎn)到絕對地址0x10000處執(zhí)行,通常情況這是不正確的。一個解決辦法是增加一個存儲空間,用于存儲app_start的實際地址,設(shè)若使用變量addr表示這個存儲空間。則以上這句程序?qū)⒏臑椋?br />movl addr, a0;
jsr (a0);

增加的變量addr將在數(shù)據(jù)段中占用一個4字節(jié)的空間,連接器將app_start的絕對地址存儲到該變量。在可執(zhí)行文件加載時,可執(zhí)行文件加載器根據(jù)程序?qū)⒁虞d的內(nèi)存空間計算出app_start在內(nèi)存中的實際位置,寫入addr變量。系統(tǒng)在實際處理時不需要知道這個變量的確切存儲位置(也不可能知道),系統(tǒng)只要對整個reloc段進(jìn)行處理就可以了(reloc段有標(biāo)識,系統(tǒng)可以讀出來)。處理很簡單,只需要對reloc段中存儲的值統(tǒng)一加上一個偏置(如果加載的空間比預(yù)想的要靠前,實際上是減去一個偏移量)。偏置由實際的物理地址起始值同ld文件指定的地址起始值相減計算出。這種reloc的方式部分是由uClinux的內(nèi)存分配問題引起的。

7 總結(jié)

以上主要闡述了嵌入式操作系統(tǒng)uClinux的內(nèi)核結(jié)構(gòu)、、內(nèi)存管理、多進(jìn)程處理、針對實時性的解決方案和開發(fā)環(huán)境,先對uCLinux有一個深刻的認(rèn)識,將有利于今后進(jìn)一步研究開發(fā)。



評論


相關(guān)推薦

技術(shù)專區(qū)

關(guān)閉