Software modulu pro sb r a zpracování dat. Bc. Michal Navrkal. ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická

eské vysoké u£ení technické v Praze Fakulta elektrotechnická

Diplomová práce

Software modulu pro sb¥r a zpracování dat Bc. Michal Navrkal

Vedoucí práce:

Doc.Ing. Róbert Lórencz, CSc.

Studijní program: Elektrotechnika a informatika strukturovaný magisterský

Obor: Informatika a výpo£etní technika

leden 2009

iv

Pod¥kování Tímto bych cht¥l pod¥kovat vedoucímu své diplomové práce Doc.Ing. Róbertu Lórenczovi, CSc. a odbornému asistentu Ing. Ji°ímu Bu£kovi za ve²kerou pomoc a £as, který mi v¥novali.

v

vi

Prohlá²ení Prohla²uji, ºe jsem svou diplomovou práci vypracoval samostatn¥ a pouºil jsem pouze podklady uvedené v p°iloºeném seznamu. Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu 60 Zákona £. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon· (autorský zákon).

V Praze dne 20.1. 2009

.............................................................

vii

viii

Abstract The aim of this work was to create software for complete embedded solution for data acquisition in experimental nuclear physics based on FPGA. First I was concerned with embedded systems and operating systems for embedded solutions, particularly OS Linux. In the second part of this work I described how device drivers look and how they are written correctly. In the third part I gave an account of process of creating bootable Linux image and device drivers implementation for our embedded system. At the conclusion I described client-server solution for obtaining data from this dedicated embedded system.

Abstrakt Tato práce se zaobírá vývojem softwaru pro embedded za°ízení na bázi FPGA, které slouºí k hromadnému sb¥ru a zpracování dat v experimentální jaderné fyzice. Nejprve jsem se zaobíral embedded systémy a pro n¥ vhodnými opera£ními systémy, zejména pak OS Linux. V druhé £ásti jsem popsal, jak vypadají ovlada£e za°ízení pro tento OS a jak je správn¥ implementovat. Ve t°etí £ásti jsem popsal vlastní postup pro vytvo°ení pln¥ funk£ního linuxového obrazu pro tento vestavný systém a implementaci ovlada£· pro p°ístup k nam¥°eným hodnotám a kontrolu celého systému. Na záv¥r jsem popsal a ukázal vyvinuté programy pro komunikaci mezi tímto vestavným za°ízením a uºivatelskými aplikacemi.

ix

x

Obsah Seznam obrázk·

xiii

Seznam tabulek

xv

1 Úvod

1

2 Popis systému

3

2.1

DAQ modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.2

Vestavné systémy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.2.1

Denice

3

2.2.2

Historie vestavných systém· . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.2.3

Opera£ní systémy pro embedded za°ízení . . . . . . . . . . . . . . . . . . .

5

Hardwarové vybavení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.3

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Analýza °e²ení 3.1

13

3.1.1

Co to vlastn¥ je? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

Modely vývoje ovlada£· za°ízení

3.1.2

3.2

13

Ovlada£e za°ízení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.1.2.1

Windows driver model . . . . . . . . . . . . . . . . . . . . . . . .

15

3.1.2.2

Linux driver model . . . . . . . . . . . . . . . . . . . . . . . . . .

16

Jádro Linux systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.2.1

Ovlada£e v kernel space

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.2.2

Ovlada£e v user space

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

3.2.3

Moduly jádra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

3.2.4

Správa pam¥ti

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

3.2.5

P°id¥lování pam¥ti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

3.2.6

Linux boot proces

23

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Vlastní implementace 4.1

4.2

4.3

4.4

27

Port Linuxu pro XUP V2P

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.1.1

K°íºový kompilátor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.1.2

Kompilace jádra OS linux . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4.1.3

BusyBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

4.1.4

Vytvo°ení RFS

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

Implementace ovlada£· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

4.2.1

Histogramická jednotka

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

4.2.2

Ovlada£ DCM modulu . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

4.2.3

Ovlada£ pro práci s korek£ní pam¥tí

44

. . . . . . . . . . . . . . . . . . . . .

Server a klient aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

4.3.1

Komunikace mezi modulem a zobrazující aplikací . . . . . . . . . . . . . .

44

4.3.2

Server aplikace

4.3.3

Klientská PC aplikace

Testování

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

5 Záv¥r

55

6 Literatura

57

A Seznam pouºitých zkratek

59 xi

B Kongura£ní soubor kompilace jádra Linuxu

61

C Kongura£ní soubor kompilace BusyBoxu

71

D Skript pro vytvo°ení RFS s BusyBoxem

81

E Skript pro ovládání DAQServer daemona

85

F P°ehled d·leºitých p°íkaz· pro XMD

87

G Uºivatelská / instala£ní p°íru£ka

89

H Obsah p°iloºeného CD

91

xii

Seznam obrázk· 2.1

Pohled na DAQ modul a jeho umíst¥ní v systému . . . . . . . . . . . . . . . . . .

2.2

Ukázka EDK designu pro ná² systém . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.3

Pohled na vytvá°ení HW a SW bitstreamu . . . . . . . . . . . . . . . . . . . . . .

9

2.4

Úloha SysACE v systému

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

3.1

R·zné role ovlada£· za°ízení v systému, [17] . . . . . . . . . . . . . . . . . . . . .

14

3.2

Boot proces klasického PC, [7] . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

3.3

Boot proces embedded systému, [7] . . . . . . . . . . . . . . . . . . . . . . . . . .

25

4.1

Vývoj softwaru pro Target na Host platform¥

28

xiii

. . . . . . . . . . . . . . . . . . . .

4

xiv

Seznam tabulek 3.1

Podporované typy pro parametrizaci modul·

. . . . . . . . . . . . . . . . . . . .

20

4.1

P°ehled registr· DCM modulu

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

4.2

P°ehled komunika£ních rychlostí podle UART obvodu

4.3

P°ehled p°enosových rychlostí podle WiFi standardu

4.4

Tabulka zpráv pro klient-server komunikaci

xv

. . . . . . . . . . . . . . .

45

. . . . . . . . . . . . . . . .

46

. . . . . . . . . . . . . . . . . . . . .

48

xvi

KAPITOLA 1.

ÚVOD

1

1 Úvod Tématem mojí práce je návrh a implementace softwarového vybavení pro modul, který slouºí k hromadnému sb¥ru dat. Modul je ur£en pro sbírání £etností výskytu £ástic v experimentální jaderné fyzice. V následujícím textu celé diplomové práce budu tento modul ozna£ovat jako DAQ modul Data Acquisition modul. Práce souvisí a navazuje na práci kolegy Ing. Mat¥je

Machalce: Hardware modulu pro sb¥r a zpracování dat [11], jejíº výsledkem byl návrh kompletní hardwarové architektury modulu a jeho za£len¥ní do celkového designu systému. Cílem obou t¥chto prácí je vytvo°it celistvý fungující vestavný systém s opera£ním systémem Linux, který bude data nejenom shromaº¤ovat, ale bude i zprost°edkovávat p°ístup k t¥mto dat·m ostatním aplikacím. Práce m¥la být p·vodn¥ koncipována pro FPGA °ady Virtex4 FX, která obsahuje embedded procesor PowerPC 405. Nicmén¥ po dohod¥ s vedoucím práce byla z d·vodu absence vhodné desky s £ipem Xilinx Virtex4 zvolena implementace na vývojové desce XUP VirtexII Pro s FPGA XC2VP30, která je na kated°e po£íta£· k dispozici a je taktéº vybavena dv¥mi hardcore embedded procesory PowerPC 405. Práce v sob¥ zahrnuje vytvo°ení image s fungujícím systémem pro procesor PowerPC 405, ovlada£e DAQ modulu pro opera£ní systém Linux ve verzi jádra 2.4, návrh a implementaci zp·sobu kominikace mezi DAQ modulem a uºivatelskými aplikacemi odstín¥nými od p°ímého p°ístupu k modulu nebo jeho ovlada£·m. Funk£nost systému a komunikace bude ov¥°ena klientskou aplikací zobrazující data z DAQ modulu ve form¥ sloupcových graf· a koordinující £innost modulu vzdálen¥. V následující kapitole si p°iblíºíme ná² DAQ modul a hardware, který máme k dispozici. Poté bude následovat analýza vývoje nízkoúrov¬ového softwaru pro embedded za°ízení (OS a ovlada£e) a popis vlastní implementace takovéhoto softwaru pro ná² modul. Na záv¥r p°edstavím moºnosti komunikace uºivatelských aplikací s modulem a popí²i implementaci jednoho zvoleného °e²ení (klient-server °e²ení).

2

KAPITOLA 1.

ÚVOD

KAPITOLA 2.

POPIS SYSTÉMU

3

2 Popis systému V této kapitole se zam¥°ím na celkový popis systému, jak hardware tak i software. P°iblíºíme si, jak vypadá modul pro sb¥r dat, jaké £ásti ho tvo°í a jaké jsou jeho úkoly. Seznámíme se s pojmy, jako jsou vestavný systém a RTOS, nakoukneme do procesu vývoje vestavných za°ízení a podíváme se blíºe, na jakém hardwaru budeme vlastn¥ pracovat (viz. [22]).

2.1

DAQ modul

Tento modul, jak jsem jiº zmi¬oval v úvodu, vznikl jako diplomová práce na kated°e po£íta£· VUT v Praze. Autorem je Ing. Mat¥j Machalec a podrobný popis je k dispozici v jeho diplomové práci [11]. Modul slouºí ke sb¥ru a zaznamenávání statistických dat v experimentální jaderné fyzice. P°esn¥ji se jedná o zaznamenávání £etností výskytu (histogramu) jaderných £ástic o specické energii v prost°edí. Modul (jeho £ást) také generuje signály pro dvojici detektor· £ástic, jejichº analogový výstup je digitalizován taktéº dvojicí analogov¥-digitálních p°evodník·. Takto digitalizovaná data jsou zpracována modulem a uchovávána v jeho pam¥ti ve form¥ histogramických záznam·. Digitalizovaná data jsou je²t¥ p°ed uchováním v pam¥ti modulu zpracována £ástí DAQ modulu zodpov¥dnou za korekci nam¥°ených dat. Tuto logickou £ást DAQ modulu budu ozna£ovat za korek£ní £ást modulu nebo je²t¥ jednodu²eji korek£ní pam¥´ modulu, protoºe jde vlastn¥ o p°ekladovou tabulku (uloºenou v pam¥ti) £ásti nam¥°ené hodnoty na hodnotu jinou, korek£n¥ upravenou. Práv¥ obsah pam¥ti, kde se uchovávají histogramy nás bude eminentn¥ zajímat, to jsou data, která pot°ebujeme z modulu vy£íst a dát k dispozici uºivatelským aplikacím. Budu ji nazývat histogramickou £ástí DAQ modulu nebo histogramickou pam¥tí modulu. ást, která se stará o generování signál· pro detektor a p°evodníky je sice sou£ástí DAQ modulu, je v²ak na n¥m nezávislá a do systému (do návrhu v EDK) se za£le¬uje samostatn¥. Budu ji v celé práci ozna£ovat za DCM modul, i p°esto, ºe je sou£ástí DAQ modulu. Zjednodu²ený pohled na DAQ modul je vid¥t na obrázku 2.1.

2.2

Vestavné systémy

Aplika£ní oblast vestavných systém· (angl. embedded systems ) roste stále aº neuv¥°itelným tempem a zahrnuje v sob¥ nep°eberné mnoºství odv¥tví a za°ízení. Setkáme se s nimi tém¥° na kaºdém kroku, i kdyº si to £asto ani neuv¥domujeme, jsou základem kaºdého moderního elektronického za°ízení. P°íklad· proto najdeme dost a dost, po£ínaje jednoduchými systémy vybavenými pouze £idly, p°es mobilní za°ízení v²eho druhu, domácí spot°ebi£e, výdejní automaty aº k velkým systém·m s n¥kolika procesory na jednom £ipu. Embedded systémy pat°í bezesporu k nejroz²í°en¥j²í variant¥ vyuºívání výpo£etních systém· v·bec. Dokazují to i £ísla WSTS [18] z roku 2005, kdy z 9 miliard procesor· vyrobených v tomto roce, jich na²lo uplatn¥ní ve vestavných systémech plných 8,8 miliardy. Zbylá 2% p°ipadla na pracovní a serverové stanice.

2.2.1 Denice Denovat, co v²echno zahrnout pod pojem vestavný systém není jednoduché. V literatu°e najdeme více denic [17]:

4

KAPITOLA 2.

POPIS SYSTÉMU

Obrázek 2.1: Pohled na DAQ modul a jeho umíst¥ní v systému

•

Po£íta£ zabudovaný do systému, ov²em skrytý p°ed uºivatelem.

•

Dedikovaný po£íta£ pracující v reálném £ase jako sou£ást v¥t²ího uceleného systému. Tomuto systému poskytuje své výpo£etní sluºby, koordinuje a °ídí jeho £innost jako celku.

•

Malý po£íta£ový systém, zabudovaný uvnit° sloºit¥j²ího za ú£elem vy²²í výkonnosti nebo efektivnosti.

•

Cílové prost°edí slouºící pouze k vykonávání dané £innosti, neslouºí k vývoji systému, ten se provádí na hostitelském PC.

•

Systém obsahující aº n¥kolik mikroprocesor·, jejichº úkolem je °ídit £innost jednotlivých £ástí systému (displeje, motory, £idla. . . ).

Z pohledu uºivatele £asto degraduje charakterizace vestavných systém· na systémy, které jsou ur£ené k vykonávání jediné úlohy nebo mnoºiny úloh, ke kterým jsou optimalizovány co se tý£e náklad·, rozm¥r·, rychlosti návrhu a bezpe£nosti. Nemusí se nutn¥ snaºit o spln¥ní optim ve v²ech t¥chto ohledech najednou. Z pohledu vývojá°e je nutno zahrnout do klasikace dal²í vlastnosti, jako jsou moºnost vyvíjet paraleln¥ hardwarovou a softwarovou £ást systému, dostate£né mnoºství opera£ních systém· vhodných pro poºadované sou£ásti, dostatek mikroprocesor· pro kaºdou jednotlivou úlohu, sloºitost lad¥ní systému a nutnou robustnost systému a odolnost proti chybám a nep°íznivým vliv·m okolí. Bez ohledu na typ nebo velikost aplikace, klí£ovou z·stává úloha testování, monitorování a odstra¬ování chyb. FPGA °ady VirtexII Pro jsou zdárným p°íkladem embedded °e²ení, které dokáºe t¥ºit ze SoC zp·sobu navrhování obvod·. Jedná se o pln¥ programovatelný FPGA obvod s dv¥ma hardcore procesory PowerPC 405, propojitelnými s ostatními £ástmi obvodu skrze IBM CoreConnect bus. Komunika£ní zpoºd¥ní mezi procesorem a IP jádrem je redukováno na

KAPITOLA 2.

POPIS SYSTÉMU

5

minimum, z d·vodu existence p°ímého propojení a sdílení rychlé pam¥ti s malou dobou odezvy. Spole£ná koexistence FPGA obvodu a hardcore procesoru dovoluje odd¥lit vývoj a testování hardwaru a softwaru do dvou nezávislých v¥tví. Jen záv¥re£né testování a monitoring je pot°eba provád¥t na kone£né konguraci vestavného systému. FPGA a mikroprocesory zastávají kaºdý trochu odli²nou roli. FPGA jsou kongurovatelné reprogramovatelné digitální obvody, které se obvykle programují interpretací kódu zapsaného v n¥jakém hardware popisujícím jazyku, jakým je nej£ast¥ji VHDL nebo Verilog. Kdeºto mikroprocesor vykonává p°eddenovanou mnoºinu instrukcí a neoplývá takovou exibilitou. Ta je dána pouze mohutností mnoºiny instrukcí procesoru a ²ikovností programátora. Programáto°i na takto nízké úrovni pí²í zejména v jazyce C, uº mén¥ £asto v C++, pop°ípad¥ rovnou v instrukcích daného procesoru.

2.2.2 Historie vestavných systém· P°edtím neº se blíºe seznámíme s na²í vývojovou deskou a na²í kongurací hardwaru, je ur£it¥ p°ínosné podívat se trochu do historie vývoje vestavných systém· a do doby, která p°edcházela jejich vzniku a roz²í°ení. Po£íta£ové systémy se b¥hem vývoje transformovaly z ob°ích výpo£etních jednotek zabírajících n¥kolik místností na kompaktní p°enosné po£íta£e, které se snadno vejdou do kapsy. Jak u takovýchto za°ízení bývá £asto zvykem, stojí u jejich zrodu vojenské poºadavky, potaºmo poºadavky související s vesmírným programem. A to zejména poºadavky na spolehlivost a kompaktnost za°ízení. V takovýchto situacích jde trochu stranou otázka nancí. Za první embedded systém je obecn¥ povaºován navád¥cí po£íta£ pro vesmírný program Apollo vyvinutý v laborato°ích MIT v USA. Práv¥ sniºování velikosti a váhy p°inutilo pouºít v¥dce Charlese Stark Drapera integrované obvody. První hromadn¥ vyráb¥ný embedded systém byl navád¥cí systém pro taktické st°ely Minuteman z roku 1961. Ten byl je²t¥ vytvo°en z jednotlivých tranzistor·, ov²em jeho nástupce Minuteman II z roku 1967 jiº pouºíval velké mnoºství integrovaných obvod·. S hromadnou produkcí t¥chto integrovaných obvod· zákonit¥ p°i²lo jejich dramatické zlevn¥ní umoº¬ující vyuºití integrovaných obvod· i v komer£ních výrobcích. Od té doby zaznamenaly embedded systémy obrovský boom a jiº v osmdesátých letech byla v¥t²ina d°íve externích sou£ástek integrována na jednom £ipu. Neustále se zlep²ovaly výpo£etní moºnosti mikroprocesor· a klesala cena. To umoºnilo nahrazení klasické analogové sou£ástky digitálními obvody °ízenými mikrokontroléry.

2.2.3 Opera£ní systémy pro embedded za°ízení Embedded opera£ní systém je omezen¥j²í verze OS, jaké známe z osobních po£íta£·. Omezení jsou kladena ve smyslu poskytování men²í mnoºiny funkcí a uºite£ných vlastností. Jsou v¥t²inou navrºeny s ohledem na uspokojování speciálních pot°eb embedded systém·. Mohou být psány p°ímo na míru danému za°ízení nebo se dají pouºít univerzální. Rostoucí míra vyuºívání embedded OS je zap°í£in¥na samotným vývojem embedded za°ízení od úzce zam¥°ených, k t¥m více komplexn¥j²ím. To s sebou p°iná²í pot°ebu °ídit hardwarové a softwarové zdroje a pot°ebu stabilního a konzistentního rozhraní pro vývoj aplikací. D·leºitou podmnoºinou embedded OS jsou tzv. realtime OS (RTOS). Jde o OS obsluhující podn¥ty z okolí v reálném £ase. V reálném £ase zde nemusí nutn¥ znamenat okamºit¥ jakmile nastanou , ale v n¥jaké garantované dob¥, která závisí na specické aplikaci za°ízení. Ur£it¥ sem nelze vypsat jednu jedinou denici a tak uvedeme n¥kolik b¥ºných, £asto se vyskytujících denic RTOS [5].

1. Denice

Real-time systém je systém, ve kterém je správnost výstupu závislá nejen na správ-

6

KAPITOLA 2.

POPIS SYSTÉMU

nosti výsledku výpo£tu, ale téº na £ase, v n¥mº je výsledek spo£ten.

2. Denice

Real-time systém je systém, který reaguje p°edvídatelným zp·sobem na nep°ed-

vídatelné externí události.

3. Denice

Pokud lze dokázat, ºe realtime systém splní svá ultimáta (deadlines) (a to za pou-

ºití chování systému v nejhor²ím moºném p°ípad¥, nikoliv analýzou pr·m¥rného chování systému), potom m·ºeme °íci, ºe chování systému je p°edvídatelné.

Hlavními znaky RTOS jsou:

•

minimální latence p°i reakci na událost

•

minimální latence p°i p°epínání výpo£etních vláken

•

£asto nutnost malých rozm¥r·

•

minimalizace £asových okamºik·, kdy je vypnuto p°eru²ení

•

preemptivní plánování zaloºené na prioritách

•

správná funkce závisí nejen na výpo£etním výsledku, ale také na £ase, kdy ho bude dosaºeno

•

obvykle malé systémy se specializovaným pouºitím, p°ípadn¥ jako nadstavba v¥t²ích OS (Windows, Linux)

Nej£ast¥j²ím d¥lením RTOS je na Soft a Hard RTOS.

Hard real time

vykonání poºadavku po deadline je nep°ípustné a m·ºe vést aº ke katastro-

ckým selháním

Soft real time

tolerují jistou míru latence, zpoºd¥ní m·ºe vést ke sníºení kvality poskytova-

ných sluºeb, ale není kritické pro chod systému (nap°. výpadek rámce ve video p°enosu)

Jako p°íklady RTOS m·ºeme uvést Windows s RTX (s Real Time eXtensions), RTLinux, VxWorks, QNX, FreeRTOS.

2.3

Hardwarové vybavení

Ná² embedded systém postavíme na bázi FPGA. P°esn¥ji p·jde o desku Xilinx XUP s FPGA °ady VirtexII Pro XC2VP30 s dv¥mi hardcore procesory PowerPC 405 spole£nosti IBM. Deska má pom¥rn¥ bohatou výbavu:

•

DDR SDRAM (aº 2GB, pouºijeme 256 MB modul)

•

System ACE

TM °adi£ a Type II CompactFlashTM konektor pro uloºení dat a konguraci

FPGA

•

Platform USB kongura£ní port

•

Podpora pro Golden a User kongura£ní bitstream uloºený v PROM

•

On-board 10/100 Ethernet

KAPITOLA 2.

POPIS SYSTÉMU

•

RS-232 DB9 sériový port

•

Dva PS-2 porty

•

LED diody, p°epína£e, tla£ítka

•

AC-97 audio kodek s konektory

•

XSGA výstup, rozli²ení aº 1200 x 1600 @70 Hz

7

Krom¥ toho, deska je vybavena sadou nízko i vysokorychlostních expanzních konektor· kompatibilních s deskami Digilent.

PowerPC 405 •

Aº 450 MHz, 700+ MIPS RISC (32-bitová Harvardská architektura)

•

5-stup¬ová pipeline

•

Hardwarová násobi£ka i d¥li£ka

•

32 x 32-bitových registr· pro v²eobecné pouºití

•

16 KB 2-cestn¥ asociativní instruk£ní a datová cache

•

MMU umoº¬ující provoz RTOS

•

64-záznamová TLB spole£ná pro data a instrukce

•

Velikost stránky je prom¥nná (1KB - 16 KB)

•

Podpora IBM CoreConnect bus architektury

•

Podpora pro lad¥ní a trasování

•

Podpora pro hardwarové akcelerátory a koprocesory t°etích stran

•

Podpora pro uºivatelem denované instrukce

•

Podpora pro DSP

•

Little i Big endian mód

Vývoj na²eho modulu odpovídá typickému design ow embedded aplikací s RTOS. Pro²el postupn¥ fázemi:

•

návrh nového IP jádra DAQ modulu

•

sestavení a propojení IP jader do celistvého designu (procesor, sb¥rnice, periferie. . . )

•

kongurace jádra opera£ního systému

•

vývoj rmwaru a podp·rných aplikací

•

nahrání celého designu do FPGA

8

KAPITOLA 2.

POPIS SYSTÉMU

Obrázek 2.2: Ukázka EDK designu pro ná² systém

Design byl vytvá°en v návrhovém softwaru EDK rmy Xilinx [20]. Jaké IP bloky jsou zapojené v na²em návrhu je vid¥t na obrázku 2.2. Výsledkem syntézy designu je soubor s p°íponou .bit jde o tzv. hardwarový bitstream, tedy posloupnost bit· nutných pro implementaci hardwaru z logických bun¥k a pro propojení hardcore jader s ostatními v FPGA obvodu. EDK pro nás krom¥ bitstreamu produkuje i jiné soubory. Tím nejd·leºit¥j²ím p°i vývoji obrazu linuxového jádra je hlavi£kový soubor xparameters.h, v kterém jsou denovány jednozna£né identikátory jader pouºitých v designu, bázové adresy t¥chto jader, vektory p°eru²ení a jiné konstanty, které budeme pot°ebovat p°i vývoji ovlada£e a konguraci kernelu. Jako softwarový bitstream pouºijeme obraz jádra Linuxového opera£ního systému. Takovýto soubor nese p°íponu .elf. Tento standard p·vodn¥ vydaný Unix System Laboratories se stává stále více populárním a to nejenom mezi embedded systémy. Stal se jiº defaultním binárním formátem na opera£ních systémech Linux a Solaris a to hlavn¥ díky faktu, ºe representace kontrolních dat v objektových souborech je platform¥ nezávislá, narozdíl od jeho p°edch·dc· (a.out, COFF. . . ). Jak se vytvá°í oba soubory je vid¥t na obrázku 2.3. Oba tyto soubory pot°ebujeme n¥jakým zp·sobem dostat do FPGA. Hardwarový bitstream pot°ebujeme ke konguraci FPGA, abychom m¥li v·bec na £em spustit OS a softwarový bitstream zase abychom m¥li na syntetizovaném hardwaru co spustit. Moºností, jak se s tímto vypo°ádat je více. Obecn¥ je nejvíce doporu£ováno vyuºít SysACE kontrolér, který je schopný z .ace souboru (kombinace .bit a .elf ) uloºeného na CF disku v FAT16 oddíle nakongurovat FPGA, nainicializovat CPU a zapo£ít boot proces s nahráním Linux kernelu do instruk£ní pam¥ti. CF pak m·ºe být pouºita jako datové úloºi²t¥ t°eba pro Linux RFS. Tento zp·sob je p°iblíºen na obrázku 2.4.

KAPITOLA 2.

POPIS SYSTÉMU

9

Obrázek 2.3: Pohled na vytvá°ení HW a SW bitstreamu

Soubor .ace vytvo°íme pomocí utility GenACE. Pot°ebujeme mírn¥ upravit teacle script pro desku XUP, který najdeme v <EDK>/data/xmd/genace.tcl. Doplníme na za£átek souboru do místa, kde se popisují podporované desky následující:

# Production XUPV2P - created by Jonathon W. Donaldson - 7/21/2006 set xupv2p(jtag_chain_options) "-configdevice devicenr 1 idcode 0x0127e093 irlength 14 partname xc2vp30 -debugdevice devicenr 1 cpunr 1" set xupv2p(jtag_fpga_position) 1 set xupv2p(jtag_devices) "xc2vp30" Upravený skript si nahrajeme k na²emu designu, nap°. do adresá°e gen_ace. Vytvo°íme si soubor s parametry pro GenACE - xupGenACE.opt. Vypadá n¥jak takto:

-jprog -board xupv2p -target ppc_hw -hw implementation/system.bit -elf elf_directory/zImage.elf -ace ace_directory/system.ace Soubor si nahrajeme do adresá°e s genace.tcl skriptem tedy adresá°e gen_ace. Poté spustíme EDK shell a zadáme p°íkaz:

$ xmd -tcl gen_ace/genace.tcl -opt gen_ace/xupGenACE.opt Podotýkám, ºe skript o£ekává hardwarový bitstream v implementation/system.bit, .elf soubor v elf_directory/zImage.elf a výsledný .ace soubor nalezneme v ace_directory/system.ace (specikováno v xupGenACE.opt souboru).

10

KAPITOLA 2.

POPIS SYSTÉMU

Obrázek 2.4: Úloha SysACE v systému

Druhou moºností je nahrát oba bitstreamy odd¥len¥. Tohoto postupu se vyuºívá zejména p°i vývoji a testování. Hardwarový bitstream m·ºeme nahrát p°es JTAG rozhraní pomocí Impact utility nebo m·ºe být uloºena v PROM pam¥ti na desce a po kaºdém restartu nahrána do FPGA. Samoz°ejm¥ záleºí na desce, jak je vybavená. XUP tyto moºnosti má. Po nahrání HW bitstreamu se m·ºeme k PowerPC p°ipojit p°es XMD a nahrát do jeho pam¥ti výkonný kód (.elf soubor). V EDK Shellu:

$ XMD Xilinx Microprocessor Debug (XMD) Engine Xilinx EDK 8.2.02 Build EDK_Im_Sp2.4 Copyright (c) 1995-2005 Xilinx, Inc. All rights reserved. XMD\% XMD\% connect ppc hw -cable xilinx_platformusb frequency 12000000 XMD\% dow zImage.elf XMD\% run Více uºite£ných p°íkaz· pro XMD je v p°íloze F. Volba Linuxu jako opera£ního systému pro ná² modul nebyla náhodná. Hlavním d·vodem byla jeho v²estrannost a samoz°ejm¥ i volná bezplatná dostupnost (za dodrºení licen£ních podmínek GPL). Práv¥ volná dostupnost zdrojových kód· d¥lá z Linuxu ideálního kandidáta na post OS pro ne zrovna mainstreamové projekty, které ov²em ºádají dostate£ný výkon, stabilitu a uºivatelskou p°ív¥tivost. Zdrojové kódy jiº del²í dobu existují v podob¥ vhodné pro platformu PowerPC, to znamená p°eportované pro procesor PowerPC. Z dostupných distribucí jsem vybral MontaVista Linux s jádrem ve verzi 2.4, p°esn¥ ²lo o verzi 2.4.26. Vedli mn¥ k tomu d·vody zcela jasné a evidentní. Jednak je to verze jádra odzkou²ená na mnoha aplikacích po celém sv¥t¥

KAPITOLA 2.

POPIS SYSTÉMU

11

a za druhé je to existence velice dobré podpory pro tém¥° v²echny periferie a IP jádra dostupné pro desku XUP a v neposlední °ad¥ p°ímá podpora této distribuce z vývojového prost°edí Xilinx EDK. Samoz°ejm¥ jsem nejprve zkou²el zprovoznit pro desku XUP nov¥j²í jádro verze 2.6. Av²ak zde je podpora pro tuto desku ze strany výrobce minimální. Poda°ilo se mi sice vytvo°it obraz schopný nabootovat a namountovat RFS na CF, ov²em po dokon£ení init programu systém zamrzne a není moºné se nalogovat jako uºivatel root. Navíc nejsou k dispozici pro toto jádro ovlada£e pro na²e síóvé rozhraní. P°estoºe se mi nepoda°ilo tyto problémy vy°e²it, myslím, ºe i tato cesta by mohla být p°i velké snaze sch·dná. P°echod na 2.6 jádro by mohl být jednodu²²í po vým¥n¥ vývojové desky práv¥ pro n¥jakou z °ady Virtex4 FX, kde je podpora ze strany rmy Xilinx mnohem lep²í. Tento p°echod s sebou p°iná²í pot°ebu upravit i na²e ovlada£e. V tom nespat°uji zásadní problém, pokud bude podpora z nov¥j²ích verzí EDK alespo¬ taková, jaká je pro verzi jádra 2.4. Moºnost vydat se cestou 2.6 jádra jsem nechal jako moºnost pro budoucí pokra£ování práce na tomto projektu.

12

KAPITOLA 2.

POPIS SYSTÉMU

KAPITOLA 3.

ANALÝZA EENÍ

13

3 Analýza °e²ení V této £ásti bych se rád v¥noval problematice ovlada£· za°ízení, doporu£eným postup·m p°i jejich vývoji, modul·m jádra a tomu, co se d¥je po zapnutí takového vestavného za°ízení. Podrobnosti je moºno dohledat v literatu°e [17],[6],[2], p°ípadn¥ [13].

3.1

Ovlada£e za°ízení

Ovlada£, p°esn¥ji ovlada£ za°ízení (angl. device driver ) je software, který umoº¬uje opera£nímu systému pracovat s hardwarem. P·vodn¥ vzniklo pojmenování ovlada£ za°ízení jako ozna£ení ovlada£· fyzických za°ízení, p°estoºe dnes jiº toto striktní omezení na fyzická za°ízení dávno neplatí. Výraz ovlada£ £asto p°enesen¥ ozna£uje i £ásti opera£ního systému poskytující jinou funkcionalitu neº jen p°ístup k hardware a tedy se nejedná doslova o ovlada£ za°ízení - zvlá²´ pokud v daném opera£ním systému neexistuje jiné pojmenování. Typickým p°íkladem je £ást implementující n¥který typ souborového systému. Vyskytují se i p°ípady, kdy není zcela jasné, zda k ovlada£i pat°í n¥jaké fyzické za°ízení nebo ne. Jako p°íklad m·ºe poslouºit rozhraní ovlada£e EMS, které p·vodn¥ zprost°edkovávalo p°ístup k externím pam¥óvým za°ízením, pozd¥ji k pam¥ti od 1MB vý²e tzv. expanded memory. N¥které ovlada£e jsou sou£ástí opera£ního systému, jiné jsou distribuovány spolu s hardwarem. Pro kaºdý exemplá° n¥jakého hardwarového za°ízení (i pro ta virtuální) n¥kdo musel napsat ovlada£, aby bylo za°ízení zcela funk£ní. Je mnoho d·vod·, pro£ se zabývat psaním ovlada£·. Jedním z nich je rychlost, jakou vznikají stále nová a nová za°ízení pot°ebující kvalitní, pokud moºno bezchybný, ovlada£.

3.1.1 Co to vlastn¥ je? Ovlada£e se £asto ozna£ují za £erné krabi£ky, které zprost°edkovávají komunikaci a °ízení hardwaru a zárove¬ komunikují se zbytkem opera£ního systému pomocí obecn¥j²ích, dob°e denovaných a známých rozhraní, která zaji²újí vy²²í úrove¬ abstrakce. Základní vlastností abstrakce je pouºití stejného nebo podobného rozhraní pro podobná za°ízení: t°eba abstrakce blokového za°ízení umoº¬uje pracovat stejn¥ s diskem, disketou a CD/DVD mechanikou. Dále plní funkci ur£itého opro²t¥ní programátor· aplika£ních program· od znalosti fungování a chování za°ízení. Zpravidla bývá práce s rozhraním snaz²í neº p°ímý p°ístup k za°ízení. Odd¥lení obsluhy za°ízení od jádra opera£ního systému navíc zna£n¥ zjednodu²uje návrh architektury a sniºuje moºnost chyby p°i vývoji. asto se rozhraní k ovlada£i realizuje jako soubor za°ízení (angl. device le ). Tradi£ní implementace unixových systém· nabízí uºivateli ve svém RFS adresá° /dev. V tomto adresá°i se nachází tzv. device nodes, které reprezentují r·zná za°ízení. Ne v²echny soubory v tomto adresá° musí korespondovat s fyzickým za°ízením. Existuje n¥kolik virtuálních pseudoza°ízení jako /dev/null, full, loop, zero, random a jiné, které umoº¬ují vyuºívat n¥které funkce OS. Tento p°ístup umoº¬uje p°istupovat k za°ízením jako k b¥ºnému souboru a nenutí uºivatele pouºívat speciální API. Operace nad daným za°ízením pak degradují na operace nad soubory, jako jsou otev°ení, £tení, zápis, seek nebo uzav°ení souboru. Operace na takových souborech jsou preferovanou metodou pro komunikaci mezi aplikací a ovlada£em. Jakou roli hrají ovlada£e v systému je vid¥t na obrázku 3.1.

3.1.2 Modely vývoje ovlada£· za°ízení Dobrý ovlada£ by m¥l ctít n¥kolik zásad. D·leºitým sloví£kem, které se £asto v souvislosti s kvalitou kódu ovlada£e uvádí je exibilita. Ta podtrhuje roli a základní nároky na ovlada£.

14

KAPITOLA 3.

ANALÝZA EENÍ

Obrázek 3.1: R·zné role ovlada£· za°ízení v systému, [17]

Ovlada£ by m¥l poskytnout v²echnu dostupnou funkcionalitu pro dané za°ízení a zárove¬ neklást ºádné omezení na vyuºívání t¥chto funkcionalit uºivatelem, pokud to není vyºadováno okolnostmi. D·vod je jednoduchý - kaºdý uºivatel má své specické pot°eby a nároky. Flexibilní ovlada£e poskytují £asto synchronní i asynchronní operace, umoº¬ují vícenásobný p°ístup k za°ízení. Takto psané ovlada£e nejen ºe pracují lépe z pohledu koncového uºivatele, ale i jejich vývoj je snadn¥j²í a výsledek obsahuje mén¥ chyb. asto se musí ov²em volit ur£itý kompromis mezi mírou exibility a dobou vývoje ovlada£e. Trochu jiný pohled p°edstavuje náhled na ovlada£ jako na ur£itou softwarovou mezivrstvu mezi za°ízením a aplikacemi. Potom programátor sám volí, jaká omezení budou na hardware, lépe °e£eno na p°ístup k tomuto hardwaru, kladena. Rozdílné ovlada£e mohou pro stejné za°ízení poskytovat jiné, omezené, funkce. Spolu s ovlada£em m·ºe být dodávána knihovna s roz²i°ujícími funkcemi a kontrolními nástroji (od jednoduchých aº po sloºité pln¥ gracké utility) uleh£ující práci se za°ízením a jeho kongurací. V OS Linux se rozli²ují t°i hlavní t°ídy za°ízení, tzv. driver classes. Ov²em hranice mezi t¥mito t°ídami se mohou £asto potírat a nemusí být ob£as jednoduché za°ízení do jedné z nich za°adit:

znakov¥ orientované

Jsou p°ístupné jako proud byt·. Znakové za°ízení je takové, ke kterému

se m·ºe p°istupovat jako k souboru a práv¥ znakov¥ orientovaný ovlada£ se stará o implementaci takovéhoto chování. Ovlada£ implementuje základní operace (systémová volání) jako otev°ít, £íst, zapisovat a zav°ít. Jako typický p°edstavitel této t°ídy lze uvést konsoli nebo paralelní port.

blokov¥ orientované

Blokové za°ízení je takové, které v sob¥ dokáºe udrºovat soubor systém·.

Blokové za°ízení je p°ístupné pouze po blocích dat, kde blok má nej£ast¥ji velikost jednotek kB. Jde o za°ízení s náhodným p°ístupem.

síóvé

Umoº¬uje komunikaci mezi síóvým za°ízením a opera£ním systémem, stejn¥ jako s

jinými za°ízeními nebo po£íta£i v jiné síti. D·leºitou organizací, která má velký vliv na sm¥r, kterým se vývoj ovlada£· ubírá a bude ubírat, je uskupení IHV sdruºující více neº 250 spole£ností zabývajících se vývojem a prodejem hardwarových za°ízení. Základním posláním OS je vytvá°et jakousi abstraktní vrstvu, která umoº¬uje spolupráci hardwaru a aplikací. IHV ºádá, aby ve²kerý její hardware byl schopen

KAPITOLA 3.

ANALÝZA EENÍ

15

vyuºívat v²echny dostupné vlastnosti a specika daného OS. Na druhou stranu OS chce vyuºít ve²keré výhody a výkonnostní moºnosti hardwaru, na kterém b¥ºí. Pokaºdé, kdyº se ob¥ zmín¥né strany, vývojá°i OS a hardwaru, snaºí p°idávat nebo n¥jakým zp·sobem p°eskupovat funkcionalitu, jedná se vºdy o dynamickou interakci. O co se jedná kaºdému je to, ºe hardware má prost¥ fungovat bez n¥jakých sloºitých zásah·, krok· nebo omezení. Dnes pracuje Linux s mnohem v¥t²ím mnoºstvím za°ízení neº kterýkoliv jiný OS v historii. Nicmén¥ ani tento komfort neposta£uje, pokud neexistuje podpora pro za°ízení, které práv¥ pot°ebujete pouºívat. V minulosti opera£ní systém Windows dosti t¥ºil z faktu, ºe IHV utrácelo mnohem více zdroj· na vývoj ovlada£· pro OS Windows. P°ehled silných a slabých stránek Windows a Linuxového modelu pomáhá objasnit dne²ní situaci na poli ovlada£· za°ízení a poskytuje téº informace vedoucí k pochopení, pro£ nakonec Linux p°edb¥hl Windows v kvalit¥ podpory týkající se hardwarových za°ízení a jejich ovlada£·.

3.1.2.1 Windows driver model Mnoho výrobc· hardwaru je podrobn¥ seznámeno s Windows modelem. Teorie skrývající se za Windows modelem spo£ívá v poskytování stabilního ABI rmou Microsoft ve form¥ mnoºiny systémových volání nebo, chcete-li, volání systémových funkcí, které mohou vývojá°i ovlada£· vyuºívat. Tato rozhraní reprezentují mnoºinu sluºeb jádra OS dostupných ovlada£·m za°ízení. IHV testuje a certikuje jejich ovlada£e oproti vydaným ABI daného OS. Microsoft p°islíbil poskytovat stejné binární rozhraní po celou dobu vývoje a ºivota OS, takºe IHV se m·ºe, a také tak £iní, na toto rozhraní spolehnout. Opodstatn¥ní tohoto p°edpokladu je tak trochu skryto v pozadí. Jde o snahu poskytnout vývojá°·m za°ízení moºnost odd¥lit sv·j vývoj od vývoje OS. Idea je taková, ºe Microsoft kontroluje svoje uzav°ené (nezve°ejn¥né) kódy OS a vývojá°i IHV kontrolují své uzav°ené kódy ovlada£·, se spole£ným stabilním ABI jakoºto jediného rozhraní mezi t¥mito dv¥ma kusy kódu. I p°estoºe vývojá°i ovlada£· nemají jakýkoliv p°ístup nebo náhled do jádra OS mimo toto ABI, spatn¥ napsaný ovlada£ obsahující chyby m·ºe stále zp·sobit pád celého systému. A opravdu, ovlada£e stojí za nejv¥t²ím procentem pád· a nestability systému. IHV nezve°ej¬ují zdrojové kódy od svých Windows ovlada£·, jsou vydávány pouze jako binární soubory. IHV m·ºe vydávat nové ovlada£e nebo upgradeovat staré nezávisle na vývoji OS, p°ípadn¥ m·ºe nechat uºivatele instalovat nov¥j²í verze. Jednou stinnou stránkou tohoto p°ístupu je, ºe ABI stabilního ovlada£e pot°ebuje po OS, aby toto rozhraní zamknul. To znamená, ºe pokud dojde ke zm¥n¥ ABI, a´ uº z d·vodu bezpe£nosti nebo výkonu, dané rozhraní se nesmí zru²it, ale ozna£it za zastaralé (obsolete ). Jako p°íklad uve¤me situaci, kdy na obou systémech, Windows a Linux, pot°ebuji p°epsat interní systémové USB implementace ovlada£·. Linux by byl schopný upgradeovat rozhraní a následn¥ ovlada£e, a poté p°ed¥lat rozhraní OS. Na druhou stranu Windows, musí pokra£ovat v poskytování starého rozhraní, coº m·ºe zp·sobit bolesti hlavy nejednomu vývojá°i, ale m·ºe taktéº vést k chybám a bezpe£nostním mezerám. Tento jev se n¥kdy také ozna£uje za vlá£ení koule zp¥tné binární kompatibility . Binární ovlada£e mají navíc tendenci být chybov¥j²í, protoºe chyby mohou být odhaleny a opraveny pouze sdruºením IHV, ne komunitou výrobc· systém·, vývojá°· a uºivatel·. Dal²í klí£ovou nevýhodou uzav°ené povahy Windows ovlada£· je opakování velkého mnoºství d·leºitých £ástí kód· nap°í£ r·znými ovlada£i. Tato duplicita je zp·sobena malým mnoºstvím lidí, kte°í mají p°ístup ke kód·m. Protoºe nikdo nemá moºnost vid¥t ve²keré tyto kódy, je tedy velice t¥ºké vy£lenit a optimalizovat spole£né podmnoºiny kód·. Nejv¥t²ím problémem Windows modelu je fakt, ºe stabilní ABI ovlada£· nez·stává stabilní. Microsoft modikoval Windows ABI v kaºdém vydání Windows OS! Kaºdá zm¥na v ABI m·ºe zp·sobit konec bezproblémového fungování hardwaru. K xaci problému je pot°eba, aby IHV

16

KAPITOLA 3.

ANALÝZA EENÍ

p°epsali ovlada£e na nejnov¥j²í ABI. To je v²ak práce £asov¥ velice náro£ná a m·ºe zabrat celá léta. N¥kte°í £lenové IHV se nap°íklad rozhodli rad¥ji nepodporovat v·bec Windows Vista pro star²í hardware. A kaºdé nové vydání Windows (v£etn¥ servisních balí£k· a záplat) navíc poskytuje ovlada£·m nový prostor pro jejich disfunkci. Jak jiº podotkl magazín PC World v jednom ze svých vydání: Microsoftský debakl s nefungováním ovlada£· pro Windows Vista po upgradu na Service Pack 1 je o£ekávaným a neodvratným výsledkem strategického rozhodnutí rmy ohledn¥ OS Windows p·vodn¥ vydaným p°ed více neº dv¥mi dekádami.".

3.1.2.2 Linux driver model Linux model vývoje ovlada£· je odli²ný. U linuxového modelu IHV vkládá akceptované zdrojové kódy do hlavní vývojové v¥tve linuxového kernelu. Tím pádem zaji²úje ve°ejný dohled na kvalitu kódu ovlada£e a na jeho bezchybnost £i p°ípadná bezpe£nostní rizika. Linux nemá vedle stabilního ABI ani stabilní API. To znamená, ºe neexistuje garance, ºe n¥jaké rozhraní poskytované v jedné verzi jádra Linuxu bude dostupné ve verzích následujících. V kontrastu s tím, co jsem práv¥ °ekl, Linux kernel poskytuje stabilní uºivatelské rozhraní v user space pro linuxové aplikace. To je d·vod pro£ p°edkompilované linuxové aplikace mohou b¥ºet korektn¥ na více distribucích a více verzích jednotlivých distribucí. To je rozdíl oproti ovlada£·m za°ízení, které nemají ºádné garance, ºe n¥jaké rozhraní jádra na kterém závisí, a´ uº binární nebo ve form¥ zdrojových kód·, z·stanou konsistentní mezi verzemi jádra. Fakticky, kód ovlada£e je integrální sou£ástí linuxového OS. Jakmile je jednou ovlada£ akceptován do hlavní v¥tve linuxových kód·, bude obsahován po°ád, i pokud se zm¥ní n¥jaké vnit°ní rozhraní jádra. To znamená, kdyº se p°ijme patch m¥nící rozhraní jádra, musí patch zárove¬ upgradeovat kaºdý ovlada£, který na n¥m závisí. Hlavní síla tohoto p°ístupu z uºivatelského pohledu je, ºe jakmile, v kontrastu s proprietárními OS jako Windows Vista, jednou za°ízení funguje na dané verzi Linuxu, jeho podpora pokra£uje skrze v²echny následující verze. Za°ízení jsou obvykle odebírány pouze v p°ípad¥, ºe se staly velice z°ídka pouºívanými. Dá se °íci, ºe v Linuxu se podpora hardwaru jenom zlep²uje, nikdy nezhor²uje. Z pohledu IHV je nejv¥t²í výhodou fakt, ºe ovlada£ vydaný touto organizací je p°ístupný ²iroké komunit¥ vývojá°·, znamenající, ºe ostatní lidé opravují, vylep²ují a p°idávají dal²í funkcionality do tohoto ovlada£e. Kdyº se zm¥ní vnit°ní rozhraní jádra v nové verzi OS, IHV nemusí psát a vydávat nový ovlada£, jejich ovlada£ je upgradeován automaticky. Zastaralé rozhraní pak m·ºe být ozna£eno za dále nepouºívané (deprecated ) a rad¥ji odstran¥no, neº aby bylo sou£ástí jádra nav¥ky. Spole£né subsystémy mohou být z ovlada£· faktorizovány a vedou tak k men²í chybovosti ovlada£·. A to samoz°ejm¥ zlep²uje stabilitu, bezpe£nost a zralost obou - OS i ovlada£e. Navíc tento Linux model umoº¬uje podporu nap°í£ architekturami tém¥° zadarmo. Dokonce kdyº IHV testuje své ovlada£e jen na jedno£ipové architektu°e, vývojá°i, které to zajímá, se ujistí, ºe ovlada£ funguje s kaºdou architekturou podporující Linux, kterých je mnohem více neº kdy m¥l jakýkoliv jiný OS. Síla tohoto p°ístupu se projevila zejména za poslední dekádu, kdy se mnoho po£íta£ových architektur p°eorientovalo z 32 na 64 bit·. Tém¥° v²echny ovlada£e byly rychle updatovány pro podporu t¥chto nových architektur. Podpora ovlada£· pro 64-bitové Windows Vista dokonce na nejroz²í°en¥j²í architektu°e x86 z·stává i dnes dosti omezená. Nejv¥t²í p°ekáºkou Linux driver modelu pro n¥které £leny IHV je nutnost otev°ených kód· jejich ovlada£·. P°estoºe skupina vydavatel· ovlada£· odmítající tento p°ístup slábne, stále takoví existují.

KAPITOLA 3.

3.2

ANALÝZA EENÍ

17

Jádro Linux systému

Na tomto míst¥ se blíºe podíváme na jádro linuxového opera£ního systému s ohledem na ovlada£e za°ízení.

3.2.1 Ovlada£e v kernel space Rolí OS je poskytnout aplikacím konzistentní pohled na hardware po£íta£e, na kterém b¥ºí. OS se také musí starat o nezávislost operací provád¥ných b¥ºícími programy a o ochranu p°ed neoprávn¥ným p°ístupem ke zdroj·m (pam¥´, za°ízení. . . ). Toho je OS schopný pouze za p°edpokladu, ºe je schopný vynutit si tuto ochranu od aplikací. Kaºdý moderní procesor je takovéhoto chování schopen. Základ je v existenci n¥kolika (minimáln¥ dvou) úrovní nebo stav·, ve kterých CPU pracuje. Kaºdý stav má rozdílné role a pro kaºdý stav bývá povolena jen ur£itá mnoºina operací a ostatní jsou na této nejniº²í úrovni zakázány. Program m·ºe b¥hem svého vykonávání mezi t¥mito úrovn¥mi p°epínat, pokud samoz°ejm¥ splní podmínky, které na n¥j OS v tomto sm¥ru klade. V Linuxu se pouºívají dv¥ úrovn¥, a to superuser (kernel) mód a user mód. Jak jméno napovídá, v kernel módu b¥ºí jádro OS a v user space ostatní aplikace. Kernel mód neklade ºádná omezení na b¥h programu, zatímco v user space procesor omezuje p°ímý p°ístup k hardwaru a neautorizované pam¥ti. V p°ípad¥, ºe CPU podporuje více úrovní neº 2, jsou pouºity ta nejvy²²í a nejniº²í. User a kernel mód v sob¥ nesou nejenom dv¥ rozdílné úrovn¥ zabezpe£ení vykonávání kódu, ale i dva rozdílné adresové prostory se svým vlastním adresováním (memory mapping ). V p°ípad¥, ºe user space program pouºije systémové volání nebo dojde k vyvolání p°eru²ení, dojde k p°epnutí do kernel space, kde se systémové volání nebo p°eru²ení obslouºí. Rozdíl p°eci jenom ale mezi t¥mito dv¥mi situacemi existuje. Pokud kernel space obsluhuje systémové volání n¥jakého procesu z user space, pracuje se v kontextu tohoto procesu a je moºno p°istupovat k dat·m tohoto procesu v jeho adresovém prostoru. Pokud ov²em dojde k p°eru²ení, potom obsluha p°eru²ení nemá jakékoliv informace o kterémkoliv procesu. Velkým rozdílem p°ístupu k psaní b¥ºných aplikací a ovlada£· je vypo°ádání se s tzv. soub¥hem (concurrency ). Aplikace v¥t²inou b¥ºí sekven£n¥ od za£átku do konce a vývojá°i se nemusejí moc starat o to, co v²echno se m·ºe v jednom okamºiku stát. U ovlada£· to takto nejde. Musí se brát v potaz, ºe m·ºe dojít ve stejnou chvíli k soub¥hu spousty v¥cí, s kterými si musí poradit s ohledem na konsistenci. V Linuxu je n¥kolik zdroj· soub¥hu:

•

opera£ní systém jako takový umoº¬uje b¥ºet více proces·m najednou (multitasking ) a kaºdý z nich se m·ºe snaºit p°istupovat nebo vyuºívat ná² ovlada£

•

spousty za°ízení je schopno p°eru²it procesor a vykonat asynchronní obsluhu zrovna v okamºiku, kdy se ovlada£ pokou²í uskute£nit jinou operaci

•

samoz°ejm¥ i Linux m·ºe b¥ºet na víceprocesorové platform¥ (vícejádrové procesory, SMP, vícevláknové procesory...), kde na kaºdém procesoru m·ºe b¥ºet proces p°istupující k na²emu ovlada£i

Výsledkem je, ºe ovlada£ musí být reentrantní, coº znamená, ºe musí být schopen b¥ºet sou£asn¥ ve více neº jednom kontextu. To sebou nese pot°ebu dob°e navrhnout datové struktury a ochránit p°ístup ke sdíleným prost°edk·m tak, aby nedocházelo ke kolizím na sdílených prost°edcích (race coditions ). Naprosto ²patným p°ístupem je, pokud se spokojíme s konstatováním, ºe nebezpe£í soub¥hu se nás netýká do té doby, dokud £ást kódu nevede k uspání procesu. To platí pouze v p°ípad¥, pokud by nebyl Linux preemptivní. Pokud tedy nedojde k p°eru²ení, opravdu neodebírá jádro procesor procesu, který b¥ºí v kernel módu. Ov²em s p°íchodem SMP je tento p°ístup naprosto nedosta£ující.

18

KAPITOLA 3.

ANALÝZA EENÍ

3.2.2 Ovlada£e v user space Je jasné, ºe n¥kterým zejména za£ínajícím programátor·m m·ºe p°ipadat psaní ovlada£e jako modulu jádra OS (viz. kapitola 3.2.3) sloºité a nepohodlné a dávají rad²i p°ednost ovlada£·m v user space. I tato moºnost je sch·dná a jak uº to bývá, oba p°ístupy mají své výhody i nevýhody. Základní rozdíly obou p°ístup·:

•

m·ºeme pouºívat p°ilinkovanou C knihovnu, kdeºto v kernel space ne

•

lep²í moºnosti debuggování

•

snadn¥j²í odstra¬ování chyb pokud dojde k zablokování procesu, pouºijeme p°íkaz kill pouze na tento proces, kdeºto v kernelu dojde k pádu celého systému

•

pam¥´ v user space je swapovatelná, kdeºto pam¥´ jádra je v pam¥ti po°ád

•

dob°e napsaný ovlada£ m·ºe i v user space ctít sou£asný p°ístup více proces· k za°ízení

•

v user space nejsou dostupná p°eru²ení, musí se pouºít systémové volání vm86, coº zap°í£i¬uje ur£itou výkonnostní degradaci

•

p°ímý p°ístup do pam¥ti je moºný pouze p°es /dev/mem a to pouze privilegovaným uºivatel·m

•

celková doba odezvy je v user space v¥t²í

•

pokud je ovlada£ odswapován na disk, doba odezvy roste dramaticky, je moºno vyuºít mlock na zamknutí n¥kterých stránek pam¥ti, ale je také pouze pro privilegované uºivatele

Volba, kam umístit ovlada£, záleºí p°ípad od p°ípadu. U n¥kterého hardwaru je vhodné zvolit user space a nezat¥ºovat se zbyte£nými sloºitostmi ohledn¥ jádra OS. Jindy je p°ímo nutností pono°it se do hloubky jádra OS a jím nabízených funkcionalit.

3.2.3 Moduly jádra V unixových opera£ních systémech se ovlada£e obvykle pí²í jako tzv. moduly jádra. Jde o kusy kódu, které se mohou na poºádání nahrát k jádru OS. Moduly jsou sou£ástí kernel space a roz²i°ují schopnosti a funkcionalitu jádra OS, aniº by muselo docházet k restartu systému. Jsou bu¤ dynamicky linkovány k jádru za b¥hu, aº kdyº jsou pot°ebné, nebo se staticky slinkují p°i p°ekladu jádra. Pokud bychom moduly nem¥li, museli bychom vytvá°et jednotná, tím pádem i obrovská jádra a také p°idání nové funkcionality by se neobe²lo bez znovu vytvo°ení jádra a restartu systému. Tím, ºe jsou linkovány k jádru OS, jsou jeho sou£ástí a vykonávají se v kernel módu. Kaºdý modul ovlada£e musí implementovat rozhraní, umoº¬ující jádru OS odebírat nebo naopak p°ilinkovat tento modul k jádru. To má své nesmírné výhody. Kód se nemusí kompilovat spolu s jádrem OS a být jeho sou£ástí, ale m·ºe se v p°ípad¥ pot°eby pozd¥ji doinstalovat. Jedná se prakticky o dv¥ funkce int init_module(void) a void cleanup_module(void). Jak jejich názvy napovídají, init_module se zavolá p°i instalování modulu do jádra (nap°. p°íkazem insmod) a naopak cleanup_module se zavolá t¥sn¥ p°edtím, neº je modul z jádra odstran¥n (nap°. p°íkazem rmmod). Je²t¥ dodám, ºe od jádra verze 2.3.13 se pro tyto startovací a ukon£ovací funkce m·ºe zvolit libovolný název, nemusí se striktn¥ jmenovat init_module a cleanup_module. Jen musíme dát kernelu v¥d¥t, jak se tyto funkce skute£n¥ jmenují. Toho docílíme pomocí maker module_init(init_function) a module_exit(cleanup_function) denovaných v hlavi£kovém

KAPITOLA 3.

ANALÝZA EENÍ

19

souboru linux/init.h. Kaºdý modul navíc musí importovat hlavi£kový soubor linux/module.h. Takový ukázkový modul by pak mohl vypadat takto:

#include // Needed by all modules #include // Needed for KERN_ALERT #include // Needed for the macros static int hw_module_init(void) { printk(KERN_ALERT "Hello, World!\n"); return 0; } static void hw_module_exit(void) { printk(KERN_ALERT "Goodbye, World!\n"); } module_init(hw_module_init); module_exit(hw_module_exit); Co se tý£e kompilace kernel modul·, i ta má svá specika.

•

Kompilovat s agem c, protoºe modul není spustitelný kód, ale objektový soubor

•

Zapnutá optimalizace z d·vodu pouºívání inline funkcí, bez optimalizace se m·ºe stát, ºe n¥které volání maker bude interpretováno jako volání funkcí, které ov²em nebudou linkerem nalezeny

•

Kompilovat s header soubory jádra, se kterým se bude modul pouºívat

•

Denovat symbol __KERNEL__ °íkající, ºe se kód bude vykonávat v kernel módu a nejedná se o uºivatelský proces

•

Denovat symbol MODULE

•

Navíc se vyplatí nastavit zobrazování varování na v²echny W -Wall

Pokud kompilujeme pro kernel 2.4 a nov¥j²í a chceme zabránit varovným hlá²kám typu:

Warning: loading xxx.o will taint the kernel: no license See http://www.tux.org/lkml/#export-tainted for information about tainted modules musíme specikovat licenci, pod kterou bude modul distribuován. Krom¥ toho m·ºeme s vyuºitím p°ipravených maker specikovat autora, popis, ú£el a t°eba podporovaná za°ízení nebo t°ídy za°ízení. Tato makra jsou denována v linux/module.h :

MODULE_LICENSE("GPL"); MODULE_AUTHOR("Michal Navrkal"); MODULE_DESCRIPTION("DAQ HW MODULE DRIVER"); MODULE_SUPPORTED_DEVICE("DAQ MODULE");

20

KAPITOLA 3.

zkratka

ANALÝZA EENÍ

typ

b

byte

h

short int

i

integer

l

long int

s

string

Tabulka 3.1: Podporované typy pro parametrizaci modul·

Modul, stejn¥ jako uºivatelský program pro p°íkazovou °ádku, m·ºe p°ebírat argumenty, které nejsou známy p°i p°ekladu. Jen p°edávání je jiné neº p°es argc/argv, protoºe samoz°ejm¥ modul nemá ºádnou funkci main. On se nevykonává postupn¥ od za£átku funkce main, on jen reaguje na systémová volání pro která má implementovanou podporu (open, read, write, close. . . ). Aby mohl modul p°ebrat n¥jakou hodnotu jako parametr, denujeme pro kaºdý takto p°edávaný parametr globální prom¥nnou v rámci modulu a pouºijeme makro MODULE_PARAM. Toto makro p°ebírá dva parametry, prom¥nnou a její typ. Podporované typy vidíme v tabulce 3.1. Ukázka pouºití:

int myint = 3; char *mystr; MODULE_PARM (myint, "i"); MODULE_PARM (mystr, "s"); P°edání parametru probíhá p°i nahrávání modulu:

insmod xxx.o myint=5 Pokud není parametr nastaven p°i instalaci, pouºije se jeho hodnota nastavená p°i kompilaci modulu. Je moºné p°edávat i pole hodnot:

int myshortArray[4]; MODULE_PARM (myintArray, "2-4i"); Kde 2 znamená minimální a 4 maximální po£et p°edávaných prvk· pole. Informace o tom, jaké operace jsou nad daným souborem za°ízení povoleny, se uchovává ve struktu°e le_operations denované v linux/fs.h. Tato struktura vypadá takto:

struct file_operations { struct module *owner; loff_t (*llseek) (struct file *, loff_t, int); ssize_t (*read) (struct file *, char *, size_t, loff_t *); ssize_t (*write) (struct file *, const char *, size_t, loff_t *); int (*readdir) (struct file *, void *, filldir_t); unsigned int (*poll) (struct file *, struct poll_table_struct *); int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long); int (*mmap) (struct file *, struct vm_area_struct *); int (*open) (struct inode *, struct file *); int (*flush) (struct file *);

KAPITOLA 3.

};

ANALÝZA EENÍ

21

int (*release) (struct inode *, struct file *); int (*fsync) (struct file *, struct dentry *, int datasync); int (*fasync) (int, struct file *, int); int (*lock) (struct file *, int, struct file_lock *); ssize_t (*readv) (struct file *, const struct iovec *, unsigned long, loff_t *); ssize_t (*writev) (struct file *, const struct iovec *, unsigned long, loff_t *);

S výjimkou poloºky owner, coº je ukazatel na vlastní modul a nastavuje se makrem THIS_MODULE, jde o ukazatele na funkce, které implementují danou funkcionalitu pro dané za°ízení a jeho ovlada£. Nemusí se samoz°ejm¥ implementovat v²echny funkce, nepodporované se jednodu²e nastaví na NULL. Zajímavý je zp·sob, jakým se p°edávají tyto ukazatele na funkce. Jedná se o roz²í°ení gcc z d·vodu v¥t²í názornosti a p°ehlednosti.

struct file_operations fops = { read: device_read_function, write: device_write_function, open: device_open_function, release: device_release_function };

3.2.4 Správa pam¥ti Procesor PowerPC je, na rozdíl od jeho softcore náhrady procesoru Microblaze, vybaven jednotkou MMU. V²echny adresy, které si bu¤ nastavíme ru£n¥ nebo se nám automaticky vygenerují v návrhovém software EDK, jsou adresy fyzické. Z t¥chto adres m·ºeme rovnou £íst, pokud je PowerPC v módu, kdy nepouºívá p°eklad adres, nap°. p°i p°ipojení k procesoru p°es XMD. To ov²em není ná² p°ípad s pouºitím OS Linux. Ten má implementovanou podporu pro p°eklad fyzických adres na virtuální a naopak a pln¥ ji vyuºívá. Pokud tedy chceme v na²ich ovlada£ích p°istupovat k n¥jakému adresovému místu a t°eba jenom dereferencovat pointer s touto adresou, m·ºe se stát, i nemusí, ºe p°istupujeme k adrese ve virtuálním adresovém prostoru (protoºe n¥která virtuální adresová místa se mapují jedna k jedné s fyzickými). Proto je pot°eba si vºdy daný adresový rozsah pouºívaný v ovlada£i p°emapovat za pouºití systémové funkce void* iore-

map(unsigned long phys_adr, unsigned long size). Tím dáme jasn¥ najevo, ºe chceme pracovat s virtuálním adresovým prostorem, který odpovídá fyzickým adresám, které máme denované od EDK. Nad t¥mito adresami jiº m·ºeme pracovat, jak jsme zvyklí z uºivatelských aplikací. Po ukon£ení pouºívání tohoto adresového prostoru, tedy p°i odstran¥ní modulu s ovlada£em, je nutno toto mapování zru²it - iounmap(void* addr).

3.2.5 P°id¥lování pam¥ti Kaºdý program pro svojí práci pot°ebuje n¥jakou pam¥´ nad kterou m·ºe provád¥t svoje operace. Nejinak je tomu u ovlada£·. Jak jsem °ekl, ovlada£ je sou£ástí jádra (pominu-li moºnost user space ovlada£·) a proto pro n¥j platí ur£ité odli²nosti co do získávání pam¥ti od jádra OS a navrácení pam¥ti p°i odstran¥ní ovlada£e z pam¥ti (p°i odstran¥ní modulu z jádra). Nejjednodu²²í zp·sob, jak získat k dispozici pam¥´, je pouºít podobné funkce, které známe z C knihovny a to kmalloc a kfree. Tato moºnost v²ak není jediná, kernel nabízí v¥t²í mnoºinu funkcí nabízejících pohodlnou alokaci pam¥ti pot°ebné velikosti a vlastností.

Kmalloc

22

KAPITOLA 3.

ANALÝZA EENÍ

Je nejjednodu²²í cestou jak získat od jádra alokovanou pam¥´. Pracuje podobn¥ jako malloc. Je rychlá a vrací souvislou oblast ve fyzické pam¥ti. Alokovanou pam¥´ nenuluje, ponechává ji p°ede²lý obsah. P°ebírá dva argumenty. První z nich je poºadovaná velikost pam¥óvé oblasti. Jádro obsluhuje fyzickou systémovou pam¥´, která je dostupná pouze v ur£itých svazcích. Linux ovládá alokaci pam¥ti pomocí mnoºiny tzv. pool·, ve kterých leºí objekty volné pam¥ti ur£ité velikosti. P°i poºadavku na volnou pam¥´ se koukne do poolu objekt· vhodné velikosti a tento objekt vrátí. Pokud ºádný nenajde, vrátí chybu. Nutno poznamenat, ºe tyto velikosti jsou dány mocninou 2. Ov²em nedoporu£uje se, zejména pokud jde o star²í verze jader (star²í neº 2.4), alokovat p°esn¥ mocniny dvou. Jádro u t¥chto svazk· pouºívá kontrolní agy, které sniºují jejich velikost, proto v p°ípad¥ dotazu nap°íklad na 1024 B musí kernel pouºít svazek v¥t²í (v p°ípad¥ 2.0 kernelu je to aº 2048 B-tový svazek) a zna£n¥ tak sniºujeme efektivnost celého procesu p°id¥lování pam¥ti.

Kmalloc je schopný alokovat oblasti do velikosti 128 KB, o n¥co mén¥ u star²ích jader. Pokud pot°ebujeme více pam¥ti, musíme pouºít jinou techniku. Druhým parametrem je parametr udávající poºadavky na vlastnosti pam¥ti. Nej£ast¥ji se pouºívá ag GFP_KERNEL, znamenající alokaci pam¥ti v rámci kontextu procesu b¥ºícího v kernel space. Tento parametr s sebou p°iná²í moºnost, ºe volající proces bude uspán v p°ípad¥, ºe systém má nedostatek volné pam¥ti. V takovém p°ípad¥ se systém pokusí provést akce, které vedou k uvoln¥ní dostate£ného mnoºství pam¥ti. To znamená, ºe volaná funkce musí být reentrantní. Pokud chceme vylou£it moºnost takového uspání, pouºijeme ag GFP_ATOMIC. Je nutností pouºít tento ag v p°ípad¥ pouºití v obsluze p°eru²ení, front proces· a timer·. Dal²í agy se mohou pouºít navíc k t¥mto dv¥ma, mají p°ed sebou dv¥ podtrºítka. __GFP_DMA zna£í, ºe poºadujeme pam¥´ z adresového prostoru vhodného pro DMA p°enos. __GFP_HIGHMEM znamená, ºe akceptujeme pam¥´ i z tzv. oblasti high memory. Kernel rozd¥luje pam¥´ na t°i základní oblasti. Normální, vhodnou pro DMA a high memory oblast. Oblast vhodná pro DMA je jen ta, která je dostupná pro za°ízení podporující DMA p°enos. Toto omezení je dáno velikostmi adresových sb¥rnic pouºívaných k p°ipojení za°ízení k procesoru a sb¥rnice propojující opera£ní pam¥´ a procesor. High memory je oblast, která pot°ebuje zvlá²tní zacházení p°i p°ístupu k ní. Jedná se o oblasti v horní £ásti adresního prostoru procesoru. Tuto podporu mají jen n¥které procesory, x86 od procesoru Pentium II a SPARC. V p°ípad¥ pouºití agu spolu s procesorem bez podpory high memory, je ag nastaven na 0 a jeho p°ípadný logický sou£et s ostatními agy nemá ºádný význam. Podrobnosti o agách a procesu alokace je moºné najít v ,

<mm/page_alloc.c> a <mm/init.c>. P°i alokaci pam¥ti je moºné vyuºít vlastní cache s objekty vlastní velikosti. Zejména pokud £asto alokujeme objekty o dané velikosti. U²et°í se tak n¥jaký £as na vyhledání poolu vhodné velikosti. Takovéto cache jsou typu kmem_cache_t a vytvá°í se voláním kmem_cache_create() a parametry kterými jsou název tohoto nového poolu a velikost objekt·. K alokaci t¥chto objekt· potom slouºí funkce kmem_cache_alloc(). Pro vrácení objektu do cache kmem_cache_free() a pro zru²ení cache nap°. p°i odstra¬ování modulu kmem_cache_destroy(). Zru²it se nám povede pouze cache, do které jsou vráceny v²echny naalokované objekty, jinak odstran¥ní selºe a ukazuje to na p°ítomnost n¥jakého memory leaku. Pouºití této cache s sebou p°iná²í i moºnost statistického p°ehledu o vyuºívání pam¥ti, za p°edpokladu, ºe je zapnutá v konguraci jádra. Ov²em toto sledování zpomaluje b¥h celého systému.

Get_free_page a podobné Kdyº pot°ebuje modul v¥t²í mnoºství pam¥ti neº 4KB, je obvykle lep²í vyuºít techniky orientované na stránky. Funkce unsigned long get_zeroed_page(int ags) vrací pointer na novou stránku a vyplní ji nulami. Podobn¥ funguje get_free_page(int ags) s tím rozdílem, ºe obsah stránky je ponechán. Pokud chceme n¥kolik stránek následujících ve fyzické pam¥ti za sebou a

KAPITOLA 3.

ANALÝZA EENÍ

23

ne jen jedinou, pouºijeme funkci get_free_pages(int ags, unsigned long order), kde order je °ád mocniny dvou pro po£et stránek. To znamená, ºe pokud chceme 4 stránky, order je 2, pokud 8, order je 3 atd. Po pouºití stránky ji uvolníme voláním free_page(unsigned long addr) nebo free_pages(unsigned

long addr, unsigned long order). Argument ag má stejný význam jako u kmalloc. Tyto funkce se mohou volat kdykoliv a musí se samoz°ejm¥ kontrolovat jejich selhání z d·vodu nedostatku takového mnoºství volné pam¥ti.

Boot time alokace Pokud pot°ebujeme skute£n¥ velké mnoºství pam¥ti, m·ºe se £asto stát, ºe alokace selºe, protoºe neexistuje tak velký souvislý kus volné pam¥ti. e²ením by mohla být alokace v dob¥ startování systému. Tato technika není p°íli² elegantní a pouºívá se skute£n¥ v p°ípadech, kde ostatní moºnosti selhávají. Nutno hned °íci, ºe modul nem·ºe alokovat pam¥´ p°i bootování, to m·ºe pouze ovlada£ p°ímo p°ilinkovaný k jádru. Tato technika není p°íli² £istá, protoºe obchází jakoukoliv systémovou správu pam¥ti. D°íve to v²ak t°eba byla jediná moºnost, jak zajistit alokaci pam¥ti vhodné pro DMA. Podrobnosti lze nalézt v linux/bootmem.h a linux/bootmem.c.

3.2.6 Linux boot proces Bootováním se ozna£uje proces od zapnutí za°ízení nebo od jeho resetu po okamºik spou²t¥ní první uºivatelské aplikace. Dá se rozd¥lit do n¥kolika £ástí. Ihned po startu vykonává procesor instrukce, nacházející se pro n¥j na dob°e známém adresovém míst¥. V p°ípad¥ klasických PC je tímto kódem malá utilita, která dokáºe nainicializovat chipset základní desky a dostat °adi£ opera£ní pam¥ti do stavu, kdy m·ºe být BIOS, uloºený v¥t²inou ve ash pam¥ti na základní desce, dekomprimován a nahrán do pam¥ti do oblasti nazývané shadow RAM. Tato £ást pam¥ti od tohoto okamºiku pat°í chipsetu základní desky a OS si ji nem·ºe p°ivlastnit. Tato utilita startuje na adrese 0xFFFF0. Prvním krokem BIOSu v¥t²inou bývá spu²t¥ní POSTu ov¥°ujícího funk£nost hardwaru. Po jeho skon£ení je z pam¥ti odstran¥n, ale n¥které uºite£né funkce a systémová volání BIOSu z·stávají nadále. V p°ípad¥ embedded systém· hovo°íme spí²e o tzv.

boot monitorech (U-boot, RedBoot, Lucent), které se nacházejí na ash pam¥ti v systému a mají v popisu práce nahrát jádro systému do pam¥ti, p°edat mu pot°ebné informace, jako nap°. jaký oddíl kterého disku pouºít jako RFS, a spustit ho. Tyto monitory jsou uloºeny na adrese tzv.

resetovacího vektoru, lépe °e£eno na této adrese se nachází instrukce nepodmín¥ného skoku na adresu s monitorem. Resetovací vektor je umíst¥n uº od návrhá°· procesoru na známé adrese. V p°ípad¥ PowerPC je touto adresou 0xFFFFFFFFC. Flash pam¥´, na které je v¥t²inou kernel umíst¥n, je pomalej²í a p°ipojená p°es uº²í sb¥rnice neº ostatní pam¥ti systému. Záznam na ash obvykle obsahuje 2 aº 4 £ásti bootloader (povinný), nevolatilní uloºení kongura£ních parametr· bootování, linux kernel (povinný) a init ramdisk. Úloha BIOSu je samoz°ejm¥ mnohem sloºit¥j²í, protoºe PC je mnohem exibiln¥j²í a variabiln¥j²í neº kterékoliv jiné vestavné za°ízení. Úkolem BIOSu je získat p°ehled o dostupných za°ízeních a ur£it moºná za°ízení, z kterých se dá bootovat (CD-ROM, oppy, HDD, sí´. . . ). Z tohoto za°ízení je nahrán tzv. primární bootloader, jehoº velikost je men²í neº 512B, do pam¥ti po£íta£e. Nachází se v MBR, coº není nic jiného neº první sektor disku. Primární bootloader v t¥ch 512B obsahuje jednak výkonný kód, ale i malou partition tabulku se £ty°mi záznamy, pro kaºdou partition jeden. Jeho úkolem je najít a nahrát second stage bootloader do pam¥ti a spustit jej. Hledání probíhá práv¥ procházením jiº zmín¥né £ty°-záznamové tabulky a hledáním aktivního záznamu. Sekundární bootloader bývá n¥kdy nazýván zavad¥£em jádra, protoºe práv¥ jeho úkolem je nahrát jádro systému do pam¥ti. A£koliv by ²lo napsat bootloader, který by se

24

KAPITOLA 3.

ANALÝZA EENÍ

celý ve²el do t¥chto 512B a nemusel se takto d¥lit na n¥kolik etap, není k tomu p°íli² d·vod·. Primární a sekundární bootloader v sob¥ zahrnují t°eba LILO nebo GRUB. Výhodou GRUBu je, ºe na rozdíl od zavad¥£e LILO, m·ºe nahrávat kernel ze souborových systém· jako jsou ex2, ex3, protoºe tyto souborové systémy d·v¥rn¥ zná. LILO nahlíºí na zdroj jako na raw data. Kdyº je kernel v pam¥ti, za£íná fáze spou²t¥ní zpracování kernelu. I kdyº je primárním úkolem bootloaderu nahrát obraz kernelu do RAM, m·ºe také voliteln¥ do RAM nahrát init ramdisk. Ten obsahuje minimální mnoºství modul· kernelu, pot°ebných k dostání kernelu do stavu, kdy je pln¥ schopen namountovat ko°enový systém soubor· z RFS disku. Zejména v d°ív¥j²ích dobách byl tento postup nutný z d·vod· pouºití SCSI disk· jako RFS. Pokud je pouºit init ramdisk, dochází k jeho do£asnému namountování jako RFS. U n¥kterých embedded systém· m·ºe být tento RFS jediným, který se pouºije. Tento postup je oblíbený hned z n¥kolika d·vod·:

•

RFS je vºdy zapisovatelný, dá to mnohem men²í námahu pouºít ramdisk, neº si tuto vlastnost sloºit¥ vynucovat na n¥jakém do£asném míst¥

•

není zde problém s moºným omezením ºivotnosti £astými zápisovými a mazacími cykly, jak je tomu u ash pam¥tí

•

celkem snadno se zajistí integrita RFS po kaºdém restartu (kontrolou uloºeného CRC po prvním bootu)

Obraz jádra OS uº od jisté doby není p°ímo spustitelný kód, nýbrº komprimovaný obraz, vyºadující dekomprimaci p°ed jakýmkoliv pokusem o spu²t¥ní. Na za£átku obrazu se nachází rutina, která kernel rozbalí a p°esune do vy²²ích oddíl· pam¥ti i s p°ípadným init ramdiskem a jádro spustí. P°i spou²t¥ní jádra dochází k nastavování d·leºitých £ástí systému týkající se zejména správy pam¥ti, proces· a p°eru²ení. Po ukon£ení kernel fáze se spou²tí první aplikace z uºivatelského prostoru, kterou nej£ast¥ji bývá /sbin/init. Init dokon£í celou fázi procesu bootování a nakonguruje prost°edí pro uºivatele. Rozdíly mezi boot procesem klasického PC a embedded systému jsou patrné z obrázk· 3.2 a 3.3.

Obrázek 3.2: Boot proces klasického PC, [7]

KAPITOLA 3.

ANALÝZA EENÍ

Obrázek 3.3: Boot proces embedded systému, [7]

25

26

KAPITOLA 3.

ANALÝZA EENÍ

KAPITOLA 4.

VLASTNÍ IMPLEMENTACE

27

4 Vlastní implementace V této kapitole se kone£n¥ podíváme, jak jsem postupoval p°i vytvá°ení obrazu linuxového jádra fungujícího pro ná² design. Taktéº se podíváme, jak jsem se vypo°ádal s ovlada£i pro ná² modul a s tím, jak data z modulu vy£íst a zobrazit na dedikovaném PC.

4.1

Port Linuxu pro XUP V2P

Podíváme se, jak zkompilovat jádro opera£ního systému pro platformu PPC 405, jak vytvo°it RFS a jaké máme moºnosti pro jeho uloºení [8].

4.1.1 K°íºový kompilátor Jak jsem uvedl, ná² embedded systém je postaven na procesoru PowerPC 405, který, jak je z°ejmé, má jinou architekturu a mnoºinu instrukcí neº procesor z rodiny x86, jaký máme v¥t²inou ve svých po£íta£ích. Z toho d·vodu nem·ºeme pouºít kompilátor, který máme k dispozici na svých linuxových opera£ních systémech. Na °adu musí p°ijít tzv. k°íºová kompilace (angl.

crosscompilation ). Je to proces, p°i kterém dochází k p°ekladu zdrojových kód· do instrukcí jiné architektury, neº na jaké p°eklad provádíme. Ke k°íºovému p°ekladu se uchylujeme, pokud nejsme na cílové platform¥ schopní p°eklad provést v·bec (nedostatek systémových prost°edk·) nebo je p°eklad zna£n¥ £asov¥ náro£ný a tím pádem neefektivní. Já jsem musel vyuºít k°íºovou kompilaci, protoºe nemám p°ístup k ºádnému fungujícímu stroji s procesorem PowerPC, který by byl schopný emitovat nativní instrukce své architektury. Je, pokud ne p°ímo nutné, tak alespo¬ velice vhodné, vytvo°it celý tzv. toolchain, coº je balík program· vytvo°ených v rámci projektu GNU [9], vyuºívaných p°i vývoji aplikací a opera£ních systém·. Zahrnuje v sob¥ zejména:

•

GCC GNU C Compiler sada p°eklada£· nejenom pro jazyk C

•

GNU Binutils sada nástroj· pro zacházení s binárními jednotkami kód· (linker a jiné nástroje)

•

GNU Make nástroj pro zjednodu²ení a automatizaci p°ekladu zdrojových kód·

•

GDB GNU Debugger ladící nástroj pro vývojá°e

•

GNU Build Tools autoconf, automake, libtool, autoheader. . .

Kroskompila£ních toolchain· je dostupných mnoho, r·zn¥ obsáhlých a pro mnoho zdrojových a cílových architektur. Vybral jsem Crosstool [4], který m¥l na fórech zabývajících se p°ekladem pro jiné architektury neº x86 jen ty nejlep²í reference. Jak to m·ºe vypadat p°i takové kroskompilaci je vidno na obrázku 4.1. Stáhneme si zdrojové kódy aktuální verze Crosstoolu do vývojového adresá°e. Dále si vytvo°íme adresá°, kam si bude Crosstool stahovat pot°ebné zdrojové kódy a knihovny, a adresá°, kam uloºíme výsledný zkompilovaný toolchain a zm¥níme mu vlastníka na uºivatele, pod kterým budeme kompilovat.

$ mkdir xup $ cd xup $ wget http://kegel.com/crosstool/crosstool-0.42.tar.gz

28

KAPITOLA 4.


Obrázek 4.1: Vývoj softwaru pro Target na Host platform¥

$ $ $ $ $

tar -xvzf crosstool-0.42.tar.gz cd crosstool-0.42 mkdir downloads sudo mkdir /opt/crosstool sudo chown <user_name>:users /opt/crosstool/

Otev°eme si soubor crosstool-0.42/demo-ppc405.sh a provedeme v n¥m pot°ebné zm¥ny. Crosstool je ve své podstat¥ sada skript·, která si zdrojové kódy pot°ebných nástroj· stahuje z ve°ejn¥ dostupného FTP serveru ftp.gnu.org, takºe je p°i kompilaci nutné mít p°ipojení k internetu. Kódy jsou stahovány do adresá°e nastaveného v prom¥nné TARBALLS_DIR, takºe je jen na nás, jak tento adresá° nastavíme. Stejn¥ tak je na nás, jakým zp·sobem nastavíme prex (prom¥nná PREFIX) pro výsledné nástroje a umíst¥ní zkompilovaného toolchainu (prom¥nná RESULT_TOP).

TARBALLS_DIR=$HOME/xup/crosstool-0.42/downloads RESULT_TOP=/opt/crosstool Odkomentujeme °ádek, který vybírá verzi GNU C p°eklada£e a C knihovny. Já jsem pouºil:

eval `cat powerpc-405.dat gcc-3.4.4-glibc-2.3.3.dat` sh all.sh -notest Nejnov¥j²í verze p°eklada£e nedokáºí p°eloºit kódy 2.4. jádra bez úprav. V této verzi jádra se pouºívají programátorské konstrukce, které byly pozd¥ji ozna£eny za deprecated a nové verze kompilátor· (gcc od verze 4.0) je nep°eloºí. Proto jsem zvolil verzi gcc 3.4.4, navíc je to verze, kterou pouºívá EDK ve verzi 8.2. P°ed spu²t¥ním skriptu je²t¥ nastavíme prom¥nné prost°edí TARGET, PREFIX a doplníme PATH o ná² adresá° s výsledným toolchainem.

KAPITOLA 4.


29

export TARGET=powerpc-405-linux-gnu export PREFIX=/opt/crosstool/$TARGET export PATH=$PREFIX/bin:$PATH P°i vlastní kompilaci Crosstoolu se objevuje chyba podobného zn¥ní:

In file included from version.c:33: /home/misan/XUP/crosstool-0.43/build/powerpc-405-linux-gnu/gcc-3.4.4-glibc-2.3.3/ build-glibc/Csu/version-info.h:2:1: missing terminating " character /home/misan/XUP/crosstool-0.43/build/ powerpc-405-linux-gnu/gcc-3.4.4-glibc-2.3.3/build-glibc/csu/ version-info.h:3:1: missing terminating " character make [2]: *** [/home/misan/XUP/crosstool-0.43/build/powerpc-405-linux-gnu/ gcc-3.4.4-glibc-2.3.3/build-glibc/csu/version.o] Error 1 make [2]: Leaving directory `/home/misan/XUP/crosstool-0.43/build/ powerpc-405-linux-gnu/gcc-3.4.4-glibc-2.3.3/glibc-2.3.3/csu' make [1]: *** [csu/subdir_lib] Error 2 make [1]: Leaving directory `/home/misan/XUP/crosstool-0.43/build/ powerpc-405-linux-gnu/gcc-3.4.4-glibc-2.3.3/glibc-2.3.3' make: *** [lib] Error 2 Jde o chybu zp·sobenou ²patn¥ ozna£eným komentá°em v souboru /xup/crosstool-

0.42 /build/powerpc-405-linux-gnu/gcc-3.4.4-glibc-2.3.3/build-glibc/csu/version-info.h, kde jsou komentá°e uvozeny uvozovkou, s £ímº si C kompilátor pochopiteln¥ nedokáºe poradit. e²ení je jednoduché a spo£ívá v zakomentování include tohoto souboru v souboru /xup/cross-

tool-0.42/build/powerpc-405-linux-gnu/gcc-3.4.4-glibc-2.3.3/glibc-2.3.3/csu/version.c. Ov²em musíme zakomentování provézt bu¤ p°ímo v archivu /xup/crosstool-0.42/downloads/

glibc-2.3.3.tar.gz, nebo´ skript all.sh si p°ed kompilací tyto archivy rozbalí a zm¥nu provedenou v /xup/crosstool-0.42/build/ powerpc-405-linux-gnu/gcc-3.4.4-glibc-2.3.3/glibc-2.3.3/ csu/version.c by nám p°epsal zp¥t. Nebo m·ºeme provést zakomentování include aº po rozbalení archivu. Je²t¥ podotknu, ºe pro bezproblémovou kompilaci je nutné mít k dispozici na vývojovém stroji programy, které jsou na n¥kterých distribucích v základních instala£ních balí£cích, jinde se musí doplnit. Já jsem kompiloval na distribuci Ubuntu, tak popí²i, co je nutné doplnit do základní instalace. Jedná se zejména o balí£ek build-essential, který nám umoºní v·bec kompilovat spustitelné programy p°ímo ze zdrojových kód·. P°i jeho absenci se vyskytne chyba a kompilace se p°eru²í:

checking for gcc... gcc checking whether the C compiler (gcc ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. Nainstalovat balí£ek

build-essential : sudo

apt-get install build-essential

Dále program patch pro moºnou aplikaci patch·:

applying patch /home/misan/XUP/crosstool-0.43/patches/glibc-2.3.3/ arm-ctl_bus_isa.patch getandpatch.sh: 1: patch: not found patch /home/misan/XUP/crosstool-0.43/patches/glibc-2.3.3/arm-ctl_bus_isa.patch failed

30

KAPITOLA 4.

Nainstalovat balí£ek

patch: sudo


apt-get install patch

Program pro generování parser· umoº¬ujících p°evod bezkontextových gramatik do LR(1) bison:

GLIBC_ADDON_OPTIONS not set, so guessing addons from GLIBCTHREADS_FILENAME and GLIBCCRYPT_FILENAME /home/misan/XUP/crosstool-0.43/crosstool.sh: 110: bison: not found crosstool: You don't have bison installed Nainstalvat balí£ek

bison: sudo

apt-get install bison

GNU lexikální analyzátor ex (The Fast Lexical Analyzer):

GLIBC_ADDON_OPTIONS not set, so guessing addons from GLIBCTHREADS_FILENAME and GLIBCCRYPT_FILENAME /home/misan/XUP/crosstool-0.43/crosstool.sh: 111: flex: not found crosstool: You don't have flex installed Nainstalovat balí£ek

ex: sudo

apt-get install ex

Po cca. 1,5 hodinové kompilaci bychom m¥li vid¥t hlá²ku podobnou této, kde nás skript informuje, kde se nachází výsledný toolchain a ºe se mu poda°ilo tímto toolchainem zkompilovat program typu Hello, world! :

Cross-toolchain build complete. Result in /opt/crosstool/powerpc-405-linux-gnu. + exit 0 + cd /home/misan/XUP/crosstool-0.43 + sh testhello.sh + cd /opt/crosstool/powerpc-405-linux-gnu + test ! -d tmp + mkdir tmp + cd tmp + test x != x + cat + /opt/crosstool/powerpc-405-linux-gnu/bin/powerpc-405-linux-gnu-gcc -static hello.c -o powerpc-405-linux-gnu-hello-static + /opt/crosstool/powerpc-405-linux-gnu/bin/powerpc-405-linux-gnu-gcc hello.c -o powerpc-405-linux-gnu-hello + test -x /opt/crosstool/powerpc-405-linux-gnu/bin/powerpc-405-linux-gnu-g++ + cat + /opt/crosstool/powerpc-405-linux-gnu/bin/powerpc-405-linux-gnu-g++ -static hello2.cc -o powerpc-405-linux-gnu-hello2-static + /opt/crosstool/powerpc-405-linux-gnu/bin/powerpc-405-linux-gnu-g++ hello2.cc -o powerpc-405-linux-gnu-hello2 + echo testhello: C compiler can in fact build a trivial program. testhello: C compiler can in fact build a trivial program. + test = 1 + test = 1 + test = 1 + test 1 = + echo Done. Done.

KAPITOLA 4.


31

4.1.2 Kompilace jádra OS linux Kdyº uº máme jádro £ím p°eloºit, musíme si nejprve stáhnout jeho zdrojové kódy z n¥jakého voln¥ dostupného repositá°e na internetu. Já jsem pouºil mirror ppc.bkbits.net/linuxppc_2_4_devel, který pouºívá repositá° BitKeeper. Ke staºení je pot°eba klient daného repositá°ového systému, který je k dispozici na adrese http://www.bitmover.com/bk-client2.0.shar. Pro práci se shell archivem pot°ebujeme balí£ek sharutils. Archiv rozbalíme, p°eloºíme BitKeeper klienta a stáhneme kódy jádra:

$ $ $ $

sh bk-client2.0.shar cd bk-client2.0 make ./bkf clone bk://ppc.bkbits.net/linuxppc_2_4_devel ../linuxppc_2_4_devel

Staºené kódy na n¥kolika místech drobn¥ upravíme s ohledem na ná² design z EDK: 1. v souboru arch/ppc/boot/simple/Makele nahradíme p°esunutí výsledného image jadra jeho p°ekopírováním: zImage-EMBEDDED: zvmlinux mv zvmlinux ../images/zImage.$(END) nahradíme: zImage-EMBEDDED: zvmlinux cp zvmlinux ../images/zImage.$(END) 2. zakomentujeme °ádek s #error I2C... v souboru arch/ppc/boot/simple/embed_cong.c Ten je d·leºitý pro desku ml310, pro kterou jsou prvoplánovit¥ tyto kódy ur£ené, která pomocí I2C £te MAC adresu ethernetového rozhraní, u desky XUP není I2C pot°eba. 3. v závislosti na zvolené baudrate sériové komunikace pro UART16550 v designu EDK zm¥níme tuto rychlost i v ovlada£i umoº¬ující výpis bootovacích a debugovacích hlá²ek na konsoli: v arch/ppc/boot/common/ns16550.c (v mém p°ípad¥ na 115200) v arch/ppc/kernel/gen550_dbg.c (v mém p°ípad¥ na 115200) P°ed vlastní kompilací jádra je nutné správn¥ pozm¥nit hlavní make le nastavit cílovou architekturu (aby se správn¥ vygenerovalo menu pro konguraci jádra) a k°íºový kompilátor:

ARCH := ppc CROSS_COMPILE = powerpc-405-linux-gnuNyní, kdyº máme nastavenou správnou architekturu, zbavíme se do£asných soubor· a jiného `smetí' p°íkazem make clean a jádro si nakongurujeme. Moºností, jak p°istoupit ke konguraci jádra, je více (textové x gracké rozhraní):

•

make cong odpovídáme na kladené otázky (ano/ne, zadání velikosti, výb¥r z moºností...), nelze se vracet zp¥t

•

make menucong textový nástroj, moºno libovoln¥ procházet kongura£ní moºnosti, nutný balí£ek ncurses

•

make xcong nástroj pro X-Windows, vyºadována qt knihovna

Nastavení kongura£ního souboru je d·leºitou sou£ástí celé kompilace, je v²ak pom¥rn¥ intuitivní a dob°e popsané v helpu samotné kongurace. Jisté funkce jsou nutné pro správné fungování systému, jiné nám jen práci usnadní. O n¥kterých volbách se zmíním v souvislosti s umíst¥ním RFS. Sv·j kongura£ní soubor p°ikládám v p°íloze B.

32

KAPITOLA 4.


P°ed spu²t¥ním kompilace je pot°eba je²t¥ nakopírovat vygenerované konstanty a ovlada£e z EDK do stromu kernelu (tzv. BSP), viz. [19]. Mn¥ se osv¥d£ila praxe nekopírovat celý obsah BSP, nýbrº pouze soubor xparameters_ml310.h s vygenerovanými konstantami pro ná² design (nastavení p°eru²ení, adresové rozsahy...) a ovlada£e ponechat p·vodní z vývojového stromu. Musel jsem sice vy°e²it n¥kolik nekompatibilit mezi generovaným xparameters_ml310.h a kódy ovlada£· (r·zné verze EDK generují konstanty s r·znými jmény se stejným významem, nap°. XPAR_OPB_SYSACE_0_DEVICE_ID vs. XPAR_SYSACE_0_DEVICE_ID), ale zato jsem nem¥l problémy s funk£ností ºádného za°ízení, jak tomu bylo v p°ípad¥ pouºití ovlada£· z BSP pro SysACE. Chyby typu `nemohu najít konstantu xxx` se hledají lépe, neº d·vod, pro£ se zastaví boot proces p°i p°ístupu ke CF p°i pouºití ²patných ovlada£·! Kdyº máme nastaveno jádro pro kompilaci, spustíme vlastní p°eklad p°íkazem make dep &&

make zImage, které nám vy°e²í závislosti a vytvo°í komprimovaný obraz jádra zImage.elf v adresá°i arch/ppc/boot/images.

4.1.3 BusyBox Tato utilita v sob¥ zahrnuje mnoho uºite£ných a pouºívaných program·, které kompiluje do jednoho malého spustitelného kódu. Vytvá°í vlastn¥ pro kaºdý podporovaný p°íkaz vybraný v konguraci symbolický link ukazující na jediný spustitelný soubor busybox v /bin adresá°i výsledného RFS. P°i spu²t¥ní n¥jakého z t¥chto link·, se provede p°íslu²ná operace, podle toho, jaký link vyvolal spu²t¥ní busyboxu. Programy samoz°ejm¥ mnohdy nemají tolik moºných voleb jako jejich pln¥ vybavené GNU prot¥j²ky, ale pro b¥ºnou práci pln¥ dosta£ují a u²et°í se tak °ádov¥ megabajty místa na disku s RFS. Pln¥ BusyBox popisuje jeho p°ízvisko, které °íká, ºe BusyBox je ²výcarský kapesní noºík pro embedded Linux systémy. BusyBox je pln¥ modulární a závisí na uºivateli, které p°íkazy v dob¥ kompilace ozna£í za podporované. BusyBox je ke staºení na ociálních stránkách projektu [3] v mnoha vývojových verzích. P°íkazem make menucong se dostaneme do kongura£ního menu kompilace BusyBoxu. Zde nastavíme prex pro kroskompilátor v Busybox Settings > Build Options > Crosscompiler prex na powerpc-405-linux-gnu- a v Busybox Settings > Installation Options > BusyBox instalation

prex nastavíme cestu k výslednému RFS, kam se má nakopírovat spustitelný soubor busybox a kde se mají vytvo°it symbolické linky na tento binární soubor. Ostatní volby týkající se jednotlivých podporovaných program· jsou na nás. N¥které jsou ov²em nutné, jako t°eba podpora pro init, getty, login nebo podpora pro NFS, pokud pouºíváme RFS p°es NFS. M·j kongura£ní soubor je k nalezení v p°íloze C.

4.1.4 Vytvo°ení RFS Vytvo°íme RFS pomocí skriptu mkrootfs.sh, který je voln¥ ke staºení na adrese www.klingauf.de/

/v2p/mkrootfs.tgz. Tento skript jsem upravil pro na²e ú£ely a je k vid¥ní v p°íloze D. Pokud budete upravovat p·vodní skript, doporu£uji editor, který si neporadí s DOS-ovskými konci °ádku (vim) a zobrazuje je jako ^M. Pokud pouºijete nap°. gedit, který tyto bajty rozpozná jako konce °ádku, budete se hodn¥ divit, pro£ skript nefunguje tak, jak má! Tento skript za nás vytvo°í adresá°ovou strukturu tak, jak je b¥ºná pro OS Linux. V t¥le skriptu se volá kompilace BusyBoxu, která zajistí vytvo°ení spustitelného binárního souboru busybox a pojmenovaných link· na n¥j . Dal²í na²í volbou, kterou je nutné u£init s ohledem na n¥kolik hledisek je, kam s RFS, který opera£ní systém Linux nutn¥ pot°ebuje ke svému fungování. Moºností je n¥kolik, bude na CF v jiné partition neº je .ace soubor s kongurací FPGA a obrazem OS, bude v opera£ní pam¥ti

KAPITOLA 4.


33

jako init ramdisk nebo m·ºe být p°ístupný p°es síóvé rozhraní jako NFS disk. Záleºí také, mimo jiné, v jaké fázi vývoje aplikace se nacházíme. Pro reºim vývoje a lad¥ní je výhodný NFS, protoºe se nemusíme zaobírat vytvá°ením ramdisku, kopírováním RFS na CF nebo brát ohled na velikost CF karty £i pam¥ti RAM.

a) CF Jak jsem zmínil v kapitole 2.3, XUP je vybaven kontrolérem pro práci s CF kartami. Jde o SysACE £ip, který krom¥ funkce £tení a zápisu je schopný detekovat soubor s kongurací FPGA na CF kart¥ a podle nastavení p°epína£· na desce je schopný z tohoto souboru FPGA nakongurovat. Pokud chceme kongurovat FPGA z CF, musíme nechat první partition CF karty naformátovanou jako DOS partition. V linuxovém fdisku se ozna£uje jako typ 6. SysACE °adi£ byl navrºen tak, ºe rozpozná pouze FAT12 nebo FAT16. Po£et sektor· na klastr musí být v¥t²í neº 1. Toto je £astým problémem na Windows strojích, protoºe formátovací utilita stanovuje vlastní optimální hodnotu po£tu sektor· na klastr, která tak m·ºe být i rovna 1, a tato partition se tak stane pro °adi£ ne£itelná. adi£ nám o tomto dá v¥d¥t rozsvícením Error LED diody. Stejn¥ tak pozor na po£et rezervovaných sektor· na za£átku kaºdého oddílu. SysACE p°e£te pouze oddíly s 1 rezervovaným sektorem, jde o MBR sektor. P°estoºe Microsoft ve svém £lánku [15] pí²e, ºe jediná povolená hodnota pro FAT12 nebo FAT16 je 1 rezervovaný sektor na klastr, pod Windows XP DOS formátovací utilita automaticky rezervuje 2-8 sektor·. V Linuxovém mkdosfs se dají v²echny tyto hodnoty nastavit.

$ sudo mkdosfs -v -F 16 -R 1 -s 16 -n XLNX_ACE /dev/sdb1 I pod Windows existuje tato utilita p°eportovaná a dá se stáhnout na adrese www.mager.org/mkdosfs/ a má dokonce v²echny pot°ebné parametry jako defaultní, takºe pak sta£í zadat n¥co jako c:\>

mkdosfs D: a daná partition bude £itelná i pro SysACE. Na tuto partition nahrajeme soubor .ace, který nakonguruje FPGA a zárove¬ spustí ná² výkonný program, kterým je samoz°ejm¥ zavad¥£ linuxu. Dále pot°ebujeme vytvo°it dva dal²í diskové oddíly: jeden typu Swap(82) a jeden typu Linux(83). Linuxový oddíl naformátujeme jako ext2, m·ºeme ale pouºít t°eba ex3, záleºí pro jaké systémy soubor· jsme dali podporu v konguraci kernelu. Na tento oddíl nakopírujeme p°ipravený RFS s BusyBoxem:

$ sudo mkswap /dev/sdb2 $ sudo mke2fs -L XLNX_RFS /dev/sdb3 Velikosti jednotlivých oddíl· záleºí na nás a na velikosti CF karty. Jen u swap oddílu se udává, ºe by m¥l být velký jako 1,5 násobek opera£ní pam¥ti systému. Ale pokud není k dispozici takto velká karta, nejedná se o ºádnou tragédii, jen je moºné, ºe chod systému nebude tak vyváºený. P°i kompilaci jádra nesmíme zapomenout na za²krtnutí podpory pro Xilinx SysACE v Block

device v menu kongurace kernelu. P°i boot procesu bude CF dostupná jako /dev/xsysace. Default bootloader kernel argument pro umíst¥ní RFS bude tedy root=/dev/xsysace/disc0/partN

rw , kde partN ozna£uje £íslo linuxového oddílu s RFS.

b) Ramdisk Vyuºijeme podpory kernelu pro init ramdisk a uloºíme si do n¥ho ná² RFS. Postup je následující: Vytvo°íme ramdisk poºadované velikosti a naformátujeme:

$ dd if=/dev/zero of=ramdisk.image bs=1k count=kbytes_size $ mke2fs -F -m 0 -b 1024 ./ramdisk.image 8192

34

KAPITOLA 4.


kde bs je velikost bloku, -m 0 znamená bez rezervovaných blok· a 8192 je velikost v po£tech blok·. Namountujeme soubor za pomoci /dev/loop0 a nakopírujeme ná² RFS:

$ mount ./ramdisk.image /mnt/initrd -t ext2 -o loop=/dev/loop0 $ cp -R ~/xup/RFS /mnt/initrd Odmountujeme vytvo°ený ramdisk, zkomprimujeme a nakopírujeme do arch/ppc/boot/images:

$ umount /mnt/initrd $ gzip -9 /tmp/ramdisk.image $ cp /tmp/ramdisk.image.gz arch/ppc/boot/images/ramdisk.img.gz Nutno podotknout, ºe ramdisk.img.gz je povinný název ramdisku, pokud bychom ho cht¥li m¥nit, musíme zm¥nit hlavní Makele pro kompilaci jádra. V p°ípad¥ pouºití RFS v ramdisku je default kernel argument root=/dev/ram rw a nesmíme zapomenout nastavit podporu pro RAM disk a initial RAM disk v konguraci kernelu a nastavit také podporovanou velikost (výchozí hodnota je 4MB, coº m·ºe být mnohdy málo). Vlastní kompilaci jádra provedeme p°íkazem make dep && make zImage.initrd. Po zkompilování najdeme v arch/ppc/boot/images soubor zImage.initrd.elf, který pouºijeme jako ná² softwarový bitstream.

c)NFS NFS je protokol umoº¬ující p°istupovat ke vzdáleným disk·m jako k lokálním. Je postaven na technologii RPC. Na stran¥ serveru si musíme podporu pro NFS server nainstalovat. Budeme pot°ebovat balí£ek nfs-kernel-server, který si p°ípadné dal²í balí£ky (portmap, nfs-common. . . ) doinstaluje. Po instalaci NFS serveru musíme p°ekongurovat portmap. Portmap je systémový daemon, který se stará o svázání jednotlivých rpc sluºeb s p°íslu²nými TCP, p°ípadn¥ UDP porty. Porty jsou RPC sluºbám p°id¥lovány dynamicky, tudíº se musí klient p°ed zahájením kaºdé komunikace s jakoukoliv RPC sluºbou dotázat portmapu na aktuální port, na kterém je tato sluºba dostupná. P°i rekonguraci portmapu se objeví dotaz, zda chceme vázat portmap na loopback, dáme ne a sluºbu portmap restartujeme:

$ sudo dpkg-reconfigure portmap $ sudo /etc/init.d/portmap restart M·ºeme se podívat, jaké RPC sluºby nám na serveru b¥ºí:

$ sudo rpcinfo -p Následn¥ p°idáme ná² RFS do exportovaných souborových systém· p°idáním °ádky do /etc/exports:

/home/misan/xup/RFS 192.168.239.1/24(rw,no_root_squash,async) Tímto povolujeme p°ístup p°es NFS k adresá°i /home/misan/xup/RFS v²em stroj·m z adres 192.168.239.1-192.168.239.255. M·ºeme samoz°ejm¥ poskytnout p°ístup výlu£n¥ jednomu stroji nebo chování ovlivnit editací soubor· /etc/hosts.deny a /etc/hosts.allow. Po editaci /etc/exports restartujeme NFS server daemona a donutíme ho ke znovuna£tení kongura£ního souboru:

$ sudo /etc/init.d/nfs-kernel-server restart $ sudo exportfs -ra $ sudo /sbin/chkconfig nfs on

KAPITOLA 4.


35

Které adresá°e a komu exportujeme se dozvíme p°íkazem:

$ sudo showmount -e Na stran¥ klienta, tudíº na stran¥ na²eho modulu je nastavení celkem jednoduché. Musíme op¥t nastavit v konguraci kernelu podporu pro NFS a RFS p°es NFS. Kernel argument nastavíme v p°ípad¥ statického p°id¥lování adres na root=/dev/nfs rw nfsaddrs=clientIP:serverIP:gateway:netmask

nfsroot=/home/misan/xup/RFS/ a odstraníme z etc/init.d/rcS statické p°id¥lování adresy pomocí ifcong. Pokud pouºíváme protokol DHCP a tudíº neznáme svou adresu p°i kompilaci, nastavíme argument na root=/dev/nfs rw nfsroot=serverIP:/home/misan/xup/RFS/

ip=on , pro získávání adresy pomocí protokolu bootp je argument root=/dev/nfs rw nfsroot=serverIP:/home/misan/xup/RFS/ ip=bootp . Klient si m·ºe samoz°ejm¥ namountovat i jiné disky NFS, ne jen sv·j RFS. Sta£í pouºít p°íkaz mount tímto zp·sobem:

$ mount nfs-server:/data_dir_onserver /mnt/data_mountpoint Více informací lze nalézt v [19],[12] a [1].

4.2

Implementace ovlada£·

Modul pro sb¥r dat se dá rozd¥lit na t°i díl£í podcelky, které je pot°eba ovládat nezávisle na sob¥. K tomu bylo zapot°ebí vyvinout t°i ovlada£e, pro kaºdou £ást jeden. Jedná se o vlastní histogramickou jednotku s hlavní pam¥tí ur£enou pouze pro £tení a mnoºinou kontrolních registr·, z nichº n¥které jsou ur£ené pro zápis a n¥které pro £tení i zápis. Korek£ní pam¥´, druhou £ást modulu, lze nejenom £íst, ale je moºno do ní i zapisovat za ú£elem správného nastavení a fungování korekce m¥°ených hodnot. T°etím ovlada£em bude ovlada£ pro DCM jednotku, který se bude starat o správné nastavení hodinových a kontrolních signál· pro p°evodníky a detektory prost°ednictvím mnoºiny kontrolních registr·.

4.2.1 Histogramická jednotka Hlavním posláním tohoto ovlada£e bude umoºnit uºivatel·m nebo uºivatelským aplikacím získat nam¥°ená histogramická data. Hardware modulu si je ukládá do blokové pam¥ti na FPGA £ipu, která je p°ístupná na adresách 0x70E00000-0x70E1FFFF (128K). Uºivatel nemá d·vod tyto data m¥nit, proto je tato pam¥´ ur£ená pouze pro £tení. Krom¥ vy£ítání této pam¥ti musíme být je²t¥ schopni n¥jakým zp·sobem resetovat, startovat, zastavovat a kontrolovat b¥h modulu sbírajícího data do histogram·. Toho dosáhneme zápisem nebo £tením £ty° 32-bitových registr· mapovaných od bázové adresy 0x7F400000. Struktura le_operations pro tento ovlada£ vypadá následovn¥:

struct file_operations daq_fops = { read: daq_read, open: daq_open, release: daq_release, ioctl: daq_ioctl, llseek: daq_llseek, }; Krom¥ t¥chto 5 funkcí musí implementovat kaºdý modul, který má ambice stát se sou£ástí jádra, je²t¥ init a cleanup funkci modulu.

36

KAPITOLA 4.


int daq_init_module(void) Vytvo°íme si strukturu charakterizující na²e za°ízení, její denice je takováto:

typedef struct DAQ_Dev { void *data; unsigned long size; devfs_handle_t handle; struct semaphore sem; } DAQ_Dev; Po vytvo°ení a inicializaci se p°edává pointer na tuto strukturu struktu°e struct le p°i registraci souboru za°ízení. Je nám pak p°ístupná ve v²ech funkcích ovlada£e implementujících systémová volání. Dostaneme se k ní p°es ukazatel private data, jak je vid¥t nap°. ve funkci pro £tení:

ssize_t daq_read(struct file *filp, char *buf, size_t count, loff_t *f_pos) { DAQ_Dev *dev = filp->private_data; ... } Ovlada£ si alokuje stejn¥ velké penzum souvislé pam¥ti v opera£ní pam¥ti jako je velikost histogramové pam¥ti v DAQ modulu, tedy 128 KB. Alokovat budeme po stránkách a pointer na alokovanou pam¥´ uloºíme do prom¥nné data a nezapomeneme nastavit size na správnou velikost. P°i velikosti stránky 4 KB pot°ebujeme 32 stránek, coº je s ohledem na popsaný zp·sob

5 stránek, °ád je tedy 5. Data v hlavní histogramové pam¥ti mo-

alokace pam¥ti po stránkách 2

dulu jsou aktualizována hardwarem modulu zhruba jednou za vte°inu. Po aktualizaci hodnot jednotka vyvolá p°eru²ení procesoru, které musí ná² ovlada£ obslouºit a vy£íst si aktuální hodnoty z této pam¥ti a uloºit je do alokované kernel pam¥ti. To znamená, ºe z hardwarové pam¥ti za°ízení se bude £íst jen a pouze v obsluze p°eru²ení. Poºadavky uºivatelských program· na aktuální hodnoty £etností se budou vy°izovat z obrazu v hlavní pam¥ti FPGA modulu. P°edejde se tím tak moºnému velkému zatíºení OPB sb¥rnice, na které je DAQ p°ipojen [21], uºivatelskými dotazy. Semafor pouºívaný k synchronizaci p°ístupu k dat·m v £lenské prom¥nné data se musí nainicializovat také. Slouºí k tomu funkce void sema_init (struct semaphore *sem, int val), která nastaví semafor sem na hodnotu val. Poslední £lenskou prom¥nnou typu devfs_handle_t ve struktu°e DAQ_Dev získáme voláním funkce denované v linux/devfs_fs_kernel.h :

devfs_handle_t devfs_register (devfs_handle_t dir, const char *name, unsigned int flags, unsigned int major, unsigned int minor, umode_t mode, void *ops, void *info)

dir

ur£uje adresá°, ve kterém se vytvo°í soubor za°ízení pro ná² ovlada£. Pokud ho nastavíme na NULL, vytvo°í se v adresá°i /dev. M·ºeme si také vytvo°it sv·j vlastní podadresá° pomocí funkce devfs_handle_t devfs_mk_dir (devfs_handle_t dir, const char *name,

void *info), kde dir je rodi£ovský adresá°, name je jméno vytvá°eného adresá°e a info je defaultní hodnota pro lp->private_data.

name ags

jméno vytvá°eného souboru za°ízení bitová maska z devfs ag· denovaných v linux/devfs_fs_kernel.h,

DEVFS_FL_AUTO_DEVNUM zajistí automatické vygenerování major a minor £ísla pro za°ízení

KAPITOLA 4.


37

major

major £íslo za°ízení, ignoruje se v p°ípad¥ pouºití agu DEVFS_FL_AUTO_DEVNUM

minor

minor £íslo za°ízení, ignoruje se v p°ípad¥ pouºití agu DEVFS_FL_AUTO_DEVNUM

mode ops info

mód pro p°ístup k za°ízení

pointer na strukturu struct le_operations s operacemi pro dané za°ízení na tuto hodnotu se inicializuje lp->private_data poté, co je za°ízení otev°eno

V init funkci modulu je také pot°eba zaregistrovat si p°eru²ení od DAQ modulu u OS, aby mohl ná² ovlada£ v·bec p°eru²ení obslouºit. V unixových systémech se poºadavek p°eru²ení ozna£uje jako IRQ a prototyp registra£ní funkce vypadá následovn¥:

int request_irq(unsigned int irq, void (*handler)(int, void *, struct pt_regs *), unsigned long flags, const char *dev_name, void *dev_id) íslo irq nám poskytne návrhový systém EDK, £ímº se zajistí, aby nedocházelo ke kolizím. EDK nám poskytne tzv. ID p°eru²ovacího vektoru. Toto £íslo musíme ode£íst od celkového po£tu p°eru²ovacích vektor·, kterých je 31. N¥která za°ízení, jak jsem zjistil, mají vektory napevno, tyto hodnoty pak návrhový systém automaticky p°eskakuje. Sta£í nám tedy denovat si na²e £íslo p°eru²ení takto:

#define DAQ_IRQ (31 - XPAR_INTC_0_HIST_DAQ_0_VEC_ID) Druhým parametrem je ukazatel na funkci, která p°eru²ení obslouºí. Tento handler p°eru²ení musí mít p°edepsané parametry a být typu void. Parametr ags je bitová maska nastavující chování správy p°eru²ení, defaultní volba je 0. Dev_name je jméno, které se zobrazí u vlastníka p°eru²ení p°i výpisu /proc/interrupts. Dev_id se pouºívá jednak p°i sdílených p°eru²eních jako jednozna£ný identikátor a za druhé jako ukazatel na strukturu ovlada£e, která se v obsluze pouºívá. Pokud ov²em nepouºíváme sdílená p°eru²ení, ani nechceme mít v obsluze p°eru²ení p°ístup ke strukturám ovlada£e, nic nám nebrání nastavit tento ukazatel na NULL. Je²t¥ nezapomeneme pomocí volání ioremap_nocache zjistit virtuální adresy, které odpovídají bázovým adresám hardwarové histogramové pam¥ti a registr· DAQ modulu a nastavit vlastníka pomocí SET_MODULE_OWNER( &daq_fops).

void daq_cleanup_module(void) Tato metoda se volá p°i odebírání modulu z jádra. V jejím t¥le musíme provést úklid po £innosti na²eho modulu. P°edn¥ musíme uvolnit p°eru²ení, která jsme si zaregistrovali:

void free_irq(unsigned int irq, void *dev_id);

irq

je £íslo p°eru²ení o jehoº odregistrování ºádám

dev_id

je unikátní identikátor pouºívaný u sdílených p°eru²ení, v p°ípad¥ nepouºívání sdíle-

ných p°eru²ení se nahrazuje NULL

Zru²it mapování fyzická - virtuální pam¥´ pro registry periferie a histogramickou pam¥´ voláním funkce iounmap. Samoz°ejm¥ uvolníme i alokovanou pam¥´ pomocí free_pages a kfree. Poslední v¥c, co musíme ud¥lat, je zru²it uzel v /dev. Poslouºí nám k tomu metoda void devfs_unregister

38

KAPITOLA 4.


(devfs_handle_t de), která p°ebírá jako parametr strukturu, kterou jsme vytvo°ili v init funkci voláním devfs_register.

int daq_open(struct inode *inode, struct le *lp) Je to první funkce, která se zavolá p°i p°ístupu k na²emu ovlada£i, tedy p°i zahájení operace nad na²ím souborem za°ízení. Není povinnost ji implementovat a potom kaºdý pokus o otev°ení ovlada£e bude úsp¥²ný. Open metodou se dá jednodu²e °ídit, kolik sou£asných p°ístup· je moºno k ovlada£i provád¥t (kolik otev°ených deskriptor· na soubor za°ízení m·ºe existovat sou£asn¥). Pomocí makra MOD_INC_USE_COUNT se dá inkrementovat globální po£ítadlo pouºití modulu, p°ípadn¥ se dotázat makrem MOD_IN_USE, zda je ná² modul stále pouºívaný. Funkce open vrací 0 pokud prob¥hla v po°ádku, jinak vrací záporné konstanty z linux/errno.h.

int daq_release(struct inode *inode, struct le *lp) Tato funkce se volá p°i ukon£ení práce se souborem za°ízení. Stejn¥ jako open funkce m·ºe chyb¥t. Makrem MOD_DEC_USE_COUNT dekrementujeme po£itadlo sou£asných p°ístup·. Release funkce vrací 0 pokud prob¥hla v po°ádku, jinak vrací záporné konstanty z linux/errno.h.

void daq_interrupt_handler(int irq, void *dev_id, struct pt_regs *regs) Takto vypadá deklarace na²í obsluhy p°eru²ení. Obsluhy p°eru²ení musí obecn¥ prob¥hnout velmi rychle a v ºádném p°ípad¥ nesmí pouºívat programové prost°edky, které by mohly vézt k uspání. Obsluha p°eru²ení také nem·ºe kopírovat data nebo jinak p°istupovat k user space, protoºe neb¥ºí v kontextu ºádného procesu. Typickým úkolem obsluhy p°eru²ení bývá p°ijmout data, n¥kam je uloºit a probudit procesy, které £ekají, aby mohly tyto data zpracovat. £asto se pouºívá technika tasklet· (nov¥j²í jádra od verze 2.4) nebo bottom-half handler·, kte°í provedou v obsluze jen to nejnutn¥j²í (bottom-half ) a £asov¥ náro£né zpracování (half-top) naplánují pomocí své vlastní nebo systémové fronty úkol· mimo obsluhu p°eru²ení [2]. My v na²í obsluze p°ekopírujeme data z histogramové pam¥ti v FPGA do pam¥ti alokované na²ím ovlada£em v jád°e OS. Pouºijeme funkci memcpy_fromio(dest, source, num), která vypadá podobn¥ jako známá C knihovní funkce memcpy. Rozdíl je v tom, ºe tato funkce dokáºe kopírovat data z I/O pam¥ti mapované do virtuálního adresového prostoru. V moderních verzích jader je tato funkce implementována nap°í£ v²emi architekturami. Implementace se ov²em li²í architektura od architektury. N¥kde jde o makra operujícími s ukazateli, n¥kde o inline funkce pouºívající p°ímo assemblerovské instrukce dané architektury. Pro nás je výhodou, ºe tato funkce dokáºe vyuºít burst mód pro p°enos dat po OPB sb¥rnici.

ssize_t daq_read(struct le *lp, char *buf, size_t count, lo_t *f_pos) Implementace funkce pro obsluhu systémového volání read je pom¥rn¥ p°ímo£ará. Po získání struktury ovlada£e zamkneme semafor, vy°e²íme moºné problémy s tím, jaké mnoºství dat a od jaké pozice se má vlastn¥ £íst, a provedeme vlastní p°enos dat do buf. Protoºe se kopíruje mezi kernel a user space, musíme pouºít funkci unsigned long copy_to_user(void *to, const

void *from, unsigned long count). P°estoºe se tato funkce chová podobn¥ jako memcpy, jeden významný rozdíl tu je. V p°ípad¥, ºe chceme kopírovat do pam¥ti v user space a takto adresovaná stránka se zrovna nenachází v pam¥ti, obsluha výpadku pam¥ti tento ná² kernel proces uspí do doby, neº se poda°í stránku do opera£ní pam¥ti nahrát. Funkce copy_to_user se pouºívá i v p°ípad¥, ºe chceme zjistit, zda daný user space ukazatel(pointer to) je nebo není validní. V obou p°ípadech vrací hodnotu °íkající, kolik bajt· zbývá z daného poºadavku p°ekopírovat, proto kontrolujeme návratovou hodnotu na 0. T¥lo funkce read vypadá takto:

ssize_t daq_read(struct file *filp, char *buf, size_t count, loff_t *f_pos)

KAPITOLA 4.

{


39

ssize_t ret = 0; DAQ_Dev *dev = filp->private_data; if(dev == NULL) return -EFAULT; //zamknu semafor if(down_interruptible(&dev->sem)) return -ERESTARTSYS; //n¥kdo chce £íst za koncem dat if(*f_pos >= dev->size) goto out; //n¥kdo chce £íst více neº mám, vrátím v²e aº do konce if(*f_pos + count > dev->size) count = dev->size - *f_pos; //nemám ºádná platná data, asi selhal init if(!dev->data) goto out; //p°ekopíruji data do user space if(copy_to_user(buf, dev->data+*f_pos,count)) { ret = -EFAULT; goto out; } //posunu ukazatel v datech *f_pos += count; ret = count; out: up(&dev->sem);

}

//vrátím skute£né mnoºství p°e£tených dat return ret;

lo_t daq_llseek(struct le *lp, lo_t o, int whence) Tato metoda se pouºívá ke zm¥n¥ aktuální £tecí/zápisové (v na²em p°ípad¥ pouze £tecí) pozice v souboru, v na²em p°ípad¥ v souboru za°ízení. Lo_t znamená long oset a je 64-bitový i na 32-bitových architekturách. Nová pozice je získána v návratové hodnot¥, z £ehoº vyplývá, ºe chybové stavy jsou signalizovány zápornými hodnotami. U funkce llseek je zajímavé, ºe pokud se neimplementuje, je vygenerována jakási defaultní llseek funkce, která ov²em umí nastavovat pozici pouze vzhledem k za£átku souboru. Pokud nám sta£í takovéto chování, nemusíme ji implementovat. Protoºe ne vºdy bude pro uºivatele výhodné £íst data souvisle, jak jdou za sebou, ale bude chtít £íst jen £ást souboru £etností, nap°. pouze pro jeden kanál ADC, bez této funkce se neobejdeme. Funkci seek vyuºívají mimo jiné t°eba funkce ze standardní knihovny C jako jsou pread a dal²í. Pot°ebují nap°íklad um¥t nastavit pozici na konec souboru nebo

40

KAPITOLA 4.


vzhledem k aktuální pozici. Na druhou stranu, pokud máme za°ízení, u kterého je seekování nemoºné (typicky konsole, pipe. . . ), musíme tuto funkci implementovat s chybovým kódem, protoºe nechceme pouºívat vygenerovaný defaultní llseek.

loff_t device_llseek(struct file *filp, loff_t off, int whence) { return -ESPIPE; /* unseekable */ } Z argumentu lp si op¥t získáme pointer na strukturu na²eho ovlada£e. Argument o zastává úlohu bu¤ absolutn¥ nebo relativn¥ ur£ené pozice v souboru. O tom jak se bude interpretovat rozhodne t°etí argument whence, který nabývá 3 hodnot:

SEEK_SET (0) SEEK_CUR (1) SEEL_END (2)

parametr o ur£uje absolutní pozici v souboru parametr o ur£uje relativní posun v·£i aktuální pozici parametr o ur£uje relativní pozici v·£i konci souboru, vºdy záporný

Implementace pro ná² ovlada£ je nyní jasná a vypadá takto:

loff_t daq_llseek(struct file *filp, loff_t off, int whence) { DAQ_Dev *dev = filp->private_data; loff_t newpos; // Máme ²patné za°ízení? if(dev == NULL) return -EBADF; switch(whence) { case 0: /* SEEK_SET */ newpos = off; break; case 1: /* SEEK_CUR */ newpos = filp->f_pos + off; break; case 2: /* SEEK_END */ newpos = dev->size + off; break; default: /* ²patná hodnota */ return -EINVAL; } // mimo rozsah? if(newpos < 0) return -EINVAL; // nastavíme novou pozici filp->f_pos = newpos;

KAPITOLA 4.

}


41

// a zárove¬ ji vrátíme return newpos;

Druhou podstatnou £ástí ovlada£e je £tení a zápis kontrolních a status registr· DAQ modulu. K p°ístupu k t¥mto registr·m z uºivatelských aplikací vyuºijeme systémové volání ioctl. Ioctl je unixový p°ístup k otázce komunikace za°ízení s vn¥j²ím sv¥tem. N¥kdy prost¥ nesta£í implementovat £tení p°ípadn¥ zápis, ale je nutné n¥jakým zp·sobem zprost°edkovat interakci mezi za°ízením a uºivatelem. K tomu se pouºívají práv¥ p°íkazy ioctl. Kaºdý ovlada£ za°ízení m·ºe implementovat své vlastní ioctl p°íkazy, n¥které pro £tení, n¥které pro zápis a nebo bez vým¥ny dat. Prototyp funkce vypadá takto:

int (*ioctl) (struct inode *inode, struct file *filp, unsigned int cmd, unsigned long arg) Inode a lp jsou struktury týkající se souboru za°ízení nad kterým je ioctl provád¥no. V argumentu cmd je uloºena informace o tom, jaká akce se má provézt. Argument arg se pouºívá pro p°edávání v¥t²ího mnoºství dat (jako pointer do user space pam¥ti) neº je 4B jako návratová hodnota volání ioctl. Jak se dá asi o£ekávat, implementace ioctl volání se implementuje pomocí switch p°íkazu, který vybírá tu správnou reakci odpovídající argumentu cmd. R·zné p°íkazy mají r·zné £íselné hodnoty, které jsou £asto symbolicky pojmenované pomocí p°íkazu preprocesoru #dene v hlavi£kovém souboru ovlada£e. Uºivatelské programy, které cht¥jí pracovat s ioctl p°íkazy daného za°ízení, potom includují tyto hlavi£kové soubory. íslo pro command si nem·ºeme ov²em jen tak zvolit, nap°. za£ít svoje p°íkazy £íslovat od 0x01. Jejich hodnota musí být unikátní v rámci celého systému, aby se zamezilo situacím, kdy aplikujeme správný existující p°íkaz, ale na ²patné za°ízení. D°íve byl command 16-bitový a skládal se z 8-bitové 'magické' konstanty zvolené pro dané za°ízení a 8-bitového £ísla commandu. Tedy nap°. pokud magická konstanta byla `k'(0x6b), pak £ísla command· vypadala takto:

#define DEV_COMMAND_01 0x6b01 #define DEV_COMMAND_02 0x6b02 #define~DEV_COMMAND_03 0x6b03 atd. Tato metoda byla nahrazena jinou. Nyní je £íslo commandu rozd¥leno na 4 £ásti:

Type

p°ebírá úlohu magického £ísla, musí se zvolit s ohledem na jiº zvolená v dokumentaci

kernelu v souboru ioctl-number.txt, toto pole je 8 bit· ²iroké

Number

po°adové £íslo p°íkazu, 8 bit·

Direction

udává sm¥r p°enosu dat pro daný p°íkaz, bitová maska sloºená z _IOC_NONE,

_IOC_READ, _IOC_WRITE

Size

velikost p°ená²ených dat, ²í°ka tohoto pole je architekturn¥ závislá a pohybuje se v rozmezí 8-14 bit·

Pro generování nebo zji²óvání informací o commandu existuje mnoºství jednoduchých maker:

_IOC_NRBITS, _IOC_TYPEBITS, _IOC_SIZEBITS, _IOC_DIRBITS udávají ²í°ku jednotlivých polí v commandu Makra pro vytvá°ení command·:

42

KAPITOLA 4.


_IOC(dir,type,nr,size) _IO(type,nr) _IOR(type,nr,size) _IOW(type,nr,size) _IOWR(type,nr,size) Makra pro zji²óvání informací z hodnoty commandu:

_IOC_DIR(nr) _IOC_TYPE(nr) _IOC_NR(nr) _IOC_SIZE(nr) Na za£átku zpracování commandu ov¥°íme, ºe typ commandu odpovídá na²emu za°ízení a ºe po°adové £íslo commandu není v¥t²í neº námi denované maximum. Pokud ov¥°ení neprojde, vrátíme podle POSIX standardu hodnotu ENOTTY.

if(_IOC_TYPE(cmd) != DAQ_IOC_MAGIC) return -ENOTTY; if(_IOC_NR(cmd) > DAQ_IOC_MAXNR) return -ENOTTY; V p°ípad¥, ºe se jedná o command s vým¥nou dat mezi kernel a user space, musíme také ov¥°it, ºe adresa v user space je platná. Poslouºí nám k tomu funkce int access_ok(int type, const

void *addr, unsigned long size) deklarovaná v asm/uaccess.h. Argument type nabývá hodnot VERIFY_READ, pokud jde o £tení user space pam¥ti, nebo VERIFY_WRITE p°i zápisu do user space pam¥ti. Addr je adresa v user space a size je velikost pam¥ti, kterou chceme kontrolovat. Funkce vrací 1 pokud je p°ístup v po°ádku nebo 0 p°i selhání. Pokud ovlada£ selºe p°i p°ístupu k user space pam¥ti, m¥l by vrátit podle standardu EFAULT. Je²t¥ upozorním, ºe sm¥r udávaný v hodnot¥ commandu je z pohledu ovlada£e. Pokud se má £íst n¥co na ovlada£i, znamená to, ºe se bude zapisovat do user space pam¥ti a naopak! Lépe je to vid¥t na následujícím fragmentu kódu:

if(_IOC_DIR(cmd) & _IOC_READ) err = !access_ok(VERIFY_WRITE, (void *)arg, _IOC_SIZE(cmd)); else if(_IOC_DIR(cmd) & _IOC_WRITE) err = !access_ok(VERIFY_READ, (void *)arg, _IOC_SIZE(cmd)); if(err) return -EFAULT; Podporované p°íkazy pro DAQ modul jsou denovány v daq.h:

/* pouºívá 'g' jako magickou konstantu */ #define DAQ_IOC_MAGIC 'g' #define DAQ_IOC_START _IO(DAQ_IOC_MAGIC, 0) #define DAQ_IOC_STOP _IO(DAQ_IOC_MAGIC, 1) #define DAQ_IOC_READ_R0 _IOR(DAQ_IOC_MAGIC, #define DAQ_IOC_READ_R1 _IOR(DAQ_IOC_MAGIC, #define DAQ_IOC_READ_R2 _IOR(DAQ_IOC_MAGIC, #define DAQ_IOC_READ_R3 _IOR(DAQ_IOC_MAGIC, #define DAQ_IOC_MAXNR 5

2, 3, 4, 5,

sizeof(int)) sizeof(int)) sizeof(int)) sizeof(int))

KAPITOLA 4.

43


Registr

Mód p°ístupu

Význam

REG0

read

stavový registr pro DCM

REG1

read&write

hrubý fázový posun pro signál BIMP

REG2

read&write

hrubý fázový posun pro signál ADC_CLK

REG3

read&write

hrubý fázový posun pro signál CCLK

REG4

read&write

jemný fázový posun pro signál BIMP

REG5

read&write

hrubý fázový posun pro signál ADC_CLK

REG6

read&write

hrubý fázový posun pro signál CCLK

REG7-REG15

read&write

nevyuºívaný

Tabulka 4.1: P°ehled registr· DCM modulu

4.2.2 Ovlada£ DCM modulu Ovlada£ pro DCM modul bude oproti DAQ modulu velice jednoduchý. Od tohoto ovlada£e pot°ebujeme mít moºnost pouze ovládat sadu 16 registr· dostupných od adresy 0x7F300000. Sou£asná verze hardwaru pouºívá pouze prvních 7, ostatní jsou rezervovány pro moºné budoucí pouºití. P°esn¥j²í popis registr· najdeme v tabulce 4.1. Tyto registry budeme ovládat pomocí ioctl. Není proto nutné implementovat funkci pro £tení, zápis a seek. Ov²em funkci read jsem se rozhodl p°eci jen doimplementovat pro usnadn¥ní vy£ítání více registr· najednou. Struktura le_operations pro ovlada£ DCM modulu vypadá nakonec následovn¥:

struct file_operations dcm_fops = { open: dcm_open, release: dcm_release, read: dcm_read, ioctl: dcm_ioctl, }; Init funkce se chová podobn¥ jako u DAQ modulu, i zde musíme zjistit virtuální bázovou adresu registr· periferie. V adresá°i /dev nám vznikne nové za°ízení dcm. I struktura udrºující pot°ebné informace o tomto ovlada£i je totoºná s p°edchozí. Ov²em prom¥nná data zde funguje jen jako buer p°i vy£ítání dat z I/O pam¥ti do user space pam¥ti. Size udává velikost bueru, která je nastavena na nejv¥t²í moºné penzum dat, které bude chtít uºivatel vy£íst, tedy v²echny registry 16*4B = 64B.

typedef struct DCM_Dev { void *data; unsigned long size; devfs_handle_t handle; struct semaphore sem; }DCM_Dev; Oproti tomu nám p°ibylo ioctl p°íkaz·, vzhledem k tomu, ºe pot°ebujeme £íst 16 registr· a zapisovat 15, pot°ebujeme 31 ioctl p°íkaz·. Jako magická konstanta bylo pouºito `k':

#define DCM_IOC_MAGIC 'k' #define DCM_IOC_MAXNR 30

44

KAPITOLA 4.


4.2.3 Ovlada£ pro práci s korek£ní pam¥tí Pro práci s korek£ní pam¥tí byl vytvo°en dal²í samostatný modul jádra s implementovanými funkcemi pro £tení a tentokráte i zápis do odd¥leného pam¥óvého prostoru 0x71E000000x71E03FFF (16K). Tento adresový prostor je sice velký 16K, ale to je z d·vodu moºného roz²í°ení korekce z dne²ních 8 bit· na plných 12 bit·. Tedy v sou£asnosti je od adresy 0x71E00000

8 = 256 poloºek o velikosti 4B kaºdá. Pro nás to tedy znamená, ºe budeme £íst prv-

ukládáno 2

ních 256*4 = 1024B. Dál nás zatím tato pam¥´ nezajímá. Z t¥ch 4B uloºených na kaºdé adrese (zarovnané na 4B) nás zajímají pouze spodní 2B, protoºe nahrazujeme pouze 8 bit· nam¥°ené hodnoty. Struktura le_operations:

struct file_operations corr_fops = { read: corr_read, write: corr_write, open: corr_open, release: corr_release, llseek: corr_llseek, }; Nebudeme implementovat ioctl, protoºe tento modul tvo°í pouze pam¥´, kterou m·ºeme pouze £íst nebo zapisovat. S ohledem na moºné pouºití uºivatelských aplikací s podporou sostikovan¥j²ího seeku, neº který je automaticky generován pro kaºdé za°ízení, jsem se rozhodl implementovat i seek. Jinak musíme o²et°it v²echny moºné problémy a situace jako je tomu u DAQ modulu, vyjma p°eru²ení.

4.3

Server a klient aplikace

Nebylo by vhodné a mnohdy ani moºné, aby uºivatelé a jejich aplikace p°ímo p°istupovali p°es ovlada£e k DAQ modulu. Lep²ím °e²ením je nechat uºivatele odstín¥né od ovlada£· a p°ístup k dat·m vy°e²it pomocí mezivrstvy, která pob¥ºí na na²í FPGA desce. P·jde o TCP server v podob¥ systémového daemona, který bude °e²it poºadavky klient·.

4.3.1 Komunikace mezi modulem a zobrazující aplikací Podíváme-li se na modul z jiného pohledu, jde vlastn¥ o samostatn¥ fungující výpo£etní systém, postavený co do HW na FPGA a SW na opera£ním systému Linux. Nam¥°ená data by nám ov²em nebyla k ni£emu, kdyby z·stala na tomto stroji a nebyla moºnost je dále studovat a zpracovávat. Je zde samoz°ejm¥ moºnost data zpracovávat na stroji, na kterém b¥ºí ná² DAQ modul. Ov²em zde by jsme mohli velice rychle narazit na jistá výpo£etní omezení, ke kterým nás nutí procesor PowerPC 405 a jeho pracovní frekvence 400MHz. Jako daleko výhodn¥j²í se jeví moºnost, ve které tento stroj funguje jako jakýsi aplika£ní server, jak ho známe ze t°ívrstvé architektury. £ili tento server nebude zprost°edkovávat pro klienty p°ístup k databázi nebo jinému datovému úloºi²ti, jak je b¥ºné, nýbrº bude fungovat jako mezivrstva mezi klienty zobrazujícími a dále zpracujícími data a modulem se svými ovlada£i. P°i takto navrºené architektu°e p°ístupu je nutné vy°e²it otázku komunikace jednak mezi serverem a modulem a zadruhé mezi serverem a klientem, potaºmo klienty.

Ad 1)

Zde je °e²ení jednoduché. Ve²kerou komunikaci je moºné provést skrze na²e t°i ovla-

da£e. Server pob¥ºí na stejném stroji jako se nachází ná² modul, m·ºe tedy aplikovat operace £tení, zápisu nebo ioctl nad soubory za°ízení /dev/daq, /dev/dcm a /dev/corr.

KAPITOLA 4.

45


UART chip

Buer size (bytes)

Max speed (bit/s)

8250

none

9 600

16450

1

9 600

16550

16

115 200

16650

32

430 800

16750

64

921 600

16850

128

1,5 Mbps

Tabulka 4.2: P°ehled komunika£ních rychlostí podle UART obvodu

Jako ukázku uvedu fragment kódu zapisujícího do korek£ní pam¥ti data z bueru buf o délce count:

#define CORR_FILE "/dev/corr" ... fd = open(CORR_FILE, O_WRONLY); if(fd < 0) { fprintf(stderr, "%s: %s\n", CORR_FILE, strerror(errno)); return 1; } int written = write(fd, buf, count); close(fd); Podobným zp·sobem m·ºeme provád¥t ostatní operace nad na²imi soubory za°ízení. Více v

sys/ioctl.h a unistd.h.

Ad 2)

Zde je ná² návrh nutno zváºit hned z n¥kolika hledisek. Jsme limitováni jednak na

stran¥ modulu, tedy FPGA desky a jejích periferií a také na komunika£ních perifériích klientských stroj·. Pokud bychom se striktn¥ drºeli na²í XUP V2P, museli bychom volit mezi sériovou linkou a ethernetovým rozhraním. Pokud p°ipustíme moºnost implementace na jiné desce nebo moºnost roz²í°ení XUP o dal²í periférie pomocí roz²i°ujících konektor·, rozroste se nám mnoºina komunika£ních primitiv o dal²í - WiFi, IrDA a Bluetooth. Vzhledem k tomu, ºe je moºné i komunikaci p°es IrDA a Bluetooth transformovat na komunikaci p°es TCP/IP, postavil jsem komunikaci mezi serverem a klientem na TCP/IP soketech. Dal²í otázkou je nutná p°enosová kapacita spojení mezi klientem a serverem. Za p°edpokladu, ºe budeme chtít obnovovat data na klientovi kaºdou jednu vte°inu, musíme být schopni p°enést 112 kB/s histogramických dat. A to je opravdu jen ta nejniº²í teoretická mez, protoºe do této rychlosti nepo£ítám komunika£ní overhead. Podíváme se na dostupné technologie a jejich rychlosti a omezení podrobn¥ji:

- sériová linka Point-To-Point Protocol Standard RS232 pochází jiº z roku 1969 a umoº¬uje sériovou komunikaci dvou za°ízení. V sou£asné dob¥ se zdá, ºe jiº denitivn¥ ustoupilo výkonn¥j²ím sériovým rozhraním (USB). P°enosové rychlosti komunikace po sériové lince záleºí na pouºitém UART obvodu - tedy obvodu starajícího se o p°evod mezi sériovou a paralelní formou p°ená²ených dat. P°ehled rychlostí je vid¥t v tabulce 4.2. V na²em designu pouºíváme UART 16550, jehoº rychlost je nedosta£ující. Moºným °e²ením v

46

KAPITOLA 4.

Standard

Pásmo [GHz]

p·vodní IEEE 802.11 IEEE 802.11a


Max rychlost [Mbit/s]

Rok vydání

2,4

2

1997

5

54

1999

IEEE 802.11b

2,4

11

1999

IEEE 802.11g

2,4

54

2003

IEEE 802.11n

2,4 nebo 5

aº 600

2009

Tabulka 4.3: P°ehled p°enosových rychlostí podle WiFi standardu

p°ípad¥ nutnosti komunikace po sériové lince by mohla být komprimace p°ená²ených dat (pomalé) nebo zv¥t²ení updatovacího intervalu.

-WiFi WiFi je standardem pro lokální bezdrátové sít¥ a vychází z p·vodní specikace IEEE 802.11 z roku 1997. WiFi rozhraní jsou dnes jiº hojn¥ roz²í°eny a najdeme je tém¥° ve v²ech p°enosných po£íta£ích a ve velké v¥t²in¥ moderních mobilních telefon· a smartphon·. P°enosové rychlosti jsou dány standardem podporovaným daným síóvým rozhraním (viz. tabulka 4.3). Z tabulky je patrné, ºe i p·vodní standard IEEE 802.11 dosahuje p°enosové rychlosti 256 kB/s.

-Bluetooth Bluetooth je moderní bezdrátová komunika£ní technologie slouºící k propojení mezi dv¥ma nebo i více za°ízeními. Technologii Bluetooth denuje standard IEEE 802.15.1 z roku 2002. Bluetooth se vyskytuje v za°ízeních v n¥kolika verzích. Stav v roce 2006 byl takový, ºe v¥t²ina za°ízení pouºívala Bluetooth ve verzi 1.2. Tato verze dosahuje p°enosových rychlostí 720 kb/s, tedy 90 kB/s. Prozatím poslední verze, specikace Bluetooth 2.0 EDR (Enhanced Data-Rate), zavádí novou modula£ní techniku pi/4-DQPSK a zvy²uje tak datovou propustnost na trojnásobnou hodnotu oproti Bluetooth 1.2 (2,1 Mbit/s). Moºnost komunikovat pomocí soket· p°es Bluetooth je vázáno na podporu LAP (LAN Access Prole) prolu nebo jeho nástupce PAN (Personal Area Networking) s protokolem BNEP (Bluetooth Network Encapsulation Protocol).

-IrDA IrDA je standard vytvo°ený IrDA konzorciem, který denuje jak bezdrátov¥ p°ená²et digitální data pomoci infra£erveného zá°ení. V sou£asnosti je toto komunika£ní rozhraní vytla£ováno rádiovým p°enosem (Bluetooth) eliminujícím nutnost p°ímé viditelnosti mezi komunikujícími body. IrDA je také velice náchylná na zvý²enou chybovost p°enosu BER p°i rostoucí vzdálenosti a intenzit¥ okolního osv¥tlení.

Serial Infrared (SIR)

- jako sériová linka, max 115 kbit/s

Medium Infrared (MIR) Fast Infrared (FIR)

- 0.576 Mbit/s a 1.152 Mbit/s

- aº 4 Mbit/s

Very Fast Infrared (VFIR) Ultra Fast Infrared (UFIR)

- aº 16 Mbit/s - ve vývoji, p°edpokládaná rychlost aº 100 Mbit/s

Infra£ervená za°ízení mají implementován protokol IrLAN (Infrared Local Area Network), který jim umoº¬uje p°ipojit se k lokální síti bu¤ p°es Access Point nebo p°ímo s jiným za°ízením Point-to-Point.

KAPITOLA 4.


47

4.3.2 Server aplikace Serverová aplikace je klasický jednovláknový server, který vy°izuje poºadavky od klient· postupn¥, jak vznikají. Naslouchá na TCP portu 2468 a £eká na p°ipojení klienta. Po akceptování spojení z jakékoliv adresy, dojde k vytvo°ení soketového spojení. Pokud se reakce serveru doºaduje více klient· naráz, jsou uloºeny do fronty, odkud je postupn¥ server odebírá. Domluva o tom, co klient od serveru poºaduje, se d¥je na základ¥ zpráv, jejichº forma a význam je p°edem domluvený a známý pro ob¥ strany. Jedná se o 4B £ísla, která si server p°e£te ze soketového streamu jako první ihned po vyzvednutí poºadavku z fronty. Podle hodnoty této zprávy provede akci nad na²imi t°emi soubory za°ízení. Akce m·ºe vyºadovat p°e£tení dal²ích dopl¬ujících dat od klienta, nap°. hodnoty pro zápis do registr·, do korek£ní pam¥ti, £íslo ADC kanálu p°i vy£ítání histogramických dat pouze pro jeden kanál atd. Pokud server o£ekává dal²í data a klient mu je neposkytne, spojení s klientem se po vypr²ení timeoutu uzav°e a p°ejde se k obsluze dal²ího poºadavku. Mnoºina zpráv a jejich význam je vid¥t v tabulce 4.4. innost serveru ukazuje následující pseudokód:

int main(){ //vytvo°íme socket if(!CreateSocket()) return -1; //pojmenujeme socket if(!BindSocket()) return -1; //vytvo°íme frontu poºadavk· o kapacit¥ 10 if(!Listen(10)) return -1; do{

//vytáhneme jedno spojení z fronty, pokud neexistuje, server se uspí AcceptClientConnection(); ReadMessage();

switch(message){ case M1: Do1(); break; case M2: Do2(); break; ... } CloseConnection(); }while(1);

}

CloseSocket(); return 0;

Server pob¥ºí na FPGA v pozadí jako systémový daemon ovládaný p°es skript /etc/init.d/daqd.

48

KAPITOLA 4.


Symbolický název (hodnota)

Popis

Za°ízení

WRITE_CORRECTION_MEM (0x11)

Zapí²e hodnoty do korek£ní pam¥ti

/dev/corr

READ_CORRECTION_MEM (0x22)

Vy£te hodnoty z korek£ní pam¥ti

/dev/corr

READ_HISTOGRAMS (0x33)

Vy£te aktuální hodnoty histogram·

/dev/daq

READ_HIST_ONE_CHANNEL (0x34)

Vy£te histogramy pro jeden A/D kanál

/dev/daq

READ_HIST_REGS (0x44)

Vy£te v²echny 4 registry DAQ periferie

/dev/daq

START_DAQ (0x55)

Zahájí £innost DAQ periferie

/dev/daq

STOP_DAQ (0x66)

Ukon£í £innost DAQ periferie

/dev/daq

READ_DCM_REG0 (0x71)

P°e£te registr R0 DCM modulu

/dev/dcm



/dev/dcm



/dev/dcm



/dev/dcm



/dev/dcm



/dev/dcm



/dev/dcm



/dev/dcm



/dev/dcm

READ_DCM_REG9 (0x7A)


/dev/dcm

READ_DCM_REG10 (0x7B)


/dev/dcm

READ_DCM_REG11 (0x7C)


/dev/dcm

READ_DCM_REG12 (0x7D)


/dev/dcm

READ_DCM_REG13 (0x7E)


/dev/dcm

READ_DCM_REG14 (0x7F)


/dev/dcm



/dev/dcm

WRITE_DCM_REG1 (0x81)

Zapí²e do registru R1 DCM modulu

/dev/dcm



/dev/dcm



/dev/dcm



/dev/dcm



/dev/dcm



/dev/dcm



/dev/dcm



/dev/dcm



/dev/dcm

WRITE_DCM_REG10 (0x8A)


/dev/dcm

WRITE_DCM_REG11 (0x8B)


/dev/dcm

WRITE_DCM_REG12 (0x8C)


/dev/dcm

WRITE_DCM_REG13 (0x8D)


/dev/dcm

WRITE_DCM_REG14 (0x8E)


/dev/dcm

WRITE_DCM_REG15 (0x8F)


/dev/dcm

READ_DCM_REGS (0x90)

Vy£te v²ech 16 DCM registr· najednou

/dev/dcm

WRITE_DCM_REGS (0x91)

Zapí²e do registr· R1-R15

/dev/dcm

Tabulka 4.4: Tabulka zpráv pro klient-server komunikaci

KAPITOLA 4.


49

Moºnosti jsou tradi£ní - start, stop, force-reload a restart. Jak tento skript vypadá je vid¥t v p°íloze E.

4.3.3 Klientská PC aplikace Pro otestování modulu, ale i pro ov¥°ení komunikace mezi aplika£ním serverem a uºivatelskou aplikací poºadující data z histogram·, byl vytvo°en klient pro PC. Tento klient umí nejenom zobrazovat nam¥°ené £etnosti výskytu £ástic, ale i nastavovat korek£ní pam¥´ a signály ovládané DCM modulem p°es GUI rozhraní. Klient byl napsán pro platformu .Net 2.0 v jazyce C#. Data jsou zobrazována ve form¥ sloupcových graf· s vyuºitím LGPL komponenty ZedGraph [23]. Architektura klienta byla navrºena s ohledem na op¥tovnou pouºitelnost kódu p°i p°ípadném vývoji klienta pro PDA nebo smartphone. V takovém p°ípad¥ je nutné vym¥nit komponentu pro kreslení graf·, protoºe tato není kompatibilní s .Net Compact Framework 2.0, pouºívaným ve v¥t²in¥ moderních PDA postavených na OS Windows CE a navrhnout vlastní GUI. ást komunikující se serverem je psaná jako samostatný projekt, vznikne tedy samostatná .NET assembly, která se m·ºe k tomuto PDA klentu p°ilinkovat. Funkce klienta by se dali rozd¥lit do t°í £ástí, podle toho, jaké £ásti modulu se týkají (DCM, DAQ, CORR). Vlastní GUI je tvo°eno aplika£ním Windows formulá°em s hlavním menu, tabcontrolem se záloºkami a status li²tou.

Záloºka General: •

Na této záloºce máme moºnost nastavit p°ipojení k aplika£nímu serveru b¥ºícímu na FPGA desce. Pot°ebujeme adresu a port. K ov¥°ení dostupnosti serveru je moºno pouºít tla£ítko Test Server Availability. Navíc si zde zvolíme, zda chceme zobrazovat histogramická data z pam¥ti DAQ modulu nebo chceme pouºít data z generátoru normálního rozloºení. Mezi t¥mito dv¥ma módy se p°epínáme pomocí checkboxu Use Curve Simulator. K implementaci tohoto simulátoru mn¥ vedla skute£nost, ºe nemáme k dispozici skute£né detektory ani A/D p°evodníky z kterých bychom plnili histogramickou pam¥´ DAQ modulu. Tyto data si musíme vymyslet. V HW modulu implementován generátor histogramických záznam·, jehoº moºnosti jsou ov²em zna£n¥ omezené. Nedovoluje nám vygenerovat n¥jaká zajímav¥j²í rozloºení hodnot. Díky tomuto SW generátoru Gaussova rozloºení se dá lépe ov¥°it funk£nost klienta a jeho zobrazování hodnot v grafu. P°i tvorb¥ generátoru jsem vycházel z [16] a aplikoval jsem inverzní kumulativní distribu£ní funkci normálního rozloºení na generátor náhodných £ísel dostupný v .Net frameworku. P°i pouºití generátoru dat se nám zp°ístupní na této záloºce sekce pro nastavení hodnot generované k°ivky pro jednotlivé ADC kanály (výb¥r z comboboxu). Lze nastavit pro generované hodnoty st°ední hodnotu a rozptyl. Nejedná se v²ak o absolutní £ísla. V p°ípad¥ st°ední hodnoty je to £íslo z intervalu <-1;1>, kde 0 znamená st°ed grafu, tedy histogramický kanál 2048 a analogicky -1 levý okraj a 1 pravý okraj grafu. U rozptylu jde o jakýsi percentuální rozptyl, tedy £íslo v intervalu (0;1>. Na náhledu si lze prohlédnout, jak bude k°ivka (rozloºení hodnot v histogramických kanálech) zhruba vypadat a p°ípadn¥ provád¥t zm¥ny, dokud nedosáhneme spokojenosti.

Záloºka DAQ: •

Start a ukon£ení sb¥ru dat Zahájení sbírání dat probíhá zápisem hodnoty 0xAB do kontrolního registru REG1 histogramického modulu. Tuto hodnotu za nás zapí²e server ioctl p°íkazem nad souborem za°ízení /dev/daq. P°ed kaºdým spu²t¥ním sb¥ru dat jsou hlavní i pomocné pam¥ti modulu automaticky hardwarov¥ smazány. Pokud je jiº sb¥r dat zahájen, volání této funkce

50

KAPITOLA 4.


se nikterak neprojevuje, nefunguje tedy jako restart. Pokud chceme modul restartovat, musíme zapsat do registru jakoukoliv hodnotu odli²nou od 0xAB, tím se £innost sb¥ru dat zastaví (pam¥´ z·stává nesmazaná) a poté zápisem 0xAB smazat pam¥´ a spustit sb¥r dat.

•

£tení a zobrazování registr· DAQ modulu REG0 zatím bez vyuºití REG1 kontrolní registr DAQ modulu, slouºí k zastavování a spou²t¥ní sb¥ru dat REG2 status registr DAQ modulu, pouze pro £tení REG3 zatím bez vyuºití Je k dispozici moºnost £íst jednotlivé registry samostatn¥ nebo v²echny najednou (tla£ítko Read All Registers)

•

Double precision Zajímavým roz²í°ením funk£nosti modulu ze strany klienta je Double precision mode, aktivovaný po za²krtnutí stejnojmenného checkboxu. Pam¥´ histogram· v modulu má rozsah 32 bit· na kaºdou poloºku. P°i nejpesimi£t¥j²í situaci, tedy pokud budeme p°i£ítat do n¥jakého histogramického kanálu kaºdý cyklus, dojde k dosaºení hranice maximální £etnosti za cca. 70 minut. V HW je ud¥lána podpora pro saturaci. Nestane se tedy, ºe bychom nam¥°ili výsledky, které by mohly být velice zavád¥jící v p°ípad¥ p°ete£ení. V Double precision módu se sám klient postará o to, aby nedo²lo k saturaci nam¥°ených £etností v£asným resetováním DAQ modulu. P°i tomto resetu p°ijdeme o data za p°ibliºn¥ 20 ms (zji²t¥no empiricky), protoºe takovou dobu trvá zastavit jednotku, vy£íst data z hlavní histogramové jednotky a znovu spustit jednotku. Jedná se o um¥lé softwarové roz²í°ení, pokud by nesta£ily 32-bitové rozsahy sbíraných £etností. Klient, jak jsem °ekl, zapí²e hodnotu 0x11 do povolovacího registru REG1 a tím zastaví sbírání dat, vy£te data z pam¥ti, protoºe v pam¥ti z·stávají do op¥tovného nastartování sb¥ru dat. Po vy£tení zapí²e 0xAB do povolovacího registru REG1, £ímº zajistí op¥tovné nastartování sbírání dat. Po spu²t¥ní sb¥ru dat si vy£tená data klient p°i£te k jiº nasbíraným hodnotám z p°ípadného p°ede²lého cyklu. Hodnoty se ukládají do datového typu double, který je schopný zobrazovat £ísla v intervalu

±5.0 × 10−324

aº

±1.7 × 10308 ,

jak se pí²e v

dokumentaci .NET 2.0 [14].

Záloºka Graph: •

Gracké zobrazení dat Zobrazení nasbíraných dat probíhá ve form¥ sloupcových graf·, které se pravideln¥ p°e-

12 = 4096 hodnot, z nichº kaºdá má

kreslují. Pro kaºdý kanál p°evodníku (je jich 7) jde o 2

32 bit· rozsah. Které kanály se zobrazují, má moºnost uºivatel zvolit za²krtnutím checkboxu p°íslu²ného kanálu v groupboxu Showed Channels. Tímto zp·sobem tak i omezíme mnoºství p°ená²ených dat mezi klientem a serverem, protoºe nezobrazované kanály se neaktualizují. Interval mezi aktualizacemi dat je taktéº uºivatelsky nastavitelný v intervalu v¥t²ím neº 1 sekunda, defaultn¥ je obnova nastavena na 2 s. Protoºe 4096 hodnot je pro b¥ºné rozli²ení p°íli² (a to mluvím pouze o jednou kanálu p°evodníku), m·ºe si uºivatel p°epínat mezi zobrazením v²ech 4096 hodnot, nebo zvolit mód, p°i kterém se vykreslují jen n¥které hodnoty takovým zp·sobem, aby byl graf p°ehledný a celkový vývoj k°ivky grafu z·stal zachován. P°epínání probíhá pomocí checkboxu Full resolution. U kaºdé osy je dvojice tla£ítek umoº¬ující zv¥t²ení a zmen²ení m¥°ítka dané osy. Uºivatel se m·ºe na této záloºce také snadno p°epnout do módu (Oine x Online mód), ve kterém jsou aktualizace dat z modulu pozastaveny (pozastaveno jejich vy£ítání ze serveru, fyzicky

KAPITOLA 4.


51

se sbírají dále) a m·ºe tento stav zkoumat podrobn¥ji, t°eba p°i plném zobrazení v²ech hodnot. V ovládacím panelu na této záloºce najdeme t°i ikony, °íkající v jakém módu pro stisk levého tla£ítka my²i pracujeme. Ikona nalevo zna£í Area zoom, tedy po stisku levého tla£ítka my²i a následném pohybu my²i se vybere oblast grafu, která se po uvoln¥ní tla£ítka my²i zv¥t²í na celý prostor pro graf. Ikona uprost°ed ozna£uje horizontální kurzor, tedy modrou horizontální £áru, která se pohybuje dle pohybu my²i. Obdobn¥ funguje mód pro vertikální kurzor (ikona napravo). Po kliknutí pravým tla£ítkem do okna grafu se objeví kontextové menu nabízející dal²í funkce. Graf lze uloºit do schránky (Copy), uloºit na jiné místo (Save Image As. . . ) nebo rovnou vytisknout (Print. . . ). Poloºka menu Show Point Values povoluje nebo ru²í zobrazování informací o kaºdém sloupci grafu, tedy jeho hodnotu v ose x a y. Poslední poloºkou je Set Scale to Default, která zru²í v²echna aplikovná zv¥t²ení nebo zmen²ení m¥°ítka (tla£ítky + a -) a´ uº pro osu x nebo y.

•

Práce se snapshoty Klientská aplikace podporuje zaznamenání aktuálního stavu modulu do XML souboru. To znamená zaznamenání aktuální sady dat histogram·, hodnot korek£ní pam¥ti a nastavovacích registr· DCM modulu. Pokud má pozd¥ji uºivatel pot°ebu dále data zkoumat, m·ºe si tento snapshot na£íst (v Oine módu) a zobrazit v aplikaci. Tuto funkci je moºno také pouºít k archivaci nam¥°ených dat.

Záloºka Correction: •

Práce s korek£ní pam¥tí Krom¥ zobrazení hodnot korek£ní pam¥ti, jejich úprav¥ a zápisu zp¥t do pam¥ti modulu, podporuje aplikace p°ímý export a import do/ze souboru. Formát souboru je nejjednodu²²í moºný, kaºdý °ádek znamená jednu hodnotu v korek£ní pam¥ti. O£ekává se tedy soubor s 256 °ádky (korekce 8 bit·)

Záloºka DCM: •

Nastavování signál· Záloºka DCM slouºí k práci s DCM modulem starajícím se o signály pro A/D p°evodníky a detektory. Pro kaºdý ze t°í signál· (BIMP, ADC_CLK, CCLK) je naprogramována podpora pro £tení a zápis do kontrolních registr· pro hrubý a jemný posun signál·. I DCM má read-only status registr, podle kterého se dá zjistit aktuální stav DCM a jeho p°ípadné chybové stavy. Pro registry, které se zatím nepouºívají nebyla podpora v GUI naprogramována. Na serveru se ov²em s budoucím vyuºitím po£ítá a je implementováno £tení a zápis do t¥chto registr· REG 7-15.

Ve spodní stavové li²t¥ jsou zobrazovány informace o tom, zda pracujeme v Online nebo Oine módu, informace o dostupnosti serveru a o tom, zda pouºíváme generátor Gaussova rozloºení nebo zda pracujeme s daty z modulu. Uºivatelské nastavení aplikace je uchováváno v kongura£ním souboru v systémovém adresá°i Documents and Settings\AllUsers\AppData\DAQ PC

Client\client.cong. P°i startu se tedy obnoví nastavení aplikace takové, jako bylo p°i posledním uzav°ení. Uchovává se pozice a velikost aplika£ního okna, adresa a port aplika£ního serveru, interval pro obnovu dat, p°íznak zda se pouºívá generátor, p°íznak Online módu, zobrazované kanály, nastavení korek£ní pam¥ti a hodnoty pro nastavení signál· DCM modulu. Za tímto ú£elem byla vytvo°ena vlastní XML kongura£ní sekce DAQPCClientCongSection, která obsahuje dal²í podsekce. Ke v²em poloºkám kongurace se dá pohodln¥ dostat p°es objektové rozhraní aplika£ní kongurace.

52

KAPITOLA 4.


Configuration m_conf = ConfigurationManager.OpenMappedExeConfiguration( fileMap, ConfigurationUserLevel.None); m_hist_section = m_conf.GetSection("DAQPCClientSettings") as DAQPCClientConfigSection; if (m_hist_section == null) { m_hist_section = new DAQPCClientConfigSection(); m_conf.Sections.Add("DAQPCClientSettings", m_hist_section); m_conf.Save(); } Klientská aplikace se distribuuje ve form¥ Microsoft Installer souboru, který zajistí nahrání aplikace do systému a vytvo°ení odkazu v Start menu.

4.4

Testování

Samoz°ejm¥, ºe jako kaºdý kus softwaru, i námi vytvo°ený SW si ºádá ov¥°ení, ºe d¥lá to, co po n¥m poºadujeme. Obraz OS m·ºeme ov¥°it jen a pouze pozorováním. B¥hem práce na jiº hotovém obrazu OS Linux jsem nepozoroval ºádný problém s nestabilitou systému nebo jeho dlouhými odezvami. Co se tý£e fungování ovlada£·, bylo ov¥°eno, ºe nezp·sobují problém p°i instalaci modulu ani p°i jeho odebírání z jádra. Kontrola memory leak· je v kernel modulech mnohem sloºit¥j²í neº v user space aplikacích a nástroje jako Valgrind nelze pouºít. Spokojil jsem se proto s pe£livou kontrolou kódu pro získání a uvol¬ování pam¥ti ve v²ech ovlada£ích. Kontrolu, ºe nám ovlada£e poskytují p°ístup ke správným dat·m, jsem provedl následujícím zp·sobem:

•

Nakonguroval jsem FPGA nahráním HW bitstreamu system.bit p°es utilitu Impact

•

P°ipojil jsem se k PowerPC p°es XMD a nahrál jsem do n¥j p°íkazem dow ná² obraz OS

•

Zastavil jsem DAQ modul p°íkazem mwr 0x7F400004 0x1111 (zápis do REG1 DAQ modulu)

•

Spustil jsem DAQ modul p°íkazem mwr 0x7F400004 0xAB (zápis do REG1 DAQ modulu)

•

Po nasbírání n¥jakých dat jsem periferii op¥t zastavil

•

Vy£etl jsem hodnoty z histogramické pam¥ti modulu do souboru p°íkazem mrd 0x70E00000

28672 > histdump.txt (£tení 28672 4B poloºek od adresy 0x70E00000)

•

Spustil jsem vykonávání instrukcí procesoru p°íkazem run

•

P°ipojil jsem se klientskou aplikací k daqServeru

•

Vy£etl jsem si klientem data taktéº do souboru tak, aby m¥li stejný formát (70E00000: FFFFFFFF)

•

Oba soubory jsem porovnal

KAPITOLA 4.


53

Takto jsem ov¥°il, ºe ovlada£e vy£ítají skute£né hodnoty, které jsou zapsány v histogramové pam¥ti. Postup jsem aplikovaj na korek£ní pam¥´ (navíc ov¥°ení zápisu zapsáním a následným vy£tením odli²ných hodnot, neº jaké HW nastaví po restartu) i jednotlivé registry periférií. Klientská aplikace vyuºívá moºnosti .Net prost°edí na zpracování výjimek. K zaznamenání t¥chto nestandardních stav· a debugovacích hlá²ek pouºívá logovací komponentu log4net [10]. Logovací soubor se nachází v temp adresá°i p°ihlá²eného uºivatele, £ili nej£ast¥ji v Documents

and Settings\<username>\Local Settings\Temp\daq_client_log.txt (záleºí jak máme nastavenou prom¥nnou prost°edí TEMP).

54

KAPITOLA 4.


KAPITOLA 5.

ZÁVR

55

5 Záv¥r Mým úkolem v této diplomové práci bylo navrhnout a implementovat software modulu pro sb¥r a zpracování dat a navrhnout zp·sob komunikace mezi modulem a aplikacemi zpracovávajícími nasbíraná data. Vytvo°il jsem obraz linuxového jádra pro platformu PowerPC 405 s fungujícími periferiemi z designu modulu vzniklého jako výsledek diplomové práce Ing. Mat¥je Machalce [11]. Ukázal jsem n¥kolik strategií, jak se vypo°ádat s umíst¥ním RFS pro embedded systémy. Pro takto fungující jádro jsem vytvo°il t°i kernel moduly koncipované jako ovlada£e znakov¥ orientovaných za°ízení. Byla samoz°ejm¥ ov¥°ena jejich funk£nost porovnáním s p°ímým p°ístupem k adresovým prostor·m modulu p°es XMD. Byl navrºen zp·sob komunikace mezi modulem a vn¥j²ím sv¥tem poºadujícím data. Bylo p°ihlédnuto k mnoha okolnostem a výsledný návrh byl téº implementován a odzkou²en v reálu. Navíc byla vytvo°ena .NET aplikace, která dokáºe nejenom data z modulu vy£íst a zobrazit, ale dokáºe téº modul °ídit a nastavovat, pop°ípad¥ pracovat v reºimu bez spojení s modulem, p°i kterém vyuºívá generátor normálního rozloºení jako zdroj svých histogramických dat. Jak jsem psal jiº v úvodu práce, nebyl pouºit FPGA £ip °ady Virtex4, ale VirtexII Pro. Tato skute£nost nás ov²em nikterak neomezovala a p°echod na vhodnou desku s Virtex4 (musí být °ady FX s embedded procesorem PowerPC a s dostatkem ostatních zdroj· pro implementaci designu - BRAM, distribuovaná pam¥´, DCM jednotky, nap°. XC4VFX140) je otázkou p°egenerování designu v nov¥j²í verzi Xilinx EDK s podporou této desky (ovlada£e pro periferie) a drobných úprav v konguraci jádra. Moºná roz²í°ení nebo pokra£ování této práce spat°uji v p°echodu na linuxové jádro verze 2.6 spolu s p°echodem na desku s FPGA Virtex4 FX. Moºnosti se také nabízí na stran¥ klientské aplikace, kde by stálo za zváºení napsání vlastní komponenty pro zobrazování sloupcových graf·. Ta by se poté vyuºila nejen pro stávající platformu PC, ale také p°i vývoji klienta pro PDA za°ízení. Prací na této diplomové práci jsem si rozhodn¥ roz²í°il znalosti z oblasti opera£ního systému Linux (zejména fungování jádra a ovlada£·), návrhu a p°ístupu k implementaci softwaru i hardwaru pro vestavná za°ízení s OS Linux.

56

KAPITOLA 5.

ZÁVR

KAPITOLA 6.

57

LITERATURA

6 Literatura [1] ABC Linuxu. Webové stránky.

http://www.abclinuxu.cz/. [2] Alessandro Rubini, Jonathan Corbet. Linux Device Drivers. O'Reilly, 2nd edition, 2001. [3] BusyBox. Ociální webové stránky projektu.

http://www.busybox.net. [4] Crosstool. Ociální webové stránky projektu.

http://kegel.com/crosstool. [5] D. Abbott. Linux for Embedded and Real-time Applications, 2003. [6] Daniel P. Bovet, Marco Cesati.

Understanding the Linux Kernel. O'Reilly, 3rd edition,

November 2005. [7] L. A. Edwards.

Migrating from x86 to PowerPC, Part 2: Anatomy of the Linux boot

process. IBM Technical Library, February 2005. [8] Embedded Research Group, University of Washington. Conguring linux for the XUPV2P Development Board, June 2006.

http://www.cs.washington.edu/research/lis/mosaic/xup_ppc_linux.shtml. [9] GNU Projects. Ociální webové stránky.

http://www.gnu.org/. [10] log4net - Logging tool. Ociální webové stránky projektu.

http://logging.apache.org/log4net/. [11] M. Machalec. Hardware modulu pro sb¥r a zpracování dat, 2008. [12] Matthias Kalle Dalheimer, Matt Welsh. Running Linux. O'Reilly, 5rd edition, December 2005. [13] Michael Barr. Programming Embedded Systems in C and C++. O'Reilly, 1st edition, 1999. [14] Microsoft Corporation. .Net 2.0 Documentation.

http://msdn.microsoft.com/en-us/netframework/default.aspx. [15] Microsoft Corporation. FAT: General Overview of On-Disk Format, May 1999.

http://staff.washington.edu/dittrich/misc/FatFormat.pdf. [16] Richard Ulrich. FAQ about Gaussian, July 2001.

http://www.pitt.edu/~wpilib/statfaq/gaussfaq.html. [17] Wikipedia. Ociální webové stránky.

http://en.wikipedia.org/wiki. [18] World Semiconductor Trade Statistics. Ociální webové stránky organizace.

http://www.wsts.org/. [19] Xilinx, Inc. Automatic Generation of Linux 2.4 (Monta Vista Linux 3.1) Board Support Packages, 2006. [20] Xilinx Inc. EDK Documentation, 2006.

58

KAPITOLA 6.

LITERATURA

[21] Xilinx, Inc. OPB IPIF, Product Specication, August 29, 2006. [22] Xilinx, Inc. XUP VirtexIIPro Development System, March 8, 2005. Hardware Reference Manual. [23] ZedGraph. Ociální webové stránky projektu.

http://zedgraph.org.

PÍLOHA A.

SEZNAM POUITÝCH ZKRATEK

A Seznam pouºitých zkratek ABI

Application Binary Interface

ADC API

Analog Digital Converter Application Programming Interface

BER

Bit Error Ratio

BIOS BSP CF

Basic Input Output System

Board Support Package

Compact Flash

CPU

Central Processing Unit

CRC

Cyclic Redundancy Check

DAQ

Data Acquisition

DCM

Digital Clock Management

DHCP DMA

Dynamic Host Conguration Protocol

Direct Memory Access

DSP

Digital Signal Processing

ELF

Executable and Linking Format

EMS

Expanded Memory Specication

FAT

File Allocation Table

FPGA FTP

Field Programmable Gate Array

File Transfer Protocol

GNU

GNU's Not UNIX

GPL

GNU General Public License

GUI

Graphical User Interface

HW

Hardware

IHV

Independent Hardware Vendors

IP

Intellectual Property

IrDA IRQ ISE

Infrared Data Association Interrupt Request

Integrated Software Environment

JTAG

Joint Test Action Group

59

60

PÍLOHA A.

LGPL

GNU Lesser General Public License

MBR

Master Boot Record

MIPS

Million Instructions Per Second

MMU

Memmory Management Unit

NFS

Network File System

OPB OS

SEZNAM POUITÝCH ZKRATEK

On-Chip Peripheral Bus

Operating System

PDA

Personal Digital Assistant

POSIX POST PPC

Portable Operating System Interface Power-On Self Test

PowerPC

PROM RFS

Programmable Read-Only Memory

Root File System

RISC

Reduced Instruction Set Computer

RPC

Remote Procedure Call

RTOS SCSI

Real Time Operating System

Small Computer System Interface

SDRAM SMP SoC SW

Synchronous Dynamic Random Access Memory

Symmetric MultiProcessing System on Chip

Software

SysACE

System ACE Interface Controller

TCP

Transmission Control Protocol

TLB

Translation Look-Aside Buer

UART UDP

Universal Asynchronous Receiver/Transmitter

User Datagram Protocol

USB

Universal Serial Bus

V2P

Virtex2 Pro

VHDL

Very high speed integrated circuit Hardware Description Language

XMD

Xilinx Microprocessor Debugger

XML

eXtensible Markup Language

XUP

Xilinx University Program

PÍLOHA B.

KONFIGURANÍ SOUBOR KOMPILACE JÁDRA LINUXU

B Kongura£ní soubor kompilace jádra Linuxu # # Automatically generated by make menuconfig: don't edit # # CONFIG_UID16 is not set # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_HAVE_DEC_LOCK=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_ADVANCED_OPTIONS=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # Platform support # CONFIG_PPC=y CONFIG_PPC32=y # CONFIG_6xx is not set CONFIG_40x=y # CONFIG_44x is not set # CONFIG_POWER3 is not set # CONFIG_POWER4 is not set # CONFIG_8xx is not set CONFIG_4xx=y # CONFIG_PPC_STD_MMU is not set # CONFIG_ARCTIC2 is not set # CONFIG_ASH is not set # CONFIG_CEDER is not set # CONFIG_BEECH is not set # CONFIG_CPCI405 is not set # CONFIG_EP405 is not set # CONFIG_EVB405EP is not set # CONFIG_OAK is not set # CONFIG_RAINIER is not set # CONFIG_REDWOOD_4 is not set # CONFIG_REDWOOD_5 is not set # CONFIG_REDWOOD_6 is not set # CONFIG_SYCAMORE is not set # CONFIG_TIVO is not set # CONFIG_WALNUT is not set CONFIG_XILINX_ML300=y # CONFIG_ALL_PPC is not set # CONFIG_SMP is not set CONFIG_MATH_EMULATION=y CONFIG_NOT_COHERENT_CACHE=y CONFIG_UART0_TTYS0=y # CONFIG_UART0_TTYS1 is not set # CONFIG_PM is not set CONFIG_EMBEDDEDBOOT=y CONFIG_VIRTEX_II_PRO=y CONFIG_XILINX_OCP=y CONFIG_GEN550=y CONFIG_405=y CONFIG_IBM405_ERR51=y CONFIG_IBM405_ERR77=y # CONFIG_PPC4xx_DMA is not set # CONFIG_OCP_PROC is not set # # General setup

61

62

PÍLOHA B.


# # CONFIG_HIGHMEM is not set # CONFIG_LOWMEM_SIZE_BOOL is not set # CONFIG_KERNEL_START_BOOL is not set # CONFIG_TASK_SIZE_BOOL is not set # CONFIG_PIN_TLB is not set CONFIG_HIGHMEM_START=0xfe000000 CONFIG_LOWMEM_SIZE=0x30000000 CONFIG_KERNEL_START=0xc0000000 CONFIG_TASK_SIZE=0x80000000 # CONFIG_ISA is not set # CONFIG_EISA is not set # CONFIG_SBUS is not set # CONFIG_MCA is not set # CONFIG_PCI is not set # CONFIG_8260_PCI9 is not set # CONFIG_PC_KEYBOARD is not set CONFIG_NET=y CONFIG_SYSCTL=y CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_KCORE_ELF=y CONFIG_BINFMT_ELF=y CONFIG_KERNEL_ELF=y # CONFIG_BINFMT_MISC is not set # CONFIG_OOM_KILLER is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set # # Parallel port support # # CONFIG_PARPORT is not set # CONFIG_GEN_RTC is not set # CONFIG_PPC_RTC is not set CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE="console=ttyS0,115200 root=/dev/xsysace/disc0/part3 rw ip=on" # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Plug and Play configuration # # CONFIG_PNP is not set # CONFIG_ISAPNP is not set # # Block devices # # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_CISS_SCSI_TAPE is not set # CONFIG_CISS_MONITOR_THREAD is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_XILINX_SYSACE=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=8192 CONFIG_BLK_DEV_INITRD=y # CONFIG_BLK_STATS is not set # # Multi-device support (RAID and LVM) #

PÍLOHA B.

# # # # # # # #


CONFIG_MD is not set CONFIG_BLK_DEV_MD is not set CONFIG_MD_LINEAR is not set CONFIG_MD_RAID0 is not set CONFIG_MD_RAID1 is not set CONFIG_MD_RAID5 is not set CONFIG_MD_MULTIPATH is not set CONFIG_BLK_DEV_LVM is not set

# # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set # CONFIG_NETLINK_DEV is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_IP_PNP_BOOTP=y # CONFIG_IP_PNP_RARP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # # # # # # # # # # # # # # # # # # # # # #

SCTP Configuration (EXPERIMENTAL) CONFIG_IP_SCTP is not set CONFIG_ATM is not set CONFIG_VLAN_8021Q is not set CONFIG_IPX is not set CONFIG_ATALK is not set Appletalk devices CONFIG_DEV_APPLETALK is not set CONFIG_DECNET is not set CONFIG_BRIDGE is not set CONFIG_X25 is not set CONFIG_LAPB is not set CONFIG_LLC is not set CONFIG_NET_DIVERT is not set CONFIG_ECONET is not set CONFIG_WAN_ROUTER is not set CONFIG_NET_FASTROUTE is not set CONFIG_NET_HW_FLOWCONTROL is not set

# # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set # # ATA/IDE/MFM/RLL support # # CONFIG_IDE is not set # CONFIG_BLK_DEV_HD is not set

63

64

PÍLOHA B.


# # SCSI support # # CONFIG_SCSI is not set # # # # # # # # # # # # # # # #

Fusion MPT device support CONFIG_FUSION is not set CONFIG_FUSION_BOOT is not set CONFIG_FUSION_ISENSE is not set CONFIG_FUSION_CTL is not set CONFIG_FUSION_LAN is not set I2O device support CONFIG_I2O is not set CONFIG_I2O_BLOCK is not set CONFIG_I2O_LAN is not set CONFIG_I2O_SCSI is not set CONFIG_I2O_PROC is not set

# # Network device support # CONFIG_NETDEVICES=y # # # # # # # # #

ARCnet devices CONFIG_ARCNET is not set CONFIG_DUMMY is not set CONFIG_BONDING is not set CONFIG_EQUALIZER is not set CONFIG_TUN is not set CONFIG_ETHERTAP is not set

# # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_MACE is not set # CONFIG_BMAC is not set # CONFIG_GMAC is not set CONFIG_XILINX_ENET=y # CONFIG_SUNLANCE is not set # CONFIG_SUNBMAC is not set # CONFIG_SUNQE is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_NET_ISA is not set # CONFIG_NET_PCI is not set # CONFIG_NET_POCKET is not set # # # # # # # # # # # # #

Ethernet (1000 Mbit) CONFIG_ACENIC is not set CONFIG_DL2K is not set CONFIG_E1000 is not set CONFIG_MYRI_SBUS is not set CONFIG_NS83820 is not set CONFIG_HAMACHI is not set CONFIG_YELLOWFIN is not set CONFIG_R8169 is not set CONFIG_SK98LIN is not set CONFIG_TIGON3 is not set

PÍLOHA B.


# # Backplane Networking # # CONFIG_NPNET is not set # # # # # # # #

On-chip net devices CONFIG_FDDI is not set CONFIG_HIPPI is not set CONFIG_PLIP is not set CONFIG_PPP is not set CONFIG_SLIP is not set

# # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # # # # # #

Token Ring devices CONFIG_TR is not set CONFIG_NET_FC is not set CONFIG_RCPCI is not set CONFIG_SHAPER is not set

# # Wan interfaces # # CONFIG_WAN is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Console drivers # # # Frame-buffer support # # CONFIG_FB is not set # # # # # # # # #

Input core support CONFIG_INPUT is not set CONFIG_INPUT_KEYBDEV is not set CONFIG_INPUT_MOUSEDEV is not set CONFIG_INPUT_JOYDEV is not set CONFIG_INPUT_EVDEV is not set CONFIG_INPUT_UINPUT is not set

65

66

PÍLOHA B.


# # Macintosh device drivers # # # Character devices # # CONFIG_VT is not set CONFIG_SERIAL=y CONFIG_SERIAL_CONSOLE=y # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set # CONFIG_UNIX98_PTYS is not set # # I2C support # CONFIG_I2C=m # CONFIG_I2C_ALGOBIT is not set # CONFIG_SCx200_ACB is not set # CONFIG_I2C_ALGOPCF is not set # CONFIG_I2C_PPC405_ALGO is not set # CONFIG_I2C_XILINX is not set CONFIG_I2C_CHARDEV=m CONFIG_I2C_PROC=m # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_MOUSE is not set # # # # # # # # # # # # # # # # # # # # # # #

Joysticks CONFIG_INPUT_GAMEPORT is not set CONFIG_QIC02_TAPE is not set CONFIG_IPMI_HANDLER is not set CONFIG_IPMI_PANIC_EVENT is not set CONFIG_IPMI_DEVICE_INTERFACE is not set CONFIG_IPMI_KCS is not set CONFIG_IPMI_WATCHDOG is not set Watchdog Cards CONFIG_WATCHDOG is not set CONFIG_SCx200 is not set CONFIG_SCx200_GPIO is not set CONFIG_AMD_PM768 is not set CONFIG_NVRAM is not set CONFIG_RTC is not set CONFIG_X1226_RTC is not set CONFIG_DTLK is not set CONFIG_R3964 is not set CONFIG_APPLICOM is not set

# # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # # # # # # # # #

Direct Rendering Manager (XFree86 DRI support) CONFIG_DRM is not set CONFIG_XILINX_GPIO is not set CONFIG_XILINX_TS is not set CONFIG_XILINX_UARTLITE is not set CONFIG_XILINX_UARTLITE_CONSOLE is not set CONFIG_XILINX_SPI is not set

PÍLOHA B.


# # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # File systems # # CONFIG_QUOTA is not set # CONFIG_QFMT_V2 is not set CONFIG_AUTOFS_FS=y # CONFIG_AUTOFS4_FS is not set # CONFIG_REISERFS_FS is not set # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BEFS_DEBUG is not set # CONFIG_BFS_FS is not set CONFIG_EXT3_FS=y CONFIG_JBD=y CONFIG_JBD_DEBUG=y CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y # CONFIG_UMSDOS_FS is not set CONFIG_VFAT_FS=y # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_JFFS2_FS is not set # CONFIG_CRAMFS is not set CONFIG_TMPFS=y CONFIG_RAMFS=y # CONFIG_ISO9660_FS is not set # CONFIG_JOLIET is not set # CONFIG_ZISOFS is not set # CONFIG_JFS_FS is not set # CONFIG_JFS_DEBUG is not set # CONFIG_JFS_STATISTICS is not set # CONFIG_MINIX_FS is not set # CONFIG_VXFS_FS is not set CONFIG_NTFS_FS=y # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y CONFIG_DEVFS_FS=y CONFIG_DEVFS_MOUNT=y CONFIG_DEVFS_DEBUG=y # CONFIG_DEVPTS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set # CONFIG_XFS_FS is not set # CONFIG_XFS_QUOTA is not set # CONFIG_XFS_RT is not set # CONFIG_XFS_TRACE is not set # CONFIG_XFS_DEBUG is not set # # Network File Systems # # CONFIG_CODA_FS is not set

67

68

PÍLOHA B.


# CONFIG_INTERMEZZO_FS is not set CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFS_DIRECTIO=y CONFIG_ROOT_NFS=y # CONFIG_NFSD is not set # CONFIG_NFSD_V3 is not set # CONFIG_NFSD_TCP is not set CONFIG_SUNRPC=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y # CONFIG_SMB_FS is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # CONFIG_ZISOFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # CONFIG_SMB_NLS is not set CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-1" # CONFIG_NLS_CODEPAGE_437 is not set # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ISO8859_1=m # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set

PÍLOHA B.


# # Sound # # CONFIG_SOUND is not set # # IBM 4xx options # # # USB support # # CONFIG_USB is not set # # Support for USB gadgets # # CONFIG_USB_GADGET is not set # # Bluetooth support # # CONFIG_BLUEZ is not set # # Cryptographic options # # CONFIG_CRYPTO is not set # # Library routines # # CONFIG_CRC32 is not set CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y # # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set # CONFIG_SERIAL_TEXT_DEBUG is not set CONFIG_LOG_BUF_SHIFT=0

69

70

PÍLOHA B.


PÍLOHA C.

KONFIGURANÍ SOUBOR KOMPILACE BUSYBOXU

C Kongura£ní soubor kompilace BusyBoxu # # Automatically generated make config: don't edit # HAVE_DOT_CONFIG=y # # Busybox Settings # # # General Configuration # # CONFIG_NITPICK is not set # CONFIG_FEATURE_BUFFERS_USE_MALLOC is not set # CONFIG_FEATURE_BUFFERS_GO_ON_STACK is not set # CONFIG_FEATURE_BUFFERS_GO_IN_BSS is not set CONFIG_SHOW_USAGE=y # CONFIG_FEATURE_VERBOSE_USAGE is not set # CONFIG_FEATURE_COMPRESS_USAGE is not set # CONFIG_FEATURE_INSTALLER is not set # CONFIG_LOCALE_SUPPORT is not set CONFIG_GETOPT_LONG=y CONFIG_FEATURE_DEVPTS=y # CONFIG_FEATURE_CLEAN_UP is not set CONFIG_FEATURE_SUID=y # CONFIG_FEATURE_SUID_CONFIG is not set # CONFIG_FEATURE_SUID_CONFIG_QUIET is not set # CONFIG_SELINUX is not set CONFIG_BUSYBOX_EXEC_PATH="/proc/self/exe" # # Build Options # # CONFIG_STATIC is not set # CONFIG_BUILD_LIBBUSYBOX is not set # CONFIG_FEATURE_FULL_LIBBUSYBOX is not set # CONFIG_FEATURE_SHARED_BUSYBOX is not set # CONFIG_LFS is not set USING_CROSS_COMPILER=y CROSS_COMPILER_PREFIX="powerpc-405-linux-gnu-" # CONFIG_BUILD_AT_ONCE is not set # # Debugging Options # # CONFIG_DEBUG is not set # CONFIG_DEBUG_PESSIMIZE is not set # CONFIG_NO_DEBUG_LIB is not set # CONFIG_DMALLOC is not set # CONFIG_EFENCE is not set CONFIG_DEBUG_YANK_SUSv2=y # # Installation Options # # CONFIG_INSTALL_NO_USR is not set CONFIG_INSTALL_APPLET_SYMLINKS=y # CONFIG_INSTALL_APPLET_HARDLINKS is not set # CONFIG_INSTALL_APPLET_DONT is not set PREFIX="/home/misan/xup/RFS" # # Busybox Library Tuning # CONFIG_MD5_SIZE_VS_SPEED=2 # # Applets #

71

72

PÍLOHA C.


# # Archival Utilities # # CONFIG_AR is not set # CONFIG_FEATURE_AR_LONG_FILENAMES is not set # CONFIG_BUNZIP2 is not set # CONFIG_CPIO is not set # CONFIG_DPKG is not set # CONFIG_DPKG_DEB is not set # CONFIG_FEATURE_DPKG_DEB_EXTRACT_ONLY is not set # CONFIG_GUNZIP is not set # CONFIG_FEATURE_GUNZIP_UNCOMPRESS is not set CONFIG_GZIP=y # CONFIG_RPM2CPIO is not set # CONFIG_RPM is not set CONFIG_TAR=y CONFIG_FEATURE_TAR_CREATE=y # CONFIG_FEATURE_TAR_BZIP2 is not set # CONFIG_FEATURE_TAR_LZMA is not set CONFIG_FEATURE_TAR_FROM=y CONFIG_FEATURE_TAR_GZIP=y # CONFIG_FEATURE_TAR_COMPRESS is not set # CONFIG_FEATURE_TAR_OLDGNU_COMPATIBILITY is not set CONFIG_FEATURE_TAR_GNU_EXTENSIONS=y # CONFIG_FEATURE_TAR_LONG_OPTIONS is not set # CONFIG_UNCOMPRESS is not set # CONFIG_UNLZMA is not set # CONFIG_FEATURE_LZMA_FAST is not set CONFIG_UNZIP=y # # # # # # #

Common options for cpio and tar CONFIG_FEATURE_UNARCHIVE_TAPE is not set CONFIG_FEATURE_DEB_TAR_GZ is not set CONFIG_FEATURE_DEB_TAR_BZ2 is not set CONFIG_FEATURE_DEB_TAR_LZMA is not set

# # Coreutils # CONFIG_BASENAME=y # CONFIG_CAL is not set CONFIG_CAT=y # CONFIG_CATV is not set CONFIG_CHGRP=y CONFIG_CHMOD=y CONFIG_CHOWN=y # CONFIG_CHROOT is not set # CONFIG_CKSUM is not set # CONFIG_CMP is not set # CONFIG_COMM is not set CONFIG_CP=y CONFIG_CUT=y # CONFIG_DATE is not set # CONFIG_FEATURE_DATE_ISOFMT is not set CONFIG_DD=y CONFIG_FEATURE_DD_SIGNAL_HANDLING=y CONFIG_FEATURE_DD_IBS_OBS=y # CONFIG_DF is not set CONFIG_DIFF=y CONFIG_FEATURE_DIFF_BINARY=y CONFIG_FEATURE_DIFF_DIR=y # CONFIG_FEATURE_DIFF_MINIMAL is not set # CONFIG_DIRNAME is not set # CONFIG_DOS2UNIX is not set # CONFIG_UNIX2DOS is not set # CONFIG_DU is not set # CONFIG_FEATURE_DU_DEFAULT_BLOCKSIZE_1K is not set CONFIG_ECHO=y CONFIG_FEATURE_FANCY_ECHO=y

PÍLOHA C.


CONFIG_ENV=y # CONFIG_FEATURE_ENV_LONG_OPTIONS is not set # CONFIG_EXPR is not set # CONFIG_EXPR_MATH_SUPPORT_64 is not set CONFIG_FALSE=y # CONFIG_FOLD is not set # CONFIG_HEAD is not set # CONFIG_FEATURE_FANCY_HEAD is not set CONFIG_HOSTID=y CONFIG_ID=y # CONFIG_INSTALL is not set # CONFIG_FEATURE_INSTALL_LONG_OPTIONS is not set CONFIG_LENGTH=y CONFIG_LN=y CONFIG_LOGNAME=y CONFIG_LS=y CONFIG_FEATURE_LS_FILETYPES=y CONFIG_FEATURE_LS_FOLLOWLINKS=y CONFIG_FEATURE_LS_RECURSIVE=y CONFIG_FEATURE_LS_SORTFILES=y CONFIG_FEATURE_LS_TIMESTAMPS=y CONFIG_FEATURE_LS_USERNAME=y CONFIG_FEATURE_LS_COLOR=y CONFIG_FEATURE_LS_COLOR_IS_DEFAULT=y # CONFIG_MD5SUM is not set CONFIG_MKDIR=y # CONFIG_FEATURE_MKDIR_LONG_OPTIONS is not set # CONFIG_MKFIFO is not set CONFIG_MKNOD=y CONFIG_MV=y # CONFIG_FEATURE_MV_LONG_OPTIONS is not set # CONFIG_NICE is not set # CONFIG_NOHUP is not set # CONFIG_OD is not set CONFIG_PRINTENV=y CONFIG_PRINTF=y CONFIG_PWD=y CONFIG_REALPATH=y CONFIG_RM=y CONFIG_RMDIR=y # CONFIG_SEQ is not set # CONFIG_SHA1SUM is not set # CONFIG_SLEEP is not set # CONFIG_FEATURE_FANCY_SLEEP is not set CONFIG_SORT=y CONFIG_FEATURE_SORT_BIG=y # CONFIG_STAT is not set # CONFIG_FEATURE_STAT_FORMAT is not set CONFIG_STTY=y # CONFIG_SUM is not set # CONFIG_SYNC is not set CONFIG_TAIL=y CONFIG_FEATURE_FANCY_TAIL=y # CONFIG_TEE is not set # CONFIG_FEATURE_TEE_USE_BLOCK_IO is not set CONFIG_TEST=y # CONFIG_FEATURE_TEST_64 is not set CONFIG_TOUCH=y # CONFIG_TR is not set # CONFIG_FEATURE_TR_CLASSES is not set # CONFIG_FEATURE_TR_EQUIV is not set CONFIG_TRUE=y CONFIG_TTY=y CONFIG_UNAME=y # CONFIG_UNIQ is not set # CONFIG_USLEEP is not set # CONFIG_UUDECODE is not set # CONFIG_UUENCODE is not set # CONFIG_WATCH is not set # CONFIG_WC is not set CONFIG_WHO=y CONFIG_WHOAMI=y

73

74

PÍLOHA C.


# CONFIG_YES is not set # # Common options for cp and mv # # CONFIG_FEATURE_PRESERVE_HARDLINKS is not set # # Common options for ls, more and telnet # CONFIG_FEATURE_AUTOWIDTH=y # # Common options for df, du, ls # # CONFIG_FEATURE_HUMAN_READABLE is not set # CONFIG_FEATURE_MD5_SHA1_SUM_CHECK is not set # # Console Utilities # # CONFIG_CHVT is not set CONFIG_CLEAR=y # CONFIG_DEALLOCVT is not set # CONFIG_DUMPKMAP is not set # CONFIG_LOADFONT is not set # CONFIG_LOADKMAP is not set # CONFIG_OPENVT is not set # CONFIG_RESET is not set CONFIG_SETCONSOLE=y # CONFIG_FEATURE_SETCONSOLE_LONG_OPTIONS is not set # CONFIG_SETKEYCODES is not set # CONFIG_SETLOGCONS is not set # # Debian Utilities # # CONFIG_MKTEMP is not set # CONFIG_PIPE_PROGRESS is not set # CONFIG_READLINK is not set # CONFIG_FEATURE_READLINK_FOLLOW is not set # CONFIG_RUN_PARTS is not set # CONFIG_FEATURE_RUN_PARTS_LONG_OPTIONS is not set CONFIG_START_STOP_DAEMON=y CONFIG_FEATURE_START_STOP_DAEMON_FANCY=y CONFIG_FEATURE_START_STOP_DAEMON_LONG_OPTIONS=y CONFIG_WHICH=y # # Editors # CONFIG_AWK=y CONFIG_FEATURE_AWK_MATH=y # CONFIG_ED is not set CONFIG_PATCH=y CONFIG_SED=y CONFIG_VI=y CONFIG_FEATURE_VI_COLON=y CONFIG_FEATURE_VI_YANKMARK=y CONFIG_FEATURE_VI_SEARCH=y CONFIG_FEATURE_VI_USE_SIGNALS=y CONFIG_FEATURE_VI_DOT_CMD=y CONFIG_FEATURE_VI_READONLY=y CONFIG_FEATURE_VI_SETOPTS=y CONFIG_FEATURE_VI_SET=y CONFIG_FEATURE_VI_WIN_RESIZE=y CONFIG_FEATURE_VI_OPTIMIZE_CURSOR=y # # Finding Utilities # # CONFIG_FIND is not set

PÍLOHA C.


# CONFIG_FEATURE_FIND_PRINT0 is not set # CONFIG_FEATURE_FIND_MTIME is not set # CONFIG_FEATURE_FIND_MMIN is not set # CONFIG_FEATURE_FIND_PERM is not set # CONFIG_FEATURE_FIND_TYPE is not set # CONFIG_FEATURE_FIND_XDEV is not set # CONFIG_FEATURE_FIND_NEWER is not set # CONFIG_FEATURE_FIND_INUM is not set # CONFIG_FEATURE_FIND_EXEC is not set CONFIG_GREP=y CONFIG_FEATURE_GREP_EGREP_ALIAS=y CONFIG_FEATURE_GREP_FGREP_ALIAS=y CONFIG_FEATURE_GREP_CONTEXT=y # CONFIG_XARGS is not set # CONFIG_FEATURE_XARGS_SUPPORT_CONFIRMATION is not set # CONFIG_FEATURE_XARGS_SUPPORT_QUOTES is not set # CONFIG_FEATURE_XARGS_SUPPORT_TERMOPT is not set # CONFIG_FEATURE_XARGS_SUPPORT_ZERO_TERM is not set # # Init Utilities # CONFIG_INIT=y # CONFIG_DEBUG_INIT is not set CONFIG_FEATURE_USE_INITTAB=y CONFIG_FEATURE_INIT_SCTTY=y CONFIG_FEATURE_EXTRA_QUIET=y # CONFIG_FEATURE_INIT_COREDUMPS is not set CONFIG_FEATURE_INITRD=y CONFIG_HALT=y CONFIG_MESG=y # # Login/Password Management Utilities # CONFIG_FEATURE_SHADOWPASSWDS=y # CONFIG_USE_BB_SHADOW is not set # CONFIG_USE_BB_PWD_GRP is not set CONFIG_ADDGROUP=y CONFIG_DELGROUP=y CONFIG_ADDUSER=y CONFIG_DELUSER=y CONFIG_GETTY=y CONFIG_FEATURE_UTMP=y CONFIG_FEATURE_WTMP=y CONFIG_LOGIN=y # CONFIG_FEATURE_SECURETTY is not set CONFIG_PASSWD=y CONFIG_SU=y # CONFIG_SULOGIN is not set # CONFIG_VLOCK is not set # # Linux Ext2 FS Progs # # CONFIG_CHATTR is not set # CONFIG_E2FSCK is not set CONFIG_FSCK=y # CONFIG_LSATTR is not set # CONFIG_MKE2FS is not set # CONFIG_TUNE2FS is not set # CONFIG_E2LABEL is not set # CONFIG_FINDFS is not set # # Linux Module Utilities # CONFIG_INSMOD=y # CONFIG_FEATURE_INSMOD_VERSION_CHECKING is not set CONFIG_FEATURE_INSMOD_KSYMOOPS_SYMBOLS=y # CONFIG_FEATURE_INSMOD_LOADINKMEM is not set # CONFIG_FEATURE_INSMOD_LOAD_MAP is not set

75

76

PÍLOHA C.


# CONFIG_FEATURE_INSMOD_LOAD_MAP_FULL is not set CONFIG_RMMOD=y CONFIG_LSMOD=y # CONFIG_FEATURE_LSMOD_PRETTY_2_6_OUTPUT is not set CONFIG_MODPROBE=y CONFIG_FEATURE_MODPROBE_MULTIPLE_OPTIONS=y # # Options common to multiple modutils # CONFIG_FEATURE_CHECK_TAINTED_MODULE=y CONFIG_FEATURE_2_4_MODULES=y CONFIG_FEATURE_2_6_MODULES=y # CONFIG_FEATURE_QUERY_MODULE_INTERFACE is not set # # Linux System Utilities # CONFIG_DMESG=y # CONFIG_FBSET is not set # CONFIG_FEATURE_FBSET_FANCY is not set # CONFIG_FEATURE_FBSET_READMODE is not set # CONFIG_FDFLUSH is not set # CONFIG_FDFORMAT is not set # CONFIG_FDISK is not set # FDISK_SUPPORT_LARGE_DISKS is not set # CONFIG_FEATURE_FDISK_WRITABLE is not set # CONFIG_FEATURE_AIX_LABEL is not set # CONFIG_FEATURE_SGI_LABEL is not set # CONFIG_FEATURE_SUN_LABEL is not set # CONFIG_FEATURE_OSF_LABEL is not set # CONFIG_FEATURE_FDISK_ADVANCED is not set # CONFIG_FREERAMDISK is not set # CONFIG_FSCK_MINIX is not set # CONFIG_MKFS_MINIX is not set # CONFIG_FEATURE_MINIX2 is not set # CONFIG_GETOPT is not set # CONFIG_HEXDUMP is not set # CONFIG_HWCLOCK is not set # CONFIG_FEATURE_HWCLOCK_LONG_OPTIONS is not set # CONFIG_FEATURE_HWCLOCK_ADJTIME_FHS is not set # CONFIG_IPCRM is not set # CONFIG_IPCS is not set # CONFIG_LOSETUP is not set # CONFIG_MDEV is not set # CONFIG_FEATURE_MDEV_CONF is not set # CONFIG_FEATURE_MDEV_EXEC is not set # CONFIG_MKSWAP is not set # CONFIG_FEATURE_MKSWAP_V0 is not set CONFIG_MORE=y CONFIG_FEATURE_USE_TERMIOS=y CONFIG_MOUNT=y CONFIG_FEATURE_MOUNT_NFS=y # CONFIG_PIVOT_ROOT is not set # CONFIG_RDATE is not set # CONFIG_READPROFILE is not set # CONFIG_SETARCH is not set CONFIG_SWAPONOFF=y # CONFIG_SWITCH_ROOT is not set CONFIG_UMOUNT=y CONFIG_FEATURE_UMOUNT_ALL=y # # Common options for mount/umount # CONFIG_FEATURE_MOUNT_LOOP=y # CONFIG_FEATURE_MTAB_SUPPORT is not set # # Miscellaneous Utilities # # CONFIG_ADJTIMEX is not set

PÍLOHA C.


# CONFIG_BBCONFIG is not set # CONFIG_CROND is not set # CONFIG_DEBUG_CROND_OPTION is not set # CONFIG_FEATURE_CROND_CALL_SENDMAIL is not set # CONFIG_CRONTAB is not set # CONFIG_DC is not set # CONFIG_DEVFSD is not set # CONFIG_DEVFSD_MODLOAD is not set # CONFIG_DEVFSD_FG_NP is not set # CONFIG_DEVFSD_VERBOSE is not set # CONFIG_FEATURE_DEVFS is not set # CONFIG_EJECT is not set CONFIG_LAST=y CONFIG_LESS=y CONFIG_FEATURE_LESS_BRACKETS=y CONFIG_FEATURE_LESS_FLAGS=y # CONFIG_FEATURE_LESS_FLAGCS is not set # CONFIG_FEATURE_LESS_MARKS is not set # CONFIG_FEATURE_LESS_REGEXP is not set # CONFIG_HDPARM is not set # CONFIG_FEATURE_HDPARM_GET_IDENTITY is not set # CONFIG_FEATURE_HDPARM_HDIO_SCAN_HWIF is not set # CONFIG_FEATURE_HDPARM_HDIO_UNREGISTER_HWIF is not set # CONFIG_FEATURE_HDPARM_HDIO_DRIVE_RESET is not set # CONFIG_FEATURE_HDPARM_HDIO_TRISTATE_HWIF is not set # CONFIG_FEATURE_HDPARM_HDIO_GETSET_DMA is not set # CONFIG_MAKEDEVS is not set # CONFIG_FEATURE_MAKEDEVS_LEAF is not set # CONFIG_FEATURE_MAKEDEVS_TABLE is not set # CONFIG_MOUNTPOINT is not set # CONFIG_MT is not set # CONFIG_RUNLEVEL is not set # CONFIG_RX is not set # CONFIG_STRINGS is not set # CONFIG_SETSID is not set # CONFIG_TASKSET is not set # CONFIG_TIME is not set # CONFIG_WATCHDOG is not set # # Networking Utilities # # CONFIG_FEATURE_IPV6 is not set # CONFIG_ARPING is not set # CONFIG_DNSD is not set # CONFIG_ETHER_WAKE is not set # CONFIG_FAKEIDENTD is not set # CONFIG_FTPGET is not set # CONFIG_FTPPUT is not set # CONFIG_FEATURE_FTPGETPUT_LONG_OPTIONS is not set CONFIG_HOSTNAME=y # CONFIG_HTTPD is not set # CONFIG_FEATURE_HTTPD_WITHOUT_INETD is not set # CONFIG_FEATURE_HTTPD_RELOAD_CONFIG_SIGHUP is not set # CONFIG_FEATURE_HTTPD_SETUID is not set # CONFIG_FEATURE_HTTPD_BASIC_AUTH is not set # CONFIG_FEATURE_HTTPD_AUTH_MD5 is not set # CONFIG_FEATURE_HTTPD_CONFIG_WITH_MIME_TYPES is not set # CONFIG_FEATURE_HTTPD_CGI is not set # CONFIG_FEATURE_HTTPD_CONFIG_WITH_SCRIPT_INTERPR is not set # CONFIG_FEATURE_HTTPD_SET_REMOTE_PORT_TO_ENV is not set # CONFIG_FEATURE_HTTPD_ENCODE_URL_STR is not set CONFIG_IFCONFIG=y CONFIG_FEATURE_IFCONFIG_STATUS=y CONFIG_FEATURE_IFCONFIG_SLIP=y CONFIG_FEATURE_IFCONFIG_MEMSTART_IOADDR_IRQ=y CONFIG_FEATURE_IFCONFIG_HW=y # CONFIG_FEATURE_IFCONFIG_BROADCAST_PLUS is not set # CONFIG_IFUPDOWN is not set # CONFIG_FEATURE_IFUPDOWN_IP is not set # CONFIG_FEATURE_IFUPDOWN_IP_BUILTIN is not set # CONFIG_FEATURE_IFUPDOWN_IPV4 is not set

77

78

PÍLOHA C.


# CONFIG_FEATURE_IFUPDOWN_IPV6 is not set # CONFIG_FEATURE_IFUPDOWN_IPX is not set # CONFIG_FEATURE_IFUPDOWN_MAPPING is not set CONFIG_INETD=y CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_ECHO=y CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_DISCARD=y CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_TIME=y CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_DAYTIME=y CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_CHARGEN=y # CONFIG_FEATURE_INETD_RPC is not set CONFIG_IP=y CONFIG_FEATURE_IP_ADDRESS=y CONFIG_FEATURE_IP_LINK=y CONFIG_FEATURE_IP_ROUTE=y # CONFIG_FEATURE_IP_TUNNEL is not set # CONFIG_FEATURE_IP_SHORT_FORMS is not set # CONFIG_IPADDR is not set # CONFIG_IPLINK is not set # CONFIG_IPROUTE is not set # CONFIG_IPTUNNEL is not set # CONFIG_IPCALC is not set # CONFIG_FEATURE_IPCALC_FANCY is not set # CONFIG_FEATURE_IPCALC_LONG_OPTIONS is not set # CONFIG_NAMEIF is not set # CONFIG_NC is not set # CONFIG_NC_GAPING_SECURITY_HOLE is not set CONFIG_NETSTAT=y # CONFIG_NSLOOKUP is not set CONFIG_PING=y CONFIG_FEATURE_FANCY_PING=y # CONFIG_PING6 is not set # CONFIG_FEATURE_FANCY_PING6 is not set CONFIG_ROUTE=y # CONFIG_TELNET is not set # CONFIG_FEATURE_TELNET_TTYPE is not set # CONFIG_FEATURE_TELNET_AUTOLOGIN is not set # CONFIG_TELNETD is not set # CONFIG_FEATURE_TELNETD_INETD is not set # CONFIG_TFTP is not set # CONFIG_FEATURE_TFTP_GET is not set # CONFIG_FEATURE_TFTP_PUT is not set # CONFIG_FEATURE_TFTP_BLOCKSIZE is not set # CONFIG_DEBUG_TFTP is not set CONFIG_TRACEROUTE=y # CONFIG_FEATURE_TRACEROUTE_VERBOSE is not set # CONFIG_FEATURE_TRACEROUTE_SOURCE_ROUTE is not set # CONFIG_FEATURE_TRACEROUTE_USE_ICMP is not set # # udhcp Server/Client # # CONFIG_APP_UDHCPD is not set CONFIG_APP_UDHCPC=y # CONFIG_APP_DUMPLEASES is not set CONFIG_FEATURE_UDHCP_SYSLOG=y CONFIG_FEATURE_UDHCP_DEBUG=y # CONFIG_VCONFIG is not set CONFIG_WGET=y CONFIG_FEATURE_WGET_STATUSBAR=y CONFIG_FEATURE_WGET_AUTHENTICATION=y # CONFIG_FEATURE_WGET_IP6_LITERAL is not set # CONFIG_FEATURE_WGET_LONG_OPTIONS is not set # CONFIG_ZCIP is not set # # Process Utilities # # CONFIG_FREE is not set # CONFIG_FUSER is not set CONFIG_KILL=y CONFIG_KILLALL=y CONFIG_PIDOF=y

PÍLOHA C.


CONFIG_FEATURE_PIDOF_SINGLE=y CONFIG_FEATURE_PIDOF_OMIT=y CONFIG_PS=y CONFIG_FEATURE_PS_WIDE=y # CONFIG_RENICE is not set # CONFIG_BB_SYSCTL is not set CONFIG_TOP=y CONFIG_FEATURE_TOP_CPU_USAGE_PERCENTAGE=y # CONFIG_UPTIME is not set # # Shells # CONFIG_FEATURE_SH_IS_ASH=y # CONFIG_FEATURE_SH_IS_HUSH is not set # CONFIG_FEATURE_SH_IS_LASH is not set # CONFIG_FEATURE_SH_IS_MSH is not set # CONFIG_FEATURE_SH_IS_NONE is not set CONFIG_ASH=y # # Ash Shell Options # CONFIG_ASH_JOB_CONTROL=y CONFIG_ASH_READ_NCHARS=y CONFIG_ASH_READ_TIMEOUT=y CONFIG_ASH_ALIAS=y CONFIG_ASH_MATH_SUPPORT=y CONFIG_ASH_MATH_SUPPORT_64=y CONFIG_ASH_GETOPTS=y CONFIG_ASH_BUILTIN_ECHO=y CONFIG_ASH_BUILTIN_TEST=y CONFIG_ASH_CMDCMD=y CONFIG_ASH_MAIL=y CONFIG_ASH_OPTIMIZE_FOR_SIZE=y CONFIG_ASH_RANDOM_SUPPORT=y CONFIG_ASH_EXPAND_PRMT=y CONFIG_HUSH=y CONFIG_LASH=y CONFIG_MSH=y # # Bourne Shell Options # # CONFIG_FEATURE_SH_EXTRA_QUIET is not set CONFIG_FEATURE_SH_STANDALONE_SHELL=y CONFIG_FEATURE_COMMAND_EDITING=y CONFIG_FEATURE_COMMAND_EDITING_VI=y CONFIG_FEATURE_COMMAND_HISTORY=15 # CONFIG_FEATURE_COMMAND_SAVEHISTORY is not set CONFIG_FEATURE_COMMAND_TAB_COMPLETION=y CONFIG_FEATURE_COMMAND_USERNAME_COMPLETION=y # CONFIG_FEATURE_SH_FANCY_PROMPT is not set # # System Logging Utilities # CONFIG_SYSLOGD=y CONFIG_FEATURE_ROTATE_LOGFILE=y # CONFIG_FEATURE_REMOTE_LOG is not set # CONFIG_FEATURE_IPC_SYSLOG is not set CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=0 # CONFIG_LOGREAD is not set # CONFIG_FEATURE_LOGREAD_REDUCED_LOCKING is not set CONFIG_KLOGD=y # CONFIG_LOGGER is not set

79

80

PÍLOHA C.


PÍLOHA D.

SKRIPT PRO VYTVOENÍ RFS S BUSYBOXEM

D Skript pro vytvo°ení RFS s BusyBoxem #!/bin/sh # # mkrootfs.sh creates a root filesystem for the # Xilinx XUPV2P embedded Linux kernel. # ##################################################### # DO NOT RUN THIS SCRIPT AS ROOT! IT'S DANGEROUS!! # ##################################################### # Original Author # (C) Wolfgang Klingauf 2003, 2004 [ [email protected] ] # # Re-written for the XUPV2P board with much more capability by # (C) Jonathon W. Donaldson 2006 # # Modified by Michal Navrkal 2008 <[email protected]> # # So what the heck does this script do? # 1) Removes any existing root file system in $RFS location # 2) Creates all directories needed for a usable file system # 3) Compiles BusyBox and stores in RFS # 4) Modifies permissions and ownerships of $RFS # # # Modify variables below to meet your requirements # # cross compiler prefix CC=powerpc-405-linux-gnu # gcc & glibc versions chosen for PPC Linux GCC_VER=gcc-3.4.4 GLIBC_VER=glibc-2.3.3 # embedded linux kernel version PPC_KERNEL_VER=2.4.26 # development directory DEV_DIR=/home/misan/xup # where the root file system should be placed RFS=${DEV_DIR}/RFS # HTTP server root HTTP_ROOT=/var/www/localhost/htdocs # embedded linux kernel sources PPC_KERNEL_SRC=${DEV_DIR}/mvistappc_2_4_devel

81

82

PÍLOHA D.


# location of busybox BUSYBOX=${DEV_DIR}/busybox-1.2.0 # location of *non-prefixed* tool-chain binaries which will be copied to the RFS TARGET_PREFIX=/opt/crosstool/${CC}/${CC} # cross build tools directory BUILD_TOOLS=${DEV_DIR}/crosstool-0.42/build/${CC}/${GCC_VER}-${GLIBC_VER}/${GLIBC_VER} # # DO NOT MODIFY BELOW THIS LINE! # Unless, of course, you know what you're doing. :-) # # Get location of this script and associated files MKROOTFS=`pwd` echo -e "mkrootfs v0.5 - (C) Jonathon W. Donaldson 2006\n" echo "About to build XUPV2P root filesystem in $RFS" echo "...press Enter to proceed or CTRL-C to abort..." read cd ${MKROOTFS} # remove old rootfs, if exist if [ -a ${RFS} ]; then echo "Removing old rootfs located at $RFS..." echo "You may need to enter your sudo password." echo -n "Press Enter to proceed or CTRL-C to abort..." read sudo rm -rf ${RFS} fi # create directories echo "Creating directory structure..." mkdir -p ${RFS}/{bin,boot,dev/{pts,shm},etc/opt,home,lib,mnt,proc} mkdir -p ${RFS}/{root,sbin,tmp,usr/local,var,opt} for dirname in ${RFS}/usr ${RFS}/usr/local do mkdir $dirname/{bin,etc,include,lib,sbin,share,src} ln -s share/{man,doc,info} $dirname mkdir $dirname/share/{dict,doc,info,locale,man} mkdir $dirname/share/{nls,misc,terminfo,zoneinfo} mkdir $dirname/share/man/man{1,2,3,4,5,6,7,8} done mkdir ${RFS}/var/{lock,log,mail,run,spool} mkdir -p ${RFS}/var/{tmp,opt,cache,lib/misc,local} mkdir ${RFS}/opt/{bin,doc,include,info}

PÍLOHA D.

mkdir chmod chmod # for ln -s


83

-p ${RFS}/opt/{lib,man/man{1,2,3,4,5,6,7,8}} 0750 ${RFS}/root 1777 ${RFS}/tmp ${RFS}/var/tmp syslogd /tmp/messages ${RFS}/var/log/messages

# copy glibc echo "Copying glibc..." cd ${TARGET_PREFIX}/lib cp *-*.so ${RFS}/lib cp -d *.so.[*0-9] ${RFS}/lib cp libSegFault.so libmemusage.so libpcprofile.so ${RFS}/lib echo "glibc copied! To reduce the size of installed libraries, use strip /lib/*.so" # Install /etc, this should exist! echo "Installing /etc..." cp -a ${MKROOTFS}/etc ${RFS} # Install /www if [ -a ${MKROOTFS}/www ]; then echo "Installing /www..." mkdir -p ${RFS}${HTTP_ROOT} cp -a ${MKROOTFS}/www/* ${RFS}${HTTP_ROOT} echo "" >> ${RFS}/etc/inetd.conf echo "# The following line was added by 'mkrootfs.sh' for the HTTP server since" >> ${RFS}/etc/inetd.conf echo "# I rely on inetd for httpd functionality. You can change httpd" >> ${RFS}/etc/inetd.conf echo "# to run completely on its own as well. It doesn't really matter." >> ${RFS}/etc/inetd.conf echo "www stream tcp nowait root /usr/sbin/httpd httpd -h ${HTTP_ROOT}" >> ${RFS}/etc/inetd.conf fi # RFS direcotry structure generated echo "Congratulations! Your RFS has been created!" echo echo "Now installing busybox to get a running system..." cd ${BUSYBOX} # Compile BusyBox! echo "Compiling BusyBox..." make dep && make && make install # Compiling Hello World! echo "Compiling the ever-famous 'Hello World!'..." ${CC}-gcc -o ${MKROOTFS}/hello ${MKROOTFS}/hello.c echo "Copying 'Hello World!' binary and source to ${RFS}/root..."

84

PÍLOHA D.


mv ${MKROOTFS}/hello ${RFS}/root cp ${MKROOTFS}/hello.c ${RFS}/root # The following changes must be made to fixe ownership # issues that occur when MontaVista attempts to mount the RFS. # Don't believe me? Comment out these lines and see what # happens when you boot the board! echo "Changing permissions and ownerships of RFS..." echo "You may need to enter your sudo password." chmod 600 ${RFS}/etc/fstab chmod 644 ${RFS}/etc/group chmod 644 ${RFS}/etc/host.conf chmod 600 ${RFS}/etc/hosts chmod 755 ${RFS}/etc/init.d/rcS chmod 755 ${RFS}/etc/init.d chmod 644 ${RFS}/etc/inittab chmod 644 ${RFS}/etc/issue chmod 644 ${RFS}/etc/issue.net chmod 644 ${RFS}/etc/motd chmod 644 ${RFS}/etc/nsswitch.conf chmod 644 ${RFS}/etc/passwd chmod 644 ${RFS}/etc/profile chmod 644 ${RFS}/etc/protocols chmod 777 ${RFS}/etc/resolv.conf chmod 644 ${RFS}/etc/rpc chmod 644 ${RFS}/etc/services chmod 755 ${RFS}/etc/udhcpc chmod 755 ${RFS}/etc/udhcpc/default.script chmod 644 ${RFS}/var/www/localhost/htdocs/* chmod 755 ${RFS}/var/www/localhost/htdocs sudo chown -R root:root ${RFS} # RFS done echo "Your RFS has been built!" # And...We're Done! echo "***SCRIPT COMPLETE***"

PÍLOHA E.

SKRIPT PRO OVLÁDÁNÍ DAQSERVER DAEMONA

E Skript pro ovládání DAQServer daemona #! /bin/sh -e # # daqServer daemon control script # # Author: Michal Navrkal <[email protected]> # FEL CVUT, 2008 # set -e PATH=/bin:/usr/bin:/sbin:/usr/sbin DAEMON=/root/daqServer PID="" test -x $DAEMON || exit 0 case "$1" in start) echo "Starting daq server daemon" #start_daemon $DAEMON /sbin/start-stop-daemon --start --background --exec $DAEMON ;; stop) echo "Stopping daq server daemon" PID=$(ps | grep daqServer | grep -v grep | awk '{print $1}') kill $PID ;; force-reload|restart) $0 stop $0 start ;; *) echo "Usage: /etc/init.d/daqd {start|stop|restart|force-reload}" exit 1 ;; esac exit 0

85

86

PÍLOHA E.

SKRIPT PRO OVLÁDÁNÍ DAQSERVER DAEMONA

PÍLOHA F.

PEHLED DLEITÝCH PÍKAZ PRO XMD

F P°ehled d·leºitých p°íkaz· pro XMD help

Zobrazí nápov¥du pro XMD

connect targets

P°ipojení k procesoru Seznam cílových za°ízení

disconnect dow

Odpojení od procesoru

Nahrání .elf souboru do pam¥ti

run

Start vykonávání programu od po£áte£ní adresy

con

Pokra£ování vykonávání kódu z aktuální pozice

stp

Vykonání ur£itého po£tu instrukcí

rst

Reset procesoru

stop

Zastavení vykonávání programu

rrd

tení registru

rwr

Zápis do registru

mrd

tení obsahu pam¥ti

mwr

Zápis do pam¥ti

bps

Nastavuje sw nebo hw breakpoint

bpr

Ru²í breakpoint

bpl

Seznam breakpoint·

state

Výpis stavu procesoru

P°esn¥j²í popis lze získat aplikací p°íkazu help na zde vypsané p°íkazy.

87

88

PÍLOHA F.

PEHLED DLEITÝCH PÍKAZ PRO XMD

PÍLOHA G.

UIVATELSKÁ / INSTALANÍ PÍRUKA

89

G Uºivatelská / instala£ní p°íru£ka Toolchain Crosstool pro PowerPC: 1. rozbalte \binaries\Crosstool\crosstool_chain.tar.gz do /opt/crosstool 2. nastavte cestu k toolchainu Crosstool do prom¥nné PATH dle kapitoly 4.1.1 Rekompilace Linuxu: 1. rozbalte \source codes\Linux_2_4_devel\linuxppc_2_4_devel.tar.gz nap°. do adresá°e linuxppc 2. v adresá°i linuxppc spus´te make menuconfig a nakonfigurujte si jádro 3. v adresá°i linuxppc spus´te make dep && make zImage 4. v adresá°i linuxppc/arch/ppc/boot/images je image zImage.elf se systémem Spu²t¥ní celého systému: 1. naformátujte CF se t°emi oddíly dle kapitoly 4.1.4a 2. nahrajte \binaries\ace file\system.ace do FAT16 oddílu na CF 3. rozbalte \binaries\RFS\rfs.tar.gz do Linux oddílu na CF 4. zapn¥te desku XUP V2P s konfigurací z CF 5. po boot procesu se nalogujte jako root (bez hesla) 6. daqServer není pot°eba spou²t¥t, jiº pob¥ºí DAQ PC Client: 1. pro po£íta£e s .Net 2.0 (instalátor si zkontroluje jeho p°ítomnost, p°i jeho absenci nabídne moºnost staºení a instalace z internetu) 1. spus´te setup.exe z adresá°e \binaries\DAQ PC Client 2. spus´te program DAQ PC Client pomocí zástupce ve Start menu nebo rovnou z místa instalace

90

PÍLOHA G.

UIVATELSKÁ / INSTALANÍ PÍRUKA

PÍLOHA H.

OBSAH PILOENÉHO CD

H Obsah p°iloºeného CD /design /source codes /BitKeeper /BusyBox /DAQ PC Client /daqServer /Drivers /Linux_2_4_devel /MakeRFS /binaries /ace file /Crosstool /DAQ PC Client /elf file /RFS /text

-- EDK projekt celého systému --------

klient repositá°ového systému zdrojové kódy BusyBoxu zdrojové kódy klienta pro PC zdrojové kódy a makefile serveru zdrojové kódy a makefile v²ech ovlada£· zdrojové kódy pouºitého OS skripty pro vytvo°ení RFS

-------

ACE soubor s obrazem Linuxu a RFS na CF p°eloºený toolchain pro p°eklad pro PowerPC instala£ní soubory klienta pro PC binární soubor s jádrem OS archiv s RFS pro ná² systém pdf a tex formát práce

91

92

PÍLOHA H.

OBSAH PILOENÉHO CD

Software modulu pro sb r a zpracování dat. Bc. Michal Navrkal. ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická

Recommend Documents