Sem vložte zadání Vaší práce.

Transkript

1 Sem vložte zadání Vaší práce.

2

3 České vysoké učení technické v Praze Fakulta informačních technologií Katedra počítačových systémů Diplomová práce Zavaděč a podpůrné prostředky pro výrobu LTE routeru Bc. Jan Kapic Vedoucí práce: Ing. Alexandru Mihnea Moucha 14. května 2012

4

5 Poděkování Rád bych poděkoval firmě 2N Telekomunikace a.s. za umožnění práce na vývoji produktu, jenž je obsahem této práce. Dále Tomáši Květenskému z vývojového týmu skupiny 23 firmy 2N, který usměrňoval mojí práci a pomáhal mi při řešení implementačních problémů. V neposlední řadě děkuji mému vedoucímu Alexi Mouchovi za vedení diplomové práce a zařizování všeho potřebného pro její bezchybný běh.

6

7 Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů. V souladu s ust. 46 odst. 6 tohoto zákona tímto uděluji nevýhradní oprávnění (licenci) k užití této mojí práce, a to včetně všech počítačových programů, jež jsou její součástí či přílohou a veškeré jejich dokumentace (dále souhrnně jen Dílo ), a to všem osobám, které si přejí Dílo užít. Tyto osoby jsou oprávněny Dílo užít jakýmkoli způsobem, který nesnižuje hodnotu Díla a za jakýmkoli účelem (včetně užití k výdělečným účelům). Toto oprávnění je časově, teritoriálně i množstevně neomezené. Každá osoba, která využije výše uvedenou licenci, se však zavazuje udělit ke každému dílu, které vznikne (byť jen zčásti) na základě Díla, úpravou Díla, spojením Díla s jiným dílem, zařazením Díla do díla souborného či zpracováním Díla (včetně překladu), licenci alespoň ve výše uvedeném rozsahu a zároveň zpřístupnit zdrojový kód takového díla alespoň srovnatelným způsobem a ve srovnatelném rozsahu, jako je zpřístupněn zdrojový kód Díla. V Praze dne 14. května

8 České vysoké učení technické v Praze Fakulta informačních technologií c 2012 Jan Kapic. Všechna práva vyhrazena. Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora. Odkaz na tuto práci Jan Kapic. Zavaděč a podpůrné prostředky pro výrobu LTE routeru: Diplomová práce. Praha: ČVUT v Praze, Fakulta informačních technologií, 2012.

9 Abstract The aim of this work is the implementation of bootloader for new LTE version of 2N R EasyRoute router. The work is focused on techniques used in software development for network devices such as router. The work explains the importance of bootloader in a network device. Another important part of this thesis is the presentation of this product production cycle and development of supporting tools. These tools will allow an initial recovery of the router motherboard. Keywords Router, bootloader, board support package (BSP), linux kernel, network file system (NFS), JFFS2 filesystem, TFTP protocol, EEPROM memory, NAND memory, NOR memory, DDR2 memory Abstrakt Tato práce se zabývá realizací zavaděče operačního systému v nové LTE verzi síťového směrovače 2N R EasyRoute. Práce se zaměřuje na techniky, které se používají při návrhu softwarového vybavení směrovačů, a přibližuje čtenáři význam zavaděče v samotném síťovém zařízení. Další důležitou částí této práce bylo představení oživovacího procesu tohoto produktu a navržení podpůrných prostředků pro produkční linku, které umožní prvotní oživení základní desky směrovače. Klíčová slova Směrovač, zavaděč operačního systému, vrstva BSP v zavaděči operačního systému, linuxové jádro, souborový systém NFS, souborový systém JFFS2, protokol TFTP, paměť typu EEPROM, paměť typu NAND, paměť typu NOR, paměť typu DDR2 9

10

11 Obsah Úvod 17 1 Teoretický úvod Embedded zařízení Zavaděč operačního systému Analýza a návrh Nástin vývoje směrovače 2N R SpeedRoute Směrovače 2N R EasyRoute a 2N R SpeedRoute Analýza zavaděče Easyboot ve směrovači 2N Easyroute Vývojový kit a SDK firmy Mindspeed Zavaděč Das U-boot Oživovací proces směrovače 2N R SpeedRoute Cíl práce a návrh řešení Realizace Realizace zavaděče operačního systému Realizace podpůrných nástrojů pro produkční linku Problémy při realizaci v průběhu celého vývoje Výsledky a testování Testování realizovaných částí implementace Zhodnocení implementace hlavního zavaděče Zhodnocení implementace inicializačního EEPROM zavaděče Zhodnocení realizace emulátoru I 2 C EEPROM paměti Nastínění dalšího vývoje a možných vylepšení Závěr 121 Literatura 123 A Seznam použitých zkratek 125 B Obsah přiloženého CD

12 C Report z oživovacího a expedičního procesu

13 Seznam obrázků 1.1 Rozdíl v bootloaderu osobního počítače a embedded zařízením Nástin vývoje programového vybavení pro směrovač 2N R SpeedRoute Router 2N R SpeedRoute (nalevo) a 2N R EasyRoute (napravo) Případová studie číslo 1 - předplacený Wi-Fi Hot Spot Případová studie číslo 2 - záložní připojení Případová studie číslo 3 - náhrada ADSL Případová studie číslo 4 - záložní router Grafické znázornění rozdělení logických oddílů Start zavaděče Easyboot Ukázka komunikace klient server protokolem Caller Struktura zprávy Caller boot response a Caller boot request Vývojový kit 83xxx-HWG-001-A firmy Mindspeed Blokový diagram procesoru řady Comcerto Blokový diagram vývojového kitu 83xxx-HWG-001-A Struktura souboru uimage Start zavaděče Das U-boot Ukázka stanoviště, na kterém probíhá oživovací test Ukázka fixtury pro základní desku směrovače 2N R EasyRoute Ukázka stanoviště, na kterém probíhá expediční test směrovače 2N R EasyRoute Návrh mapování GMAC PHY ethernetového switche (2) Scénáře způsobu oživení směrovače 2N R SpeedRoute Princip použití emulátoru I 2 C EEPROM paměti Analýza komunikace mezi procesorem a I 2 C EEPROM pamětí Mapa příkazu er pro primární zavaděč U-boot Ukázka spuštění služby Caller přes smyčku NetLoop Průchod funkcí CallerTimeout() Znázornění důležitých funkcí při inicializaci switche AR8328N Struktura hlavičky zavaděče ISB Mapa příkazu er pro incializační EEPROM zavaděč Schématické zapojení emulátoru sériové I 2 C EEPROM paměti Prototyp emulátoru sériové I 2 C EEPROM paměti

14 3.9 Navázání komunikace mezi procesorem a I 2 C EEPROM pamětí Zachycení komunikace klient server pomocí protokolu Caller

15 Seznam tabulek 1.1 Srovnání vlastností vybraných zavaděčů (10) Srovnání směrovačů 2N R EasyRoute a 2N R SpeedRoute Popis základních komponent operačního systému Organizace paměťového prostoru ve směrovači 2N R EasyRoute Seznam nejdůležitějších proměnných z ENVx a jejich význam Seznam příkazů bootloaderu Easyboot Parametry příkazové řádky linuxového jádra Význam jednotlivých částí zpráv protokolu Caller Základní set příkazů zavaděče U-boot Seznam důležitých proměnných zavaděče Das U-boot Parametry příkazové řádky linuxového jádra zavaděče U-boot Ukázka několika definic z konfiguračního souboru desky c1kevm Srovnání zavaděčů Das U-boot a Easyboot Organizace paměťového prostoru ve směrovači 2N R SpeedRoute Minimální požadavky na inicializační EEPROM zavaděč Instrukční set inicializačního EEPROM zavaděče Přehled funkcí finální verze inicializačního EEPROM zavaděče

16

17 Úvod Cílem této diplomové práce bylo seznámení s novou verzí síťového směrovače 2N R EasyRoute. Nová verze produktu s názvem 2N R SpeedRoute obsahuje oproti svému předchůdci několik zlepšení a změn, které se citelně podepsali na samotném vývoji programového vybavení směrovače. Tato práce se zaměřuje na tu část programového vybavení, která je důležitá při samotném startu směrovače. Touto částí je zavaděč operačního systému. Bylo třeba nastudovat tvorbu zavaděče pro tento typ vestavěného systému a navrhnout řešení, které poskytne plnou zpětnou kompatibilitu k zavedeným konvencím a funkcím zavaděče ve staré verzi produktu. Zadání této práce bylo stanoveno tak, aby pokrylo nejen potřeby chodu samotného zařízení, ale i tak, aby umožnilo co nejefektivnější a nejrychlejší prvotní oživení směrovače na produkční lince. Body zadání tedy z větší části přímo kopírují potřeby oživovacího procesu výrobku, který se taktéž v práci snažím zachytit. První část práce obsahuje teoretický úvod do problematiky embedded systémů. Popisuje základní techniky návrhu softwarového vybavení pro tyto systémy a představuje síťový směrovač jako vestavěné zařízení. Následuje obecný popis zavaděče operačního systému a krátký přehled zavaděčů v embedded systémech. Rozbor oživovacího procesu a existujícího řešení zavaděče poskytne kapitola analýza a návrh řešení. Stejná kapitola se poté snaží navrhnout možné způsoby realizace bodů, jenž vyplynuly ze samotné analýzy. Kapitola realizace se zaměřuje na popis implementace jednotlivých bodů návrhu a zhodnocení chyb, které se běhěm realizace objevily. Poslední kapitola obsahuje popis, jakým se jednotlivé části implementace testovaly. Dále se kapitola věnuje zhodnocení výsledků realizace a natínění dalších možných cest vývoje. Na počátku této práce neexistoval žádný prototyp základní desky směrovače. Vývoj základní desky začal ve stejné době jako vývoj programového vybavení. To ovlivnilo průběh a tempo celého vývoje. Problémy, které jsem řešil v průběhu vývoje jsou popsány v samostatné kapitole 3.3. Dále během vývoje nebylo jasné, jak se nový směrovač bude jmenovat. Jméno tohoto směrovače dostalo za úkol vymyslet marketingové oddělení firmy 2N. Vymyšlení jména 2N R SpeedRoute trvalo měsíc a bylo během posledního týdne třikrát změněno. 17

18

19 Kapitola 1 Teoretický úvod Tato kapitola se zabývá teoretickým úvodem do problematiky vestavěných systémů. Kategorizuje síťový směrovač a nastiňuje techniky vývoje softwarových prostředků pro tato zařízení. Další část této kapitoly vysvětluje pojem zavaděč operačního systému, jehož implementace je jedním z cílů této práce. Povaha a rozsah práce nedovoluje jít v teorii příliš do hloubky. Probrány jsou pouze pojmy, které s prací úzce souvisí a to pouze v rozsahu, který čtenáři umožní lehký nadhled nad konkrétním tématem. 1.1 Embedded zařízení Embedded zařízení či vestavěný systém je jednoúčelový systém, který má za úkol plnit předem definovanou činnost. Řídící počítač je zabudován přímo do zařízení, které ovládá. Oproti osobnímu počítači chybí univerzálnost systému. Vzhledem k tomu, že je vestavěný systém určen pro konkrétní účel, mohou tvůrci systému při návrhu optimalizovat systém pro konkrétní aplikaci a tím snižovat cenu výrobku. Vestavěné systémy jsou často vyráběny sériově ve velkém množství, takže úspora bývá znásobena velkým počtem vyrobených kusů. S rozvojem mikroprocesorů a řídících jednotek se hranice mezi zařízeními a osobními počítači stírá. V současnosti se můžeme potkat s embedded systémem na každém kroku od smartphonů přes bankomaty, tiskárny a mnoho dalších. Jeden z příkladů embedded systému je právě i síťový směrovač. Dále se zaměříme na velice důležitý aspekt embedded systémů a to spolehlivost Spolehlivost embedded systému U embedded systému se často počítá s tím, že zařízení bude fungovat bez chyb nepřetržitě několik let, případně vyskytne-li se chyba, dokáží se z této chyby zotavit. Proto je software pro tyto systémy vyvíjen a testován daleko pečlivěji než na klasických počítači. Při návrhu embedded systému se počítá i s mechanickou chybou, tzn. že se vynechávají prvky náchylné na mechanické 19

20 1. Teoretický úvod poškození jako například harddisky, přepínače či tlačítka. Hezkým příkladem je nahrazení klasického harddisku pamětí bez pohyblivých částí např. SSD disk. Definice spolehlivosti embedded systémů 1. Systém nelze kvůli opravě bezpečně vypnout nebo je pro opravu nepřístupný. Obecně se toto týká testovacích podsystémů vestavěných systémů a přepínačů na síti. Místo hardwarové náhrady lze použít softwarový záložní režim, který poskytuje částečnou funkčnost. Příklady: systémy ve vesmíru, podmořské kabely, navigační majáky, systémy pro vrtání děr a automobily 2. Systém musí být neustále v chodu z bezpečnostních důvodů. Parametry jsou podobné jako u předešlého typu, ale záložní softwarové režimy nejsou v takové míře tolerovány. Příklady: řídicí systémy jaderných reaktorů, řízení nebezpečných provozů v chemických továrnách, železniční zabezpečovací zařízení, řízení motorů u jednomotorových letadel 3. Zastavení systému způsobí velké finanční ztráty. Tyto systémy obvykle obsahují několik vestavěných testů indikujících správný chod systému a existuje on-line záložní systém nebo záložní softwarový režim a ruční ovládání. Příklady: telefonní ústředny, řízení továren, ovládání mostů a výtahů, řízení bezhotovostních převodů peněz a elektronická tržiště 4. Systém nemůže běžet v nebezpečném nebo nekorektním stavu. Při běhu v nebezpečném nebo nekorektním stavu by došlo k velkým finančním ztrátám nebo ohrožení zdraví. Při detekci nebezpečného stavu je jediným řešením ukončit chod systému a indikovat chybu. Příklady: lékařské přístroje, zálohované letecké přístroje a stroje (například motor u vícemotorových letadel), automatické burzy K zajištění spolehlivosti se používá několik mechanismů a technik, které se navzájem kombinují. Uvedu základní. Watchdog timer je jednoduchý čítač, který se periodicky nuluje běžícím softwarem v systému, pokud nedošlo k vynulování, watchdog systém restartuje. Další technikou je redundantní paměťový prostor, do kterého se zařízení může přepnout v případě, že původní byl poškozen. Oblíbený je také tzn. "kulhavý mód", který v případě chyby poskytne, alespoň omezenou funkci zařízení. Dále pak vývoj nad Trusted Base architekturou (TCB), která zajistí vysokou spolehlivost a bezpečí prostředí systému. Komplexnější může být vestavěný dohledový systém, který dokáže bezpečně enkapsulovat každou komponentu systému tak, aby byla odstíněná od komponent ostatních. To nám zajistí nemožnost propagace chyb z jednoho subsystému do subsystému druhého. 20

21 1.1. Embedded zařízení Návrh softwarového vybavení pro embedded systém Jak už jsem zmínil, typů vestavěných systému je velmi mnoho. V každém systému je kladen důraz na něco jiného, ne jenom na cenu. Některé systémy pracují v reálném čase, protože zpoždění činnosti nebo akce ovládané řídícím procesorem může mít fatální důsledky. Většinou se jedná o zařízení, použité v kritických systémech jako je doprava. V těchto případech je vývoj veden s největší přesností a opatrností viz sekce 1.1.1, na druhou stranu máme systémy, kde je důležitá rychlost vývoje, komplexnost a modularita pro budoucí rozšíření systému. Software určený pro vestavěné systémy je často označován jako firmware a je uložen v čipech ROM nebo Flash na rozdíl od programů v osobním počítači, které jsou uloženy na pevném disku. Tento software často počítá s omezenými prostředky zařízení malá nebo žádná klávesnice, omezený nebo žádný displej, malé množství paměti RAM a podobně Architektury návrhu V embedded systému se setkáme s několika architekturami návrhu: Simple control loop - jednoduchá kontrolní smyčka Jedná se o nejjednodušší formu návrhu. Software obsahuje jednoduchou smyčku, ve které cyklí a volá podprogramy, které obstarávají určité funkce softwaru či obsluhují hardware. Interrupt controlled system - systém řízen přerušením Často jsou embedded systémy řízeny přerušením. To znamená, že úloha systému je spuštěna na podnět některé z událostí, která vyvolá přerušení. Přerušení může být generováno interně (např. čítače procesoru s předdefinovanou frekvencí) či externě (např. příjmem bajtu přes sériovou linku). Tyto typy systémů jsou použity v případě, pokud jsou obslužné rutiny krátké, jednoduché a vyžadují nízkou latenci. Často tento typ systémů obsahuje taktéž hlavní smyčku, ve které můžeme volat jednotlivé rutiny, ty však musí počítat s nečekaným přerušením. Pokud obsluha přerušení trvá delší dobu, můžeme tuto událost zaznamenat a vykonat jí později v hlavní smyčce. S trochou nadsázky poté můžeme říct, že se jedná o jednoduchý multitasking s diskrétními procesy. Cooperative multitasking - kooperativní multitasking Systém nepreemptivního multitaskingu je velice podobný systému s jednoduchou kontrolní smyčkou, až na to, že smyčka je schovaná v API. Programátor definuje sérii úloh, kde každá úloha má svoje vlastní prostředí, ve kterém běží. Když je úloha nečinná tzn. ve stavu idle, zavolá se idle rutina, většinou nazvaná pause, wait, yield, nop apod. Výhody a nevýhody jsou stejné jako u jednoduché kontrolní smyčky, až na to, že v tomto případě je rozšiřování systémů daleko jednodušší. 21

22 1. Teoretický úvod 22 Preemptive multitasking (multi-threading) - preemptivní multitasking Tento typ architektury obsahuje kousek nízkoúrovňového kódu, který přepíná mezi úlohami či vlákny na základě přerušení od časovače. U tohoto systému můžeme říci, že obsahuje "jádro"operačního systému. Systém je komplexní v závislosti na tom, kolik funkcionality je potřeba. Protože se systém naoko chová jako paralelní, je nutné, aby kód pro vykonání úlohy byl napsán a testován velice pečlivě (toto se nevztahuje na systémy s MMU jednotkou), mohlo by totiž dojít k tomu, že jedna úloha poškodí data úloze druhé. Dále musí dodržet mechanismy výlučného přístupu ke sdílené proměnné jako semafory, systém front, nebo neblokující synchronizační schéma. Mikro jádro Mikro jádro je druh jádra operačního systému, které je velmi malé a obsahuje jen nejzákladnější funkce, tzn. správu paměti a podporu pro plánování procesů a mezi procesové komunikace. Tím se minimalizuje objem běžícího kódu v privilegovaném režimu. Ostatní potřebné části jádra jsou řešeny v uživatelském prostoru jako běžné procesy: ( u mikrojader se označují servery ) správa souborového systému ovladače zařízení podpora protokolů pro počítačové sítě a další. Mezi zástupce systémů s mikrojádrem patří MINIX (od verze 3), PikeOS, QNX a Symbian OS. Opakem mikrojádra je monolitické jádro, kompromisem pak hybridní jádro. Monolitické jádro Monolitické jádro je druh jádra operačního systému, jehož veškerý kód běží ve stejném paměťovém prostoru (kernel space). V tomto případě mluvíme o velkých jádrech, které jsou portována pro potřeby vestavěných zařízení. To dává programátorovi prostředí podobná tomu, která zná z operačních systému typu Linux nebo Microsoft Windows. Z toho plynou výhody i nevýhody jeho nasazení. Velkou výhodou je produktivita v oblasti vývoje. Mezi nevýhody patří cena zařízení, která se odvíjí od vyšších hardwarových nároků systému, a menší spolehlivost, za kterou může robustnost a složitost jádra. Příkladem monolitických jader v embedded zařízeních je embedded Linux a Windows CE. Obliba monolitických jader stoupá, využívají se především v síťových zařízeních typu síťových směrovačů, GPS zařízeních a podobně. Mezi hlavní důvody popularity monolitických jader patří:

23 1.2. Zavaděč operačního systému Porty na jednotlivé počítačové architektury jsou již často dostupné. Možnost využití volně šiřitelných zdrojových kódů ovladačů, webových serverů a podobného softwaru. Modularita tohoto řešení zajistí snadné rozšiřování stávajícího systému o další funkcionality, stejně tak jako ořezání nepotřebné Kategorizace síťového směrovače Tato sekce představuje základní set typů vestavěných systémů a jeho vlastností. Síťový směrovač je jedním z typů embedded systémů. Je to prvek, který nutně nepotřebuje rychle reagovat na podněty z okolí, tzn. nevyžaduje realtime operační systém. Naopak je vyžadována komplexnost systému a jeho modularita. Produkty 2N R SpeedRoute a jeho předchůdce 2N R EasyRoute jsou zástupci těchto vestavěných systémů. Trend poslední doby, kdy se jde cestou, která slibuje rychlejší vývoj aplikací za cenu vyšších nároků na hardwarové vybavení zařízení, proniká i do oblasti embedded systémů. 1.2 Zavaděč operačního systému Tato sekce se zabývá teoretickým úvodem do zavaděčů operačních systémů. Zavaděč operačního systému neboli bootloader je označení pro počítačový program, který je typicky napsaný v jazyce symbolických adres. Účelem každého zavaděče je nakopírování hlavního programu 1, který je větší, do operační paměti. Dále pak jeho aktivace 2 ve formě předání řízení počítače. Často je bootloader uložen na okraji paměťového prostoru např. MBR v klasických počítačích, či offset 0x0 paměti NOR flash v embedded systémech. Mezi další obecné vlastnosti zavaděčů patří předávání určitých parametrů zaváděnému programu. Záměrně je zde použito slovní spojení obecné vlastnosti, protože v dalších ohledech se zavaděče pro různá zařízení často liší Rozdíl mezi zavaděčem v embedded systému a klasickém počítači Pod pojmem zavaděč operačního systému se většinou automaticky předpokládá jeho nasazení v klasickém počítači. Zde se definuje zavaděč jako počítačový program, který je spuštěn po provedení POST testů BIOSu. BIOS na základní desce plní několik úkolů, hlavním je však inicializace a konfigurace připojených hardwarových zařízení. POST testy, které provádí BIOS mají za úkol otestovat hardware v zařízení. Důvod, proč se toto zmiňuje, je ten, že v embedded zařízeních většinou žádný BIOS není, stejně tak POST 1 Zaváděný program bývá ve většině případů jádro operačního systému 2 Odskok na entry point programu. 23

24 1. Teoretický úvod testy nejsou záležitostí samozřejmou. Zavaděč v embedded zařízeních bývá často daleko primitivnější, než zavaděč v klasickém počítači. Někdy tomu je tak zcela záměrně, a to hlavně kvůli omezenému paměťovému prostoru. Na obrázku je vidět rozdíl ve skladbě zavaděče osobního počítače a embedded zařízením. I když se nejedná o pravidlo, obecně je možné říct, že zavaděč v embedded zařízení obstarává i tu část funkcionality, jakou obstarává BIOS v počítači osobním. Obrázek 1.1: Rozdíl v bootloaderu osobního počítače a embedded zařízením Úkol zavaděče v embedded zařízení Jak již bylo zmíněno, zavaděč v embedded zařízení nemá na starost pouze zavedení operačního systému, ale i samotnou inicializaci zařízení. Úkoly zavaděče v embedded zařízení jsou uvedeny níže. Inicializace Baterie testů POST Zavedení operačního systému Inicializace Inicializace je proces, který nastaví především procesor a často také paměť RAM 3, do které se po inicializaci zavaděč relokuje. Inicializace samotného procesoru zahrnuje nastavení fázových závěsů, různých druhů keší, přerušení, I/O sběrnic, vstupních a výstupních pinů. 3 Linuxové jádro se o nastavení paměti RAM vůbec nestará, proto se inicializace této paměti stává nutností. 24

25 1.2. Zavaděč operačního systému Baterie testů POST Tyto diagnostické testy mají za úkol zkontrolování funkčnosti zinicializovaného systému. V případě, že z nějakého důvodu některý z testů selže, je start systému přerušen a na chybu se reaguje, např. vstupem do obnovovacího režimu. Jedním ze základních testů často bývá otestování paměti RAM Zavedení operačního systému Zaváděn může být jakýkoliv program, zde se ale bude brát v potaz pouze jediný, a tím je jádro operačního systému. Jádro operačního systému je nedílnou součástí operačního systému. Jeho hlavní úkol spočívá v přidělovaní paměti a času procesoru ostatním programům. Dále se stará o ovládání periferních zařízení a poskytuje uživateli jednotné API pro práci s různým hardwarem. Při startu operačního systému jádro často potřebuje od zavaděče několik informací. Zavaděč mu tyto informace předává pomocí parametrů v textové podobě v tzv. kernel boot command-line. Mezi parametry najdeme např. to jaké nastavení sériové linky se má použít pro kontakt s uživatelem, nebo to, kde má jádro hledat svůj kořenový souborový systém (root filesystem). Tyto parametry nejsou nutností. Jádro je může mít nakonfigurovány přímo v sobě. Pro zavedení jakéhokoliv programu je potřeba nahrát zaváděný program do operační paměti (RAM) a provést skok na bod vstupu tzv. entry point tohoto programu, tím se předá řízení zaváděnému programu. Často se ještě před zavedením jádra vypínají přerušení, dále vyplachují a vypínají instrukční a datové keše (pokud je procesor obsahuje) Srovnání zavaděčů operačního systému V tabulce 1.1 najdeme srovnání nejznámějších zavaděčů operačních systémů. Výčet funkcí všech zavaděčů je mimo možnosti rozumného zobrazení. Uvedeny jsou pouze hlavní funkce zavaděčů. 25

26 1. Teoretický úvod Name Advanced command GRUB Legacy Scriptable Supported architecture Supported filesystem Yes No i386(pc) FAT16, FAT32, MI- NIX fs, ext2fs, ReiserFS, GRUB 2 Yes Yes i386(pc, coreboot, OLPC, Mac), PowerPC(Mac, Pegasos II),... RedBoot yes yes (boot ARM, ColdFire, x86, only) MIPS, PPC,... Das U-Boot Yes Yes PPC, ARM, Barebox Yes Yes ARM, AVR32, ColdFire, m68k, MicroBlaze, x86,... Blackfin, NIOS2, MIPS, x86, PPC JFS,... ext2, ext3, ext4, btrfs, zfs, ufs, ntfs, FAT16, FAT32... Supported OS FreeBSD, NetBSD, OpenBSD, GNU/Linux Linux(PC, mac), FreeBSD(pc), OpenBSD(pc), NetBSD(pc) Supported executable Supported protocol ELF TFTP gzip?? gzip JFFS2 Linux, ecos ELF TFTP, serial (Xmodem) FAT, VFAT, ext2, ext3, JFFS2, ReiserFS, nfs... FAT, VFAT, cramfs, nfs FreeBSD, Linux, LynxOS, OpenBSD, QNX, Solaris, VXworks,... ELF, U-Boot image format TFTP, NFS, serial Linux? TFTP, NFS, serial Supported decompression gzip bzip2, gzip, lzma bzip2, gzip, lzma Tabulka 1.1: Srovnání vlastností vybraných zavaděčů (10) 26

27 Kapitola 2 Analýza a návrh Tato kapitola je spíše rešeršního rázu. Zabývá se teoretickou přípravou pro následnou implementaci jednotlivých bodů zadání a je nezbytná pro pochopení této práce jako celku. Je rozdělena na tři hlavní části. První část představuje produkty 2N R EasyRoute a 2N R SpeedRoute. Obsahuje srovnání jejich hardwarových parametrů a popisuje jejich programové vybavení. Dále se snaží analyzovat stávající řešení zavaděče ze starého produktu 2N R EasyRoute, které mělo být referencí pro vývoj zavaděče v produktu novém. Následuje představení vývojového kitu, na kterém v počátcích vývoj probíhal. Součástí vývojového kitu bylo i SDK, které v mnohém vývoj programového vybavení urychlilo. V této části najdeme prvky z SDK, ze kterých se při implementaci softwarového vybavení směrovače vycházelo, a které byly při vývoji použity. V druhé části je popsán oživovací proces směrovače 2N R EasyRoute, ze kterého vyplývá nutnost použití jednotlivých podpůrných prostředků pro expediční linku. Třetí část v bodech shrne záměry z této práce a nastíní implementaci jednotlivých bodů zadání. 27

28 2. Analýza a návrh 2.1 Nástin vývoje směrovače 2N R SpeedRoute Tato sekce v krocích nastíní budoucnost toho, jak se bude postupovat v samotném vývoji směrovače 2N R SpeedRoute a to jak po stránce softwarového vybavení, tak po stránce vývoje hardwaru. To je důležité hlavně pro pochopení významu vývojového kitu ve vývojovém cyklu tohoto produktu. Jednotlivé fáze vývoje vidíme na obrázku 2.1. Jedná se pouze o vývojové vlákno zaměřené na téma této práce. Paralelně s tímto běžela vlákna další, která se zaměřovala na vývoj jádra operačního systému. Obrázek 2.1: Nástin vývoje programového vybavení pro směrovač 2N R SpeedRoute První část je čistě analytická a zajímá se o stávající řešení implementované ve směrovači 2N R EasyRoute. Následuje seznámení s vývojovým kitem a jeho SDK, ve kterém bude předmětem zájmu především zavaděč Das U-boot. Po analýze zavaděče Das U-boot následuje samotný vývoj zavaděče pro směrovač 2N R SpeedRoute, který v počátcích probíhá na zmíněném vývojovém kitu. Dalším z kroků je přechod na prototyp zavaděče 2N R SpeedRoute, kdy se zavaděč přizpůsobí první verzi základní desky směrovače 2N R SpeedRoute. V této fázi je nutné vyladit chyby a dodělat v novém zavaděči prvky, které nemohly být implementovány na vývojovém kitu. Po odladění zavaděče na prototypu základní desky, se vývoj ubírá k nástrojům produkční linky směrovače. Tyto nástroje slouží k tomu, aby bylo možné provést prvotní oživení nového směrovače. Na konci tohoto vývojového cyklu jsou jednotlivé části otestovány a nasazeny na produkční lince. 28

29 2.2. Směrovače 2N R EasyRoute a 2N R SpeedRoute 2.2 Směrovače 2N R EasyRoute a 2N R SpeedRoute Zařízení 2N R EasyRoute je bezdrátový 3G router představující cenově dostupnou a spolehlivou alternativu k ADSL připojení. Je ideálním řešením pro menší firmy nebo společnosti s pobočkami, které se z jakýchkoli důvodů chtějí zbavit závislosti na pevných linkách. Zařízení 2N R SpeedRoute vychází z již existujícího konceptu zařízení 2N R EasyRoute. Nový produkt 2N R SpeedRoute má přinést zlepšení v oblasti výkonu a rychlosti připojení jak v sítích mobilních, tak sítích počítačových. Popis nejdůležitějších hardwarových komponent bude uveden níže. Obrázek 2.2: Router 2N R SpeedRoute (nalevo) a 2N R EasyRoute (napravo) Základní přehled funkcí směrovačů 2N R EasyRoute a 2N R SpeedRoute Pro tuto práci není kompletní výčet funkcí směrovačů potřebný. Uvedu 4 případové studie, které demonstrují použití těchto směrovačů v praxi. Předvedou vlastnosti, které odlišují směrovače 2N R EasyRoute a 2N R SpeedRoute od směrovačů jiných. Tyto materiály byly převzaty z (1) Předplacený Wi-Fi Hot Spot Předplacený Wi-Fi Hot Spot nabízí jednoduchý způsob jak zpoplatnit internetové připojení uživatelů a přehledný jednoduchý účtovací systém. K Wi-Fi Hot Spotu může být současně připojeno cca 30 uživatelů. 2N R EasyRoute dále poskytuje hlasové volání a fax, pokud je třeba. Toto použití je graficky znázorněno na obrázku

30 2. Analýza a návrh Obrázek 2.3: Případová studie číslo 1 - předplacený Wi-Fi Hot Spot Záložní připojení 2N R EasyRoute umožňuje vytvořit aktivní záložní připojení prostřednictvím sítě UMTS ke stávajícímu připojení (ADSL, kabelové připojení, Wi-Fi apod.). V případě, že dojde k poruše primárního připojení, 2N R EasyRoute automaticky přesměruje data do 3G sítě. Jakmile je spojení obnoveno, data jsou opět směrována přes primární připojení. Toto použití je graficky znázorněno na obrázku 2.4 Obrázek 2.4: Případová studie číslo 2 - záložní připojení 30

31 2.2. Směrovače 2N R EasyRoute a 2N R SpeedRoute Náhrada ADSL 2N R EasyRoute je kompletní komunikační řešení pro společnosti, které nemají přístup k internetovému připojení pomocí ADSL. Prostřednictvím sítě UMTS zajišťuje datové připojení, telefonní a faxové hovory. To znamená, bez jakýchkoli kabelů. K zařízení můžete připojit analogový telefon nebo fax a až 4 počítače přes LAN, přes Wi-Fi až 246 zařízení. Toto použití je graficky znázorněno na obrázku 2.5 Obrázek 2.5: Případová studie číslo 3 - náhrada ADSL Záložní router 2N R EasyRoute je připojen k primárnímu routeru jako záloha. V případě, že u primárního routeru dojde k výpadku, 2N R EasyRoute okamžitě vytvoří záložní připojení prostřednictvím UMTS. Toto automatické připojení je zajištěno díky protokolu VRRP. Toto použití je graficky znázorněno na obrázku Hardwarový profil 2N R EasyRoute a 2N R SpeedRoute V tabulce 2.1 najdeme srovnání klíčových komponent obou směrovačů. Hlavní změnou oproti starému návrhu je jiná architektura procesoru. Starý procesor ADM 5120 firmy Infineon je založen na architektuře MIPS. Dvoujádrový procesor M83241G firmy Mindspeed v produktu 2N R SpeedRoute má jádro typu 31

32 2. Analýza a návrh Obrázek 2.6: Případová studie číslo 4 - záložní router ARM 1136J. Další velkou změnou je zdvojnásobení kapacity paměti RAM. K tomu je použita paměť typu DDR2, která je daleko rychlejší, a kterou zmíněný procesor podporuje. K navýšení na dvojnásobek kapacity došlo i u paměti NAND flash. V neposlední řadě následují síťové prvky. Do nového směrovače je zabudován gigabitový ethernetový switch, síťová Wi-Fi karta podporující standard n s chipsetem ath9k a nový LTE modul MC7710 firmy Sierra, který umožní připojení routeru v sítích LTE. 2N Easyroute 2N Speedroute Komponenta Procesor ADM 5120 M83241G RAM 64 MB SDRAM 128 MB DRR2 NOR Flash 512 kb 512 kb NAND Flash 64 MB 128 MB Ethernet switch v procesoru (built in) AR8328N Wi-Fi PCI modul NEO-611 (802.11abg) DNXA-116 (802.11abgn) Sierra modul MC8795V MC7710 Tabulka 2.1: Srovnání klíčových komponent směrovačů 2N R EasyRoute a 2N R SpeedRoute 32

33 2.2. Směrovače 2N R EasyRoute a 2N R SpeedRoute Programové vybavení směrovače 2N R EasyRoute Ve směrovači 2N R EasyRoute je použit operační systém Linux, přesněji verze, která se nejvíce podobá distribuci OpenWrt. OpenWrt je speciální linuxová distribuce určena pro široké spektrum směrovačů. Jedná se o operační systém, který svojí funkcionalitou dohání operační systémy plnohodnotných linuxových serverů. Obsahuje vlastní balíčkovací systém Opkg, který je derivátem balíčkovacího Ipkg systému Openmoko. Operační systém ve směrovači 2N R EasyRoute se oficiální distribuci OpenWrt opravdu pouze podobá. Obsahuje upravené linuxové jádro, vlastní organizaci kořenového souborového systému a upravené vanilkové verze programů, které v operačním systému fungují. Odlehčený webový server s podporou CGI skriptů zajišťuje přístup k uživatelskému rozhraní sloužící ke konfiguraci směrovače. Uživatelské rozhraní je psáno kompletně v jazyce C++, důvodem je objektový přístup tohoto programovacího jazyka. Princip návrhu uživatelského rozhraní je podobný webovým server aplikacím v jazyce Java, kdy je aplikace rozdělena na část funkční (Servlet) a část frontendu (JSP stránka). Pro tyto účely byl navržen zvláštní tagovací jazyk připomínající právě JSP (Java Server Pages). V tabulce 2.2 jsou poznámky k hlavním rysům operačního systému. Komponenta Verze Poznámka Jádro systému Linux Linux kernel release Modifikovaná verze jádra upravená přesně pro potřeby zařízení 2N R EasyRoute Použitý souborový systém JFFS2 Speciální souborový systém specializovaný na paměti typu Flash. Příkazová řádka busybox Busybox je příkazový procesor, který má v sobě vestavěné implementace mnoha standardních unixových příkazů. Webový server thttpd-2.25b Webový server thttpd je jednoduchý, lehce přenositelný a rychlý HTTP server. Zpracování rozhraní uživatelského Frontend uživatelského rozhraní je kompletně napsán v jazyce C++. S webovým servervem se komunikuje pomocí CGI skriptů. Tabulka 2.2: Popis základních komponent operačního systému 33

34 2. Analýza a návrh Charakteristické vlastnosti operačního systému směrovače z pohledu embedded systémů Za hojné nasazování systému Linux v embedded systémech může samotná filozofie (9) tohoto operačního systému. Za jeho rozšíření může míra abstrakce, která se v linuxovém jádru používá. Pro přeportování systému na jiné zařízení stačí mít vhodný kompilátor na cílovou architekturu procesoru a napsat tzv. BSP (Board Support Package), který obsahuje nastavení specifické přímo pro dané zařízení. Níže si ukážeme prvky operačního systému Linux, které jsou pro embedded systémy typické. Memory Technology Devices (MTD) jednou z ukázek abstrakce systému Linux je použití mtd zařízení. Tato technika se používá v embedded systémech na úrovni souborového systému. Ve zkratce můžeme říct, že zařízení mtd umožňuje jednotný přístup k různým druhům pamětí Flash. Tuto abstrakci nám umožní vrstva Flash Translation Layer (FTL), která tyto paměťová zařízení prezentuje jako zařízení bloková. Zařízení jsou vytvořena jádrem v kořenovém souborovém systému, přesněji ve složce /dev. Souborový systém JFFS2 (Journalling Flash File System version 2) je speciální souborový systém specializovaný na paměti typu Flash. Ty mají běžně omezený počet zápisů, proto se snaží zapisovat rovnoměrně na celou plochu paměťového prostoru. Soubory se nemažou, pouze se přidávají novější verze, a v případě, že dojde k zaplnění jednotky, zde funguje garbage collector, který uvolní nepoužívané místo a data uspořádá. Veškeré operace se žurnálují, takže je odolný proti výpadkům napájení. Nevýhodou těchto souborových systémů je pomalý zápis. Démon ER Démon ER běží na pozadí operačního systému a zaštiťuje veškeré operace spojené s potřebami směrovače. Spouštění tohoto programu provádí init skript, který spouští jádro operačního systému při startu operačního systému. Je to rodičovský proces pro téměř všechny služby (unity), které směrovač poskytuje. Tento démon umí fungovat ve dvou módech. normal je mód, který je výchozí pro běh směrovače v normálním provozu. tester je mód, který je použit pro testování v oživovacím procesu. V módu tester se uživateli po zavedení jádra otevře jednoduchá příkazová řádka. Ta se stejně jako zavaděč ovládá přes sériovou linku. Pomocí tohoto módu je možné manipulovat s obsahem oddílu LICENCE (2.2.4), spouštět testy na jednotlivé komponenty hardwaru apod. Je s ním také spojené nahrávání firmwaru do flash pamětí a to jak zavaděče (NOR), tak i operačního systému (NAND). Více o použití tohoto démonu v módu tester najdeme v sekci

35 2.2. Směrovače 2N R EasyRoute a 2N R SpeedRoute Operační systém není předmětem této práce, avšak obsahuje části, které je nutné zahrnout i do návrhu zavaděče. Jsou to především části, které se týkají rozvržení paměťového prostoru, umístění jádra operačního systému, parametrů, které se předávají při zavádění jádra a systému vnitřních proměnných routeru. Dále bude následovat vysvětlení těchto částí Organizace paměťového prostoru ve směrovači 2N R EasyRoute Níže je v tabulce 2.3 vidět rozdělení paměťového prostoru směrovače na jednotlivá mtd zařízení. Směrovač obsahuje dva typy flash pamětí. Menší paralelní paměť typu NOR, která je rychlejší a svým náhodným přístupem k datům vyhovuje potřebám spouštění kódu, je použita k bootování. Druhá flash paměť typu NAND je větší a obsahuje jádra systému, kořenové souborové systémy a oddíl APP. Z důvodu toho, že se zde pracuje s pamětí typu flash, je možný počet zapisovacích cyklů paměti omezen, proto je APP jediným oddílem, který je přimontován s povolením zápisu. Důvod zdvojení oddílů ENVx, KERNELx a ROOTx vysvětlí sekce Oddíl APP slouží k uložení: Konfigurace směrovače Adres DHCP klientů Tiketů Wi-Fi hotspotu Historie volání Uložení SMS zpráv Velikost oddílu Název oddílu Zařízení mtd Typ paměti 256 kb BOOTLOADER mtd0 64 kb ENV0 mtd1 64 kb ENV1 mtd2 128 kb LICENCE mtd3 8 MB KERNEL0 mtd4 8 MB KERNEL1 mtd5 16 MB ROOT0 mtd6 16 MB ROOT1 mtd7 16 MB APP mtd8 NOR NAND Tabulka 2.3: Organizace paměťového prostoru ve směrovači 2N R EasyRoute 35

36 2. Analýza a návrh Systém vnitřních proměnných a licence Směrovač 2N R EasyRoute obsahuje vlastní sadu proměnných. Jedná se o oddíly ENV0 a ENV1. Dále pak obsahuje oddíl LICENCE, který bude vysvětlen na konci této sekce. Proměnné ENV0 a ENV1 slouží k uchování informací, které se používají především při zavádění linuxového jádra. Obsahují adresy umístění kořenového souborového systému a linuxového jádra (adresy KERNELx a ROOTx), dále pak jejich kontrolní součty (CRC). Tyto parametry pomáhají zavaděči operačního systému sestavit příkazovou řádku jádra operačního systému 4. O sestavení příkazové řádky jádra a způsobech bootování pojednává sekce Oddíl LICENCE je specifický tím, že se v paměti nevyskytuje v otevřené formě, ale je zašifrován pomocí šifry RC4. Obsahuje sériové číslo produktu, které mu je přiděleno při oživovacím procesu, seznam MAC adres síťových rozhraní a IMEI GSM modulu. Tento oddíl se při startu dešifruje a přečte se z něj sériové číslo, které je důležité v dalším běhu zavaděče viz Název proměnné Význam proměnné version verze firmwaru time timestamp vytvoření firmwaru kernel_loc adresa umístění jádra kernel_size velikost jádra kernel_crc kontrolní součet jádra kernel_base adresa na kterou bude jádro nakopírováno kernel_entry adresa vstupu, místo kam se při zavádění jádra skočí root_loc adresa umístění kořenového souborového systému root_size velikost kořenového souborového systému root_crc kontrolní součet kořenového souborového systému root_dev parametr pro příkazovou řádku jádra. Říká jádru jaký mtd oddíl má přimontovat jako kořenový souborový systém root_type určuje typ souborového systému (nfs, jffs2) serial sériové číslo, které se kopíruje z oddílu LICENCE seq sekvenční číslo, které nám říká to, jaký oddíl je právě aktuální state stavy firmware Tabulka 2.4: Seznam nejdůležitějších proměnných z ENVx a jejich význam Střídání paměťových oddílů Střídání paměťových oddílů je známá technika ke zvýšení spolehlivosti, používaná v embedded systémech. Jeden z oddílů slouží vždy jako záložní. V routeru 2N R EasyRoute jsou vždy spárované oddíly se stejným koncovým číslem. Například pokud se při zavádění jádra nepodaří načíst oddíl KERNEL1, nebo 4 Kernel boot command-line 36

37 2.3. Analýza zavaděče Easyboot ve směrovači 2N Easyroute nesedí jeho CRC, je tento oddíl přeskočen a zkouší se oddíl druhý. Graficky znázornění logických oddílů najdeme na obrázku 2.7. Obrázek 2.7: Grafické znázornění rozdělení logických oddílů Oddíly KERNELx a ROOTx obsahují firmware směrovače. Při prvním nahrávání firmwaru do směrovače se naplňují oba logické oddíly. To znamená. že se logické oddíly zrcadlí. Informaci o tom, jaký logický oddíl je aktivní uchovává proměnná seq (2.4). Aktivní oddíl je ten s největším sekvenčním číslem. Při dalším nahrání firmwaru uživatelem se zapisuje do oddílu s nižším sekvenčním číslem. Tento postup je algoritmicky vysvětlen v sekci Dalším prvkem pro zvýšení spolehlivosti je redundantní zápis do paměťového oddílů ENVx. Každá sada proměnných je uložena v paměťovém oddílu dvakrát. Pokud se nepodaří přečíst proměnné z prvního umístění (např. nesedí CRC), čtou se proměnné z umístění druhého. 2.3 Analýza zavaděče Easyboot ve směrovači 2N Easyroute Zde se přiblížíme k jednomu z bodů této práce, kterou je samotná analýza zavaděče operačního systému ve směrovači 2N R EasyRoute. V tomto směrovači je použit zavaděč s názvem Easyboot. Nejedná se o zavaděč všeobecně známý. Název Easyboot vznikl pouze pro interní účely firmy 2N. V úplném po- 37

38 2. Analýza a návrh čátku vývojového cyklu směrovače 2N R EasyRoute se vývoj tohoto produktu urychlil použitím vývojového kitu a dodaného SDK firmy Mikrotik tak, aby vývoj hardwaru směrovače mohl probíhat současně s vývojem programového vybavení. Zavaděč Easyboot je tedy modifikovanou verzí bootloaderu z SDK dodaného firmou Mikrotik. Tato sekce má za úkol analyzovat důležité vlastnosti zavaděče, které bude třeba implementovat v novém zavaděči směrovače 2N R SpeedRoute Přehled funkcí zavaděče Easyboot Zavaděč obsahuje několik klíčových vlastností týkající se uživatelského prostředí, síťového subsystému a práce s pamětí. Předností tohoto zavaděče je velikost výsledného spustitelného souboru. Mezi tyto vlastnosti patří: jednoduchá příkazová řádka (CLI) možnost zavedení operačního systému z paměti typu NAND možnost zavedení operačního systému přes síťový protokol TFTP aktualizace zavaděče ve flash paměti NOR přes protokol xmodem Uživatelské prostředí je velice jednoduché. Popis CLI a seznam příkazů najdeme v sekci Mezi primární úkoly zavaděče patří zavedení operačního systému (OS). Tento zavaděč dokáže zavést OS jak z flash paměti NAND, tak pomocí síťového protokolu TFTP. Poslední užitečnou funkcí je aktualizace zavaděče v paměti NOR flash pomocí sériové linky, přesněji pomocí protokolu xmodem Význam zavaděče Easyboot ve směrovači 2N R EasyRoute Teorii ohledně zavaděčů operačních systémů vysvětluje sekce 1.2, dále vysvětluje i základní rysy zavaděče operačního systému. Jak už víme, zavaděč operačního systému v embedded zařízení plní dva 5 primární úkoly. Inicializace Zavedení operačního systému K tomuto se přidávají další vlastnosti a funkce, které často umožňují práci s externími periferiemi jako např. paměť, displej, či ethernetový switch. Následně bude rozebrána inicializace a zavádění operačního systému směrovače 5 POST testy zde neuvažuji. Jednoduché testování RAM při startu zahrnuje inicializace. 38

39 2.3. Analýza zavaděče Easyboot ve směrovači 2N Easyroute Easyboot Inicializace směrovače 2N R EasyRoute Inicializace se skládá ze dvou částí. V první řadě se jedná o nízkoúrovňovou inicializaci. Tato inicializace má za úkol připravit základní nutné podmínky pro běh zavaděče. Nízkoúrovňová inicializace v zavaděči Easyboot zahrnuje: nastavení fázových závěsů procesoru nastavení datových a instrukčních keší procesoru nastavení přerušení procesoru nastavení vstupních a výstupních pinů procesoru nastavení paměti SDRAM 6 V druhé řadě se jedná o inicializaci, která se stará o nastavení okolních zařízení jako jsou ethernetové switche, flash paměti apod. Tato inicializace se provádí, až pokud je jí skutečně potřeba (Lazy Initialization). Například nemá smysl nastavovat ethernetový switch, pokud se v průběhu zavádění operačního systému nebude používat. Mezi tyto inicializace se řadí : vyčištění datového segmentu.bss nastavení sériové linky nastavení prostředí pro práci s pamětí NAND flash nastavení dynamické alokace paměti (heap) detekce paměti NOR flash inicializace ethernetového switche 7 6 Tato paměť je využita při zavádění operačního systému. 7 Provádí se kvůli protokolu Caller ( ). 39

40 2. Analýza a návrh Způsoby zavádění operačního systému Linux ve směrovači 2N R EasyRoute Zavést operační systém znamená, nahrát jádro operačního systému (OS) do operační paměti a provést skok na správné místo v nahraném programu. Zavaděč Easyboot dokáže zavést systém dvěma možnými způsoby. načtením jádra OS z flash paměti NAND (oddíly KERNELx) načtením jádra OS systému ze sítě pomocí protokolu TFTP První možnost je výchozí a využívá se pokaždé, když bude směrovač startovat a nebude proveden zásah ze strany uživatele. Zásahem je myšlen vstup do CLI zavaděče zadáním přístupového kódu přes sériovou linku. Paměť NAND je určena pro běžný uživatelský firmware. Jádro operačního systému se čte z oddílů KERNEL0 a KERNEL1. Po zavedení jádra operačního systému tímto způsobem, si jádro operačního systému mapuje svůj kořenový souborový systém z jednoho z oddílů ROOTx. Oddíly jsou spárované (2.7) tzn., že oddílu KER- NEL0 náleží kořenový souborový systém ROOT0. Oba oddíly jsou umístěny na flash paměti NAND (2.3). Druhá možnost, tedy zavádění systému pomocí protokolu TFTP se používá především při vývoji programového vybavení, testování a oživení základní desky směrovače. V tomto případě se jádro operačního systému stáhne ze síťového úložiště pomocí protokolu TFTP. Po zavedení tímto způsobem si jádro operačního systému namapuje svůj kořenový souborový systém pomocí NFS. Je třeba rozlišit samotný způsob načítání jádra operačního systému a jeho další běh. To, že je v tomto případě zavádění jádra operačního systému ze sítě (TFTP) svázáno s mapováním kořenového souborového systému přes NFS, je jen otázkou návrhu zavaděče Easyboot, Další chování jádra operačního systému ovlivňuje zavaděč operačního systému pomocí parametrů, které předává jádru jako řetězec v tzv. kernel boot command-line. Tato příkazová řádka jádra pro oba zmíněné způsoby je vysvětlena v sekci Start zavaděče Easyboot Na obrázku níže 2.8 vidíme algoritmus, jakým zavaděč Easyboot startuje. Popis jednotlivých stavů Board Init je inicializace zavaděče viz Reset button probe je test stisknutí tlačítka reset směrovače. viz TCP/IP Stack Init je inicializace síťového subsystému. Check the waiting time je testování prodlevy delay_time. Tedy doby, kdy má uživatel šanci zadat přístupový kód a vstoupit tak do CLI zavaděče Easyboot. Pokud měřený čas přesáhne hodnotu delay_time, je zaveden operační systém z flash paměti NAND. 40

41 2.3. Analýza zavaděče Easyboot ve směrovači 2N Easyroute Load char to buffer & test it for the access code je proces, kdy se do bufferu načítají stisknuté klávesy. Pokud posloupnost stisknutých kláves odpovídá přístupovému kódu, je uživatel vpuštěn do CLI zavaděče Easyboot. Listen for Caller packets je test na to, jestli nepřišel paket protokolu Caller. Pokud ano a paket obsahuje licenční číslo daného směrovače, zavede se jádro OS pomocí protokolu TFTP. Protokolu Caller se věnuje sekce Obrázek 2.8: Start zavaděče Easyboot Uživatelské rozhraní zavaděče Easyboot Příkazová řádka či CLI (Command-line interface) zavaděče Easyboot je jediný způsob, jakým lze bootloader ovládat. Příkazová řádka je chráněná přístupovým kódem a přistupuje se k ní pomocí sériové linky ( UART ). Ukázka CLI se nachází na obrázku níže. Zde je vidět i jednoduchost příkazové řádky. 41

42 2. Analýza a návrh S/ N: ABCDEFGH Press key... [ u] Update Bootloader [ e] Print Environment [ c] Print Config [ n] Boot from NAND [ t] Boot from TFTP [ m] Select Model [ p] Select Profile [0-9] Select Station Ukázka příkazové řádky zavaděče Easyboot Seznam příkazů V tabulce níže je kompletní výčet příkazů zavaděče Easyboot. Klávesa Název příkazu Význam příkazu [ u ] Update Bootloader Provede update stávajícího zavaděče v paměti pomocí protokolu [ e ] Print Environment Vytiskne obsah paměťových oddílů ENVx [ c ] Print Config Vytiskne stávající konfiguraci danou parametry Model, Profile a Station [ n ] Boot from NAND Nabootuje operační systém z prostoru Flash paměti NAND [ t ] Boot from TFTP Stáhne Linuxové jádro ze serveru TFTP a následně nabootuje z NFS [ m ] Select Model Vybere model směrovače z množiny modelů [ p ] Select Profile Vybere profil směrovače z množiny profilů [ 0 9 ] Select Station Nastaví číslo stanice Tabulka 2.5: Seznam příkazů bootloaderu Easyboot Specifické vlastnosti zavaděče Easyboot Zavaděč Easyboot obsahuje několik specifických vlastností, které je dobré zmínit. Jedná se o vlastnosti, které bude třeba implementovat v zavaděči novém. Patří mezi ně tyto prvky: Systém profilů, modelů a stanic Systém výběru aktivního oddílu při zavádění OS z flash paměti NAND Příkazová řádka jádra operačního systému v zavaděči Easyboot Bootovací protokol Caller Propagace stisknutého tlačítka reset do operačního systému 42

43 2.3. Analýza zavaděče Easyboot ve směrovači 2N Easyroute Systém profilů, modelů a stanic Princip profilů, modelů a stanic ovlivňuje parametry, které jsou použité při zavádění samotného jádra operačního systému pomocí síťového protokolu TFTP. Přesněji se týkají bootování z NFS souborového systému, který je použit na produkční lince. Parametr Station zajišťuje bezkoliznost IP a MAC adres v případě více oživovacích stanovišť. Níže je výčet jednotlivých parametrů a jejich funkce. Volba parametrů Model, Profile a Station se provádí přes CLI zavaděče. Profil je množina parametrů, která udává IP adresu vlastního routeru, IP adresy serverů TFTP a NFS, IP adresu defaultní brány a masku sítě. Definice těchto profilů se provádí v konfigurační hlavičce bootloaderu a je statická. Model je označení hardwarové verze směrovače, po jejíž změně se mění kořenový souborový systém. Tato část se týká především oživovacího procesu směrovače. Každá hardwarová verze směrovače má na produkčním serveru svůj vlastní kořenový NFS souborový systém a složku se svým vlastním firmwarem. Definice těchto modelů se opět provádí v konfigurační hlavičce bootloaderu. Station je parametr, který nabývá přirozených čísel z intervalu, který je rovný počtu oživovacích pracovišť (cca 10). Po změně tohoto parametru se mění MAC adresa a IP adresa směrovače dána parametrem Profile Příkazová řádka jádra operačního systému Linux v zavaděči Easyboot Příkazová řádka jádra operačního systému (neboli kernel boot command-line) je prostředek, kterým zavaděč dokáže ovlivnit běh jádra operačního systému. Jedná se o textový řetězec obsahující parametry specifické pro danou verzi jádra. Tyto parametry se předávají jádru různě, je nutná jistá domluva mezi jádrem a zavaděčem. Zavaděč Easyboot to dělá takto: 1. Nahraje 8 jádro operačního systému do operační paměti RAM na adresu kernel_loc (viz ENVx proměnné 2.4). 2. Najde od adresy kernel_loc řetězec CMDLINE:. * cmdline = ( char *) memmem ( kernel_, 200, " CMDLINE :", 8); 3. Na místo v operační paměti za tento řetězec 9 uloží příkazovou řádku. 8 Možné z paměti NAND, či TFTP. 9 cmdline+=8 43

44 2. Analýza a návrh reset =2958 media =0 console = ttys0, ro panic =1 \ mac =00:00:00:00:00:69 serial = ABCDEFGH \ root =/ dev / mtdblock7 rootfstype = jffs2 Ukázka příkazové řádky jádra při zavádění OS z paměti NAND reset =2958 media =2 console = ttys0, \ mac =02:00:00:00:00:00 \ root =/ dev / nfs rw nfsroot = :/ er/ umtez1 \ ip = : :: : easyroute : eth0 : off Ukázka příkazové řádky jádra při zavádění OS pomocí protokolu TFTP Jednotlivé parametry jádra, které zavaděč Easyboot předává jádru OS, jsou vysvětleny v tabulce 2.6. Parametr Význam reset propagace doby stisku tlačítka reset do OS media medium, ze kterého se zavádí OS 10 console nastavení IP adres pro komunikaci po síti mac MAC adresa rozhraní pro komunikaci po síti root cesta ke kořenovému souborovému systému nfsroot kořenový souborový systém na NFS úložišti ip nastavení IP adres serial sériové číslo produktu rootfstype typ souborového systému panic čas v sekundách, po kterém se OS restartuje v případě kernel panic Tabulka 2.6: Parametry příkazové řádky linuxového jádra Algoritmus výběru aktivního oddílu při zavádění OS z flash paměti NAND V sekci je popsán mechanizmus, kterým se zvyšuje spolehlivost celého systému směrovače. Tímto mechanizmem je systém střídání paměťových oddílů. Tento systém střídání funguje na jednoduchém principu. Vždy je aktivní pouze jeden logický oddíl, který obsahuje nejaktuálnější vypálený firmware. Postup, kterým se zavádí OS z aktuálního oddíl je následující: Zjisti aktuální paměťový oddíl ENVx zavaděč přečte sekvenční číslo a vybere za aktuální banku ten paměťový oddíl, který obsahuje nejvyšší sekvenční číslo seq. Pokud zavaděč narazí na prázdné místo v paměti tzn., že v paměťový oddíl neobsahuje proměnné ENVx, je tento oddíl přeskočen a zkouší se oddíl druhý. To se děje i v případě, že

45 2.3. Analýza zavaděče Easyboot ve směrovači 2N Easyroute 2. Zaveď operační systém (OS) z aktuálního paměťového oddílu ENVx v tomto kroku se zavaděč pokusí zavést OS z paměti NAND. Pokud se nepodaří zavést OS, je tento oddíl přeskočen a zkouší se oddíl druhý. Pokud na zavedení OS selžou oddíly oba dva, zavaděč skončí v nekonečné smyčce a signalizuje chybu pomocí LED diod Bootovací protokol Caller Tento protokol je alternativou k nastavování parametrů ze sekce pomocí CLI. Tyto parametry ovlivňují zavádění jádra operačního systému přes protokol TFTP. Celý koncept nasazení tohoto protokolu je vidět na obrázku 2.9. Server posílá broadcast pakety 11, které obsahují sériové číslo směrovače a údaje potřebné k zavedení jádra operačního systému. Při startu směrovače (2.8) zavaděč poslouchá. Dostane-li paket se svým sériovým číslem, vyčte z něj potřebné parametry a zavede operační systém. Směrovač musí mít přidělené sériové číslo. Význam protokolu Caller na produkční lince je vysvětlen v sekci Typy zpráv protokolu Caller zpráv. Zavaděč potřebuje znát pouze dva typy Caller boot request je typ paketu, který posílá server směrovači. Obsahuje parametry potřebné k zavedení operačního systému pomocí síťového protokolu TFTP. Caller boot response je typ paketu, kterým směrovač serveru potvrzuje příjem paketu Caller boot request. Oba typy zpráv mají stejný formát hlavičky. Do paketu Caller boot response se při odpovědi zkopíruje celá hlavička z přijatého paketu Caller boot request. Struktura zpráv je vidět na obrázku Význam jednotlivých částí zprávy je v tabulce Propagace stisknutého tlačítka reset do operačního systému Tlačítko reset slouží nejen k restartování směrovače, ale i k vracení směrovače do výchozího nastavení. Uvést zavaděč ve výchozí nastavení znamená vyprázdnění oddílu APP (2.2.4). Tuto operaci nedělá sám zavaděč, ale operační systém směrovače. Při stisku tlačítka reset si zavaděč zaznamenává dobu, po kterou je tlačítko stisknuté. Tento čas potom předá jádru operačního systému v parametru reset (2.6). 11 Broadcast v rámci linkové vrstvy (DEST_MAC=FF:FF:FF:FF:FF:FF). 45

46 2. Analýza a návrh Obrázek 2.9: Ukázka komunikace klient server protokolem Caller 2.4 Vývojový kit a SDK firmy Mindspeed V této sekci popisuji kit 13, na kterém vývoj zavaděče v počátcích probíhal. Jedná se o vývojový kit 83xxx-HWG-001-A nebo-li lidštěji, o model c1kevm. Obecně se dnešní vývoj hardwaru ubírá tím směrem, že se výsledná základní deska skládá z těch nejlevnějších a nejdostupnějších komponent. Dalším kritériem, tentokrát pro usnadnění vývoje programového vybavení, je SDK. Jedná se o software, který je většinou dodáván s kitem výrobce procesoru. Často se jedná o cross kompilátor a tzv. BSP (Board support package), tedy o kusy zdrojového kódu týkající se operačního systému, či zavaděče. Tyto kusy kódu jsou specifické přímo pro dané zařízení. Firma Mindspeed splňovala všechna tato kritéria a nejvíce se shodovala s potřebami pro vývoj nového směrovače 13 Kity firmy Mindspeed byly ve vývoji celkem dva, uvádím pouze první, který byl použit v implementaci zavaděče operačního systému. 46

47 2.4. Vývojový kit a SDK firmy Mindspeed Obrázek 2.10: Struktura zprávy Caller boot response a Caller boot request 2N R SpeedRoute. Tento přístup je jedna z technik, kterým výrobce procesoru dostává svůj procesor do různých typů zařízení, a má tak zajištěn jistý odběr svého produktu. Cena vývojového kitu je v řádu několika tisíc $. Obrázek 2.11: Vývojový kit 83xxx-HWG-001-A firmy Mindspeed 47

48 2. Analýza a návrh Typ zprávy Pole ve zprávě Význam Header ID PID volajiciho procesu Magic Hodnota: 0xdeadbeef Type Typ paketu 12 Caller Boot Request Filter Sériové číslo požadovaného směrovače IP IP adresa, kterou si nastaví směrovač Netmask Maska sítě TFTP Adresa TFTP serveru pro stažení jádra OS NFS Adresa NFS serveru pro namapování souborového systému Kernel Cesta k binární podobě jádra OS Root Cesta ke kořenovému adresáři OS MAC MAC adresa, kterou si nastaví směrovač pro komunikaci Caller Boot Response Serial Sériové číslo směrovače, který odpovídá Tabulka 2.7: Význam jednotlivých částí zpráv protokolu Caller Popis vývojového kitu Složení základní desky umožňovalo vývoj programového vybavení dříve, než byl hotový samotný prototyp routeru 2N R SpeedRoute. Tato sekce se zabývá rozborem hardwaru vývojového kitu Procesor M83263G řady Comcerto 1000 Srdcem celé desky je procesor řady Comcerto Jedná se o dvoujádrový procesor s architekturou ARM 1136J. Procesor je taktován na frekvenci 650 MHz a obsahuje 3 druhy keší. Datovou a instrukční keš, jejichž velikost je 64 kb a DTCM keš velkou 32 kb, která se nejvíce podobá klasické L1 keši. Řadič pamětí typu DDR2 SDRAM umožňuje připojení paměti až do standardu DDR Přímo na čipu také najdeme 128 kb velkou paměť SRAM, přezdívanou ARAM. Síťový subsystém zahrnuje dvě ethernetové MAC, které umožní práci se switchem přes rozhraní RGMII, GMMI, RMII nebo MII. Níže jsou uvedeny klíčové prvky tohoto procesoru a blokový diagram (převzato z (4)), který jednotlivé prvky znázorní graficky. 48 Klíčové prvky procesoru M83263G :

49 2.4. Vývojový kit a SDK firmy Mindspeed Dual CPU ARM 1136J core s frekvencí 650 MHz 64 kb Data cache, 64 kb Instruction cahe, L1 32 kb cache 16/32-bit řadič pamětí DDR2 ( až do DDR2-800 ) Vestavěná 128 kb dual-access low-latency SRAM (ARAM) Podpora pro IPv4/v6 IPSec (full CPU offload) 2 x PCIe lanes root end point 2 x Ethernet MACs ( RGMII; GMII; RMII; nebo MII ) Obrázek 2.12: Blokový diagram procesoru řady Comcerto Periferie vývojového kitu Neméně důležitou částí jsou i prvky umístěné mimo čip procesoru. Mezi základní periferie patří paměť typu DDR2 SDRAM ve velikosti 256 MB s taktem I/O sběrnice 400 MHz a taktem paměti 200 MHz. Dále paměť typu NOR flash (dále pouze NOR) o velikosti 16 MB. Plnou kapacitu paměti můžeme využít pouze v případě, kdy nepoužíváme paměť NAND. Paměť NOR je připojena k paralelní sběrnici a v případě povolení paměti NAND je posledních 6 nejvyšších adresních vodičů paměti NOR použito pamětí NAND. Tento návrh nám zredukuje paměť NOR na pouhých 256 kb. Multiplexování těchto vodičů není možné, už kvůli vysoké napěťové úrovni v klidovém stavu paměti NAND. 49

50 2. Analýza a návrh Paměť NAND je na desce ve velikosti 512 MB. Základní deska obsahuje jeden gigabitový port WAN a čtyři gigabitové porty LAN. Komunikaci po sériové lince zařizují dva UART moduly procesoru. Externí Wi-Fi karta je připojena pomocí rozhraní PCIe. V poslední řadě základní deska obsahuje patici, která slouží k připojení sériové I 2 C paměti. Tento prvek bude důležitý v následujících kapitolách týkající se oživovacího procesu. Níže je seznam těchto periferií a blokový diagram (převzato z (6)), který vybavení desky znázorní graficky. Parametry periferií vývojového kitu : 256 MB DDR2-800 SDRAM 16 MB NOR flash 512 MB NAND flash & T1 Framer 1x Gigabit Ethernet Wide Area Network (WAN) port, 4x Gigabit Ethernet Local Area Network (LAN) port 2x Universal Asynchronous Receiver/Transmitter (UART) Peripheral Component Interface (PCI) Interface-Host X1 PCIe & minipci WiFi card Inter-IC Bus (I2C) interface 64 kb EEPROM & 16-Bit GPIO 2 x Universal Asynchronous Receiver/Transmitter (UART) Software development kit (SDK) firmy Mindspeed Jak již bylo zmíněno, nedílnou součástí, která rapidně urychlí vývoj je Software development kit, či devkit, dodávaný s vývojovým kitem. V oblasti embedded zařízení se jedná o sadu nástrojů, které jsou určené pro nějakou cílovou platformu. V tomto případě se jedná o vývojový kit. Úkolem SDK je maximálně ulehčit život návrháři, a to hlavně v počátcích vývoje. Obsahuje základní set programového vybavení, na kterém se poté dá budovat zbytek aplikace. SDK firmy Mindspeed obsahuje různé komponenty. Některé z nich si popíšeme níže. Samotnou základní desku firma Mindspeed prezentuje jako router. Dodává k němu webové uživatelské rozhraní, upravenou verzi operačního systému OpenWrt se zavaděčem Das U-boot Obsah SDK V SDK tohoto vývojového kitu jsou zajímavé zvláště tři komponenty, které jsou použity v dalším návrhu programového vybavení směrovače 2N R SpeedRoute. 50

51 2.4. Vývojový kit a SDK firmy Mindspeed Obrázek 2.13: Blokový diagram vývojového kitu 83xxx-HWG-001-A Zavaděč Das U-boot je zavaděč, který je v embedded systémech velice oblíbený. Srovnání je ho vlastností s ostatními zavaděči najdeme v tabulce 1.1. Samotnému zavaděči Das U-boot je věnována sekce 2.5. V SDK je použita verze Das U-boot v Cross kompilátory 14 jsou použity celkem dva. Důvod, proč se nepoužívá pouze jeden, bude uveden v Jedná se o tyto kompilátory: 14 Kompilátory, u kterých je cílová architektura jiná než architektura zdrojová. 51

52 2. Analýza a návrh Toolchain ARM GCC uclibc Toolchain ARM GCC Glibc 2.7 Linuxové jádro je použito ve verzi Linux kernel release SDK taktéž obsahuje ovladače k periferiím, které jsou součástí vývojového kitu. I když se jedná o nesmírně důležitý prvek ve vývoji programového vybavení směrovače 2N R SpeedRoute, není obsahem této diplomové práce. V práci budou zmíněny pouze vlastnosti jádra, které úzce souvisí se zavaděčem operačního systému Společné vlastnosti vývojového kitu se směrovačem 2N Speedroute Nový směrovač 2N R SpeedRoute maximálně využívá výhod vývojového kitu. Jak po stránkách softwaru, tak po stránkách hardwaru Hardwarové srovnání vývojového kitu se směrovačem 2N R SpeedRoute Vývojový kit se od hardwarového návrhu směrovače 2N R SpeedRoute nepatrně liší. To ovlivní i přechod z vývojového kitu na ostrou verzi základní desky směrovače 2N R SpeedRoute. Seznam zmíněných rozdílů: jiný model procesoru jiné rozložení GPIO pinů jiný ethernetový switch jiný velikost pamětí s jinou velikostí paměťových bloků Srovnání programového vybavení vývojového kitu se směrovačem 2N R SpeedRoute S rozdílem v hardwaru vývojového kitu a základní deskou směrovače přichází nutnost modifikace programového vybavení pro specifické potřeby směrovače nového. Týká se to již zmíněného zprovoznění switche a drobných změn, které souvisí s novým návrhem základní desky směrovače. Dále se jedná o požadavky, které jsou spojené se softwarem ve staré verzi směrovače 2N R EasyRoute. Obecně se programové vybavení vývojového kitu s novým směrovačem bude lišit ve skladbě celého operačního systému, proto nemá cenu rozebírat jednotlivé body návrhu jiných částí, než jakých se týká tato diplomová práce. Ty důležité prvky z SDK, které bude třeba do projektu začlenit, 52

53 2.5. Zavaděč Das U-boot již byly zmíněny Bude třeba použít kompilátory z SDK a modifikovat tyto prvky: jádro operačního systému Linux 15 zavaděč operačního systému Das U-boot 2.5 Zavaděč Das U-boot Open source projekt s názvem Das U-boot (Universal Bootloader) či U-boot, je zavaděč operačního systému primárně určený pro embedded zařízení. Podporuje mnoho počítačových architektur. V první řadě vznikl pro počítačovou architekturu PPC. Následovala architektura ARM a další. Dnes je zavaděč velice oblíbený pro svou obsáhlou funkcionalitu, univerzálnost a podporu, kterou zajišťuje komunita vývojářů okolo projektu. Tato sekce představuje funkce zavaděče a obsahuje analýzu zdrojových kódů zvláště pak částí, které souvisejí s budoucím návrhem. Poslední část sekce srovnává zavaděč U-boot se zavaděčem Easyboot Pravidla ve vývoji zavaděče Das U-boot Vývojáři se kolem projektu Das U-boot snaží dodržet několik pravidel, která jsou důležitá pro samotný vývoj zavaděče. Je nutné je uvést, aby byla pochopena filozofie a struktura tohoto projektu. Keep it Small primárním účelem zavaděče je zavést operační systém. Jedná se o úkol, na který nechceme vyplýtvat zbytečně moc hardwarových prostředků. Typicky je zavaděč na menší paměti (NOR), než samotný operační systém (NAND). Tato paměť často bývá díky svému náhodnému přístupu a složitosti dražší. Cílem je zahazovat zbytečnou funcionalitu a generovat co nejmenší zdrojový binární kód. Obecně zavaděč U-boot může v základní sestavě funkcí fungovat na zařízeních s 128 KiB ROM nebo 256 KiB NOR Flash. Keep it Fast běžný koncový uživatel neví o existenci zavaděče vůbec nic. Prioritou zavaděče je zajištění co nejrychlejšího startu zařízení. K tomu se používají dva hlavní principy: Povolení keší a to, co nejrychleji a kdykoliv je to možné. Inicializovat pouze periferie, které potřebujeme pro splnění primárního cíle zavaděče. 15 Není předmětem této diplomové práce. 53

54 2. Analýza a návrh 54 Keep it Simple zavaděč má splňovat pouze účel, pro který byl stvořen a to pouze v takové míře, která je nutná pro jeho nezbytnou funkcionalitu. Cílem je udržovat kód maximálně přehledný a transparentní. Keep it Portable zavaděč Das U-boot byl portován na několik stovek základních desek. Je důležité, aby kód, který bude přidán do projektu, bylo možné použít na co nejvíce platformách. Zdrojový kód, který je platformě závislý, tzn. jazyk symbolických adres je důležité používat co nejméně a pouze tam, kde je to nezbytně nutné. Je cílem dosáhnout co největší možné abstrakce, kterou asi nejvíce připomíná abstraktní vrstva HAL (Hardware abstraction layer). Ta vývojáři umožňuje ovládat různé druhy hardware přes jednotné API. Keep it Configurable pro každou desku je vytvořena zvláštní konfigurace, která zařízení poskytuje pouze tu funkcionalitu, která je zrovna potřeba. Je třeba se ujisti, že toto přidávání a odebírání funkcí je maximálně jednoduché. Pokud nějaká z funkcí není použita, neměla by hrát žádnou roli ve výsledné kompilaci zavaděče. Keep it Debuggable návrh zavaděče je choulostivou nízkoúrovňovou záležitostí. Velmi často je zavaděč nasazován v nových zařízeních, kdy jakýkoliv problém v chodu systému může být způsoben jak chybou programového vybavení, tak chybou v samotném hardwarovém návrhu. Je třeba držet se kontrolních výpisů, a to v celém průběhu životního cyklu zavaděče. Keep it Usable existují tři skupiny uživatelů s různými požadavky. Koncoví uživatelé jedná se o tu skupinu, která o existenci zavaděče operačního systému většinou vůbec neví a vědět nechce. Koncovému uživateli jde pouze o spuštění některé z jeho aplikací v již zavedeném operačním systému. Systémoví návrháři jedná se o skupinu, která se zajímá o návrh operačního systému a samotných aplikací. Jejich požadavkem je dostat od zavaděče co největší množství funkcí v co nejkratším čase nasazení. Návrháři zavaděče U-boot skupina návrhářů, která má za úkol samotnou portaci zavaděče na nová zařízení. Jejich požadavkem je to, aby portace byla co nejjednodušší. Zavaděč Das U-boot se snaží vyhovět všem požadavkům těchto skupin. Keep it Beautiful tento bod spočívá ve striktním dodržování pravidel týkajících se psaní kódu, komentování a udržování pořádku v celém projektu. Existují jisté předpisy tzv. Coding style requirements, které určují tyto základní pravidla.

55 2.5. Zavaděč Das U-boot Keep it Maintainable cílem je dodržet vysokou míru přehlednosti kódu, přesněji podle názvu vysokou udržovatelnost kódu. Maximálně se vyhnout podmínkám preprocesoru #ifdef, používat weak funkce a dodržovat předpisy pro psaní kódu dané komunitou. Keep it Open Cílem je udržet projekt v komunitě. Je žádoucí určitá míra spolupráce ze strany vývojářů ve formě přidávání záplat a rozšiřování celého projektu Jaká je skutečnost? V projektu je skutečně dbáno na pravidla uvedená v Dalo by se říct, že se v měřítku operačních systémů a jejich jader jedná o malý projekt, který, ač nemá tak striktní a sofistikovaný systém na příjímání záplat a rozšíření, dosahuje v oblasti přehlednosti a modularity systému velice pěkných výsledků. I přes to v kódu často najdeme vysokou míru redundance, dále se v kódu objevují často matoucí podmínky pro preprocesor, které jsou bohužel nutností. Další nepřehlednost je především v hlavičkových souborech zavaděče, zvláště pak ve společném hlavičkovém souboru s názvem common.h, podobně je na tom Makefile projektu, který je velice objemný. Většinou se jedná o prvky nepřehlednosti, které nejsou spojené se špatným návrhem tohoto zavaděče. Obecně celý projekt znepřehledňuje míra multiplatformnosti tohoto zavaděče Funkce a možnosti zavaděče Zavaděč Das U-boot má několik obecných vlastností, které ho odlišují od zavaděčů ostatních. První vlastnost byla zmíněna hned v úvodu této sekce. Jedná se o zavaděč, který podporuje širokou škálu zařízení fungujících na různých počítačových architekturách. Z pravidel vývoje uvedených výše je jasné, že snaha udržet systém a pořádek v takto rozsáhlém projektu je prioritou vývojářů. Nejedná se vůbec o jednoduchý úkol. Návrh celého systému je koncipován vysoce modulárně, což je druhou důležitou vlastností tohoto projektu. Díky této vlastnosti je možné zavaděč flexibilně upravovat pro potřeby daného zařízení, a to velice rychle a efektivně. Jednotlivé funkce a vlastnosti zavaděče již byly zmíněny v tabulce srovnání zavaděčů viz 1.1. Mezi ty nejdůležitější vlastnosti patří: Podpora počítačové architektury typu ARM Podpora operačního systému Linux Přívětivé uživatelské prostředí Možnost skriptování 55

56 2. Analýza a návrh Podpora síťových protokolů TFTP a NFS Podpora souborového systému JFFS2 Pokročilá práce s pamětí v podobě MTD oddílů Uživatelské rozhraní zavaděče U-boot K uživatelské rozhraní zavaděče se přistupuje stejně jako u zavaděče Easyboot přes CLI pomocí sériové linky. Máme na výběr dvě možnosti příkazové řádky simple CLI Bourne compatible shell (HUSH shell from Busybox) V dalších částech práce budeme uvažovat pouze možnost první. Komplexnější příkazová řádka ve formě HUSH shellu této práci nepřináší žádnou další přidanou hodnotu. Dále bude představen základní instrukční set zavaděče Základní instrukční set zavaděče Instrukční set tohoto zavaděče je velice obsáhlý. V tabulce 2.8 jsou uvedeny základní příkazy pro práci se zavaděčem. Najdeme zde pouze ty příkazy, které budou mít význam pro další práci se zavaděčem. Například zde nenajdeme příkazy týkající se souborového systému typu FAT, protože se v dalším návrhu směrovače tento souborový systém nepoužívá Proměnné a skripty zavaděče Das U-boot Das U-boot obsahuje proměnné, které konfigurují celé prostředí zavaděče. Do proměnné se ukládá hodnota ve formě textového řetězce. Seznam proměnných není fixní. Je možné vytvářet vlastní proměnné a to do velikosti, která se nastaví v konfiguraci základní desky. Nastavení uživatelských proměnných Nastavení proměnné se provede příkazem setenv <env_name> <env_value>. Pozor tento příkaz uloží proměnnou pouze do paměti RAM. Pro uložení proměnných do perzistentní paměti NOR nebo NAND je nutné použít příkaz saveenv. Proměnné uložené v RAM vypíšeme příkazem printenv. setenv ipaddr setenv serverip setenv netmask saveenv Ukázka nastavení síťového subsystému zavaděče Das U-boot 56

57 2.5. Zavaděč Das U-boot Information Commands Com- Memory mands Flash Memory Commands Execution Control Commands Com- Network mands Environment Variables Commands JFFS2 Filesystem Support Flash Com- NAND Memory mands Special mands Com- bdinfo print Board Info structure coninfo print console devices and informations flinfo print FLASH memory information iminfo print header information for application image imls list all images found in flash help print online help? alias for help cmp memory compare cp memory copy md memory display mm memory modify (auto-incrementing) mtest simple RAM test mw memory write (fill) nm memory modify (constant address) erase erase FLASH memory protect enable or disable FLASH write protection bootm boot application image from memory go start application at address addr nfs boot image via network using NFS protocol tftpboot boot image via network using TFTP protocol printenv print environment variables saveenv save environment variables to persistent storage setenv set environment variables run run commands in an environment variable chpart change active partition mtdparts define flash/nand partitions fsinfo print information about filesystems fsload load binary file from a filesystem image ls list files in a directory (default /) uload load kernel file from a filesystem image nand NAND flash sub-system i2c I2C sub-system eeprom EEPROM sub-system Tabulka 2.8: Základní set příkazů zavaděče U-boot 57

58 2. Analýza a návrh První příkaz nastaví proměnnou ipaddr. Tato proměnná představuje IP adresu našeho zařízení. Druhá proměnná serverip představuje IP adresu serveru, ke kterému budeme přistupovat. Poslední proměnná netmask nastaví masku sítě. Příkaz saveenv uloží všechny proměnné do perzistentní paměti. Jednoduché skriptování Zavaděč U-boot nabízí psaní jednoduchých skriptů. Seznam příkazu píšeme za sebe a oddělujeme znakem ;. Celý příkaz pak uložíme do námi pojmenované proměnné příkazem setenv <command_name> <command>. Tyto skripty se poté pouští příkazem run <command_name>. Je možné ve skriptu používat již existující proměnné. Ke globální proměnné přistoupíme takto ${<env_name>}. Ukázka jednoduchého skriptu na update zavaděče ve flash paměti NOR. updateboot = tftp u- boot. bin ; protect off 1:0-1; erase 1:0-1; cp. b ${ filesize } Rozbor skriptu: 1. tftp u-boot.bin pomocí TFTP 16 stáhne na adresu 0x (paměť RAM) binární soubor u-boot.bin 2. protect off 1:0-1 před zápisem do paměti NOR flash, odemkne sektory 0 a 1 první banky paměti 3. erase 1:0-1 smaže sektory 0 a 1 z první banky paměti 4. cp.b ${filesize} překopíruje z adresy 0x (RAM) na adresu 0x (NOR) data o velikosti ${filesize} 17 Základní proměnné Zavaděč U-boot obsahuje několik důležitých proměnných, které je dobré zmínit viz tabulka 2.9. Z větší části se týkají nastavení síťového subsystému. Defaultní proměnné Defaultní proměnné jsou proměnné, které se načítají v případě, že se z nějakého důvodu nepodaří načíst blok proměnných ze standardního umístění většinou NOR (NAND) flash paměti. Tyto proměnné se hodí především v případě, kdy je základní deska zavaděčem zinicializována poprvé, tzn. že je velká pravděpodobnost, že se do prostoru NOR (NAND) paměti ještě nikdy firmware nezapisoval. Proměnné existují pouze v paměti RAM dokud je neuložíme příkazem saveenv, který je nahraje na předem určené místo v perzistentní paměti NOR či NAND. Poté mají prioritu proměnné z perzistentní paměti. Tyto proměnné se definují v konfiguraci základní desky pomocí definice preprocesoru CONFIG_EXTRA_ENV_SETTINGS. 16 Nastavení síťového subsystému je umístěno v sekci Po stažení souboru nastaví tuto proměnnou příkaz tftp 58

59 2.5. Zavaděč Das U-boot Konfigurace základní baudrate určuje rychlost sériové linky desky ethaddr obsahuje MAC adresu primárního ethernetového portu serial# vybírá sériový port pro komunikaci Síťové parametry ipaddr IP adresa zařízení serverip IP adresa serveru gatewayip IP adresa defaultní brány dnsip IP adresa dns serveru netmask síťová maska sítě hostname hostname zařízení rootpath cesta k NFS kořenovému souborovému systému Parametry startu zavaděčtele bootdelay počet vteřin čekání na vstup uživa- bootcmd defaultní příkaz, spuštěný po vypršení bootdelay Tabulka 2.9: Seznam důležitých proměnných zavaděče Das U-boot Definice mtd oddílů V případě, že používáme flash typu NAND či NOR je dobré nadefinovat mtd oddíly, které nám později usnadní práci s pamětí. Definice mtd oddílů se provádí v konfiguraci desky a vypadá např. takto: # define MTDIDS_ DEFAULT " nand0 = comcertonand " # define MTDPARTS_ DEFAULT \ " mtdparts = comcertonand :256 k(u- boot ),128k( env ),16000 k(fs)" # define MTDPARTITION_ DEFAULT " nand0,2" Důležitá je proměnná mtdparts, která definuje jednotlivé oddíly. Zjednodušení spočívá v tom, že řada příkazů pro práci s pamětí, či přímo souborovým systémem, umí pracovat jak s adresou oddílu, tak se jménem ( uvedeno v závorkách ) mtd oddílu. Příklad načtení jádra systému z JFFS2, které se nachází na mtd oddílu se jménem fs vypadá takto: chpart fs; uload fs Příkaz chpart změní aktivní oddíl na fs a příkaz uload tento oddíl prohledá a pokud najde soubor uimage, zkontroluje jeho hlavičku a nahraje ho do paměti RAM. Jádro systému, které se používá na vývojovém kitu, vyžaduje parametr mtdparts ve své příkazové řádce (kernel boot command line), podle které nastaví rozmístění mtd oddílů v operačního systému. Výhoda tohoto řešení je jednotná definice mtd oddílů. Měnit uskupení mtd oddílů lze i z příkazové řádky pomocí příkazu mtdparts. 59

60 2. Analýza a návrh Načtení a zavedení linuxového jádra v zavaděči Das U-boot Jádro je možné zavést několika způsoby a to nejčastěji natažením ze sítě, či natažením z nějakého paměťového úložiště např. NAND nebo NOR flash paměť. Dále můžeme využít výhod souborového systému např. JFFS2 na těchto paměťových úložištích. Cílem je nahrát obraz jádra do paměti RAM, kde s ním poté můžeme jakkoliv manipulovat. První ze způsobů již byl nastíněn v sekci , kde se ve skriptu ke stažení souboru používá příkaz tftp, podobně můžeme použít i příkaz nfs. Druhý způsob byl již taktéž uveden v Používá se k němu několik příkazů zavaděče. Typ těchto příkazů úzce souvisí s tím, jestli používáme nějaký ze souborových systémů, či nikoliv. Zajímavé jsou pro tuto práci dva způsoby umístění linuxového jádra: linuxové jádro je umístěno v kořenovém adresáři operačního systému např. /boot/uimage linuxové jádro je umístěno mimo kořenový adresář operačního systému, tzn. má definovaný vlastní paměťový oddíl. Tento způsob je použit u směrovače 2N R EasyRoute (KERNELx). Pokud je linuxové jádro umístěno v kořenovém adresáři operačního systému, používáme příkazy pro práci se souborovým systémem. Jak již bylo řečeno, v této práci bude zapotřebí pouze jediného typu souborového systému a to JFFS2. Zavaděč umí listovat souborovým systémem a prohledávat ho, dále obsahuje příkaz který je specificky navržen právě pro hledání binární podoby jádra operačního systému (uimage). Tento příkaz se jmenuje uload a jeho použití je vidět v sekci V případě umístění jádra mimo operační systém v paměťovém oddílu typu flash NAND je možné použít příkaz nboot, který kromě nakopírování do paměti RAM, provede i jednoduchou kontrolu hlavičky obrazu jádra. Obecně pokud máme umístěno jádro mimo operační systém, není potřeba žádných speciálních příkazů, postačí příkaz cp.b, který zkopíruje daný paměťový oddíl do paměti RAM. Jakmile máme jádro v paměti RAM použijeme příkaz bootm, který jádro ve formátu uimage dokáže rozbalit a zavést. O formátu uimage pojednává sekce Formát souboru uimage Je speciální formát, do kterého je zabaleno jádro systému. Nejvíce se podobá formátu zimage. Skládá se z hlavičky a samotných dat, kde hlavička obsahuje informace, které pomáhají při procesu zavádění jádra. Obrázek ukazuje strukturu tohoto typu binárního souboru. Formát uimage podporuje 60

61 2.5. Zavaděč Das U-boot i kompresi jádra pomocí gzip a bzip2, ale ta se v embedded systémech často nepoužívá. S tímto formátem dokáže manipulovat příkaz bootm, který umožní jádro v tomto formátu zavést. Obrázek 2.14: Struktura souboru uimage Příkazová řádka linuxového jádra Zavádění linuxového jádra se téměř neliší od způsobu, jakým to dělá zavaděč Easyboot. Parametry příkazové řádky jádra jsou téměř shodné. Zmíněny budou pouze důležité odchylky od příkazové řádky zavaděče Easyboot viz Zavaděč U-boot plní příkazovou řádku jádra z proměnné bootargs, tzn. že s jakoukoliv další úpravou a nastavením není problém. Předání těchto parametrů probíhá podobně jako u zavaděče Easyboot. Paramtery, které jsou předávány navíc jsou popsány v tabulce 2.10 Parametr init hwaddress partno fppmode mem Význam cesta k init skriptu MAC adresa rozhraní pro komunikaci po síti označení modelu procesoru stav FPP (Fast Passive Parallel) módu oemezení paměti RAM Tabulka 2.10: Parametry příkazové řádky linuxového jádra zavaděče U-boot Orientace ve zdrojových kódech Níže je ukázána adresářová struktura projektu U-boot. Některé složky jsou úmyslně vynechány, popsány jsou pouze ty nejdůležitější. Obecně má tato sekce usnadnit orientaci ve zdrojových kódech. Ve složce./board najdeme 61

62 2. Analýza a návrh zdrojové kódy určené přímo pro danou základní desku. Základní desky jsou zde tříděny podle výrobce a verze dané desky. Složka./common obsahuje zdrojové kódy společné pro všechny architektury a všechny verze základních desek, týkají se CLI a jednotlivých příkazů zavaděče. Složka./cpu obsahuje platformě závislé nízkoúrovňové zdrojové kódy týkající se především startu, relokace zavaděče a inicializace procesoru. Adresář./drivers obsahuje veškeré ovladače všech podporovaných periferií, např. ovladač ethernetového switche. Ve složce./fs najdeme implementaci všech podporovaných souborových systémů. Všechny hlavičkové soubory jsou umístěny ve složce./include, kde v podsložce./include/configs najdeme veškeré konfigurační soubory všech podporovaných zařízení. Složky./lib_xxx, kde xxx je cílová architektura, obsahují generické zdrojové kódy k cílové architektuře, týkají se např. další inicializace v průběhu startu zavaděče. O inicializaci zavaděče U-boot se dočteme v sekci V poslední řadě složka./net obsahuje celý síťový subsystém zavaděče. Pokud se neřekne jinak, bude brán jako výchozí (aktuální) adresář kořenový adresář projektu Das U- boot. / board...specifické zdrojové kódy základních desek common...kód společný pro všechny základní desky cpu...specifické zdrojové kódy určené pro cílové CPU doc...dokumentace projektu drivers... Ovladače k periferiím fs...zdrojové kódy týkající se souborového systému include...adresář hlavičkových souborů configs..složka obsahující konfigurace základních desek... lib_xxx...generické zdrojové kódy určené pro cílovou xxx architekturu net... Zdrojové kódy síťového subsystému Kompilace zavaděče Das U-boot Kompilace zavaděče se provádí klasicky pomocí souboru Makefile, který je umístěn v kořenovém adresáři projektu. Skládá se ze dvou kroků: make distclean tento příkaz vyčistí projekt od předešlé kompilace. 2. make xxx_config tento příkaz vytvoří hlavní konfigurační soubor config.h ve složce./include, kde xxx (např. c1kevm) představuje ozna-

63 2.5. Zavaděč Das U-boot čení základní desky. Ukázka tohoto hlavičkového souboru pro vývojový kit c1kevm viz make tento příkaz pustí samotnou kompilaci pro zvolenou konfiguraci. Výsledný binární soubor zavaděče je pojmenován u-boot.bin a je umístěn přímo v kořenovém adresáři projektu Ukázka konfiguračního souboru./include/config.h Konfigurace se sestává z výběru typu procesoru (m8326xg.h) a konfiguračního souboru základní desky. # include < configs / m8326xg.h> # define COMCERTO_ PART_ NO " M83263G " /* Automatically generated - do not edit */ # include < configs / c1kevm.h> Analýza zdrojových kódů konfigurace pro konfiguraci c1kevm Pro pochopení toho, jakým způsobem se chová zavaděč při startu, či jakým způsobem funguje síťový subsystém zavaděče, je třeba zanalyzovat zdrojové kódy zavaděče. Není prioritou této práce rozebírat každý soubor tohoto projektu. Bude zmíněna pouze ta část zdrojových kódů, která se týká toho nejdůležitějšího. Zdrojové kódy se dělí podle závislostí na několik typů: zdrojový kód určený pro konkrétní základní desku zdrojový kód určený pro konkrétní architekturu procesoru zdrojový kód určený pro konkrétní typ procesoru zdrojový kód ovladačů zařízení společný zdrojový kód Vzhledem k tomu, že konfigurací existují stovky, bude se rozebírat pouze konkrétní pro práci nejvíce zajímavý případ. Jako konfigurace bude vzat model se zkráceným jménem c1kevm, tedy vývojový kit firmy Mindspeed popsaný v kapitole 2.4. Pro zopakování se jedná o základní desku s procesorem řady Comcerto 1000, přesněji typ M83263G. Architektura procesoru je ARM1136J. 63

64 2. Analýza a návrh Konfigurace základní desky Celá konfigurace základní desky se provádí v jediném souboru. c1kevm.h a to v adresáři./include/configs, kde se nachází veškeré konfigurační soubory podporovaných zařízení. Jedná se o hlavičkový soubor, který při vytvoření konfigurace viz kompilace 2.5.6, vloží tento soubor do hlavního konfiguračního souboru config.h. Veškerá konfigurace se provádí pomocí definic a maker preprocesoru. V tabulce 2.11 jsou uvedeny pouze ty nejdůležitější. Obecně v konfiguraci existují dva druhy konfiguračních proměnných: - Configuration _OPTIONS_ začínají na CONFIG_ a týkají se většinou uživatelského prostředí. - Configuration _SETTINGS_ začínají na CFG_ a označují závislost na hardwaru (např. velikost základního bloku paměti). Uživatel, který nezná základní desku důkladně, je v dokumentaci varován před změnou těchto parametrů. Ukázka několika definic z konfiguračního souboru desky c1kevm V konfiguraci základní desky se definují desítky těchto parametrů. Je nad rámec této práce vysvětlení všech těchto parametrů. Konfigurační soubor této desky je velice dobře okomentován, v případě další potřeby odkazuji na dokumentaci projektu viz složka./doc. # define CONFIG_ETHADDR 00: aa:bb:cc:dd:ee # define CONFIG_ IPADDR # define CONFIG_ SERVERIP Start zavaděče Das U-boot Po startu bootloaderu Das U-boot se před zaváděním operačního systému, provede několik operací. Zjednodušený start systému demonstruje obrázek 2.15, kde jsou vidět jednotlivé fáze startu zavaděče. Start je logicky dělen na 3 fáze. Fáze 1 je nejdůležitější a nejchoulostivější část startu zavaděče. Většina kódu je psaná v jazyce symbolických adres. Dělí se na dvě části. 64 Low-level init jedná se o inicializaci týkající se především nastavení procesoru. Obsahuje nastavení fázových závěsů, nastavení interní SRAM (ARAM) paměti, nastavení sběrnic procesoru, nastavení keší a v poslední řadě nastavení externí paměti DDR2. Relocation jedná se o relokaci zavaděče z prostoru perzistentní paměti (NOR, EEPROM) do prostoru SDRAM, proto nízkoúrovňová inicializace zahrnuje i nastavení DDR2 paměti. O relokaci pojednává

65 2.5. Zavaděč Das U-boot Název definice Význam definice CONFIG_COMCERTO_1000 Výběr rodiny procesoru CONFIG_ARM1136 Výběr architektury procesoru CONFIG_BOARD_c1kevm Označení základní desky procesoru CONFIG_UARTx Nastavení sériové linky CONFIG_BAUDRATE Nastavení rychlosti sériové linky CONFIG_SKIP_RELOCATE_UBOOT Umožňuje přeskočit relokaci zavaděče při startu CONFIG_SKIP_LOWLEVEL_INIT Umožňuje přeskočit inicializaci zavaděče při startu PHYS_SDRAM Adresa paměti SDRAM PHYS_FLASH1 Adresa paměti NOR flash CFG_NAND_BASE Adresa paměti NAND flash GEMACx_PHY_ADDR Adresa fyzického portu rozhraní GEMAC GEMACx_CONFIG Výběr rozhraní RGMII, GMII,... {} GEMACx_MODE Nastavení duplexního módu a rychlosti přenosu rozhraní CONFIG_COMMANDS Ovládá instrukční set zavaděče CONFIG_EXTRA_ENV_SETTINGS Nastavení defaultních proměnných CONFIG_BOOTDELAY Doba, po kterou se čeká na uživatelův vstup CONFIG_ETHADDR Nastavení MAC adresy pro síťovou komunikaci CONFIG_IPADDR Nastavení defaultní IP adresy základní desky CONFIG_SERVERIP Nastavení defaultní IP adresy serveru MTDPARTS_DEFAULT Definnice mtd oddílů MTDPARTITION_DEFAULT Nastavení aktivního oddílu mtd CFG_ENV_IS_IN_NAND Uživatelské proměnné jsou umístěny v NAND flash CFG_ENV_IS_IN_FLASH Uživatelské proměnné jsou umístěny v NOR flash CFG_ENV_SIZE Velikost prostoru uživatelských proměnných CFG_ENV_ADDR Adresa prostoru uživatelských proměnných Tabulka 2.11: Ukázka několika definic z konfiguračního souboru desky c1kevm 65

66 2. Analýza a návrh Fáze 2 je orientovaná na nastavení periferií základní desky. Nastavuje přerušení, paměti NAND a NOR flash, sériovou linku pro komunikaci s uživatelem, definuje prostředí pro dynamickou alokaci paměti. Dále relokuje proměnné z prostoru perzistentní paměti do prostoru RAM. Fáze 3 je bod kdy start zavaděče končí. Jedná se o spuštění uživatelské příkazové řádky. Obrázek 2.15: Start zavaděče Das U-boot Celou fázi 1 je možné přeskočit pomocí definic: CONFIG_SKIP_RELOCATE_UBOOT CONFIG_SKIP_LOWLEVEL_INIT Tyto definice zakážou nízkoúrovňovou inicializaci a relokaci zavaděče. Toto je potřeba např. pokud zavaděč startuje z prostoru RAM. Tato technika se používá hlavně v dobách vývoje zavaděče, aby se po každé úpravě nemusela aktualizovat paměť NOR flash. Relokace zavaděče U-boot do paměti RAM Relokace je metoda, pomocí níž může být strojový kód umístěn na jiné místo v paměti, než pro které byl překladačem zkompilován. Při startu zavaděče se předpokládá spouštění strojového kódu z paměti typu ROM, toto je ovšem nežádoucí, protože se jedná o Read Only Memory, tedy o paměť, která slouží pouze pro čtení. I když např. NOR flash není ROM, je s ní takto zacházeno. Důvodů, proč se provádí relokace je více např. paměť RAM bude vždy rychlejší, než paměť typu NOR Flash či EEPROM. Relokace zavaděče U-boot není ničím speciální. Po provedení nutných nízkoúrovňových inicializací je část spustitelného kódu nakopírována na dedikovanou adresu v paměti RAM. Na tuto adresu se poté provede skok. V obrázku 2.15 tuto část spustitelného kódu představuje vše od fáze 2 a dál. 66

67 2.6. Oživovací proces směrovače 2N R SpeedRoute Srovnání se zavaděčem Easyboot Srovnání s ostatními zavaděči najdeme v tabulce 1.1. Zajímavé je však srovnání se zavaděčem Easyboot. Zavaděč Easyboot obsahuje jen tu nejnutnější funkcionalitu. To se promítá do velikosti celého zavaděče, která se pohybuje okolo 50 kb. Za zmínku stojí to, že Easyboot v porovnání se zavaděčem U-boot neobsahuje příkazovou řádku v pravém slova smyslu. CLI zavaděče U-boot je daleko složitější a propracovanější. User-friendly prostředí je vykoupeno větší velikostí výsledného binárního souboru. Ze srovnání v tabulce 2.12 je vidět převaha zavaděče U-boot v síťovém subsystému. Jedinou vlastnost, kterou zavaděč U-boot postrádá je datový přenos po sériové lince protokolem xmodem, ten v zavaděči U-boot nahradil novější ymodem a zmodem. Das U-boot Easyboot Velikost cca 150 kb cca 50kB Funkce Příkazová řádka omezená Podpora NFS Podpora TFTP Podpora souborového systému JFFS2 Zavedení linuxového jádra pouze TFTP ( NFS, TFTP ) Zavedení bootloaderu Update bootloaderu pouze xmodem (TFTP, NFS) Podpora NAND Flash Tabulka 2.12: Srovnání zavaděčů Das U-boot a Easyboot 2.6 Oživovací proces směrovače 2N R SpeedRoute Oživovací a expediční testy směrovačů 2N R SpeedRoute a 2N R EasyRoute na produkční budou až na výjimky stejné. Bude předveden oživovací proces směrovače 2N R EasyRoute. Na tomto procesu budou ukázány principy a složení jednotlivých testů. Nakonec tato sekce nastíní možné způsoby oživení nového směrovače Popis oživovacího procesu produktu 2N Easyroute v bodech Po osazení plošného spoje základní desky součástkami, je základní deska neschopna provozu. Je to z toho důvodů, že zavaděč, který obyčejně dělá inicializaci zařízení a je uložen na samém počátku paměti NOR, v této paměti není. 67

68 2. Analýza a návrh V celém oživovacím procesu existují dva testy, které mají zajistit otestování základní desky směrovače a prvotní nahrání firmwaru do paměti směrovače. Ukázkové reporty z obou testů najdeme v příloze C. Jedná se o tyto dva testy: oživovací test expediční test Oživovací test Oživovací test má za úkol otestovat základní desku směrovače po stránce hardwaru a provést prvotní nahrání zavaděče do flash paměti NOR. To, jak vypadá oživovací stanoviště, ukazuje obrázek Oživovací test probíhá v těchto krocích: Umístění základní desky do fixtury v tomto kroku se do základní desky zasunou testovací moduly Wi-Fi a GSM. Celá základní deska se poté umístí do fixtury. Fixtura je zobrazena na obrázku Jedná se o formu, která slouží k zafixování desky. Tato fixtura obsahuje hřebínky, které umožní elektrická měření na patřičných místech základní desky směrovače v průběhu testů. Fixtura taktéž umožňuje napojení na sériový port, kterým se zavaděč operačního systému ovládá. 2. Nahrání zavaděče OS do paměti NOR pomocí rozhraní JTAG v tomto kroku se provede uložení zavaděče operačního systému do flash paměti NOR pomocí JTAG programátoru. Součástí tohoto kroku je i přeměření napájecích zdrojů na základní desce zařízení. 3. Otestování tlačítka reset a test SDRAM po předchozím uložení zavaděče do paměti NOR se provede reset základní desky. Tím je spuštěn zavaděč Easyboot, který provede test paměti SDRAM. Od této chvíle se ovládá zavaděč pomocí sériové linky. Nadstavbou CLI zavaděče Easyboot je grafický nástroj (GUI) psaný v jazyce Visual Basic, který přes sériovou linku posílá potřebné příkazy. 4. Zavedení jádra OS přes síťový protokol TFTP po nastavení parametrů Model, Profile a Station se zavede jádro operačního systému přes síťový protokol TFTP. Dále si jádro operačního systému vzdáleně namapuje svůj kořenový adresář pomocí NFS. Tento kořenový adresář je uložen na testerovském serveru. Následuje spuštění démonu ER v módu tester ( ). K ovládání testerovského módu se používá stejná grafická nadstavba (GUI) jaká se používá v kroku číslo 3. Od tohoto okamžiku se veškeré testy a operace provádí se zavedeným operačním systémem pomocí zmíněného démona. 5. Zápis sériového čísla pomocí čtečky čárových kódů se načte sériové číslo směrovače, které se pomocí démona ER uloží do paměťového oddílu LICENCE.

69 2.6. Oživovací proces směrovače 2N R SpeedRoute 6. Baterie testů jedná se o sadu testů, které otestují funkčnost základní desky směrovače. Testy zahrnují měření napěťových úrovní na předem definovaných bodech základní desky směrovače, testování Dual-tone multi-frequency signaling (DTMF), testování flash pamětí NAND a NOR. Dále se testují jednotlivé ethernetové porty LAN a komunikace s Wi-Fi a GSM modulem. 7. Uložení reportu testu na testerovský server report o testu se ukládá do adresáře reportů na testerovský server. 8. Odstranění základní desky z fixtury v tomto kroku jsou základní desce odebrány testovací moduly GSM a Wi-Fi. Dále je základní deska odstraněna z fixtury a připravena k expedičnímu testu. Po provedení tohoto testu paměť NOR obsahuje zavaděč operačního systému. Dále paměťový oddíl LICENCE obsahuje sériové číslo produktu. Základní deska je schopná nabootovat operační systém, zatím však ale žádný neobsahuje. Obrázek 2.16: Ukázka stanoviště, na kterém probíhá oživovací test 69

70 2. Analýza a návrh Obrázek 2.17: Ukázka fixtury pro základní desku směrovače 2N R EasyRoute Expediční test Expediční test má za úkol připravit směrovač k expedici. To zahrnuje kompletaci zařízení a nahrání operačního systému do paměti NAND. Během kompletace je směrovač vybaven Wi-Fi a GSM modulem. Tyto moduly už v zařízení zůstávají. Po kompletaci směrovače 2N R EasyRoute je možné stále využívat sériovou linku tzn., že GUI nástroj, který řídí expediční test, ovládá směrovač pomocí sériové linky až do konce testu. Dále expediční test zahrnuje testy jednotlivých služeb směrovače, např. test provoláním, kdy se ze směrovače uskuteční hovor přes síť GSM. Opět se tyto testy spouští přes testerovské rozhraní démona ER. Ukázka stanoviště, na kterém probíhá expediční test najdeme na obrázku Expediční test probíhá v těchto krocích: Odblokování na operátora v tomto kroku se směrovač odblokuje na konkrétního operátora. 2. Načtení MAC adres v tomto kroku se směrovači přidělí zakoupené MAC adresy. To se týká síťových rozhraní LAN a WAN. MAC adresa Wi-Fi modulu

71 2.6. Oživovací proces směrovače 2N R SpeedRoute je načtena přímo z karty. Děje se tak pro pozdější uložení do paměťového oddílu LICENCE. 3. Test Wi-Fi modulu v tomto kroku se otestuje modul Wi-Fi. V testu se testuje schopnost inicializace AP a schopnost připojení směrovače k AP. 4. Test GSM modulu v tomto kroku se provoláním otestuje modul GSM. Dále se načte IMEI tohoto modulu pro pozdější uložení v oddílu LICENCE. 5. Zápis informací do paměťového oddílu LICENCE v tomto kroku se do paměťového oddílu LICENCE ukládají MAC adresy rozhraní LAN, WAN a modulu Wi-Fi, dále pak IMEI modulu GSM. 6. Nahrání operačního systému do paměti NAND po zápisu informací do paměťového oddílu LICENCE dojde k zápisu do paměťových oddílu KERNELx, ROOTx a ENVx. Od této chvíle směrovač obsahuje operační systém. 7. Smazání konfigurace v tomto kroku se nastaví defaultní konfigurace směrovače smazáním paměťového oddílu APP. 8. Nahrání zavaděče operačního systému v tomto kroku dojde k zápisu zavaděče OS do flash paměti NOR. Je možné, že mezi oživovacím a expedičním testem uběhne několik měsíců, proto se do směrovače nahrává nejaktuálnější verze zavaděče OS. 9. Kontrola zavedení operačního systému v tomto kroku se testuje korektní zavedení operačního systému z flash paměti NAND. Výstupem tohoto expedičního testu je hotový produkt připravený k prodeji. Obrázek 2.18: Ukázka stanoviště, na kterém probíhá expediční test směrovače 2N R EasyRoute 71

72 2. Analýza a návrh Možné způsoby oživení základní desky směrovače 2N R SpeedRoute Oživovací proces je spojen s bootovacími schopnostmi procesoru. Procesor na základní desce podporuje bootování z těchto periferií. sériové rozhraní SPI sériové rozhraní I 2 C 8-Bit NOR Flash 16-Bit NOR Flash (Default) Z jiných než těchto periferií bootovat nelze. Výchozím nastavením je bootování z 16-bitové flash paměti NOR. Právě na této paměti bude uložen primární zavaděč, který je předmětem této diplomové práce. V hardwarovém návrhu zavaděče 2N R SpeedRoute se rozhodlo o tom, že nebudou vyvedené kontakty pro programátor JTAG. Využito bude sériové rozhraní I 2 C. Tento způsob byl zvolen kvůli omezenému místu na základní desce směrovače. O způsobu bootování rozhodne jumper, jehož zapojení vyvolá bootování přes sériové rozhraní I 2 C Úskalí v oživovacím procesu produktu 2N R SpeedRoute Oživovací proces nekomplikuje pouze nepřítomnost JTAGu 18. S novým směrovačem přichází i nový návrh produktu tzn. jiný plast, ve kterém bude základní deska směrovače zasazena. To ovlivní především expediční test, kdy po kompletaci zařízení nebude dostupný sériový port, se kterým se doposud expediční test řídil. Tento problém vyřeší již zmíněný protokol Caller ( ), který umožní nastavení parametrů pro zavedení jádra OS ze serveru TFTP příjmem speciálního paketu Caller boot request. Testerovské rozhraní démona ER se po zavedení operačního systému bude ovládat pomocí ethernetové rozhraní na otevřeném TCP portu Tímto způsobem se do směrovače 2N R EasyRoute nahrává zavaděč OS. 72

73 2.7. Cíl práce a návrh řešení 2.7 Cíl práce a návrh řešení Jedná se o poslední a velmi důležitou část této kapitoly. Stanovují se zde úkoly vyplývající z předchozí analýzy. Dále je v této části snaha o zachycení toho, jakým způsobem se bude ubírat plnění těchto úkolů Cíle vyplývající z analýzy Zadání této diplomové práce stanovuje několik dílčích úkolů. Ty rozdělují práci na dvě implementační části. Tyto části jsou: Realizace zavaděče operačního systému Realizace podpůrných nástrojů pro produkční linku Níže budou definovány požadavky na tyto dvě implementační části Požadavky na realizaci zavaděče operačního systému Pro zavedení operačního systému je třeba zrealizovat zavaděč, který dokáže zavést jádro operačního systému z paměti typu NAND flash, nebo přes síťový protokol TFTP (případně NFS). Jak již bylo napovězeno, pro urychlení vývoje se k tomu použije právě zavaděč Das U-boot z SDK firmy Mindspeed. Tento zavaděč podporuje procesory řady Comcerto 1000 a umožňuje zavedení operačního systému přes zmíněné způsoby zavádění. Ve výchozí sestavě vyhovuje zavaděč U-boot základní desce vývojového kitu, ne však novému směrovači 2N R SpeedRoute. Zavaděč z SDK je třeba upravit tak, aby bylo možné zachovat principy, které jsou vlastní směrovači 2N R EasyRoute (např. použití starého systému proměnných). Je třeba zinicializovat nový ethernetový switch, rozšířit síťový subsystém zavaděče U-boot o protokol Caller a tento protokol otestovat v praxi. Dále se úprava tohoto zavaděče skládá z mnoha drobných úprav, které souvisí s jiným rozvržením paměťových prostorů, rozložení GPIO pinů, ošetření tlačítka reset apod Požadavky na realizaci podpůrných nástrojů pro produkční linku Realizaci podpůrných nástrojů nejvíce ovlivňuje proces oživení nového směrovače viz 2.6. Ten určí i požadavky na jednotlivé nástroje. Mezi nástroje jsou zahrnuty: Realizace inicializačního EEPROM zavaděče operačního systému 73

74 2. Analýza a návrh Realizace emulátoru sériové I 2 C EEPROM paměti Realizace inicializačního EEPROM zavaděče operačního systému Paměť NOR má obsahovat bootloader, který uživateli umožní zavést operační systém. Inicializační EEPROM zavaděč je potřeba z důvodu toho, že v prvotním stádiu, kdy se základní deska vyrobí, není ve flash paměti NOR uloženo vůbec nic, proto není boot směrovače možný. Protože procesor podporuje bootování ze sériových I 2 C EEPROM pamětí, byla zvolena tato možnost oživení směrovače. Je potřeba zrealizovat menší zavaděč s omezenou funkcionalitou, který dokáže zavést zavaděč primární. Primární zavaděč je ten, který bude používat uživatel, a který bude permanentně uložen v paměti NOR flash. Důvodem, proč se nemůže použít zavaděč pouze jeden, je velikost hlavního zavaděče, která se pohybuje okolo 150 kb. Maximální velikost sériové I 2 C EEPROM paměti je 64 kb, tudíž její velikost nedostačuje. Realizace emulátoru sériové I 2 C EEPROM paměti Je třeba navrhnout emulátor sériové I 2 C EEPROM paměti. Tento emulátor bude simulovat chování sériové I 2 C EEPROM paměti a bude náhradou paměti fyzické. V součinnosti s řízením na straně PC urychlí proces zdlouhavého nahrávání dat do paměti EEPROM. Pokud by to umožnil procesor či sběrnicový cyklus I 2 C EEPROM paměti, bylo by možné překonat hranici 64 kb (maximální velikost sériové I 2 C EEPROM paměti) a úplně se tak vyhnout použití EEPROM zavaděče Návrh na úpravy a rozšíření zavaděče Das U-boot I když zavaděč z použitého SDK poskytuje značnou část funkcionality, není upraven pro základní desku nového směrovače. Zavaděč bude nutné zmodifikovat a přeportovat na nové zařízení. Níže jsou uvedeny konkrétní prvky, které modifikace obnáší. 74 Vytvoření nové konfigurace pro směrovač 2N R SpeedRoute Bude vytvořena konfigurace, která bude určena novému směrovači. V této konfiguraci bude třeba definovat rozložení paměťového prostoru, nastavit mapování ethernetové MAC vrstvy apod. Navrhl jsem toto (2.13) rozložení paměťového prostoru. Příliš se neliší od rozložení paměťového prostoru v zavaděči 2N R EasyRoute (2.2.4). Navíc je zde pouze paměťový oddíl UBOOT-ENV, který obsahuje proměnné zavaděče U-boot. V potaz jsem bral i možnost umístit jádro přímo do souborového systému JFFS2, tím by jsem odstranil paměťové oddíly KERNEL0 a KERNEL1. Toto řešení jsem však zamítl. Prohledávání souborového systému JFFS2 trvalo příliš dlouho. Prioritou zavaděče operačního systému je především rychlé zavedení operačního systému.

75 2.7. Cíl práce a návrh řešení Velikost oddílu Název oddílu Zařízení mtd Typ paměti 256 kb U-BOOT mtd0 64 kb UBOOT-ENV mtd1 64 kb ENV0 mtd2 64 kb ENV1 mtd3 64 kb LICENCE mtd4 8 MB KERNEL0 mtd5 8 MB KERNEL1 mtd6 32 MB ROOT0 mtd7 32 MB ROOT1 mtd8 32 MB APP mtd9 NOR NAND Tabulka 2.13: Organizace paměťového prostoru ve směrovači 2N R SpeedRoute Rozšíření instrukční sady Uživatelské rozhraní zavaděče U-boot, bude rozšířeno o příkaz pojmenovaný er. Tento příkaz, pokryje veškerou funkcionalitu, kterou má zavaděč splňovat. Na jednotlivé operace nebude využíváno skriptů v uživatelském prostředí zavaděče U-boot. Drobné úpravy spojené s portací zavaděče Tyto úpravy se týkají jak uživatelského rozhraní, tak samotné inicializace při startu směrovače. Jedná se o tyto úpravy: Polymorfní boot zavaděče Ovládání hlavních LED diod směrovače Detekce tlačítka reset Umožnění vstupu do uživatelského CLI na základě přístupového kódu Bude zprovozněno ovládání General Purpose Input/Output (GPIO) pinů procesoru. Toto ovládání GPIO pinů umožní ovládání LED diod, umožní reset okolních periferií a detekci stisku tlačítka reset. Pod bodem polymorfní boot se skrývá schopnost zavaděče rozpoznat paměťový prostor, ze kterého zavaděč startuje. Pokud zavaděč zjistí, že startuje z paměti RAM 19, bude automaticky přeskočena nízkoúrovňová inicializace, která by nám start z prostoru RAM znemožnila 20. Nízkoúrovňovou inicializaci a relokaci zavaděče je možné v zavaděči U-boot vynechat. Využijí se k tomu definice preprocesoru 21 v konfiguraci základní desky. Polymorfní boot slouží k automatizaci tohoto nastavení. Provádí se proto, aby na oživovací lince nemusely být zavaděče dva. Jeden pro start z paměťového prostoru RAM a druhý pro start z paměťového prostoru NOR a EEPROM boot. 19 Inicializační EEPROM bootloader zavádí hlavní zavaděč právě z paměti RAM. 20 Došlo by k přenastavení procesoru a znemožnění přístupu do RAM. 21 CONFIG_SKIP_RELOCATE_UBOOT a CONFIG_SKIP_LOWLEVEL_INIT 75

76 2. Analýza a návrh Vstup do příkazové řádky je zabezpečen přístupovým kódem. Bude potřeba dopsat jednoduchý parser přístupového kódu a začlenit ho do startu zavaděče U-boot. Rozšíření síťové vrstvy o protokol Caller Protokol Caller nehrál ve výrobě starého routeru 2N R EasyRoute žádnou roli. Existoval však základní koncept použití tohoto protokolu. Bude nutné tento protokol zařadit do síťového subsystému zavaděče U- boot a otestovat. Vytvoří se funkce pro obsluhu komunikace přes protokol Caller a upraví se start zavaděče tak, aby bylo možné detekovat pakety protokolu Caller určené pro dané zařízení. Inicializace ethernetového switche AR8328N Nová základní deska obsahuje gigabitový ethernetový switch AR8328N, který se stará o připojení směrovače do počítačové sítě ethernet. Tento switch se nenachází na vývojovém kitu firmy Mindspeed a SDK vývojového kitu toto zařízení nepodporuje. Je třeba tento switch zinicializovat a nastavit. K nastavení tohoto switche se používá sériové rozhraní Management Data Input/Output (MDIO). Jedná se o rozhraní, které podporuje většina síťových zařízení. Zavaděč U-boot z SDK je na komunikaci po tomto rozhraní připraven a plně MDIO podporuje. Inicializace switche zahrnuje nastavení příslušných registrů v zařízení, které zajistí příslušné mapování fyzických portů na GMAC vrstvu apod. Ethernetový switch je připojen k procesoru jedním rozhraním RGMII (WAN) a jedním rozhraním GMII (LAN). Gigabit Media Independent Interface (GMII) zajišťuje rozhraní mezi vrstvou MAC (Media Access Control) v síťovém zařízení a fyzickou vrstvou. Myšlenka nezávislosti rozhraní je taková, že máme jednu vrstvu MAC, kterou jsme schopni připojit k různým druhům fyzických vrstev. Rozebírat tyto rozhraní je za hranicemi této práce, odkazuji na (12). Reduced Gigabit Media Independent Interface (RGMII) je redukovaná verze GMII, která obsahuje polovinu datových vodičů při zachování gigabitové rychlosti. Více najdeme (12). Připojení ethernetového switche na GEMAC rozhraní procesoru je vidět na obrázku Dále je na obrázku vidět i vnitřní mapování switche mezi rozhraním RGMII (či GMII) na GEMAC vrstvou switche Návrh na způsob oživení základní desky směrovače Možnosti, jakými je možné základní desku směrovače oživit, jsou značně limitované. Může za to již zmíněný hardwarový návrh základní desky a bootovací možnosti procesoru. K oživení se bude vždy používat I 2 C sériová sběrnice, na kterou se bude připojovat sériová I 2 C EEPROM paměť. Na této paměti bude 76

77 2.7. Cíl práce a návrh řešení Obrázek 2.19: Návrh mapování GMAC PHY ethernetového switche (2) menší inicializační zavaděč, který umožní zavedení primárního zavaděče, či přímo jádra operačního systému pomocí síťového protokolu NFS nebo TFTP. Použít zavaděč pouze jeden není možné, protože se primární zavaděč svojí velikostí na EEPROM paměť nevejde. Tento problém by pravděpodobně šel obejít použitím emulátoru sériové I 2 C EEPROM paměti. Definuji dva stavy základní desky směrovače. Základní desku směrovače považujeme za živou, pokud umí nabootovat bez pomoci externí I 2 C EEPROM paměti. Základní deska je připravena k expedici, pokud obsahuje nahraný operační systém v paměti NAND flash. Předvedu možné scénáře pro oživení základní desky směrovače 2N R SpeedRoute. Scénáře jsou zobrazeny níže viz Jedná se víceméně o scénář jeden, který by v případě použití emulátoru I 2 C EEPROM paměti, zkrátil celý proces o jeden krok. Za zvážení stojí i scénář, kdy EEPROM zavaděč dokáže sám zavést operační systém. Ve všech těchto scénářích figuruje stažení požadovaného souboru (jádro operačního systému či plnohodnotný zavaděč) některým síťovým protokolem (TFTP či NFS). Praxe v oživovacím procesu směrovače 2N R EasyRoute ukázala, že je nevhodné mít fixní množinu parametrů Model a Profile, proto v dalším návrhu zavaděčů musí být zahrnuta možnost vytvoření uživatelské množiny těchto parametrů. 77

78 2. Analýza a návrh Scénář 1 1. Připojení I 2 C EEPROM paměti 2. Start inicializačního EEPROM zavaděče 3. Zavadení hlavního zavaděče 4. Zavedení jádra operačního systému 5. Oživení základní desky pomocí ER démona Scénář 2 1. Připojení I 2 C EEPROM emulátoru 2. Start plnohodnotného zavaděče 3. Zavedení jádra operačního systému 4. Oživení základní desky pomocí ER démona Scénář 3 1. Připojení I 2 C EEPROM paměti 2. Start inicializačního EEPROM zavaděče 3. Zavedení jádra operačního systému 4. Oživení základní desky pomocí ER démona Obrázek 2.20: Scénáře způsobu oživení směrovače 2N R SpeedRoute Návrh na realizaci incializačního EEPROM zavaděče Oživení za pomoci I 2 C EEPROM paměti bylo zvoleno potom, co se zjistilo, že nebude možné použít k oživení základní desky programátor JTAG 22. Výsledný EEPROM zavaděč bude zredukovanou verzí plnohodnotného zavaděče Das U-boot. Bude poskytovat pouze nejnutnější funkcionalitu, která zajistí požadovanou velikost 23 výsledného spustitelného binárního souboru. V tabulce 2.14 jsou nastíněny minimální požadavky na inicializační EEPROM zavaděč. Funkce EEPROM zavaděče se budou rozšiřovat až v případě dosažení těchto minimálních požadavků, a to opět na základě velikosti výsledného binárního souboru zavaděče. V minimálních požadavcích je jednoduchá příkazová řádka, 22 Oživení programátorem JTAG byl způsob použitý v oživovacím procesu směrovače 2N R EasyRoute. 23 Velikost binárního souboru zavaděče nesmí přesáhnout 64 kb. 78

79 2.7. Cíl práce a návrh řešení U-boot EEPROM U-boot Velikost cca 150 kb omezená < 64kB Funkce příkazová řádka protokol caller NFS TFTP JFFS2 Zavedení linuxového jádra ze sítě( NFS, TFTP ) Zavedení linuxového jádra z paměti NAND Zavedení U-bootu Dynamická alokace paměti Tabulka 2.14: Minimální požadavky na inicializační EEPROM zavaděč a srovnání s plnohodnotným U-boot zavaděčem která umožní nastavit práci se sítí. Dále bude zapotřebí síťového subsystému, konkretně podpory protokolu TFTP. Zavaděč musí minimálně podporovat zavedení zavaděče plnohodnotného Návrh zařízení na emulaci EEPROM paměti Důvod realizace již byl nastíněn v Princip použití emulátoru je zobrazen na obrázku PC bude poskytovat data, která budou obsahem virtuální EEPROM paměti emulátoru. Tento emulátor bude mít na starosti interpretaci těchto dat procesoru ve směrovači 2N R SpeedRoute. Ke zvážení bylo to, jaké komunikační rozhraní v PC bude pro emulátor zvoleno. Sériový či paralelní port se nezdál být vhodný s ohledem na zastaralost rozhraní a na maximální přenosovou rychlost protokolu I 2 C. Tato rychlost se v High Speed módu pohybuje okolo 3.4 Mbit/s. Analýza komunikace ale v průběhu bootování z I 2 C sběrnice ukázala rychlost hodin SCL 92 khz viz 2.22, tedy podstatně menší. Přesto jsem se po zvážení všech schůdných variant rozhodl pro rozhraní USB (Universal Serial Bus). Výhoda tohoto řešení je zřejmá. Jedná se o jedno z nejpoužívanějších rozhraní dnešní doby. Nevýhodou je však složitost komunikace, která je cenou za univerzálnost tohoto rozhraní. Srdcem emulátoru bude mikroprocesor firmy Microchip. Přesněji procesor PIC18F2550, který je oblíbený pro svůj USB framework, který je k němu dodáván. Tento framework umožní flexibilní práci s USB rozhraním a značně urychlí samotné nasazení procesoru. Navíc procesor PIC18F2550 umožňuje komunikaci přes sériovou I 2 C sběrnici a to jak v režimu slave, tak v režimu master. Pro potřeby emulátoru je potřebný právě mód slave. 79

80 2. Analýza a návrh Obrázek 2.21: Princip použití emulátoru I 2 C EEPROM paměti Taktéž jsem zvažoval variantu přes integrovaný obvod FT2232H firmy FTDI, který je pro svojí jednoduchost masově nasazován. Variantu s procesorem PIC18F2550 jsme zvolil kvůli tomu, že jsem chtěl napsat vlastní linuxový ovladač pro práci s tímto emulátorem. To se bohužel z časových důvodů nepovedlo. Více o realizaci je možné se dočíst v sekci Obrázek 2.22: Analýza komunikace mezi procesorem a I 2 C EEPROM pamětí 80

81 Kapitola 3 Realizace Tato kapitola se zaměřuje na realizaci bodů, které vyplynuly z poměrně rozsáhlé teoretické přípravy viz kapitola 2. Hrubé rozdělení jednotlivých bodů implementace je uvedeno níže. Realizace zavaděče operačního systému Realizaci podpůrných nástrojů pro produkční linku Realizace inicializačního EEPROM zavaděče operačního systému Realizace emulátoru sériové I 2 C EEPROM paměti 3.1 Realizace zavaděče operačního systému Jak již bylo zmíněno, vycházel jsem ze zavaděče operačního systému Das U- boot, který byl součástí SDK vývojového kitu firmy Mindspeed. Celý projekt jsem rozšířil o konfiguraci nové základní desky. Dále jsem vytvořil nový příkaz v uživatelském rozhraní, který poskytuje veškerou, v zavaděči požadovanou, funkcionalitu. Rozšíření se dotklo i síťového subsystému, který byl rozšířen o protokol Caller. Vývoj těchto částí probíhal na vývojovém kitu (c1kevm) firmy Mindspeed. V poslední fázi implementace jsem připravoval zavaděč pro konkrétní hardware, kterým byl prototyp směrovače 2N R SpeedRoute. I když tato implementační část byla z větší části portace zdrojového kódu, bylo třeba dělat úpravy s rozvahou a jednotlivé části průběžně testovat. V implementaci jsem se snažil nezasahovat příliš do hloubky. Mojí snahou bylo udržet styl psaní kódu, který je celému projektu Das U-boot vlastní. Implementace zavaděče operačního systému zahrnovala: Vytvoření nové konfigurace pro směrovač 2N R SpeedRoute Přizpůsobení konfigurace pro směrovač 2N R SpeedRoute 81

82 3. Realizace Rozšíření instrukční sady Drobné úpravy spojené s portací zavaděče Polymorfní boot zavaděče Ovládání hlavních LED diod směrovače Detekce tlačítka reset Umožnění vstupu do uživatelského CLI na základě přístupového kódu Rozšíření síťové vrstvy o síťový protokol Caller Inicializace ethernetového switche AR8328N Návrh řešení k jednotlivým bodům implementace obsahuje sekce Dále bude následovat pouze konkrétní popis realizace těchto bodů Vytvoření nové konfigurace pro směrovač 2N R SpeedRoute Jako defaultní konfiguraci jsem si vzal za příklad konfiguraci vývojového kitu c1kevm. Vytvoření nové konfigurace jsem provedl ve třech krocích. 1. Vytvoření adresářové struktury pro zařízení 2N R SpeedRoute ve složce./board 2. Vytvoření konfiguračního souboru pro zařízení 2N R SpeedRoute 3. Úprava souboru Makefile Vytvoření adresářové struktury pro zařízení 2N R SpeedRoute ve složce./board Každé podporované zařízení má svojí vlastní složku ve zvláštním tvaru 24. V této složce jsou umístěny zdrojové kódy, které se týkají pouze tohoto zařízení. Vytvořil jsem adresářovou strukturu./board/2n/speedroute a zkopíroval do ní soubory ze složky./board/mindspeed/c1kevm. Dále jsem zkopíroval složku./board/mindspeed/common do složky./board/2n/. Tato složka obsahuje společné zdrojové kódy v rámci všech základních desek výrobce. Výsledná adresářová struktura je vidět níže. Mezi důležité soubory, které leží ve složce./board/2n/speedroute, patří linker skript u-boot.lds a soubor board.c, který obsahuje funkce pro inicializaci paměti SDRAM, NOR apod. 24./board/<organization_name>/<device_name> 82

83 3.1. Realizace zavaděče operačního systému / board 2N common speedroute Vytvoření konfiguračního souboru pro zařízení 2N R SpeedRoute Ve složce./include/configs najdeme konfigurační soubory všech podporovaných zařízení. Jako vzor jsem použil opět konfigurační soubor zařízení c1kevm c1kevm.h a zkopíroval ho na speedroute.h. Výsledný konfigurační soubor je tedy./include/configs/speedroute.h Úprava souboru Makefile Rozšířil jsem Makefile projektu o novou konfiguraci základní desky, aby byla možné celý projekt zkompilovat. Hlavní Makefile najdeme v kořenovém adresáři projektu. xtract_speedroute = $( subst -M83241G,,$( subst _config,,$1)) ############################################################### ## ARM1136 Systems ############################################################### speedroute_ config \ speedroute - M83241G_ config : " TEXT_ BASE = 0 x " >$( obj ) board /2N/ speedroute / -p $( obj ) [ " $( findstring M83241G, $@)" ]; then \ echo "# include < configs / m8324xg.h >" >> $( obj ) include / config.h;\ echo "# define COMCERTO_ PART_ NO \" M83241G \"" >> $( obj ) include / config.h;\ echo "... configured for speedroute - M83241G "; \ else \ echo "# include < configs / m8324xg.h >" >> $( obj ) include / config.h;\ echo "# define COMCERTO_ PART_ NO \" M83241G \"" >> $( obj ) include / config.h;\ echo "... configured for speedroute - M83241G ";\ MKCONFIG ) -a $( call xtract_ speedroute, $@) arm arm1136 speedroute 2N comcerto Úprava hlavního Makefile souboru (./Makefile) Po těchto třech krocích je připravena konfigurace základní desky směrovače, kterou bude třeba změnit k obrazu výsledného směrovače 2N R SpeedRoute. 83

84 3. Realizace Kompilace projektu probíhá za pomoci cross kompilátoru Toolchain ARM GCC Glibc 2.7. Způsob kompilace projektu pro novou konfiguraci základní desky probíhá úplně stejně jako v sekci pro základní desku vývojového kitu Přizpůsobení konfigurace pro směrovač 2N R SpeedRoute Již existující konfiguraci, kterou jsem pro směrovač připravil, bylo třeba upravit. Celá tato sekce pojednává o změnách v konfiguračním souboru speedroute.h. Části konfiguračního souboru, které souvisejí s implementací dalších bodů realizace zavaděče U-boot, budou zmíněny v příslušných sekcích Definice mtd oddílů Stejně jako je tomu v ukázce 2.2.4, jsem v konfiguraci základní desky směrovače 2N R SpeedRoute nadefinoval rozložení paměťových oddílů, které jsem navrhl v sekci Tyto definice pouze umožní jednodušší práci s pamětí v průběhu vývoje. Jedná se o logické rozdělení paměťového prostoru na MTD oddíly. # define MTDIDS_ DEFAULT \ " nor0 = comcertoflash.0, nand0 = comcertonand " # define MTDPARTS_ DEFAULT \ " mtdparts = comcertoflash.0:256 k(u- boot ),\ 64k( uboot - env ),64k( env0 ),64k( env1 ),64k( licence );\ comcertonand :8m( kernel0 ),8m( kernel1 ),\ 32m( root0 ),32m( root1 ),32m( app )" Ukázka definic mtd oddílů v nové konfiguraci směrovače (./include/configs/speedroute.h) Tyto definice jsou ve vývojovém kitu velice důležité, protože se používají při zavádění operačního systému. Přesněji se proměnná mtdparts, která obsahuje tyto definice, předá jako parametr jádru operačního systému. Ten po startu vytvoří MTD oddíly právě podle definovaného rozložení. Ve směrovači 2N R SpeedRoute se od tohoto způsobu upustilo. Jádro OS v sobě obsahuje vlastní definice MTD oddílů Konfigurace GPIO pinů základní desky směrovače Pro práci s LED diodama a tlačítkem reset, bylo nutné přiřadit periferiím příslušné GPIO piny. Tlačítko RESET je připojené na GPIO pinu s číslem 26. LED diody mají přiřazeny GPIO piny 0, 1, 2 a 3. /* INPUT GPIOs */ # define CONFIG_ RESET_ BUTTON_ GPIO 26 /* OUTPUT GPIOs */ 84

85 3.1. Realizace zavaděče operačního systému # define CONFIG_ LED0_ GPIO 0 # define CONFIG_ LED1_ GPIO 2 # define CONFIG_ LED2_ GPIO 1 # define CONFIG_ LED3_ GPIO 3 Ukázka definic GPIO pinů v nové konfiguraci směrovače (./include/configs/speedroute.h) Konfigurace defaultních proměnných Konfigurační soubor základní desky vývojového kitu (c1kevm) obsahoval velké množství defaultních proměnných 25. Mezi těmito proměnnými bylo i velké množství skriptů 26. Protože veškerou funkcionalitu obstará nový příkaz er, není již těchto skriptů potřeba. Z tohoto důvodu jsem defaultní proměnné maximálně zredukoval. Definici výchozích proměnných vidíme níže. # define CONFIG_ EXTRA_ ENV_ SETTINGS \ " hostname = speedroute \0" \ " mtdids =" MTDIDS_ DEFAULT "\0" \ " mtdparts =" MTDPARTS_ DEFAULT "\0" \ " partition =" MTDPARTITION_ DEFAULT "\0" \ " mtddevnum =2\0 " \ " mtddevname =fs \0" \ " ram_size =128 M\0" Definice profilů a modelů Význam parametrů profile a model je vysvětlen v sekci V této sekci je také zmíněno to, že množina těchto parametrů je fixní. Definici profilů a modelů vidíme níže. # define CONFIG_ DEFAULT_ PROFILE 0 # define CONFIG_ DEFAULT_ MODEL 0 # define CONFIG_ PROFILES ( X) \ X(" private ",(172,16,1,2), (255,255,255,0), (172,16,1,1), (172,16,1,1) ) \ X(" mars ",(192,168,3,201), (255,255,252,0), (192,168,3,200), (192,168,3,200) ) \ X(" sitronics ",(192,168,111,125), (255,255,255,0), (192,168,111,120), (192,168,111,120) ) # define CONFIG_ MODELS ( X) \ X (1) Ukázka definic parametrů Profil a Model v nové konfiguraci směrovače (./include/configs/speedroute.h) 25 Definice preprocesoru CONFIG_EXTRA_ENV_SETTINGS. 26 Více o skriptech v

86 3. Realizace To, jak pracuje s těmito definicemi, bude vysvětleno v sekci Tyto definice i s makrem X byly portovány ze starého zavaděče Easyboot. Výběr výchozího profilu, či modelu se provádí pomocí definic: CONFIG_DEFAULT_PROFILE CONFIG_DEFAULT_MODEL Definice proměnných JOES_ENV a oddílu LICENCE Staré proměnné ze směrovače 2N R EasyRoute jsem zde v zavaděči U-boot pojmenoval JOES_ENV. Jsou pojmenovány po vývojáři, který na produktu pracoval přede mnou. Obsah a význam těchto proměnných najdeme v sekci Oddíly ENV0, ENV1 a LICENCE jsou umístěny v prostoru paměti NOR, hned za paměťovým oddílem, kam ukládá své proměnné zavaděč U- boot. Bylo nutné nadefinovat offsety jednotlivých oddílů. Tyto offsety se počítají od adresy CFG_ENV_ADDR, která je nastavená takto: #define CFG_ENV_ADDR (PHYS_FLASH1 + 4 * PHYS_FLASH1_SECT_SIZE) Definice PHYS_FLASH1 je adresa začátku paměti NOR flash. PHYS_FLASH1_SECT_SIZE je velikost sektoru 27 paměti NOR. Čtyři sektory se vynechávají kvůli zavaděči U-boot, který je na těchto prvních čtyřech sektorech uložen Definice offsetů Takto jsem nadefinoval jednotlivé offsety paměťových oddílů. Všechny paměťové oddíly jsou definovány po 64 kb. # define CFG_ ENV_ UBOOT_ SIZE 0 x10000 # define CFG_ ENV_ ENVX_ SIZE 0 x10000 # define CFG_ ENV_ LICENCE_ SIZE 0 x10000 # define CFG_ ENV_ UBOOT 0 x10000 # define CFG_ ENV_ ENV0 CFG_ ENV_ UBOOT # define CFG_ ENV_ ENV1 CFG_ ENV_ ENV0 + CFG_ ENV_ ENVX_ SIZE # define CFG_ ENV_ LICENCE CFG_ ENV_ ENV1 + CFG_ ENV_ ENVX_ SIZE Ukázka definic offsetů paměťových oddílů v nové konfiguraci směrovače (speedroute.h) Rozšíření instrukční sady zavaděče U-boot V prvním návrhu jsem instrukční sadu rozšířil o pět příkazů. Toto řešení se mi zdálo ne příliš dobré, protože funkce byly rozdrobené a zanikaly mezi standardními funkcemi zavaděče U-boot. Navrhl jsem tedy řešení, kde bude existo- 27 Základní jednotka pro práci s touto pamětí. 86

87 3.1. Realizace zavaděče operačního systému vat pouze jeden příkaz, který zajistí veškerou potřebnou funkcionalitu, kterou směrovač 2N R SpeedRoute může potřebovat. Rozšířil jsem instrukční sadu zavaděče U-boot o příkaz er. Při psaní tohoto příkazu jsem se snažil maximálně využívat prostředí zavaděče U-boot, především systém jeho proměnných, které se využívají napříč celým zavaděčem. Stejně tak jsem často používal hotové příkazy zavaděče pomocí funkce run_command(). Nejdříve popíši to, jak se nový příkaz vytvořil. Poté se budu věnovat jeho složení a funkcím, které tento příkaz umožňuje Vytvoření příkazu er Uživatelské příkazy jsou umístěny ve složce./common. Dále je ve zvyku pojmenovávat zdrojový soubor cmd_<name_of_cmd>.c. Pro nový příkaz jsou potřeba udělat několik kroků. První dva kroky jsou zcela jasné. 1. Vytvoření zdrojového souboru cmd_er.c v./common 2. Přidání objektu cmd_er.o do Makefile v./common 3. Použití makra U_BOOT_CMD 4. Vytvoření funkce pro obsluhu příkazu 5. Přidání definice příkazu do cmd_confdefs.h Makro U_BOOT_CMD Toto makro naplní strukturu cmd_tbl_t, která obsahuje informace o příkazu, a zviditelní nový příkaz zavaděči U-boot. Děje se tak pomocí speciální sekce u_boot_cmd_start, která se definuje v linker skriptu základní desky 28. V konkrétním případě vypadá použití makra takto: /* name : is the name of the commad. THIS IS NOT a string. maxargs : the maximumn numbers of arguments this function takes command : Function pointer (* cmd )( struct cmd_ tbl_ s *, int, int, char *[]) ; usage : Short description. This is a string help : long description. This is a string U_BOOT_CMD (name, maxargs, repeatable, command," usage "," help ") */ U_BOOT_CMD (er, CFG_MAXARGS, 1, do_er, USAGE, HELP_MESSAGE_LONG ); Ukázka použití makra U_BOOT_CMD (./common/cmd_er.c) 28./board/2N/speedroute/u-boot.lds 87

88 3. Realizace První parametr vyjadřuje jméno příkazu (zde er ). Druhý parametr říká to, jaký je maximální možný počet argumentů příkazu. V příkazové řádce zavaděče U-boot je zvykem to, že pokud je parseru příkazové řádky odeslán prázdný příkaz (potvrzením klávesou Enter ), je vyvolán poslední spuštěný příkaz. Třetí parametr říká to, jestli je příkaz takto zopakovatelný ( 1 pro ANO, 0 pro NE). Čtvrtý parametr je ukazatel na obslužnou funkci příkazu. Předposledním parametrem je USAGE zpráva použitá při nesprávném použití příkazu. Poslední příkaz je nápověda zobrazitelná příkazem help. Vytvoření funkce pro obsluhu příkazu Tato funkce má speciální tvar, který je nutné dodržet. Konkrétní případ prototypu funkce do_er() vidíme níže. int do_er ( cmd_ tbl_ t * cmd, int flag, int argc, char * argv []) ; První parametr je ukazatel na strukturu cmd_tbl_t, která obsahuje informace o příkazu zadané makru U_BOOT_CMD. Druhý parametr flag obsahuje speciální příznaky příkazu. Parametr flag se v příkazu er nevyužívá. Třetí parametr argc obsahuje počet argumentů a poslední parametr seznam těchto argumentů. Návratová hodnota signalizuje chybu a v případě, že žádná chyba nenastane, vrací funkce hodnotu 0. Přidání definice příkazu do cmd_confdefs.h obsahuje definice všech příkazů v zavaděči U-boot. Soubor cmd_confdefs.h Ukázka definice pro příkaz er : # define CFG_ CMD_ ER 0 x ull /* er cmd */ Tyto definice preprocesoru slouží k tomu, aby bylo možné ovládat instrukční set zavaděče z jediného místa. Toto místo je v konfiguračním souboru dané základní desky. Definice CONFIG_COMMANDS potom obsahuje vybraný set instrukcí. Jeden bit v této definici je povolení ( 1 ) nebo zakázání ( 0 ) daného příkazu. /* * Shell configuration */ # define CONFIG_ COMMANDS ( CFG_ CMD_ FLASH CFG_ CMD_ ENV \ CFG_ CMD_ MEMORY CFG_ CMD_ MEMTEST CFG_ CMD_ MII \ CFG_ CMD_ RUN CFG_ CMD_ NET CFG_ CMD_ NAND \ CFG_ CMD_ PING CFG_ CMD_ NFS CFG_ CMD_ I2C \ CFG_ CMD_ EEPROM CFG_ CMD_ ER ) Ukázka použití makra CONFIG_COMMANDS v nové konfiguraci směrovače (speedroute.h) 88

89 3.1. Realizace zavaděče operačního systému Pomocí logické operace AND se poté vytvoří podmínka pro podmíněný překlad daného příkazu. Ukázka pro podmíněný překlad příkazu er v souboru./common/cmd_er.c: #if (CONFIG_COMMANDS & CFG_CMD_ER) Vlastnosti nového příkazu er Tento nový příkaz v sobě obsahuje veškerou funkcionalitu z původního zavaděče Easyboot. Příkaz er vlastně zastřešuje veškeré funkce, které mohl potřebovat uživatel zavaděče Easyboot. Pro urychlení vývoje bylo maximálně využito funkcí, které již zavaděč U-boot obsahoval. Tento příkaz umožní uživateli tyto hlavní funkce: nastavitelnost parametrů Profile, Model a Station aktualizace zavaděče OS ve flash paměti NOR zavedení operačního systému z flash paměti NAND zavedení operačního systému ze sítě pomocí TFTP či NFS přečtení proměnných JOES_ENV a paměťového oddílu LICENCE Zavádění operačního systému ze sítě pomocí NFS Stejně jako u zavaděče Easyboot je i zde samotné stažení jádra ze sítě spárované s pozdějším mapováním kořenového souborového adresáře operačního systému přes NFS. Kvůli tomu je nutné správně nastavit parametry jádra, které jádru nastaví podmínky pro toto mapování. Prvním krokem je stažení jádra ze vzdáleného NFS serveru. Toto stažení provedu pomocí již existujícího příkazu nfs. Cesta k jádru je uložena v proměnné kernel_file, se kterou pracuje funkce na nastavení parametru Model viz Vše se stahuje do operační paměti RAM na adresu CONFIG_JUNK_RAM_ADDR (konkrétně 0x ). sprintf ( command, " nfs %s %s", MK_STR ( CONFIG_JUNK_RAM_ADDR ), getenv (" kernel_file ") ); /* Get uimage */ if ( run_ command ( command, 0) < 0) return 1; Ukázka stažení jádra OS pomocí příkazu nfs (./common/cmd_er.c) Dalším krokem v zavádění systému je připravení příkazové řádky jádra OS. To provádím funkcí set_nfs_args(). Zmíněná funkce připraví parametry v jednom řetězci. Tento řetězec se poté uloží do proměnné zavaděče U-boot s 89

90 3. Realizace názvem bootargs. S proměnnou bootargs pracují všechny příkazy zavaděče U-boot, které se starající o zavádění operačního systému. Následuje samotné volání příkazu bootm, které se stará o zavádění OS z paměti RAM. set_nfs_args (); memset ( command,0, sizeof command ); sprintf ( command, " bootm %s", MK_STR ( CONFIG_JUNK_RAM_ADDR )); /* Boot sequence */ if( run_ command ( command, 0) < 0) return 1; Ukázka zavedení jádra OS pomocí příkazu bootm (./common/cmd_er.c) Příkaz pro zavedení operačního systému pomocí NFS je er boot nfs. Pro customizaci parametrů Model, Station a Profile jsem napsal nápovědu, kterou lze vyvolat příkazem er hint Zavádění operačního systému z flash paměti NAND Zavádění operačního systému z flash paměti NAND se postupem ničím neliší od zavádění operačního systému přes síťový subsystém. Je třeba nahrát zaváděné jádro do operační paměti RAM, a potom použít již hotový příkaz bootm. Postup, jakým se vybírá aktuální oddíl byl popsán v sekci Nejdřív je třeba načíst proměnné JOES_ENV z paměťových oddílů ENV0 a ENV1. Dále rozhodnout o tom, jaký logický oddíl je ten aktuální. To se rozhodne podle proměnné seq, která leží v obou paměťových oddílech JOES_ENV. for (i =0; i <2; i ++) ok[i] = joesenv_fetch (& jenv [i], i? CFG_ENV_ENV1 : CFG_ENV_ENV0 ); if (ok [0]) { if (ok [1]) if ( jenv [0]. seq < jenv [1]. seq ) reverse = 1; } else reverse = 1; Ukázka algoritmu pro výběr aktuálního logického oddílu (./common/cmd_er.c) Když je zjišten aktuální logický paměťový oddíl, nastavím parametry jádra set_nand_args() a pokusím se nahrát jádro do paměti příkazem nboot, který slouží pro nahrávání jádra z paměti NAND. Tomuto příkazu předám jako parametr umístění jádra v paměti NAND (nand0,0 pro paměťový oddíl KERNEL0). Můžu použít i jméno jeho mtd oddílu, k tomu je však potřeba mít 90

91 3.1. Realizace zavaděče operačního systému zapnutou podporu JFFS2 souborového systému. Tuto funkcionalitu nakonec nevyužívám, protože jádro v konečném návrhu leží mimo souborový systém JFFS2. Potom co je jádro nahrané v prostoru RAM, zavedu OS příkazem bootm. Pokud se nepodaří zavést OS z jednoho paměťového oddílu, zkouší se paměťový oddíl druhý. Dále jsem přidal možnost vynucení zavedení OS z paměťového oddílu, který se příkazu er boot nand předá jako parametr. for (i =0; i <2; i ++) { struct joesenv_ t * e; int bank = ( custom? cbank : i ^ reverse ); if (! ok[ bank ]) continue ; e = & jenv [ bank ]; set_nand_args ( bank ); static char command [1000]; sprintf ( command, " nboot %s; bootm ", get_part_name (bank, KERNEL ) ); if (( rc= run_command ( command, 0)) >= 0) return rc; } return rc; Ukázka nahrání jádra OS z NAND paměti pomocí příkazu nboot (./common/cmd_er.c) K zavedení operačního systému z flah paměti NAND v novém směrovači 2N R SpeedRoute slouží příkaz er boot nand <bank_number>, kde číslo logického paměťového oddílu (banky) je volitelné. V této funkci jsem taktéž implementoval kontrolní součet (CRC) kořenového souborového systému. Nakonec jsem však tuto kontrolu nepoužil, protože načítání paměťového oddílu s kořenovým souborovým systémem z paměti NAND bylo příliš pomalé a rapidně zpomalovalo start směrovače Přečtení proměnných JOES_ENV a paměťového oddílu LICENCE Z větší části jsem práci s proměnnými převzal ze zavaděče Easyboot. Zavaděč proměnné z oddílů ENV0 a ENV1 dokáže pouze číst, protože nic jiného nepotřebuje. Všechny funkce pro práci s proměnnými JOES_ENV nalezneme v souboru joesenv.c ve složce./common. Příkaz na vyčtení proměnných je er print env. Čtení proměnných JOES_ENV potřebujeme pro zavedení systému z flash paměti NAND. Paměťový oddíl LICENCE se při startu zavaděče dešifruje a obsah se načte do operační paměti pro další použití, např. v protokolu Caller. Obsah paměťového oddílu můžeme vypsat příkazem er print licence. Zrojové soubory pro práci s proměnnými JOES_ENV a oddílem LICENCE Tyto zdrojové soubory jsou z větší části převzaty ze starého 91

92 3. Realizace zavaděče Easyboot, proto je nebudu rozebírat. Jedná se o zdrojové soubory joesenv.c, licence.c, rc4.c a jejich hlavičkové soubory. Zdrojové soubory najdeme ve složce./common, jejich hlavičky potom ve složce./include Nastavitelnost parametrů Profile, Model a Station Parametry Profile, Model a Station se příkazem er dají vypsat a nastavit. Aktuální nastavené parametry jsou uloženy v globální struktuře er_config, která obsahuje číslo stanice a ukazatele na aktuální model a profil. Deklarace parametrů Profile, Model V sekci jsou uvedeny příklady definic, které používám dále ve zdrojovém souboru cmd_er.c takto: /* { PROFILE_NAME, MY_IP, NETMASK, NFS_SERVER_IP, TFTP_ SERVER_ IP } */ # define XX(a, b, c, d) ((( a) << 24) (( b) << 16) (( c) << 8) (d)) # define X(name, ip, netmask, nfs, tftp ) {name, XX ip, XX netmask, XX nfs, XX tftp }, static struct profile profiles [] = { CONFIG_ PROFILES ( X) }; # undef X # undef XX /* { MODEL_NAME, NFS_ ROOT_ FILESYSTEM, NFS_ KERNEL_ PATH } */ # define X(i) { " LTEZ " #i, "er/ ltez " #i, "/er/ ltez " #i "/ boot / uimage " }, static struct model models [] = { CONFIG_ MODELS ( X) }; # undef X Ukázka užití definic parametrů Profile a Model (./common/cmd_er.c) Jednotlivé definice profilů a modelů se použijí k vytvoření statických polí, se kterými se dále pracuje. Struktura er_config obsahuje ukazatele na prvky těchto polí, přesněji na aktuálně zvolené modely či profily. Více o náplni a použití parametrů Profile, Model a Station najdeme v sekci Paramtery Profile, Model a Station VS proměnné zavaděče U-boot Jak jsem zmínil, snažím se maximálně využít proměnné zavaděče U-boot. Do návrhu zavaděče bylo nutné zahrnout požadavek na customizaci parametrů spojených se zaváděním operačního systému ze sítě. Právě tato customizace je možná přes proměnné zavaděče U-boot, které se vyžívají napříč celým projektem. Nastavení některého z parametrů Profile, Model a Station znamená zadání požadavku k nastavení některé z proměnných zavaděče U-boot. Po nastavení jednoho z parametrů se nastaví struktura er_config s aktuální konfigurací a zavolá se funkce update(), která tyto parametry převede na proměnné zavaděče U-boot. Ukázka tohoto přenosu je níže. 92

93 3.1. Realizace zavaděče operačního systému /* Update profile information */ setenv (" current_profile ", c-> c_profile -> name ); setenv (" ipaddr ", ip_to_str (c-> c_profile ->ip+c-> c_station )); setenv (" netmask ", ip_to_str (c-> c_profile -> netmask ) ); setenv (" nfsip ", ip_to_str (c-> c_profile -> nfs )); setenv (" tftpip ", ip_to_str (c-> c_profile -> tftp )); /* Update model information */ setenv (" current_model ", c-> c_model -> name ); setenv (" root_path ", c-> c_model -> root ); setenv (" kernel_file ", c-> c_model -> kernel ); tmp = get_base_mac_address ( mac ); derive_mac ( tmp, c-> c_station ); tmp = mac2string ( mac ); setenv (" ethaddr ", tmp ); Ukázka funkce update() (./common/cmd_er.c) Parametry Profile a Station se přeloží na proměnné, které se používají v síťovém subsystému zavaděče U-boot. Parametr Model nastaví proměnné, které využívám ve funkci er_nfsboot(). Tato funkce zajišťuje zavádění operačního systému přes NFS. Funkce k nastavení profilů a mo- Nastavení parametrů Profile, Model delů: er print model vypíše seznam dostupných modelů z pole models[]. er print profile vypíše seznam dostupných profilů z pole profiles[]. er set model <MODEL_ID> nastaví model podle zadaného ID modelu. Toto ID je uvedeno u každého modelu z výpisu jednotlivých modelů. Tímto příkazem se přepíše ukazatel v hlavní struktuře er_config, který ukazuje na aktuální model. Poté se zavolá funkce update(), která aktualizuje proměnné zavaděče U-boot. er set profile <PROFILE_ID> nastaví profil podle zadaného ID profilu. Toto ID je uvedeno u každého profilu z výpisu profilů. Tímto příkazem se přepíše ukazatel v hlavní struktuře er_config, který ukazuje na aktuální profil. Poté se zavolá funkce update(), která aktualizuje proměnné zavaděče U-boot. Nastavení parametru Station Nastavení čísla stanice probíhá pomocí příkazu er set station <STATION_NUM>. Tímto příkazem se přepíše číslo stanice v hlavní struktuře er_config aktuální. Poté se zavolá funkce update(), která aktualizuje proměnné zavaděče U-boot. V tomto případě se inkrementuje IP a MAC adresa zavaděče. Aktuální stanici lze vypsat pomocí příkazu er print station. 93

94 3. Realizace Nastavení deaultních parametrů Profile, Model a Station při startu zavaděče Defaultní parametry se nastaví ve funkci param_set_default(), která nastaví číslo stanice na 0. Dále nastaví výchozí profil a model podle definic v konfiguračním souboru základní desky směrovače viz Tato funkce se volá těsně před načítáním uživatelova vstupu z klávesnice při startu zavaděče. Customizace parametrů Profile a Model Customizace se provádí přímo editací proměnných zavaděče U-boot. Tak jsem schopný nastavit jakkýkoliv uživatelský profil, model, či stanici. Nastavení proměnné se provádí příkazem setenv <varible_name> <variable_value>. Nápověda o tom, které parametry je třeba nastavit při zavádění OS ze sítě, se skrývá pod příkazem er hint, který tento seznam parametrů vypíše Aktualizace zavaděče OS ve flash paměti NOR Aktualizace zavaděče se provádí příkazem: er update boot [tftp/nfs] <bootloader_file> Tento příkaz sloužil pouze pro mé potřeby při vývoji zavaděče a nesouvisí s oživovacím procesem, kde se zavaděč bude nahrát v OS pomocí démona ER v testerovském režimu viz Po nahrání souboru do paměti RAM pomocí příkazů tftp nebo nfs se spustí příkaz, který soubor z paměti RAM zapíše do flash paměti NOR. Implementaci tohoto příkazu vidíme níže. sprintf ( command, " protect off 1:0-5; erase 1:0-5; cp.b %X %X ${ filesize }", \ CONFIG_ JUNK_ RAM_ ADDR, PHYS_ FLASH1 ); if( run_ command ( command, 0) < 0) return 1; Ukázka funkce na aktualizaci zavaděče v paměti NOR (./common/cmd_er.c) Pro zápis do paměti NOR je potřeba odemknout zamčené sektory, smazat tyto odemčené sektory paměti NOR a zkopírovat na ně nahraný soubor z paměti RAM 29. Zavaděč U-boot je uložen na prvních čtyřech sektorech flash paměti NOR Použití příkazu er Mapa příkazu je vidět na obrázku 3.1. Jednotlivé parametry funkce zde popíši. set tento parametr se stará o nastavování parametrů Profile, Model a Station. Jako parametr se u modelu a profilu zadává ID profilu či modelu. Toto ID je uvedeno u výpisu jednotlivých profilů či modelů. Pro nastavení stanice se za parametr dá jednoduše požadované číslo stanice. print tento parametr se stará o vypisování parametrů Profile, Model a Station. Dále umí vypsat JOES_ENV proměnné a paměťový oddíl LICENCE. 29 Soubor je stažen na adresu CONFIG_JUNK_RAM_ADDR, na kterou stahuji všechny soubory, které potřebuje příkaz er. 94

95 3.1. Realizace zavaděče operačního systému boot tento parametr slouží k samotnému zavádění operačnímu systému. Zadat lze nand 30 pro zavedení OS z flash paměti NAND nebo nfs pro zavedení OS ze síťe přes NFS. update tento příkaz s parametrem boot je schopný aktualizovat zavaděč ve flash paměti NOR. hint nápověda pro nastavení uživatelského profilu. test tímto příkazem jsem testoval vyvíjené funkce zavaděče, např. LED signalizace. Obrázek 3.1: Mapa příkazu er pro primární zavaděč U-boot 30 Vynutit zavedení ze zvoleného logického oddílu lze zařazením čísla logického oddílu za parametr nand. 95

96 3. Realizace Realizace drobných úprav spojených s portací zavaděče U-boot Protože je základní deska směrovače odlišná oproti základní desce vývojového kitu, bylo nutné udělat spoustu malých úprav zavaděče U-boot. Uvedu pouze ty něčím zajímavé Polymorfní boot zavaděče U-boot Vysvětlení toho, proč je potřeba tato vlastnost zavaděče, je uvedeno v sekci Úkolem je upravit start zavaděče tak, aby se zavaděč uměl sám rozhodnout o provedení nízkoúrovňových inicializací, a nebyl závislý na podmíněném překladu. Tato úprava se týká souboru start.s, který nalezneme v./cpu/arm1136, tedy ve složce, která obsahuje zdrojové soubory určené cílové architektuře procesoru ARM Tento kód je umístěn na uplném počátku spustitelného binárního souboru zavaděče. Zdrojový kód zavaděče U-boot je vždy kompilován na určitou adresu TEXT_BASE. Tato adresa se nastavuje v hlavním souboru Makefile. Předpokládám dva možné stavy: zavaděč je spouštěn mimo pamět RAM zavaděč je spouštěn z prostoru paměti RAM V prvním případě se jedná hlavně o bootování z flash paměti NOR. Toto bootování je specifické tím, že spustitelný kód je spuštěn z offsetu 0x0, proto je nutné pro další práci provést skok na patřičnou adresu v paměti NOR. Pokud ale je start proveden z paměti RAM, je tento skok nechtěný, protože zavaděč běží z prostoru, na který byl zkompilován a nechce provést skok do paměti NOR. Toto jsem ošetřil přidáním podmínky, která porovnává počáteční adresu RAM a adresu aktuální pozice v kódu viz níže. /* We were running from offset 0x0, now jump to Boot FLASH address, so that we can configure SDRAM */ adr r0, _start mov r1, # DDR_ BASEADDR cmp r1, r0 bls rom_ second_ loc ldr pc, = EXP_ CS0_ BASEADDR + rom_ second_ loc - TEXT_ BASE rom_second_loc : Start jsem upravil tak, aby se nízkoúrovňová inicializace provedla, když bude zavaděč spuštěn od adresy menší, než je začátek paměti RAM (0x ). V ostatních případech běží zavaděč z paměti RAM a tuto inicializaci nechce. adr r0, _start /* if we re running from RAM, we don t */ mov r1, # DDR_ BASEADDR /* want to run lowlevel init.*/ cmp r1, r0 blhi cpu_ init_ crit Poslední částí je relokace. Relokaci provádím vždy, až na případ, kdy adresa, ze které zavaděč startuje, je adresou, na kterou má být zavaděč relokován. 96

97 3.1. Realizace zavaděče operačního systému relocate : /* relocate U- Boot to RAM */ ldr r0,= _start /* r0 <- addr of _start */ ldr r1, _ TEXT_ BASE /* test if we run from flash or RAM */ cmp r0, r1 /* don t reloc during debug */ beq stack_ setup Tyto 3 podmínky zajistí nízkoúrovňovou inicializaci pouze v případě, kdy je inicializace potřeba Ovládání hlavních LED diod směrovače 2N R SpeedRoute v zavaděči U-boot LED diody jsou připojeny na víceúčelové GPIO piny procesoru. V původním směrovači 2N R EasyRoute bylo možné přepnout GPIO pin procesoru (ADM 5120) do stavu blinking. To znamená, že v zavaděči Easyboot byla signalizace s LED vyřešena velice jednoduše. Tuto funkci nový procesor řady Comcerto 1000 nepodporuje. Bylo třeba napsat jednoduché funkce pro signalizaci s LED. Na ovládání LED diod jsem vytvořil tyto makra. # define LED_INIT (X) SoC_gpio_cfg (X, GPIO_TYPE_OUTPUT ) # define LED_ON (X) SoC_gpio_set_0 ( SoC_gpio_mask (X)) # define LED_OFF (X) SoC_gpio_set_1 ( SoC_gpio_mask (X)) # define LED_STATUS (X) SoC_gpio_status ( SoC_gpio_mask (X)) Význam funkcí jednotlivých maker napoví jejich pojmenování. LED_INIT(X) nastaví GPIO pin procesoru jako výstupní. LED_ON(X) rozsvítí LED diodu. LED_OFF(X) zhasne LED diodu. LED_STATUS(X) vrátí stav GPIO pinu (LED diody). Dále byly jednotlivé LED diody očíslovány a byly jim přiřazeny příslušné GPIO piny. Toto se provedlo v konfiguraci základní desky směrovače( ). Jednotlivé LED diody jsem poté přidal do pole led_array[]. static int led_ array [] = { CONFIG_ LED0_ GPIO, CONFIG_ LED1_ GPIO,\ CONFIG_ LED2_ GPIO, CONFIG_ LED3_ GPIO }; Nad tímto polem jsem napsal inicializaci LED diod a jednotlivé funkce pro signalizaci. Prototypy funkcí a jejich význam je vidět níže. /* Inicializace pole LED diod */ static void led_ init ( void ) /* Zapne / Vypne pole LED diod */ static void set_ led_ array ( int state ) /* Signalizace svetelnym hadem */ static void do_ led_ snake ( void ) /* Signalizace systemove chyby */ void do_ error_ blink ( int interrupt_ blinking ) /* Signalizace startu zavadece */ void do_ init_ blink ( int blink_ count ) 97

98 3. Realizace Je mimo rozsah této diplomové práce popisovat všechny funkce. Tímto odkazuji čtenáře na zdrojové kódy projektu Detekce tlačítka reset Tlačítko reset je připojeno na GPIO pin číslo 26 viz Samotná funkce je implementována v souboru./lib_arm/board.c. Tento soubor se stará o další inicializace periferií po relokaci zavaděče U-boot. Start zavaděče U-boot je popsán v sekci Tento soubor obsahuje funkce, které se starají o fázi 2. Funkce načítá dobu stisku tlačítka do globální proměnné reset, která se při zavádění OS předává jádru OS pomocí kernel boot command-line (2.3.6). static int reset_ probe ( void ) { udelay (1000) ; SoC_gpio_cfg ( CONFIG_RESET_BUTTON_GPIO, GPIO_TYPE_INPUT ); while (( reset_ time = get_ ticks ()) < 11000) if ( SoC_gpio_read ( SoC_gpio_mask ( CONFIG_RESET_BUTTON_GPIO ))){ return 0; } return 0; } Funkce pro načítání stisku tlačítka reset (./lib_arm/board.c) Umožnění vstupu do uživatelského CLI na základě přístupového kódu Tato funkcionalita úzce souvisí s nasazením síťového protokolu Caller. Je to z toho důvodu, že během čtení stisků kláves zároveň poslouchá služba Caller. Ověřování přístupu do uživatelského CLI zavaděče je nedílnou součástí protokolu Caller, proto popis této funkce najdeme v sekci o implementaci protokolu Caller Zde popíši nastavení této funkce, a popíši stav zavaděče těsně před tím, než je rozhodnuto o způsobu zavedení operačního systému. Start zavaděče těsně před stavem, kdy je rozhodnuto o způsobu, jakým se zavede operační systém, je možné ovlivnit podle definic v konfiguračním souboru základní desky. Jedná se o tyto 4 nejdůležitější definice: CONFIG_BOOTCOMMAND příkaz, který bude spuštěn po vypršení prodlevy o velikosti CONFIG_BOOTDELAY. CONFIG_BOOTDELAY čas v sekundách, po kterou se bude čekat na uživatelův vstup či na příjem paketu Caller. CONFIG_AUTOBOOT_STOP_STR definice přístupového kódu. CONFIG_AUTOBOOT_PROMPT definice textu, který se objeví při čekání na uživatelův vstup do CLI. 98

99 3.1. Realizace zavaděče operačního systému /* * AUTOBOOT configuration */ # define CONFIG_BOOTCOMMAND " er boot nand " # define CONFIG_ BOOTDELAY 3 # define CONFIG_ AUTOBOOT_ KEYED # define CONFIG_AUTOBOOT_PROMPT " Type the access code...\ n" # define CONFIG_ AUTOBOOT_ STOP_ STR " 1111 " Ukázka definic parametrů ovlivňující start zavaděče (./include/configs/speedroute.h) V prvním návrhu tohoto zabezpečení, jsem použil bezpečnější metodu zamezení přístupu. Přístupové heslo bylo zašifrováno pomocí algoritmu SHA 256. Tato funkcionalita v zavaděči zůstala, ale po diskutování tohoto řešení s vedoucím projektu nebyla použita, ani integrována do protokolu Caller Rozšíření síťové vrstvy zavaděče U-boot o protokol Caller Síťový subsystém je v zavaděči poměrně robustní, avšak jednoduše rozšířitelný. Celý síťový subsystém zaštiťuje funkce NetLoop(), jejíž vstupem je požadovaný protokol (NFS, TFTP, CALLER). Už podle názvu se jedná o smyčku, ve které se poslouchá na daném ethernetovém rozhraní. Přesněji jde o stavový automat. Pro zařazení služby do síťového subsystému bylo třeba tento stavový automat rozšířit o test prerekvizit daného síťového protokolu 31. Dále bylo třeba napsat funkce, které síťová služba musí povinně obsahovat. Síťová služba obsahuje povinně tento typ funkcí: <Net_service>Start jedná se o inicializaci tohoto protokolu. V této funkci se funkcí NetSetTimeout() a NetSetHandler() nastaví handler pro funkci, kterou se bude zpracovávat příchozí paket tohoto protokolu, a prodleva, po kterou se na příchozí paket bude čekat. <Net_service>Timeout jedná se o funkci, která se volá po vypršení prodlevy (v ms) nastavenou funkcí NetSetTimeout(). V této funkci se většinou ošetřuje omezený počet prodlev, který může proběhnout. <Net_service>Handler tato funkce se stará o zpracování přijatého paketu, který je funkci předán jako parametr. Je volána funkcí NetReceive(), která pracuje jako prostředník na linkové vrstvě. Stav přenosu řídí globální proměnná NetState, která může být ve stavech: NETLOOP_RESTART restartuje celou síťovou službu. NETLOOP_SUCCESS síťová komunikace byla úspěšná. NETLOOP_FAIL síťová komunikace selhala. 31 Např. nutná znalost adresy TFTP serveru pro TFTP přenos 99

100 3. Realizace Víc informací bude zmíněno u konkrétní implementace níže. Ukázku spuštění funkce NetLoop() pro konkrétní případ protokolu Caller je na obrázku 3.2. Obrázek 3.2: Ukázka spuštění služby Caller přes smyčku NetLoop Implementace protokolu Caller v zavaděči U-boot Služba Caller se spouští ve fázi 3 na obrázku Volání služby jsem přidal do souboru main.c, který nalezneme ve složce./common. Zde probíhá před spuštěním protokolu Caller několik kroků, které je dobré zmínit. Nastavení defaultního profilu a modelu zde se načítá defaultní profil a model definovaný v konfiguračním souboru základní desky. Dešifrování oddílu LICENCE a načtení sériového čísla směrovače dešifruje se oddíl LICENCE a jeho obsah se uloží do operační paměti pro pozdější použití. 100

101 3.1. Realizace zavaděče operačního systému Spuštění služby Caller spouští se samotná služba Caller. Přesněji k tomu dochází ve funkci abort_boot(), jejíž vstupem je délka prodlevy, po kterou bude služba Caller poslouchat. První krok není pro službu Caller důležitý, další však ano. Sériové číslo je potřeba pro filtraci paketů protokolů Caller v případě, že by fungovalo víc expedičních linek. Implementaci síťového subsystému najdeme ve složce./net. V této složce leží i soubory caller.h a caller.c, které jsem ve složce vytvořil. Prerekvizity nemá tento protokol žádné. Celá funkcionalita se odehrává ve třech funkcích. CallerStart tato funkce načte přístupový kód, který se bude ověřovat proti vstupu uživatele ve funkci CallerTimeout(). Dále nastaví handler funkci pro zpracování paketů protokolu Caller. V poslední řadě nastaví první čas první prodlevy na 10 ms a skončí. Tato funkce je volaná funkcí NetLoop(), která se stará o hlídání prodlev síťových služeb ve své hlavní smyčce. CallerTimeout tato funkce je velmi důležitá, ošetřuji zde vstup klávesnice ze sériové linky. Při startu zavaděče služba Caller poslouchá po dobu, která je definovaná v definici preprocesoru CONFIG_BOOTDELAY 32. Tato prodleva je v sekundách. Hlavní princip v návrhu služby Caller je takový, že průchod touto funkcí trvá cca 1 s. Velikost prodlevy je sdílena přes globální proměnnou boot_delay. Tuto proměnnou po jednom průchodu funkcí dekrementuji. Vstup z klávesnice se načítá v jedné smyčce po dobu 990 ms. Poté se zadaný kód ověří. Pokud je kód zadán správně nastaví se proměnná NetState na NE- TLOOP_FAIL. Tato proměnná ukončí smyčku NetLoop a uživatel je vpuštěn do CLI. Pokud kód správný není a proměnná boot_delay se rovná nule, nastavím proměnnou NetState na hodnotu NETLOOP_SUCCESS. Tím zařídím ukončení smyčky NetLoop a spouštění příkazu, který je uložený v definici CON- FIG_BOOTCOMMAND. V tomto konkrétním případě se jedná o zavedení operačního systému z paměti NAND pomocí příkazu er boot nand. Pokud se hodnota proměnné boot_delay nerovná nule nastavím další prodlevu CallerTimeout na 10 ms. Lépe je průběh funkce vidět na obrázku 3.3. CallerHandler tato funkce zjistí, jestli paket je typu Caller. To zjišťuji pomocí hlavičky tohoto protokolu. Pokud ano, ověřuji sériové číslo z paketu. Pokud i to sedí, nastavím směrovači parametry z paketu Caller a zavedu operační systém pomocí příkazu er boot nfs. Pokud sériové číslo nesedí, nebo paket neobsahuje správnou hlavičku, je paket ignorován Inicializace ethernetového switche AR8328N Na staré základní desce 2N R EasyRoute byl ethernetový switch součástí procesoru, u nového směrovače 2N R SpeedRoute tomu takto není. Základní deska směrovače 2N R SpeedRoute obsahuje ethernetový switch AR8328N firmy Qualcomm Atheros. Tato součástka je jediným zařízením, které nebylo možno odladit na základní desce vývojového kitu. Návrh toho, jak budou namapovány vnitřní GEMAC na fyzické porty switche ukazuje obrázek Bylo třeba pročíst manuálové stránky ethernetového switche 32 Tato definice je umístěna v konfiguračním souboru základní desky. 101

102 3. Realizace Obrázek 3.3: Průchod funkcí CallerTimeout() (2) a nastavit příslušné registry pomocí sběrnice MDIO. Funkce pro práci s MDIO již zavaděč obsahoval, a tak stačilo napsat pouze inicializační funkci Definice jednotlivých GEMAC v procesoru Toto nastavení se týká opět konfiguračního souboru základní desky směrovače. Procesor má 2 GEMAC vrstvy a tyto vrstvy je potřeba patřičně nastavit. GEMAC0 bude obstarávat část počítačové sítě WAN pomocí rozhraní RGMII na fyzické adrese 4 v nastavení 1 Gb/s Full duplex. GEMAC1 bude obstarávat část počítačové sítě LAN pomocí rozhraní GMII na fyzické adrese 2 v nastavení 1 Gb/s Full duplex. V definicích, které jsou uvedeny níže se nejdřív povolí GEMAC vrstva procesoru a poté následují jednotlivá nastavení. /* * Emac Settings */ # define CONFIG_ COMCERTO_ GEMAC 1 /* WAN */ # define GEMAC0_ PHY_ ADDR 4 # define GEMAC0_ CONFIG CONFIG_ COMCERTO_ USE_ RGMII # define GEMAC0_ MODE ( GEMAC_ SW_ CONF \ GEMAC_ SW_ FULL_ DUPLEX GEMAC_ SW_ SPEED_ 1G ) # define GEMAC0_ PHY_ FLAGS ( GEMAC_ PHY_ AUTONEG \ GEMAC_ GEM_ DELAY_ DISABLE ) 102

103 3.1. Realizace zavaděče operačního systému /* LAN */ # define GEMAC1_ PHY_ ADDR 2 # define GEMAC1_ CONFIG CONFIG_ COMCERTO_ USE_ GMII # define GEMAC1_ MODE ( GEMAC_ SW_ CONF \ GEMAC_ SW_ FULL_ DUPLEX GEMAC_ SW_ SPEED_ 1G ) # define GEMAC1_ PHY_ FLAGS ( GEMAC_ PHY_ AUTONEG \ GEMAC_ GEM_ DELAY_ DISABLE ) Ukázka definic pro nastavení GEMACx vrstev procesoru (./include/configs/speedroute.h) Inicializační funkce Napsal jsem inicializační funkci ar8328_init(), která provede nastavení ethernetového switche podle obrázku V první řadě, aby bylo možné switch co nejdříve zprovoznit pro základní potřeby vývoje, bylo rozhraní RGMII namapováno přímo na fyzický port PHY4. Toto mapování bylo poté předěláno tak, aby bylo RGMII procesoru připojeno do GMAC vrstvy přes port 6. Obě tyto volby jdou ovládat pomocí definice PHY4_DIRECT. Vstup RGMII procesoru je určen pro segment sítě WAN. Druhé mapování se provádí z GMII procesoru na PORT 0 vrstvy GMAC switche. Toto rozhraní GMII je určené pro segment sítě LAN. Obrázek 3.4 ukazuje vzájemnou závislost funkcí, které inicializaci obstarávají. K nastavení a vyčítání registrů Obrázek 3.4: Znázornění důležitých funkcí a jejich závislostí ve zdrojovém souboru comcerto_gem.c ethernetového switche slouží dvě funkce: isis_mdio_reg_get() je funkce pro vyčtení registru přes MDIO. isis_mdio_reg_set() je funkce pro nastavení registru přes MDIO. Nebudu uvádět jednotlivé nastavované registry. Je jich velké množství a čtenáři nic neřeknou. Popíši, co jednotlivé funkce dělají. Inicializaci můžeme rozdělit na nastavení linkové vrstvy a fyzické vrstvy. ar8328_init() tato funkce se stará o zmíněnou inicializaci ethernetového switche. Obsahuje resetovací rutinu switche, nastavení LED diod switche a nastavení 103

104 3. Realizace mapování na porty GMAC, které bylo zmíněné výše. Toto mapování je na obrázku Dále vytvoří VLAN na porty, které budou patřit do segmentu LAN. Nakonec se zavolá funkce ar8328_phy_init(), která nastaví fyzickou vrstvu switche. ar8328_phy_init() tato funkce nastaví pro jednotlivé PHY porty fyzické parametry přenosu jako duplex a rychlost přenosu. Na všech portech je zapnutá funkce Auto-Negotiation, která zajistí automatické nastavení parametrů přenosu. ar8328_phy_normal_init() tato funkce nastaví parametry výše na zadaném fyzickém portu směrovače. ar8328_phy4_direct_init() tato funkce je pro účely připojení RGMII procesoru přímo na fyzický port PHY Vyčištění projektu primárního zavaděče Velkým problémem při integraci funkcí do zavaděče byla rozsáhlost projektu U-boot. Problém byl nejen v rozvětvené adresářové struktuře, ale hlavně v definicích preprocesoru. Zavaděč je univerzální právě díky podmíněnému překladu při kompilaci. Pro lepší orientaci v kódech jsem po analýze projektu odstranil veškeré nepotřebné zdrojové soubory. Z cca 5000 zdrojových souborů zbylo po redukci zdrojových souborů 400. Tento krok byl nutný pro budoucí začlenění zavaděče do projektového adresáře směrovače 2N R SpeedRoute. Na odstranění všech zbytečných definic ve zdrojovém kódu projektu bohužel nezbyl čas. Tento krok bude zahrnut v dalším vývoji viz Realizace podpůrných nástrojů pro produkční linku Tyto nástroje, jak už bylo několikrát zmíněno, představují prostředky, které umožní oživit základní desku směrovače na produkční lince. Mezi tyto prostředky patří: inicializační EEPROM zavaděč operačního systému emulátor sériové I 2 C EEPROM paměti Realizace inicializačního EEPROM zavaděče Tento inicializační EEPROM zavaděč slouží k oživení základní desky během oživovacího procesu. Původně jsem zamýšlel, že inicializační EEPROM zavaděč bude zredukovanou verzí zavaděče primárního. Od toho návrhu jsem ustoupil po nalezení zavaděče pro bootování z flash paměti NAND (NAND EEPROM bootloader) v SDK. Přesněji jsem vzal kostru NAND EEPROM bootloaderu a tu doplnil o potřebné prvky ze zavaděče primárního. V průběhu realizace jsem se rozhodl přidat mezi funkce i možnost zavést operační systém přes síťový protokol TFTP, či NFS. K tomuto kroku jsem přistoupil, až po implementování minimální funkcionality, kterou jsem stanovil v návrhu tohoto zavaděče (2.14). 104

105 3.2. Realizace podpůrných nástrojů pro produkční linku Initial Stage Bootloader (ISB) Tento zavaděč je uložen v paměti typu ROM, která je umístěna přímo v procesoru. Zdrojové kódy ISB zavaděče nejsou součástí SDK vývojového kitu, tudíž o tomto zavaděči nemám jakkékoliv bližší informace. Právě tento zavaděč umožní zavedení z periferií, které jsou vyjmenovány v Obraz zaváděného bootloaderu se stahuje z úložiště, které určí konkrétní zapojení daných pinů procesoru. To jak s obrazem zaváděného souboru tento ISB bootloader pracuje, je interní záležitost firmy Mindspeed, která tuto informaci není ochotná sdílet. Díky analýze NAND EEPROM bootloaderu z SDK a komunikaci s technickou podporou firmy Mindspeed, jsem přišel alespoň na část chování tohoto bootloaderu. Kompilace samotného EEPROM zavaděče cross kompilátorem nestačí. K výslednému binárnímu souboru zavaděče je třeba přidat hlavičku, která ISB zavaděči říká několik informací3.5. Nejdůležitější z nich je ta, která říká kolik dat se bude ze sériové I 2 C EEPROM paměti nahrávat. Právě díky tomuto parametru odpadla hlavní výhoda nasazení I 2 C EEPROM emulátoru, protože není možné zavést soubor, který je větší jak 0xFFFF, tedy 64 kb. Význam této hlavičky byl středem mého zájmu již od začátku. Bylo to hlavně z toho důvodu, že mi vyvíjený zavaděč s původní hlavičkou NAND EEPROM bootloaderu v průběhu vývoje přestal fungovat. Tato dysfunkce se projevovala tak, že se zavaděč vůbec nespustil, nebo se po zavedení choval velice nestabilně. Více informací o řešení tohoto problému je uvedeno v kapitole 3.3. Po zdlouhavé komunikaci s firmou Mindspeed se podařilo získat strukturu této hlavičky 3.5. Obrázek 3.5: Struktura hlavičky zavaděče ISB ISB bootloader nahrává výsledný obraz EEPROM zavaděče do paměti ARAM. Přesněji ho umisťuje od adresy 0x0A dál. Od této adresy je také spuštěn. Dno zásobníku je ve výchozím stavu nastaveno na adresu 0x0A a roste od vyšších adres k nižším Orientace ve zdrojových kódech projektu Projekt je velice malý. Níže uvádím popsanou adresářovou strukturu projektu. Zbytek zdrojových kódů je přímo v kořenovém adresáři zavaděče Přidání konfiguračního souboru speedroute.h Konfigurační soubor byl pouze zkopírován z primárního zavaděče U-boot do příslušné složky konfiguračních souborů. Zásahy do něj byly minimální. Na konec konfiguračního souboru jsem přidal definice pro nastavení paměti RAM. Největší změnou je zredukování příkazů příkazové řádky. # define CONFIG_ COMMANDS ( CFG_ CMD_ ENV \ 105

106 3. Realizace / build Adresář s binárními soubory zavaděče vytvořený při kompilaci eeprom.bin...binární soubor zavaděče s ISB hlavičkou image.bin... Binární soubor zavaděče bez ISB hlavičky include...adresář hlavičkových souborů configs... Složka obsahující konfigurace základních desek speedroute.h...konfigurační soubor pro směrovač2n R SpeedRoute... net... Zdrojové kódy síťového subsystému Makefile...Hlavní Makefile projektu CFG_ CMD_ MII CFG_ CMD_ RUN \ CFG_ CMD_ NET CFG_ CMD_ NFS ) Ukázka makra CONFIG_COMMANDS pro inicializační EEPROM zavaděč (./include/configs/speedroute.h) Rozšíření souboru Makefile Zavaděč, který se používal k zavádění OS z flash paměti NAND, bylo třeba rozšířit o novou konfiguraci. Dále jsem podle doporučení firmy Mindspeed kompiloval EEPROM zavaděč pomocí jiného cross kompilátoru Toolchain ARM GCC uclibc Při použití kompilátoru s knihovnami Glibc se zavaděč zasekával. speedroute mkconfig $(@ :=) arm arm1136 speedroute 2N comcerto make CFLAGS =- DCONFIG_ SPEEDROUTE Úprava souboru Makefile pro inicializační EEPROM zavaděč (./Makefile) Kompilace projektu Celý projek zkompilujeme pomocí příkazů: make clean make speedroute Výsledný binární soubor zavaděče je pojmenován eeprom.bin a je umístěn ve složce./build. Tato složka je vytvořena při kompilaci Úprava NAND EEPROM zavaděče Rozšiřování kostry zavaděče pro bootování z flash paměti NAND v SDK probíhalo postupně podle těchto kroků: 106 Integrace příkazové řádky Integrace prostředí uživatelských proměnných Integrace síťového subsystému

107 3.2. Realizace podpůrných nástrojů pro produkční linku Integrace a rozšíření příkazu er V NAND EEPROM zavaděči neexistoval žádný síťový subsystém, ani příkazová řádka s jakkýmkoliv systémem proměnných. Vše bylo nutné dopsat. Naštěstí se většinou jednalo o pouhý přenos zdrojových kódů. Pokud byl zkopírovaný zrojový soubor hodně nepřehledný, snažil jsem se ho vyčistit od nepotřebných definic preprocesoru. Usoudil jsem, že je zbytečné do linker skriptu přidávat sekci pro dynamickou alokaci paměti (heap), i když by to značně usnadnilo práci v průběhu integrace jednotlivých funkcí zavaděče. Integrace prostředí uživatelských proměnných Uživatelské proměnné jsem implementoval v souboru er_env.c pomocí statického pole env[], kde velikost jedné proměnné je 50 B. Výjímkou je proměnná kernel_line, ve které se předává příkazová řádka jádra (kernel boot commad-line) příkazu bootm. Deklaraci proměnných vidíme níže. char kernel_ line [500]; # define MAX_ EVAL 50 typedef struct erenv_t { char * var ; char val [ MAX_EVAL ]; } erenv_t ; erenv_t env [] = { { " ethaddr "," 00:11:22:33:44:55 " }, { " eth1addr "," 00:11:22:33:44:66 " }, { " ipaddr ", "" }, { " serverip ","" }, { " netmask ","" }, { " gatewayip ", "" }, { " ethact "," comcerto_gemac0 " }, { " kernel_file ", "" }, { " root_path ", "" }, { " ram_size "," 128 M" }, { NULL, "" } }; Ukázka integrace prostředí uživatelských proměnných inicializačního EEPROM zavaděče (./er_env.c) Práci s proměnnými zajišťují funkce getenv() a setenv(), které jsou ve stejném zdrojovém souboru (er_env.c). Integrace příkazové řádky Příkazová řádka byla nutnou součástí návrhu inicializačního EEPROM zavaděče. Bylo třeba umožnit spouštění uživatelských proměnných. Princip použití makra U_BOOT_CMD je vysvětlen v sekci Pro zpracování příkazové řádky jsem použil parser příkazů ze zavaděče primárního. Tento parser zde najdeme v souboru board.c. Dále jsem musel rozšířit linker skript eeprom.lds o sekci.u_boot_cmd. 107

108 3. Realizace. = ALIGN (4) ;. got : { *(. got ) } u_boot_cmd_start =.;. u_boot_cmd : { *(. u_boot_cmd ) } u_boot_cmd_end =.; Rozšíření linker skriptu inicializačního EEPROM zavaděče (./eeprom.lds) Tato sekce obsahuje struktury cmd_tbl_t všech příkazů. V tomto segmentu se poté hledá pomocí funkce find_cmd() konkrétní příkaz zadaný přes příkazovou řádku. Jako první příkaz, který jsem zavedl byl příkaz help, který vypisuje nápovědu jednotlivých příkazů Integrace síťového subsystému Síťový subsystém jsem převzal z hlavního zavaděče téměř beze změny. Jedinou změnou byla úprava inicializačního souboru ethernetového switche, který používal dynamickou alokaci paměti. Dynamické pole jsem nahradil poli statickými. static struct eth_ device _dev [3]; static struct gemac_ dev _gemac [3]; static char d_idx = 0; Odstranění potřeby dynamické alokace (./net/comcerto_gem.c) Integrace a rozšíření příkazu er Příkaz er jsem taktéž převzal z hlavního zavaděče téměř beze změny. Odebral jsem podporu proměnných JOES_ENV, kterou EEPROM zavaděč nepotřebuje. Stejně tak chybí možnost aktualizace zavaděče v paměti NOR. Dále jsem rozšířil a mírně pozměnil složení příkazu a to tak, jak ukazuje obrázek 3.6. Jedinou větší změnou je příkaz er boot, který se změnil na er load. Tento příkaz plní stejnou funkci jako příkaz er boot, jen oproti hlavnímu zavaděči příkaz er load umí zavést bootloader tzn., že stáhne požadovaný soubor a provede skok na zadanou adresu. K tomuto skoku se používá funkce go(). int do_go ( char * start_ addr ) { ulong addr, rc; int rcode = 0; int argc = 1; addr = ( ulong ) start_ addr ; printf (" Jump to %lx\n", start_addr ); rc = (( ulong (*) (int, char *[]) ) addr ) (--argc, start_addr ); if ( rc!= 0) rcode = 1; printf (" Can not do it, BOSS.\n"); return rcode ; } Ukázka funkce pro provedení skoku na entry point programu (./er_env.c) 108

109 3.2. Realizace podpůrných nástrojů pro produkční linku Obrázek 3.6: Mapa příkazu er pro incializační EEPROM zavaděč Instrukční sada EEPROM zavaděče V tabulce 3.1 najdeme kompletní výčet instrukčního setu EEPROM zavaděče. Jak je vidět, je tento instrukční set značně omezený. Název příkazu help setenv printenv bootm er Vlastnost příkazu Zobrazí nápovědu k příkazu Nastaví uživatelskou proměnnou Vypíše uživatelské proměnné Zavede jádro operačního systému z paměti Obsluha veškeré funkcionality v zavaděči Tabulka 3.1: Instrukční set inicializačního EEPROM zavaděče 109

110 3. Realizace Úprava linker skriptu pro testování zavaděče v paměti RAM V průběhu vývoje nebylo pohodlné zapisovat do paměti EEPROM po každé změně ve zdrojovém kódu zavaděče. Vývoj jsem zrychlil spouštěním EEPROM bootloaderu přímo z paměti RAM. Upravil jsem linker skript eeprom.lds v kořenovém adresáři EEPROM zavaděče. OUTPUT_FORMAT (" elf32 - littlearm ", " elf32 - littlearm ", " elf32 - littlearm ") OUTPUT_ARCH ( arm ) ENTRY ( _start ) SECTIONS {. = 0 x ;. = ALIGN (4) ;. text : { start.o (. text ) *(. text ) }. = ALIGN (4) ;. rodata : { *(. rodata ) }. = ALIGN (4) ;. data : { *(. data ) }. = ALIGN (4) ;. got : { *(. got ) } u_boot_cmd_start =.;. u_boot_cmd : { *(. u_boot_cmd ) } u_boot_cmd_end =.;. = ALIGN (4) ; bss_start =.;. bss : { *(. bss ) } _end =.;. = ALIGN (4) ;. = 0 x ; stack_ start =.;. = 0 x0a ; training_ data_ start =.; } Úprava linker skriptu pro běh inicializačního EEPROM zavaděče z prostoru RAM (./eeprom.lds) Dále jsem zakázal nízkoúrovňovou inicializaci zakomentováním příslušného skoku v souboru start.s. 110

111 3.3. Problémy při realizaci v průběhu celého vývoje /* the mask ROM code should have PLL and others stable */ /* bl cpu_ init_ crit */ Zakázání nízkoúrovňové inicializace pro běh inicializačního EEPROM zavaděče z prostoru RAM (./start.s) Po kompilaci jsem EEPROM zavaděč zavedl v hlavním zavaděči pomocí příkazu: tftp 0x image.bin; go 0x Tento příkaz ze sítě nahraje do operační paměti na adresu 0x soubor image.bin a provede skok na začátek EEPROM zavaděče. Pozor používá se binární soubor bez ISB hlavičky( ) Práce se sériovou I 2 C EEPROM pamětí v zavaděči U-boot Nahrávání na sériovou I 2 C EEPROM paměť z počátku probíhalo programátorem LabProg+. Tento programátor bohužel nepodporoval operační systém Linux, a tak jsem využil možnosti zavaděče U-boot, do kterého jsem přikompiloval funkce pro práci s I 2 C EEPROM pamětí. Zápis touto metodou byl velice pomalý, a proto jsem upravil časování sběrnicového cyklu I 2 C paměti podle konkrétní použité paměti. Zredukováním prodlev jsem byl rázem schopný zapisovat na EEPROM paměť desetinásobnou rychlostí. K zápisu na I 2 C EEPROM paměť v zavaděči U-boot se používá příkaz eemprom. Příklad použití příkazu k zápisu do EEPROM paměti vidíme níže. eeprom write <ADDR_OF_FILE> <EEPROM_ADDR_OFFSET> <FILESIZE> Realizace emulátoru sériové I 2 C EEPROM paměti Realizace emulátoru sériové I 2 C EEPROM paměti byla po dohodě s vedoucím značně zredukována. Výstupem realizace je schématické zapojení, které jsem přenesl na spojovací pole a ověřil jednoduchým programem, který byl součástí USB Frameworku firmy Microchip. Jako srdce emulátoru jsem použil již zmíněný mikroprocesor firmy Microchip PIC18F2550, který měl interpretovat data z PC procesoru ve směrovači. Použil jsem 20 MHz krystal, který je doporučen v manuálových stránkách procesoru(3). Pro možnost provádění jednoduchých testů zapojení obsahuje jednu supersvítivou LED diodu a tlačítko, které je přes externí pull-up rezistor připojen k procesoru. Emulátor obsahuje USB konektor typu B, kterým se připojuje k PC. Procesor je napájen přímo z tohoto konektoru napětím +5 V. Schéma zapojení vidíme na obrázku 3.7. Výsledné vyhotovení pak na obrázku 3.8. Obecně je tento způsob návrhu docela známý, často se k němu ale používá jiný procesor PIC18F Problémy při realizaci v průběhu celého vývoje Při realizaci docházelo často k chybám, které radikálně zpomalovaly další vývoj programového vybavení. Zvláště pak v období při přechodu na nový hardware (prototyp 111

112 3. Realizace Obrázek 3.7: Schématické zapojení emulátoru sériové I 2 C EEPROM paměti Obrázek 3.8: Prototyp emulátoru sériové I 2 C EEPROM paměti 112

113 3.3. Problémy při realizaci v průběhu celého vývoje směrovače). Některé z těchto problémů je dobré zmínit, protože často ovlivnily běh mnou navrženého zavaděče. I když se většinou jednalo o maličkosti, odbourání těchto chyb, bylo obecně velice časově náročné Odlišný počet bank paměti RAM Při přechodu na prototyp směrovače jsem zapomněl změnit počet bank v zavaděči na polovinu. To zapříčinilo nekorektní chování této paměti. Dále bylo nutné upravit šířku datové sběrnice na polovinu (16 bitů) Impedančně nepřizpůsobená základní deska směrovače S prvním prototypem základní desky firmware fungoval. Po první otočce (s druhou verzí prototypu) se základní desky směrovačů začaly chovat zvláštně, přesněji selhávala paměť RAM. Po snížení frekvence I/O sběrnice paměti na 165 MHz se chování zlepšilo. V zavaděči bylo prostředí stabilní, avšak při zavedení jádra OS, jakmile začala fungovat MMU jednotka, operační systém kolaboval. Poté se zjistilo, že základní deska složená ze čtyř vrstev, není správně impedančně přizpůsobena. Tloušťka základní desky se proti prvnímu prototypu lišila 33 v jednom µm. Tím se odhalil nekorektní výrobní postup při výrobě plošného spoje základní desky. Při takto velkých frekvencích (333 MHz) je impedanční přizpůsobení (součást hight speed návrhu) plošného spoje podmínkou. Po bližším zkoumání se nestabilita začala velmi zřídka vyskytovat i u prvních prototypů základních desek, které výrobní chybu neobsahovaly. Vše se vyřešilo snížením amplitudy datových signálů paměti RAM. Nyní již paměť funguje na maximální možné frekvenci 333 MHz a vše je stabilní Příliš velká velikost sektorů u flash paměti NOR Na vývojovém kitu firmy Mindspeed byla umístěna flash paměť NOR o velikosti 16 MB. Tato paměť měla sektory velké 128 kb. To byl ovšem problém, protože jednotlivé paměťové oddíly (ENVx atd.) byly velké 64 kb. Ovladač paměti nedokázal pracovat s menší částí paměti, a proto mazal i oddíly, které mazat neměl. Toto jsem vyřešil tak, že jsem oddíly dočasně zvětšil a přesunul do flash paměti NAND. To z toho důvodu, že adresní sběrnice flash paměti NOR měla na vývojovém kitu s pamětí NAND sdílené vodiče. V případě použití paměti NAND se redukuje velikost paměti NOR na pouhých 256 kb Neresetovaný ethernetový switch po startu Na prvním prototypu základní desky směrovače se o reset ethernetového switche staral RC článek při startu zařízení. Na prototypu druhém už tuto povinnost převzal procesor. Ve zmatku se na tento fakt zapomnělo a po startu EEPROM zavaděče byly z registrů switche vyčítány nesmysly. Při inicializaci ethernetového switche bylo třeba toto zařízení zresetovat. Reset obstarává GPIO pin procesoru s číslem 28. Resetovací rutina se přidala do hlavní inicializační funkce ethernetového switche viz GPIO pin je klidovém stavu nastaven na logickou 1. Reset spočívá v uzemění zmíněného GPIO pinu po dobu 15 ms viz níže. 33 Základní deska měla být v naprosto stejném složení. 113

114 3. Realizace SoC_gpio_cfg ( CONFIG_GPIO_ATH_RESET, GPIO_TYPE_OUTPUT ); SoC_gpio_set_1 ( SoC_gpio_mask ( CONFIG_GPIO_ATH_RESET )); udelay (1000) ; SoC_gpio_set_0 ( SoC_gpio_mask ( CONFIG_GPIO_ATH_RESET )); udelay (15000) ; SoC_gpio_set_1 ( SoC_gpio_mask ( CONFIG_GPIO_ATH_RESET )); Funkce na resetování ethernetového switche AR8328N (comcerto_gem.c) Nestabilita inicializačního EEPROM zavaděče Vývoj EEPROM zavaděče zpomalila jeho nestabilita. Nestabilitu inicializačního EEPROM zavaděče způsobily dvě věci. Příliš malý zásobník Neznalost hlavičky ISB Příliš malá alokace zásobníku Ukazatel na zásobník (SP) po nabootování EEPROM zavaděče byl ISB bootloaderem nastaven na adresu 0x0A (paměť ARAM). Protože zásobník v tomto procesoru roste směrem nahoru (od vyšších adres k nižším) byla maximální možná velikost zásobníku 1 kb, to však po rozšíření funkcionality v zavaděči nestačilo a zásobník přetékal. Pro zásobník jsem vytvořil novou sekci v linker skriptu zavaděče, která je umístěná za sekcí.bss na konci paměti ARAM. Přesněji na adrese 0x0A Část linker skriptu vidíme níže. Posunout začátek zavaděče se mi i se znalosti hlavičky ( ) nepodařilo. ISB zavaděč umisťuje kód z EEPROM vždy od adresy 0x0A dál. Byla by nutná relokace zavaděče v rámci paměti ARAM.. = ALIGN (4) ; bss_start =.;. bss : { *(. bss ) } _end =.;. = ALIGN (4) ;. = 0 x0a ; stack_ start =.; Přidání sekce pro zásobník do linker skriptu inicializačního EEPROM zavaděče (./eeprom.ls) Nastavení ukazatele na zásobník jsem provedl v souboru start.s následovně: ldr r0, = stack_start mov sp, r0 Toto řešení není úplně nejčistší, ale bylo nejrychlejší. Čistší řešení by bylo, projít volané funkce a omezit vytváření dočasných datových struktur (nejčastěji pole) na zásobníku. Tyto datové struktury by nahradilo jedno (nebo více) globálních struktur v.bss segmentu. Tímto řešením by se použití zásobníku omezilo. 114

115 3.3. Problémy při realizaci v průběhu celého vývoje Neznalost struktury hlavičky pro ISB K vývoji inicializační EEPROM zavaděče byl použit plnohodnotný zavaděč U-boot a NAND EEPROM zavaděč, který umožňoval zavádění operačního systému z paměti NAND. Tento zavaděč byl taktéž součástí SDK. Právě analýzou tohoto zavaděče se podařilo v počátcích spouštět první verze EEPROM zavaděče. S tím jak rostl jeho binární soubor, se zavaděč začal chovat zvláštně. Jeho nedeterministické chování bylo způsobeno tím, že ISB zavaděč ( ) nahrál do paměti ARAM pouze zlomek binárního souboru. Po odskoku na vzdálené místo v paměti, kde měla ležet volaná funkce (např. printf() ), zavaděč funkci nenašel. K řešení problému jsem často používal dump přes sériovou linku, kdy zavaděč začal vypisovat sám sebe. Poté se výsledné dva binární soubory (originál a vyčtený soubor) porovnávaly. Při kompilaci EEPROM zavaděče se k binárnímu souboru předřadí hlavička. To v jakém formátu je tato hlavička, je interní záležitostí výrobce procesoru, který s náma tuto informaci nechtěl sdílet. Až po zdlouhavé korespondenci s technickou podporou firmy Mindspeed se podařilo získat strukturu této hlavičky (viz níže). <Jorge > Well I~ don t think you should need it, because this is handled by the eeprom. bin generated by the make process. fyi the header is: aram \ _base \ _offset, len, aram \ _start \ _offset, all 4 byte quantities. </ Jorge > Úsek ové konverzace s technickou podporou firmy Mindspeed Poté, co jsem upravil parametr len na 0xFFFF v hlavičce, zavaděč se podařilo zavést celý. Abych vyloučil chybu v mém návrhu, testoval jsem funkce zavaděče nejdřív prostoru RAM. Až potom, co jsem vyloučil chyby typu nezinicializovaný ukazatel apod., jsem se věnoval odladění v prostoru paměti ARAM Vypnutí 802.3az u ethernetového switche AR8328N Ethernetový switch AR8328N se občas uprostřed datového přenosu zasekával. Po řešení problému s dodavatelem tohoto switche byla vypnuta funkce Green Ethernet (802.3az). Vypnutí této funkce chybu odstranilo. Tato dysfunkce byla spojená s hardwarovou chybou switche. Funkce, kterou jsem napsal pro vypnutí vlastnosti Green Ethernet, je uvedena níže. Tato funkce se volá při inicializaci fyzické vrstvy ethernetového switche ve funkci ar8328_phy4_direct_init() a ar8328_phy_normal_init() viz

116 3. Realizace static int ar8328_ disable_ 8023az ( struct gemac_ dev * gemac, char phy_addr ){ } int ret = 0; ret = miiphy_write ( gemac ->dev ->name, phy_addr, 0xd, 0x7); ret = miiphy_write ( gemac ->dev ->name, phy_addr, 0xe, 0x7); ret = miiphy_write ( gemac ->dev ->name, phy_addr, 0xd, 0 x4007 ); ret = miiphy_write ( gemac ->dev ->name, phy_addr, 0xe, 0x0); return ret ; Funkce na vypnutí 802.3az u ethernetového switche AR8328N (comcerto_gem.c) Počáteční komunikace se sériovou I 2 C EEPROM pamětí Při analýze komunikace mezi procesorem a sériovou pamětí mě nejvíce zaujal stav, který jsem s mojí znalostí sběrnice I 2 C nedokázal interpretovat. Na obrázku 3.9 je vidět start, kdy se procesor snaží navázat komunikaci s I 2 C EEPROM pamětí. Procesor po jednom sběrnicovém cyklu zvyšuje frekvenci hodinového signálu SCL na dvojnásobek. Kvůli nedostatku času jsem tuto komunikaci dál nezkoumal. Obrázek 3.9: Analýza komunikace mezi procesorem a I 2 C EEPROM pamětí. Horní průběh jsou hodiny (SCL). Dolní průběh jsou data (SDA). 116

117 Kapitola 4 Výsledky a testování Tato kapitola zmíní testování a prezentuje výsledky jednotlivých bodů implementace. Nakonec nastíní cesty dalšího vývoje a možná vylepšení, která by další vývoj mohla provázet. 4.1 Testování realizovaných částí implementace Testování funkcionality obou zavaděčů probíhalo během célé realizace. Všechny části zavaděčů byly otestovány a jsou plně funkční. Testování bylo prováděno nejen mnou, ale i testerem přímo na expedičním a oživovacím stanovišti. Dělo se tak při upravě grafických nástrojů spojených s produkční linkou. Nakonec se celá implementace otestovala provedením ostrého oživovacího a expedičního testu. Rozšíření síťového subsystému o protokol Caller bylo otestováno pomocí serverové části programu Caller, posláním Boot Request paketu se sériovým číslem testovaného směrovače. Binární soubor (caller_srv.bin) serverové části programu Caller najdeme na přiloženém CD ve složce bin, zdrojové soubory tohoto programu najdeme v archivu src/impl/caler_srv.tar.gz. Odchycenou komunikaci programem Wireshark je taktéž možné najít na přiloženém CD ve složce test. Použití příkazu vidíme níže. sudo./ caller - mode boot - mac 02: 56: 23: 12: 42: 32 - station 0 - serial dev eth1 - tftp nfs ip mask kernel /er/ ltez1 / boot / uimage -root er/ ltez1 Ukázka použití serverové části protokolu Caller Na obrázku 4.1 je vidět zmíněná komunikace mezi klientem a serverem. Oba zavaděče plní svojí funkci a ode dne jsou součástí produkčního cyklu směrovače 2N R SpeedRoute. 117

118 4. Výsledky a testování Obrázek 4.1: Zachycení komunikace klient server pomocí protokolu Caller 4.2 Zhodnocení implementace hlavního zavaděče Úspěšně jsem zmodifikoval a nasadil zavaděč Das U-boot v novém LTE směrovači 2N R SpeedRoute. Všechny části zavaděče jsou nyní plně funkční. V návrhu směrovače jsou zahrnuty důležité prvky ze směrovače 2N R EasyRoute viz , tím je dodržena i požadovaná kompatibilita se starým zavaděčem Easyboot. Množina příkazů zavaděče U-boot byla rozšířena o řídící příkaz er, který obstará všechny potřebné operace spojené se zaváděním systému. Síťový protokol Caller byl úspěšně integrován do síťového subsystému zavaděče. Zároveň proběhly i drobné úpravy týkající se inicializace a uživatelského rozhraní zavaděče U-boot. V poslední řadě byl zinicializován i nový ethernetový switch, bez jehož inicializace by celý síťový subsystém byl zcela zbytečný. Největším úspěchem, který uzavíral vývoj tohoto zavaděče, byl samotný přechod z vývojového kitu na prototyp směrovače 2N R SpeedRoute, kdy se řešily chyby často spojené s hardwarovým návrhem viz Zhodnocení implementace inicializačního EEPROM zavaděče Povedlo se zredukovat a zmodifikovat zavaděč U-boot při udržení hranice velikosti 64 kb. Po obtížné komunikaci s firmou Mindspeed se podařilo dekódovat hlavičku , kterou používá Initial Stage Bootloader (ISB) při bootování z I 2 C EEPROM paměti, poté již bylo možné načíst celý binární soubor a celý zavaděč se začal chovat stabilně. Výsledný zavaděč překonal minimální požadavky a umožnil zkrátit oživovací proces o jeden krok, kterým bylo zavedení hlavního zavaděče viz scénář číslo 3 na obrázku Nyní je tento zavaděč schopný zavést operační systém Linux. Při velikosti 53 kb se podařilo rozšířit funkcionalitu zavaděče, a to do míry kterou ukazuje tabulka 118