Linux Targetportierung für ein Embedded Automotive Framework

Transkript

1 Linux Targetportierung für ein Embedded Automotive Framework Masterarbeit am Fachbereich Informatik von Sergio Vergata Referent: Prof. Dr. Joachim Wietzke Korreferent: Prof. Dr. Gerhard Raffius Tag der Ausgabe: Tag der Abgabe:

2 Darmstadt, den 10. Oktober 2005 Ehrenwörtliche Versicherung Hiermit versichere ich, die vorliegende Arbeit selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet zu haben. Sergio Vergata

3 Inhaltsverzeichnis Abkürzungsverzeichnis iv Abbildungsverzeichnis vi Tabellenverzeichnis vii Listingverzeichnis viii 1 Vorwort 1 2 Einleitung Motivation Zielsetzung dieser Arbeit Grundlagen Aktuelle Automotive Systeme Harman Becker Blaupunkt Magneti Marelli Betriebssysteme in der Embedded Welt Anforderungen Laufzeitkomplexitäten Interrupt Latenzen Antwortzeiten von Threads Schedulingverfahren FiFo POSIX SCHED_FIFO

4 Inhaltsverzeichnis ii Round Robin POSIX SCHED_RR Adaptive Architektur des Betriebssystems Mikrokernel Monolithischer Kernel QNX VxWorks Linux Einblick in das Target System Einführung in JTAG Lauterbach PowerDebug & Trace SH-4 Überblick Interrupt Controller PCI-Controller Analyse des QNX-Systems IPL-Systemstart QNX-Systemstart PCI-System unter QNX FPGA Device Treiber Ergebnis der QNX Systemanalyse Realisierung des Linux-Systems Das Arch Verzeichnis Der angepasste Bootloader Lowlevel Linux-Kernelstart Timer Basissystem Initialisierung Erste proprietäre Anpassungen PCI Subsystem SH7751R PCI Controller

5 Inhaltsverzeichnis iii PCI Systemdevices FPGA PCI-System Interrupts unter Linux Interruptverarbeitung auf dem Target HW -> IRQ Aktivierung IRQ -> HW Aktivierung Interruptmodifikationen für das Target Gerätetreiber unter Linux Kernel MOST Gerätetreiber Systemmessungen Tools Irrwege Realtime Clock PCI-Controller Interruptverarbeitung auf dem FPGA Fazit 79 8 Zusammenfassung 82 9 Ausblick Danksagung 88 A Anhang 89 Literatur i Index ii

6 Abkürzungsverzeichnis ACPI Advanced Configuration and Power Interface ALF Automotive Linux Framework BIOS Basic Input Output System BSC Bus State Controller BSP Board Support Package CS0 Chip Select 0 DMA Direct Memory Access DRM Digital Rights Management DSL Digital Subscriber Line DVB-T Digital Video Bradcast - Terrestrial EFS Embedded File System ELF Executable and Linking Format FiFo First In First Out FPGA Field Programmable Gate Array GPIO General Purpose Input Output GPS Global Positioning System ICD In Circuit Debugger ICM In Car Multimedia ICR Interrupt Control Register IEEE Institute of Electrical and Electronics Engineers IFS Image File System INTC Interrupt Controller IPL Initial Program Loader IRL Interrupt Request Lines ISR Interrupt Service Routine JTAG Joint Test Action Group MBR Master Boot Record MMI Mensch Maschine Interface MMU Memory Management Unit MOST Media Oriented Systems Transport MTD Memory Technology Device NG2 Next Generation 2 OCIDEC OpenCores IDE Controller PCI Peripheral Component Interconnect

7 Abkürzungsverzeichnis v PCIC PCI Controller PCMCIA Personal Computer Memory Card International Association PIM Personal Information Management POSIX Portable Operating System Interface for UniX RISC Reduced Instruction Set Computing RTC Real Time Clock RTOS Real Time Operating System SCI Serial Controller Interface SCIF Serial Controller Interface with FiFo SH 3/4 Super H 3/4 TMU Timer Unit

8 Abbildungsverzeichnis 3.1 Einsatz und Trend von Embedded Betriebssystemen Einsatz und Trend von Embedded Betriebssystemen Einzelne Komponenten im Mikrokernel Einzelne Komponenten im Monolithischen Kernel Einzelne Komponenten im QNX-Mikrokernel Trace32 Oberfläche Interrupt Controller Memorymap des Targetsystems unter QNX Konfiguration der Parameterübergabe im Linux-Kernel Memorymap des Linux-Kernels Trace32 Speicherausschnitt Linux System Konfiguration Adressraum des FPGA PCI Adresszuordnung Treiberstruktur High- und Low-level Interruptverarbeitung Interruptverarbeitung Einblick

9 Tabellenverzeichnis 3.1 Komplexität von Funktionen Interrupt Quellen Zuordnung ID Zuordnung der PCI-Geräte PCI-ID Zuordnung zu PCI-ID-Select

10 Listingverzeichnis 4.1 IPL Unterbrechung QNX PCI-Window Konfiguration Das Architektur-Verzeichnis Das SH-Verzeichnis Das Board-Verzeichnis Die Kernelplattform für SH Die CPU Portierung Der IFS Header Bootparameter und Commandline Adressen Bootparameter zur Initialisierung IPL Bootausgabe Die start_kernel() Funktion Dissassembliertes Kernelbinary Serielle Schnittstellen Konfiguration im IPL SCI-Gerätetreiber im Linux-Kernel Trace einer fehlgeschlagenen Schnittstellekonfiguration Definition eines Lesezugriff Konfigurationsoption für Becker B Makefile Anpassungen für machdir Makefile Anpassungen für incdir config Eintrag Maschinentypen Eintrag Kernel Cross kompilieren

11 Listingverzeichnis ix 5.24 Binary Format des Kernels Binary Extraktion aus dem Elf-Image IFS Headergenerierung für das Kernel-Image Linux-Kernel initcalls Erste Bootausgabe des Linux-Kernel PCI-Controller Configuration Ergebnis des PCI-Bus scan Gefundene PCI-Geräte IRQ-Mapping Fehler Kernel ISR do_irq() IRQ-Mapping der Internen Interrupts IRQ-Level Zuweisung in den VHDL Sourcen PCI-ID Mapping auf IRQ Super H Interrupt Handler Funktionen Registrierung für den Interrupt Handler FPGA Interrupt mask- und unmask Adresse Interrupt Maskierung Interrupt Demaskierung Treiber Interrupt De-/Registrierung Lesezugriff des QNX-Treibers Messtimer Initialisierung Ping an das Target mit und ohne Messungen im Kernel Statistische Analyse des Timerinterrupts Statistische Analyse des Netzwerkinterrupts IFS-Headertool Print A.49 IFS-Dump eines B1 IFS

12 1. Vorwort Der Fortschritt lebt vom Austausch des Wissens. Albert Einstein Das Betriebssystem Linux erfreut sich immer mehr steigender Beliebtheit. Es wird in den verschiedenen Bereichen eingesetzt. Die vorliegende Masterthesis wurde um und mit diesem Betriebssystem erstellt. Der Erfolg von Linux basiert auf drei Säulen, der Idee, der Verbreitung und vor allem auf den überzeugten Entwicklern. Neue Ideen benötigen immer Entwickler von denen sie geteilt werde. Denn nur so kann die Vielfalt gebündelt werden und von einer Idee heraus ein Entwicklung begonnen werden. Mit dieser Arbeit wurde eine solche Idee aufgegriffen und eine Entwicklung initiiert. Diese Arbeit richtet sich an all jene, die diese Idee teilen und zu ihrer Weiterentwicklung beitragen wollen. Sprachliche Erklärung Bei der vorliegenden Masterthesis wird auf die Eindeutschung von englischen Begriffen verzichtet, ein Scheduler wird nicht als Steuerprogramm übersetzt, sondern bleibt ein Scheduler. Auch die Frage der Groß- oder Kleinschreibung englischer Begriffe, die eventuell im Deutschen schon bekannt sind, wird systematisch ignoriert. Ich wähle, wann immer ich darauf achte, die Groß- oder Kleinschreibung. [WiTr05] Viel Spaß beim Lesen.

13 2. Einleitung Wenn der Wind des Wandels weht, bauen die einen Schutzmauern, die anderen bauen Windmühlen. Chinesische Weisheit 2.1 Motivation Noch vor einiger Zeit gehörten Automotive Multimedia Systeme zur Luxusausstattung in der Automobilbranche. Mit der zunehmenden Akzeptanz und Nachfrage nach solche Systemen stieg auch der Einsatz solcher Multimediasysteme in den verschiedenen Automobilklassen. So finden sich In-Car Multimediasysteme heute in der Luxusklasse aber auch in der Kleinwagenklasse. Durch den ebenfalls stetig steigenden Einsatz von Linux in verschiedenen Embedded Systemen, wurde die Idee geboren, diese beiden Gebiete zu vereinen und somit Linux auf einem Embedded Automotive System zu portieren. Durch den Einsatz von Linux in diesem Bereich hätte man die Möglichkeit, die unterschiedlichsten Standarddienste, welche aus der PC-Welt bekannt sind, nun auch im Automobil zu nutzen. Ein weiterer wichtiger Punkt ist der aktuelle Einsatzbereich des ICM-Systems im Fachbereich Informatik. Das ICM-System wird in einem hochschulinternen Projekt genutzt und ständig weiter entwickelt und neue Techniken daran ausgetestet. Die in diesem Zusammenhang zur Verfügung stehende Hardware ist genau die nötige Plattform für eine solche Portierung. Dieses Targetsystem wurde von Harman Becker, einer Embedded Automotive Firma, entwickelt und ist somit eine repräsentative Plattform, um hierauf eine solche Arbeit aufzubauen. Um mit aktuellen Techniken Schritt halten zu können, ist es nötig, aktuelle Treiber für die unterschiedlichste Hardware vom Betriebssystementwicker zu beziehen. Hier besteht die

14 2. Einleitung 3 Idee diesen "Nachteil" durch den Einsatz eines Linux-Kernels und den hierfür vorhandenen Treibern zu umgehen. 2.2 Zielsetzung dieser Arbeit Das Ziel dieser Arbeit soll es sein, die verfügbare Automotive Hardware mit dem Betriebssystem Linux auszustatten. Es sollen Erkenntnisse gewonnen werden, ob Linux für ein solches Automotives System die erforderlichen Rahmenbedingungen erfüllt. Mit dem Linux-System soll eine stabile Basis geschaffen werden, welche für weitere Forschungs- und Entwickelungszwecke genutzt werden kann. Diese Entwicklung soll ebenfalls ein Grundsystem bieten, damit ein vorhandenes Embedded Automotive Framework auf diese Basis übertragen werden kann. Die einzelnen Komponenten, welche für ein solches Basissystem nötig sind, sollen untersucht und auf dem Basissystem ermöglicht werden. Messungen der Systemleistungen sollen eine Vergleichbarkeit ermöglichen. Damit diese Ziele erreicht werden können, gliedert sich diese Arbeit in folgende Einzelschritte: In Kapitel 3 wird eine Übersicht über bekannte ICM-Systeme-Hersteller, der eingesetzten Embedded Betriebssysteme und deren Besonderheiten gezeigt. Kapitel 4 zeigt die erzielten Analyseergebnisse des bestehenden QNX-Betriebssystems. Das Kapitel 5 leitet durch die Linux-Portierung. In diesem Kapitel werden die einzelnen Ergebnisse und Messungen beschrieben und mögliche Entwicklungen durchgesprochen. Durch Kapitel 6 wird gezeigt, dass eine Entwicklung auch immer von Komplikationen begleitet wird.

15 3. Grundlagen 3.1 Aktuelle Automotive Systeme Wie in der Einleitung bereits angedeutet, existieren auf dem Markt mittlerweile eine ganze Reihe von Herstellern für Embedded Automotive Systeme, hierzu zählen unter anderem Harman Becker, Blaupunkt und Magneti Marelli. Diese Hersteller haben ein gemeinsames Ziel, sie entwickeln Multimediasysteme für die Automobilbranche und versuchen stets eine Innovation in dessen jeweilig neusten Systemen zu integrieren. Als Grundlage für aktuelle Automotive Systeme dienen im Moment vor allem zwei Betriebssysteme. QNX Neutrino RTOS Wind River VxWorks Diese beiden Embedded Betriebssysteme werden von der jeweiligen Firma entwickelt und jegliche Änderung, welche an den Betriebssystemen programmiert werden muss, um sie an die persönlichen Bedingungen anzupassen, wird dem Hersteller in Auftrag gegeben. Durch diesen Zwischenschritt ist ein Projekt zur Neuentwicklung an zeitliche Absprachen mit dem Betriebssystemhersteller geknüpft Harman Becker Einige der verschiedenen ICM-Systeme werden von Harman Becker im Auftrag von Automobilherstellern entwickelt. Hierbei setzt Harman Becker auf beide oben angegebenen Betriebssysteme. Als Einsatzgebiet für QNX kann das aktuelle Mercedes APS 50 System genannt werden. Dieses System basiert auf einem SH3 Prozessor von Renesas und ist ein Vorgängermodell des in dieser Arbeit genutzten Target Systems.

16 3. Grundlagen 5 Als weiteres Harman Becker Projekt sei das für Audi entwickelte NG2 genannt, hier setzt Harman Becker auf VxWorks als Betriebssystem und ein SH-3 basierendes Target System Blaupunkt In Europa ist das Tochterunternehmen der Bosch Gruppe Marktführer für Autoradios. Bei Blaupunkt werden, genau wie bei Harman Becker, eigenständige ICM-Systeme entwickelt und für verschiedene Automobilhersteller speziell angepasst. Zu den von Blaupunkt entwickelten Multimedia Systemen zählt z. B. das Command System der Mercedes E-Klasse (W210). In neuen ICM-Systemen der Firma Blaupunkt wird Microsoft WindowsCE als Betriebssystem eingesetzt Magneti Marelli Bei der italienischen Automotive Firma Magneti Marelli wurde für die Fiat Gruppe das Connect Nav Plus entwickelt. Es basiert auf einem ST/Ciaolab SH-4+BCC Target System und nutzt als Betriebssystem VxWorks. Laut -Austausch mit dem Magneti Marelli Pressesprecher Luca Magnotta ist für die Nachfolgegeneration ihrer Systeme der Einsatz des Betriebssystems Linux geplant. Erste Testentwicklungen sollen ab Mitte 2006 entstehen und somit möglicherweise Anfang 2007 in die eigenen Multimediasysteme Einzug finden. Abbildung 3.1: Einsatz und Trend von Embedded Betriebssystemen 1999 (Quelle [Linu05])

17 3. Grundlagen Betriebssysteme in der Embedded Welt Die Embedded Welt besteht aus einer Vielzahl von Betriebssystemen. Bevor Linux in diesen Markt eintritt fand, waren verschiedenste proprietäre und vor allem kostenpflichtige Kernel im Einsatz. Seitdem Linux in diesen Markt aufgenommen wurde, besteht nun zum allerersten mal die Möglichkeit auf eine offene Plattform zurück zu greifen, die von verschiedenen Herstellern eingesetzt werden kann. Bei dieser Masterarbeit liegt die Idee zu Grunde, Linux für ein Embedded Automotive System zu nutzen. Diese Entscheidung, stützt sich auf zwei Hauptsäulen. Machbarkeit Marktsituation Bei einer älteren Studie aus dem Jahr 1998 (Abbildung 3.1) zeigt sich, dass der Embedded Markt noch gänzlich anders aufgeteilt ist. An dieser Marktbefragung wird ebenfalls ersichtlich, dass Linux noch eine untergeordnete Rolle einnimmt. Abbildung 3.2: Einsatz und Trend von Embedded Betriebssystemen 2005 (Quelle [Linu05]) Eine Marktstudie des Jahres 2005 (Abbildung 3.2) zeigt, dass Linux nun das führende Embedded Betriebssystem ist und zukünftig dieser Einsatz auch weiterhin steigen wird. Dies ist ebenfalls ein Ergebnisse der großen Hardwareunterstützung im Linux-Kernel, die teilweise direkt von den Chipherstellern forciert wird.

18 3. Grundlagen Anforderungen Heutzutage ist die grundsätzliche Arbeitsweise eines Betriebssystems bekannt. Meist wird sich bei der Diskussion rund um ein Betriebssystem eher auf die Anforderungen eines Desktop-Betriebssystems für den PC bezogen, welches sich jedoch von einem Embedded Betriebssystem in einigen wichtigen Punkten unterscheidet. Viele der heute im Einsatz befindlicher Embedded Systeme werden durch ein Echtzeitbetriebssystem betrieben und haben somit andere Charakteristika zu erfüllen. So unterscheiden sich die meisten Embedded Betriebssysteme von Standard PC Betriebssystemen durch in den folgenden Kapiteln genannten Punkte Laufzeitkomplexitäten Mit der Laufzeitkomplexität wird das Verhalten bewertet, das ein bestimmter Algorithmus für die Bearbeitung von Daten benötigt. Diese Bewertung bezieht sich vor allem auf die Betrachtung der Laufzeiten bei unterschiedlichen Datengrößen. So kann es für unterschiedliche Einsatzbereiche jeweils eine andere Anforderung an die Laufzeitkomplexität geben. Besonders wichtig für Betriebssysteme ist die Komplexität des zentralen Schedulers. Die Arbeitszeit einer solchen Funktion sollte gleichmäßig sein und nicht mit steigendem Arbeitsaufkommen unverhältnismäßig viel Zeit benötigen. Im Gegensatz dazu versucht man bei Verschlüsselungssystemen möglichst Algorithmen einzusetzen, welche sehr aufwändig bei der Entschlüsselung sind. Diese Laufzeitkomplexität wird durch die O-Notation angegeben, einige dieser Notationen werden in Tabelle 3.1 dargestellt. O-Notation O(1) O(logn) O(n) O(n 2 ) O(n n ) O(n!) Funktionsweise Konstant Logarithmisch wachsend Linear wachsend Quadratisch wachsend Exponentiell wachsend Faktoriell wachsend Tabelle 3.1: Komplexität von Funktionen Interrupt Latenzen Mit Interrupt Latenz wird die Zeit definiert, die ein Betriebssystem benötigt, um vom Auftreten eines Interrupts über eine Hardware-Ressource bis zur Ausführung des ersten Programmcodes innerhalb der Interrupt Service Routine zu gelangen. Das Betriebssystem kann diese Latenzzeit beeinflussen und somit meist negativ auf die Antwortzeit Einfluss nehmen, dies bedeutet die Zeiten verlängern sich. Ein solcher Einfluss ist meist eine Folge von Interrupt Priorisierung. Ein Beispiel: Ein Interrupt mit sehr hoher Priorität tritt auf und das System geht in die zugehörige ISR.

19 3. Grundlagen 8 Nun werden alle weiteren Interrupts, welche keine höhere Priorität besitzen, gesperrt und dadurch solange nicht beachtet, wie die Executiontime der laufenden ISR dauert. Man kann also sagen, dass die Latenzzeiten eines Betriebssystems nur so gut sind wie die Dauer der langsamsten ISR. Dieses Verhalten wurde von einer Schwedischen Forschergruppe gemessen und unter dem Titel Worst-Case Execution Time Analysis of Disable Interrupt Regions in a Commercial Real-Time Operating System [CEEL + 02] veröffentlicht. Eine besondere Beachtung von sehr kurzen Interrupt Latenzen findet man vor allem in dem Bereich der harten Echtzeitsysteme. Akzeptable Interrupt Latenzzeiten für ein weiches Echtzeitsystem sind mit einfachen Mitteln zu erreichen, da hier nur ein zeitlicher Rahmen angepeilt, aber keinerlei Gewähr dafür gegeben werden muss Antwortzeiten von Threads Unter der Antwortzeit von Threads versteht man die maximale Zeit, die ein Thread benötigt, vom Zeitpunkt an dem er gestartet wird bis zum Beenden seiner Aufgabe. Dies ist zum Beispiel dann der Fall, wenn eine Interaktion mit Systemhardware ansteht. Ein Beispiel: Ausgelöst durch einen Interrupt wird über die ISR ein Thread angestoßen, welcher mit hoher Priorität innerhalb des Systems seinen Task abarbeitet. Nun treten vermehrt Interrupts durch einen nicht so wichtigen und damit niederprioren Interrupt auf. Der laufende Thread wird unterbrochen und die niederpriore ISR abgearbeitet, dies wiederholt sich solange bis alle anstehenden Interrupts abgearbeitet wurden. Als entscheidende Auswirkung auf den laufenden Thread entsteht eine verlängerte Ausführungszeit und damit keine Garantie, in welcher Laufzeit ein Thread abgearbeitet wird. Ein Resultat aus dem oben aufgezeigten Systemverhalten kann eine Prioritätsinversion sein Schedulingverfahren Es gibt eine große Anzahl von Schedulern im Einsatz für Embedded Betriebssysteme, alle diese Scheduler haben einen ganz besonderen Einsatzbereich, für den sie genutzt werden. Bei einem Embedded Betriebssystem werden die meisten Tasks durch prioritätsbasierende Schedulingverfahren behandelt, doch genau dann, wenn mehrere Tasks in einem System die gleiche Prioriät haben, werden andere Schedulingverfahren benötigt. Nachfolgend werden die grundlegenden Schedulingverfahren aufgezeigt FiFo POSIX SCHED_FIFO Dies ist eines der einfachsten Schedulingverfahren, welches sich auf wenige Funktionen beschränkt.

20 3. Grundlagen 9 Funktion: Ein Task, dem die CPU zugewiesen wird, nutzt diese Rechenzeit für ein paar Zyklen, gibt danach diese freiwillig wieder ab und ermöglicht so, dass ein weiterer Task rechnend wird. Ein laufender Task kann die CPU nur dann entzogen bekommen, wenn ein höher priorer Task wartend ist und FiFo mit Verdrängung arbeitet. Problem: Aus diesem Verfahren ergeben sich Probleme, da insbesondere Tasks mit langer Anforderung an Rechenzeit alle anderen Tasks "verhungern" lassen. Hieraus ergibt sich ein Stau der anstehenden Tasks, vor allem Tasks mit kurzer Rechenzeit müssen unter Umständen lange auf ihre Ausführung warten Round Robin POSIX SCHED_RR Dieses Verfahren findet besonders in Fällen von identischer Priorität der anstehenden Tasks Verwendung. Wie man schon an der Namensgebung bemerkt, vergibt dieser Scheduler die Rechenzeitzuteilung nacheinander an alle anstehenden Tasks. Funktion: Jedem Task wird eine Zeitscheibe zugeordnet, sobald der Task rechnend ist, läuft dessen Zeitscheibe. Der Task kann genau wie beim FIFO Verfahren durch das Warten auf Ressourcen die CPU abgeben. Nach dem Ablaufen der Zeitscheibe wird der nächste wartende Task in der gleichen Prioritätsklasse rechnend. Um höherpriore Tasks bedienen zu können kann hier ebenfalls die Rechenzeit eines Tasks unterbrochen werden. Die restliche Zeitscheibe des verdrängten Tasks wird nach der Beendigung des hochprioren Tasks fortgesetzt. Problem: Durch den Round Robin Algorithmus hat man zwar eine faire Behandlung aller Tasks, doch sind hierbei besonders Tasks mit langer Anforderung an Rechenzeit benachteiligt, da sie mehrere Zeitscheiben benötigen, um einen Job abzuschließen Adaptive Bei diesem Verfahren werden aufwändigere Methoden angewandt, als bei den beiden vorhergehenden Schedulern. Wie sich durch die Namensgebung erahnen lässt, passt dieser Algorithmus den Task an Systemsituationen an. Funktion: Dieses Schedulingverfahren ist eine Weiterentwicklung des Round Robin Algorithmus, hierbei hat jeder Task ebenfalls eine Zeitscheibe zur Verfügung und kann anhand von Prioritäten seine initiale Einordnung treffen. Bei gleichberechtigten Tasks wird nach der Beendigung einer Zeitscheibe die Prioriät des gerade ausgelaufenen

21 3. Grundlagen 10 Tasks dekrementiert und somit alle anderen anstehenden Tasks bearbeitet. Um ein Echtzeitverhalten zu gewährleisten, wird darauf geachtet, dass ein Task nicht länger als eine vorgegebene Zeit wartend ist. Bei diesem Verfahren werden Prioritäten ständig verändert, doch ein Task wird niemals eine höhere Priorität erhalten als seine Initiale, nur die Anpassung der Priorität nach unten und dann wieder auf maximal die Ausgangspriorität ist möglich. Problem: Um ein solches Verfahren zu implementieren, muss man bei dessen Programmierung besonders auf die Regelungsmethoden achten und darf hier den Aufwand der Prioritätsanpassung nicht unterschätzen. So könnte man über diese Prioritätsanpassung unnötig Zeit vergeuden. Dieses spezielle Verfahren ist nicht bei allen Betriebssystemen verfügbar, jedoch sind ähnliche Verfahren auf anderen Betriebssystemen vorhanden. 3.3 Architektur des Betriebssystems Bei den aktuellen Betriebssystemen im Embedded Bereich erkennt man zwei grundsätzliche Architekturen, der Mikrokernel und der Monolithische Kernel. Dies ist ein Punkt in der Entscheidungskette für ein Embedded Betriebssystem, welcher wesentlich zur späteren Entwicklung des Gesamtsystems und den Arbeitsaufwand für eine Entwicklung und Portierung beiträgt Mikrokernel Viele aktuelle Echtzeitbetriebssysteme basieren auf einer Mikrokernel Architektur. Diese Architektur beschreibt nur minimale Betriebssystemfunktionen. So bestehen Mikrokernel meist aus einem Scheduler, welcher die Grundfunktion der Ressourcenzuteilung übernimmt. Als weiteres enthält der Mikrokernel meist die Implementierung für die Interprozesskommunikation und Funktionen zur Synchronisation. Für ein vollständiges Betriebssystem fehlen jedoch noch Gerätetreiber. Diese sind bei einem Mikrokernel nicht enthalten, sondern werden in externen eigenständigen Programmen zur Verfügung gestellt. Solche Programme werden in der Mikrokernel Architektur "Server" genannt, zu erkennen in Abbildung 3.3. Ein solcher Server läuft im Userspace der CPU, wodurch bei einer Kommunikation mit dem Betriebssystem ein Kontextwechsel stattfinden muss. Hierdurch kann der privilegierte Bereich nur von den im Mikrokernel vorhandenen Methoden gelesen und geschrieben werden. Die Zuverlässigkeit des Mikrokernels resultiert aus einer Beschränkung auf wenigen Basisfunktionen, welche sich mit überschaubarem Aufwand überprüfen und korrigieren lassen. Durch diese architekturbedingte Tatsache ist ein Mikrokernel nur sehr schwer zum Absturz zu bringen, woraus sich eine hohe Stabilität

22 3. Grundlagen 11 Applikation Applikation System Server System Server System Server System Server Mikrokernel Treiber Server Treiber Server Treiber Server Hardware Abbildung 3.3: Einzelne Komponenten im Mikrokernel ergibt. Besonders der Punkt der Stabilität ist für ein Betriebssystem in kritischen Bereichen sehr wichtig. Das Auslagern der Gerätetreiber und weiterer Komponenten wie Netzwerkstacks in den Userspace und daraus resultierenden ständigen Kontextwechsel bringen einen Nachteil in der Performance eines solchen Systems mit sich. Um diesen Performancenachteil aufzuheben, muss entweder eine hochperformante Hardwarearchitektur eingesetzt werden oder der Mikrokernel muss sehr stark optimiert werden. Aus einer Performanceoptimierung entstehen zwangsläufig Probleme bei der Portierbarkeit auf zukünftige Systemplattformen, da eine spezielle Anpassung des Kernels an den eingesetzen Prozessor und dessen Umfeld benötigt wird Monolithischer Kernel Bei dieser Kernelarchitektur sind, wie auch bei der Mikrokernelarchitektur, Basisfunktionalitäten im selben Kontext enthalten. Doch beinhaltet ein monolithischer Kernel auch Hardwaretreiber und Kommunikationstacks, welche ebenfalls im gleichen Kontext arbeiten wie die Basisfunktionen des Kernels, dargestellt in Abbildung 3.4.

23 3. Grundlagen 12 Userspace Programs & Applications System Calls Process Management Memory Management Filesystem Device Control Networking Kernelparts Concurrency Multitasking Virtual Memory Files & Directories TTY & Device Access Connectivity Features Arch. dep. Code Memory Manager FS Types * Block Devices * Character Devices * Network Subsystem Interface Drivers * Software Support Hardware Control CPU RAM Storage OutputDev Network Interfaces Hardware * Kernel Modules Abbildung 3.4: Einzelne Komponenten im Monolithischen Kernel (aus [CoRKH05]) Durch den Wegfall der Kontextwechsel bei Kommunikation mit den einzelnen Komponenten des Kernels und Treibern ist diese Architektur sehr performant. Als Nachteil einer solchen Architektur ist die komplexe Struktur zu beachten. Diese bringt zwar sehr viele Funktionen mit sich, ist aber dadurch wesentlich fehleranfälliger als eine Mikrokernelarchitektur. Durch die Architektur dieses Kernels ist von dieser Fehleranfälligkeit meist der ganze Kernel betroffen, auch wenn nur ein Treiber Fehler enthält. Um einen monolithischen Kernel stabiler zu gestalten, werden zum Beispiel im Linux- Kernel einzelne Kernelmodule in den Kernel geladen und entladen, mehr hierzu im Linuxabschnitt Kapitel QNX Basierend auf einer Mikrokernelarchitektur ist QNX als hartes Echtzeitbetriebssystem konzipiert worden. Das aktuelle QNX in der Version 6.3 mit dem Namen Neutrino ist das Resultat der Entscheidung der Firma QNX Software Systems, ihren Kernel POSIX konform zu gestalten. Diese Entscheidung beinhaltete ebenfalls, den QNX-Kernel sehr stark an den monolithischen Linuxkernel anzulehnen. Die Struktur des QNX-Kernels wird in Abbildung 3.5 ersichtlich. Um den sehr kleinen QNX Basiskernel werden die Treiber in einzelnen Servern betrieben, welche in eigenständigem Speicherbereich laufen. Durch unterschiedliche Server kann das System mit Funktionalität gefüllt werden. Diese Server werden entweder von QNX Software Systems oder dem Systementwickler erstellt.

24 3. Grundlagen 13 Abbildung 3.5: Einzelne Komponenten im QNX-Mikrokernel (Quelle [Stru05]) Durch die POSIX Anlehnung beinhaltet der QNX-Kernel als Schedulingverfahren FIFO, Round Robin und eine Mischung aus dem FIFO und dem Adaptiven Schedulingverfahren, Sporadic Scheduling genannt. Bei diesem Verfahren wird ein Task, ähnlich wie bei dem FIFO-Scheduling, so lange im Zustand rechnend belassen, wie kein Task mit höherer Priorität ansteht. Bei diesem Verfahren können Tasks ebenfalls verdrängt werden und durch höher priorisierte Tasks unterbrochen werden. Des Weiteren werden die Prioritäten der einzelnen Tasks angepasst und eine maximale Ausführungszeit wird garantiert. Als grafische Benutzeroberfläche beinhaltet QNX Photon microgui, eine schlanke, für den Embedded Bereich angepasste GUI VxWorks Genau wie QNX ist auch VxWorks als hartes Echtzeitbetriebssystem ausgelegt worden, doch mit einem etwas anderen Entwicklungsstandpunkt. Als Hauptzielgebiet für das Echtzeitbetriebssystem stand schon am Anfang seiner Entwicklung rein die Embedded Systeme Welt, was es auch zu dem führenden Embedded Echtzeitbetriebssystem macht (vgl Abbildung 3.1). Der VxWorks-Kernel mit dem Namen Wind, besteht aus einem erweiterten FIFO-Scheduling, auch preemptives Scheduling genannt, für Tasks mit unterschiedlichen Prioritäten. Als Task wird in diesem Zusammenhang die kleinste Recheneinheit bezeichnet. Bei gleichen Prioritäten kann ein Round Robin Scheduler eingesetzt werden. Als Besonderheit des VxWorks Kernels müssen die kurzen Interrupt Latenzzeiten angemerkt werden, die besonders für die harten Echtzeitanforderungen des Systems vorteilhaft sind. Eine logische Schlussfolgerung aus dem eingegrenzten Einsatzgebiet nur für Embedded Systeme ist das One Mode Verhalten, in welchem der Wind Kernel und das restliche System im selben Betriebsmodus arbeiten. Auf den meisten Systemen heißt dies, dass die CPU im Supervisor Modus läuft und somit kein ständiger Wechsel zwischen Kernel Space und User Space nötig wird, wodurch ein entscheidender Nachteil der Mikrokernelarchitektur nicht zum Tragen kommt. Doch durch diese Tatsache wird mehr Verantwortung in

25 3. Grundlagen 14 die Hand des Programmierers gelegt, was die Entwicklungszeiten für ein solches System beeinflusst. Eine weitere Besonderheit der VxWorks Architektur ist das Fehlen von vollständigen Prozessen, so kennt der Wind Kernel nur Tasks (Threads). Dies erfordert ebenfalls einen erhöhten Programmieraufwand, um multitaskingfähigen Code zu schreiben. Diese Tasks werden gegen die Kernel-Bibliotheken gebunden und laufen im gleichen Prozessraum. Somit hat im VxWorks-Kernel jede Applikation die Möglichkeit direkt auf die globalen Daten zuzugreifen. Da ein VxWorks Task im gleichen Kontext wie das restliche System arbeitet, wirken sich einzelne Fehler auf das ganze System aus. Seit der VxWorks Version 6.0 sind Prozesse im Wind-Kernel aufgenommen worden und können für ein VxWorks System genutzt werden Linux Die Geschichte von Linux im Zusammenhang mit Embedded Devices ist etwas anders als bei den beiden vorher genannten Betriebssystemen. Linux wurde als Desktopbetriebssystem konzipiert und entwickelt. So bildet ein monolithischer Kernel die Basis eines Linuxsystems. Trotz der Tatsache, dass die Entwicklung des Linux-Kernels erst 1991 begann und damals die Auffassung vertreten wurde, dass Mikrokernel die Architektur für ein zukünftiges System sind, entschied sich Linus Torvalds bei der Entwicklung des Linux-Kernels für ein monolithisches Konzept. Diese Entscheidung rief einen wahren Wortkrieg zwischen dem Betriebssysteme Professor Andrew Stuart Tanenbaum und Linus Benedikt Torvalds hervor, nachzulesen aus den Archiven der damaligen Diskussion [TaTo02]. Bis heute basiert die Kernelarchitektur auf einem monolithischen Design. Die Gerätetreiber müssen nicht fest in den Betriebssystemkern einkompiliert werden, sondern können als externe Module zu dem laufenden Kernel geladen und entladen werden. Durch einen modularen Linuxkernel besteht genau wie bei einem Mikrokernel die Möglichkeit, einzelne Treiber oder Funktionen des Kernels zu deaktivieren und zu reaktivieren. Der aktuelle Linuxkernel in der 2.6er Basisversion beinhaltet einen sehr performanten Scheduler, auch O(1)-Scheduler genannt. Durch diesen Scheduler hat Linux einen großen Schritt hin zu einem weichen Echtzeitbetriebssystem gemacht. Linux bedient sich ebenfalls der im POSIX-Standard definierten FIFO- und Round Robin Mechanismen. Wie auch bei VxWorks erklärt sich der Scheduling Mechanismus aus dem Haupteinsatzgebiet eines Linux Kernels. Bei Einführung des aktuellen Schedulers, entwickelt von Ingo Molnar, war dies besonders der Servermarkt und zunehmend der Desktopbereich. In beiden Gebieten ist keine harte Echtzeit von Nöten, doch es wird ein besonderer Augenmerk auf Antwortzeit, Effizienz und Interaktivität gelegt. So wurde der alte Linuxscheduler des 2.4er Kernel mit einer Laufzeitkomplexität von O(n) durch den im 2.6er Scheduler ausgetauscht, dessen Name auch gleichzeitig seine Komplexität darstellt O(1). Wie in Kapitel dargestellt, ist diese Laufzeit konstant, ein

26 3. Grundlagen 15 solcher Algorithmus garantiert eine bestimme Bearbeitungszeit ohne Berücksichtigung der Daten. 3.4 Einblick in das Target System Das in Rahmen dieser Masterarbeit eingesetzte InCarMultimedia System wird im Fachbereich Informatik seit WS 2003/04 in der Lehre eingesetzt. Es basiert auf einer von Harman Becker entwickelten Systemhardware. Als Hauptprozessor wurde ein Hitachi SuperH R eingesetzt. Dieser Prozessor beinhaltet in seiner Architektur einen eingebauten PCI-Controller mit dem das System an die externen Komponenten angebunden wird. An den PCI Bus ist eine externe PCI- Adapter Platine angeschlossen, worüber einzelne PCI-Karten an dem System betrieben werden können. Ebenfalls am PCI-Bus befindet sich die zweite zentrale Komponente des Targets, der Xilinx Spartan II FPGA und der Grafik Chip, ein Silicon Motion SM722. Das Target verfügt weiterhin über einen IDE Bus, an dem Festplatte und CDROM angeschlossen sind. Ebenfalls wichtig für eine Portierung sind die seriellen Schnittstellen des Targetsystems, welche in der CPU eingebettet sind und dort als SCI und SCIF zur Verfügung stehen. Als Kommunikationsbus für die Anbindung an weitere automotiven Systeme verfügt das Target über einen MOST Bus Adapter, welcher über einen OASIS OS8104 bereitgestellt wird. Dieser Chip wird über das FPGA angesprochen, welcher eine performante Bearbeitung gewährt und einen Datenpufferung innerhalb des FPGA bietet. 3.5 Einführung in JTAG JTAG ist als Standard in der IEEE Norm verankert und diente anfänglich nur dem Test von integrierten Schaltungen in der Fertigungsproduktion. Heutzutage wird über die JTAG-Schnittstelle aber nicht nur getestet, sondern sie ist für eine Portierung und Erstprogrammierung eines entwickelten Systems unumgänglich. So verbindet man mit JTAG ebenfalls einen InCircuitDebugger, kurz ICD. Meist werden auf einem Hardwaresystem alle Komponenten mit JTAG-Unterstützung in eine JTAG-Kette gehängt, worüber sie dann über einen Analyseport erreichbar sind. JTAG bietet zum Beispiel die Möglichkeit auf Hardwareebene auf die von der CPU zugänglichen Flash-Bausteine zuzugreifen und diese zu programmieren oder die CPU- Register einzeln zu beobachten Lauterbach PowerDebug & Trace32 Für die Arbeit mit der JTAG-Schnittstelle stand bei dieser Masterthesis ein PowerDebugger der Firma Lauterbach zur Verfügung. Über den CPU-Adapter lässt sich der Power- Debugger an fast jeden CPU-Typ anschließen.

27 3. Grundlagen 16 Abbildung 3.6: Trace32 Oberfläche Die Hardwareeigenschaften des PowerDebuggers werden über die Software Trace32 zur Verfügung gestellt, hierdurch ist es möglich verschiedene Aufgaben auf den Targetsystem auszuführen. So stehen folgende wichtige Funktionen bereit : Detaillierte Registeraufstellung, unterteilt in die einzelnen Komponenten welche auf dem Target verfügbar sind Direkten Lese- und Schreibzugriff auf Flash und Ram Assembler View der programmierten Software Breakpoint Unterstützung auf dem Targetsystem Anhand der gebotenen Funktionen kann ein Betriebssystem Schritt für Schritt auf dem System analysiert werden und somit an die bestehenden Ressourcen angepasst werden. Dank der komfortablen Oberfläche (vgl. Abbildung 3.6) ist es möglich, einzelne Betriebssystemroutinen zur Laufzeit zu testen und somit Fehler festzustellen oder die genaue Funktionalität zu ermitteln. Diese Hilfsmittel sind auch sehr gut für das Reverse Engineering von bestehenden Systemen geeignet, z. B. um darauf aufzubauen und die untersuchte Funktionalität für eine Portierung zu nutzen. Für das komfortable Arbeiten mit der Trace32 Oberfläche steht eine Skriptsprache namens PRACTICE [Laut05] zur Verfügung, mit deren Hilfe sich einzelne Abläufe automatisieren lassen und somit den Engineering Prozess unterstützen.

28 3. Grundlagen SH-4 Überblick Um einen genaueren Überblick über das eingesetzte Target zu bekommen, ist es vor allem nötig, die wichtigen Komponenten der eingesetzten CPU näher zu beleuchten. Im Hardware Manual [Rene03] der Herstellerfirma Renesas, über den Hitachi SuperH RISC Prozessor SH7751R, wird diese Engine folgendermaßen beschrieben: The SH-4 (SH7751 Series (SH7751, SH7751R)) microprocessor incorporates the 32-bit SH-4 CPU and is also equipped with peripheral functions necessary for configuring a user system. The SH7751 Series is built in with a variety of peripheral functions such as cache memory, memory management unit (MMU), interrupt controller, floating-point unit (FPU), timers, two serial communication interfaces (SCI, SCIF), real-time clock (RTC), user break controller (UBC), bus state controller (BSC) and PCI controller (PCIC). This series can be used in a wide range of multimedia equipment. The bus controller is compatible with ROM, SRAM, DRAM, synchronous DRAM and PCMCIA. Aus den genannten Komponenten sind besonders jene interessant, welche die Anbindung an externe Geräte realisieren und somit eng mit dem Zielsystem verknüpft sind. Diese werden in den folgenden Kapiteln näher beschrieben Interrupt Controller Der eingesetzte Interrupt Controller des SH7751R unterscheidet zwischen externen Interrupts, internen Interrupts und dem nicht maskierbaren Interrupt. So generiert z. B. der Timer auf der CPU bei jedem Timertick einen einzelnen internen Interrupt, welcher auf dem INTC angenommen wird und sofort eine Exception der CPU auslöst. Diese Art von Interrupt wird von den folgenden Komponenten erzeugt: Hitachi user debug interface unit (H-UDI) Direct memory access controller (DMAC) Timer unit (TMU) Realtime clock (RTC) Serial communication interface (SCI) Serial communication interface with FIFO (SCIF) Bus state controller (BSC) Watchdog timer (WDT) I/O port (GPIO)

29 3. Grundlagen 18 PCI bus controller (PCIC) So dürften alle auftretenden Interrupts abgedeckt sein, für den Fall, dass noch mehr Interruptquellen auf dem System bestehen, bietet der eingesetzte INTC die Möglichkeit, über vier Eingänge IRL0-3 weitere Interrupts zu generieren, welche unterschiedlichen Interrupt Levels zugeordnet werden, siehe Abbildung 3.7. Diese Eingänge können über das Interrupt Control Register (ICR) in ihrer Funktion konfiguriert werden, es gibt zwei verschiedene Möglichkeiten der Konfiguration. So können die Eingänge getrennt als vier unterschiedliche Interruptquellen angeschlossen werden, um jeweils einen Interrupt zu erzeugen. Dies wird im Hardware Manuals [Rene03] als "level sense Interrupt Mode" bezeichnet. Abbildung 3.7: Interrupt Controller (aus[rene03]) Als zweite Konfigurationsart besteht die Möglichkeit, dass sie im Verbund zueinander genutzt werden und vorgeschaltet einen Interrupt Encoder benötigen, welcher 15 verschiedene Quellen den einzelnen Interrupt Levels zuordnet. Bei dieser Art spricht [Rene03] von "Level encoded Interrupts".

30 3. Grundlagen PCI-Controller Um eine standardisierte Anbindung an andere Geräte im System zu erhalten, ist die SH7751R-CPU mit einem eingebauten PCI-Controller ausgestattet. Dieser kann frei konfiguriert werden, um als Master oder Target auf dem Bus zu agieren. Durch den PCI-Bus ist es dem SH-4 möglich, auf den Universal Bus im PC zuzugreifen, hierfür ist der PCIC fast vollständig konform zur PCI Version 2.1. Bei der Nutzung des PCIC ist zu beachten, dass ein größerer I/O Bereich für die SH7751R CPU benötigt wird. Im Standard sind 256 Bytes definiert, doch der SH-4 benötigt 1 MB und dadurch ist während der Konfiguration des PCIC besondere Vorsicht geboten, um Folgefehler auszuschließen. Der PCIC hat zwar eine Interruptgenerierung und ist auch als internes Gerät an den Interrupt-Controller angeschlossen, doch hierüber generiert der PCIC lediglich 8 fest definierte Interrupts, welche nur die PCIC Meldungen berücksichtigen (siehe Tabelle 3.2). Diese Interrupts werden durch interne Fehler im PCI-Controller ausgelöst. Interrupt Quellen PCISERR PCIERR PCIPWDWN PCIPWON PCIDMA0 PCIDMA1 PCIDMA2 PCIDMA3 Funktion Systemfehler Interrupt Algemeiner Fehler Interrupt Ausschalten Anfrage Interrupt Anschalten Anfrage Interrupt DMA0 Übertragungsende Interrupt DMA1 Übertragungsende Interrupt DMA2 Übertragungsende Interrupt DMA3 Übertragungsende Interrupt Tabelle 3.2: Interrupt Quellen Zuordnung Um Interrupts von externen Geräten, welche über den PCI-Bus angeschlossen sind, an den INTC zu melden, bietet der PCI-Controller keinerlei Möglichkeit. Jedes PCI-Geräte besitzt jeweils eine eigenständige Interruptleitung, damit diese eine zugehörige Meldung an den INTC absetzen kann. In der Dokumentation [Rene03] über den PCIC wird auf die Nutzung von IRL 0-3 hingewiesen. Durch diese Hinweise wird gezeigt, wie externe Interruptquellen mit dem INTC verbunden werden. Entweder wird ein Interrupt Multiplexer benötigt oder die Interruptquellen müssen direkt mit IRL 0-3 verbunden sein. Durch einen direkten Anschluss an IRL 0-3 sind maximal 4 verschiedene Interrupts möglich, durch den Interrupt Multiplexer können bis zu 15 verschiedene Quellen an den INTC angeschlossen werden.

31 4. Analyse des QNX-Systems Das in dieser Arbeit genutzte Target wurde von der Firma Harmann Becker mit dem Betriebssystem QNX Neutrino ausgestattet und hierfür wurden auch die nötigen Portierungen und Treiberentwicklungen betrieben. Als erster Schritt auf dem Weg hin zu einer Portierung, ist es daher wichtig, einen genauen Überblick über das bereits portierte Betriebssystem QNX zu erhalten. Das aktuelle Targetsystem wird mit Version QNX Neutrino 6.3 betrieben. QNX bietet für verschiedene Systeme ein vollständiges BSP-Kit an Entwicklungstools an. Anhand dieses BSP-Kits lässt sich ein Hardwaretarget von Grund auf, beginnend beim Bootloader, bis hin zum GUI Framework, realisieren. Ein solches QNX BSP setzt sich grundsätzlich aus 3 Komponenten zusammen: Bootloader, QNX-Mikrokernel und das QNX-System mit den Basisservern. Die Hauptaufgabe bei der Portierung des QNX-Kernels für einen anderen CPU-Typ wird von der Herstellerfirma "QNX Software Systeme" selbst übernommen. So existiert ein QNX-Kernel für die SH-4 CPU des Typs 7751R, diese Portierung des Kernels und des Basissystems beinhaltet eine vollständige Implementierung für alle Standard Komponenten der SH-7751R CPU. Durch die Basisportierung des QNX-Kernel durch die Firma "QNX Software Systeme" ist man gezwungen, jegliche Kernelinterne Arbeit durch die selbige Firma realisieren zu lassen, was zu einer starken Abhängigkeit von dieser Firma führt. Um erste grundlegende Informationen über das Targetsystem zu erhalten ist es wichtig, mit dem JTAG Debugger die genaue Memorymap des aktuellen Systems zu ermitteln (vgl. Abb. 4.1). Als grobe Unterteilung ist bekannt, dass das Targetsystem mit 64 MB Flash und 128 MB Ram bestückt ist. Um nun anhand dieser Informationen eine genauere Memorymap des noch nicht initialisierten und gebooteten Systems erstellen zu können, ist es nötig,

32 4. Analyse des QNX-Systems 21 das System in den Preinitialisierungsmodus zu versetzen. Um dies zu erreichen, ist ein einfacher Reset des Systems ausreichend, der Debugger übernimmt direkt die Verbindung zur CPU und unterbricht diese vor ihrer ersten Aktion, wodurch man ein saubere Memorymap erhält. Diese Memorymap besteht bei dem aktuellen QNX System aus 4 Bereichen, welche man in Abbildung 4.1 erkennt. 0x x x Initial Program Loader Field Programmable Gate Array Image File System 0x Embedded File System 0x7FFFFFFF Abbildung 4.1: Memorymap des Targetsystem unter QNX Bei einem Systemreset startet eine SH-4 CPU ihre erste Instruktion ab Speicheradresse 0x0. Um also ein System zu booten, muss jegliche Operation auf dem Target bei Speicheradresse 0x0 beginnen und von dort an Funktionen initiieren. Dieses initiale Systemverhalten wird bei dem verwendeten Target durch den Initial Program Loader übernommen. In Kapitel 4.1 wird auf diesen eingegangen und seine Funktionen erklärt. Einen weiteren Flashbereich, den man anhand der in Abbildung 4.1 gezeigten Memorymap erkennt, ist der FPGA-Adressraum. Hierbei handelt es sich um die Firmware des FPGA. Darauf folgt der Flashbereich zur freien Verfügung, bei der QNX-Version des Targets ist dieser Bereich in zwei Unterbereiche aufgeteilt. So wird hier unterschieden zwischen Image File System und Embedded File System. Das IFS besteht aus dem QNX Mikrokernel mit Servern für das Basissystem, alle Tools und Bibliotheken, die für ein minimal QNX-System nötig sind. Diese Einteilung wird in Listing A.49 dargestellt. Die zweite Komponente bildet das EFS, hierbei handelt es sich um ein Flashfilesystem, welches das restliche System beinhaltet und von Skripten innerhalb des IFS eingebunden wird.

33 4. Analyse des QNX-Systems IPL-Systemstart Der IPL wird direkt von der CPU angesprungen und von der Speicheradresse 0x0 ausgeführt. An erster Stelle steht eine in Assembler geschriebene Basisfunktion zur Initialisierung der Hardware. Durch das Linken des Binary in einer bestimmten Reihenfolge wird der Assemblercode der Datei reset.s, als erstes eingebunden. Hier stehen auch die allersten Befehle des IPL. Die Verarbeitung startet bei der Funktion _start(). Eines der ersten Punkte jedes Bootloaders, ist die Konfiguration des Bus State Controllers, der zugehörige Code steht ebenfalls in der Datei reset.s, genauer in der Funktion start_init(). Nachdem das System grundlegend initialisiert ist, folgt die Initialisierung der Basisperipherie, wie zum Beispiel der seriellen Schnittstelle SCI. Von hier wird auch die eigentliche IPL main() Funktion gestartet. Zu den weiteren Aufgaben des Initial Program Loader gehöret vor allem das Aktivieren des FPGA. Der IPL konfiguriert das FPGA, über die in Datei fpga_config.s dargestellte Funktion fpga_config, basierend auf der Firmware ab Speicheradresse 0x20000h und aktiviert somit die restlichen Hardwareressourcen auf dem Targetsystem, welche an das FPGA angeschlossen sind. Ab diesem Moment können die einzelnen Komponenten über Gerätetreiber angesprochen werden. Durch Beobachten der Peripherie, vor allem der angeschlossenen Festplatte, kann festgestellt werden, ob das FPGA richtig initialisiert wurde. Eine wesentliche Funktion des IPL ist das Laden des Image File Systems in den Hauptspeicher des Systems und das anschließende Aktivieren des QNX-Kernels. Um diese Funktionalität zu gewährleisten wird während des Ladens des IFS die Checksumme überprüft und somit die Ausführung von falscher Software unterbunden. Diese Checksumme und weitere Informationen werden in einen speziellen Header integriert. Durch die Funktion image_setup() wird dieser Header ausgelesen und z. B. die genaue Speicheradresse berechnet, wohin das IFS-Image kopiert werden soll. Da das IFS in seiner Funktion auf eine schnelle Ressource angewiesen ist, wird es in den RAM-Bereich kopiert und von dort aus gestartet. Die zugehörige Startadresse findet sich auch im IFS-Header wieder. Ohne einen solchen Header werden die Daten nicht als IFS-Image verstanden und der IPL bricht seine Verarbeitung ab. Der IPL, welcher auf dem Target eingesetzt wird, bietet auch weitere Funktionalitäten, wie z. B. ein minimales Bootmenü, über das andere QNX-Images geladen werden können. Dieses wird über ein proprietäres serielles Protokoll direkt in den RAM-Bereich des Targets geladen und von dort aus ausgeführt. Damit diese Funktionalität zur Verfügung steht, bedarf es eines Eingriffes von außen. Dieser Eingriff ist über die serielle Anschlußplatine möglich, hier kann durch einen Taster eine bestimmte Steuerleitung der seriellen Schnittestelle aktiviert werden und so eine Interaktion erzielt werden. Der IPL bietet die Funktion wait_rx_high() (siehe Listing 4.1) um dies zu ermöglichen. Da das aktuelle Bootsystem für die Aktivierung des FPGA zuständig ist, wird es vorerst weiterhin auf dem Target verbleiben. Im Zusammenhang mit dieser Arbeit war es nötig, den Bootloader soweit anzupassen, dass weitere Funktionen zur Verfügung stehen,

34 4. Analyse des QNX-Systems 23 welche für einen anderen Kernel nötig sind. Diese Anpassungen werden in Kapitel 5.2 beschrieben. static void wait_rx_high(void) { while(!(in8(sh_sci_base + SH_SCI_SCSPTR_OFF) & SH_SCI_SCSPTR_SPB0DT)) { } } Listing 4.1: IPL Unterbrechung Um den IPL nicht grundlegend zu verändern, sollten Headerkonformitäten des IFS Images beibehalten werden, hierfür war es nötig den Header genauer zu betrachten. 4.2 QNX-Systemstart Der QNX Systemstart ist grundsätzlich in zwei Schritte unterteilt: Starten des Betriebssystemkerns Aktivieren der einzelnen System Server (Treiber etc.) Beide Komponenten sind im IFS-Image enthalten und wurden zu diesem Zeitpunkt vom IPL in den Arbeitsspeicher geladen. Durch den IFS-Header wird die genaue Startadresse des QNX-Kernels ermittelt und durch den IPL ausgeführt. Der Kernel startet die einzelnen Komponenten, welche im Mikrokernel enthalten sind. Hier ist noch keinerlei hardwarespezifische Treiberkomponente enthalten, jegliche Treiber werden erst aktiviert, nachdem der Kernel gestartet ist. Dieser führt dann ein Startskript aus, in dem jeweils die einzelnen Server geladen werden. Dieser Execute des Kernels läuft nach einem Kontextswitch, somit laufen sämtliche Server und sonstige Software vollständig im Userspace und sind vom Kernelspace getrennt. Jeder Server, der in dem initialen Startskript aktiviert wird, bekommt einzeln Speicher zugewiesen und wird in ein Scheduling-Verfahren eingeordnet. Ein wichtiger Server bei dem aktuellen Targetsystem bildet der in Kapitel 4.3 näher erläuterte PCI Server. Erst nachdem dieser Basisserver aktiviert wurde, kann ein Gerätetreiber für eine einzelne PCI-Komponente auf diese zugreifen. Folgende Gerätetreiber sind im IFS enthalten und bieten ihre Funktionalität schon zum Bootzeitpunkt des Systems an, somit ist zum Beispiel die Ausgabe auf die serielle Schnittstelle auch beim Booten des Systems verfügbar.

35 4. Analyse des QNX-Systems 24 devc-pty devn-el900.so devf-generic devc-sersci dev-most-mops devp-hbpcc16 devg-smi7xx.so devn-ne2000.so 4.3 PCI-System unter QNX Als zentraler Bus auf dem Targetsystem wird PCI genutzt, dieser wird durch den PCI- Controller, der im SH-4 integriert ist, zur Verfügung gestellt. Um das PCI-Subsystem im QNX-System anzubieten, wird ein PCI-Server benötigt, welcher die Treiber für den PCIC des SH-4 beinhaltet. Dieser Server ist im IFS-Image enthalten und somit ist PCI ebenfalls während des Bootens verfügbar. Um das PCI-System unter QNX nutzen zu können, wurde der Templateserver von QNX genutzt und lediglich die Konfigurationsparameter an die spezifische Hardwareressourcen angepasst. Diese spezifischen Anpassungen beziehen sich hierbei besonders auf die Interrupt-Zuweisung für die jeweiligen PCI-Geräte, welche auf dem Bus während des Busscans gefunden werden. Das PCI-Subsystem unter QNX wurde minimal geändert, siehe Listing 4.2, um eine Besonderheit des Targetsystems zu berücksichtigen. #ifdef NEW_PCI_WINDOW SH7751_LB_PCIMBR = 0; SH7751_LB_PCIIOBR = 0x0; #else SH7751_LB_PCIMBR = 0x1d000000; SH7751_LB_PCIIOBR = 0x1e240000; #endif Listing 4.2: QNX PCI-Window Konfiguration Diese Änderungen beziehen sich vor allem auf das so genannte "Sliding Window", welches beim verfügbaren Target genutzt wird. Diese spezifische Funktion entstand aus den Gegebenheiten des eingesetzten PCI-Controllers und den Anforderungen an das Targetsystem. So bietet der im SH-4 integrierte PCI Controller eine Memory Window von

36 4. Analyse des QNX-Systems MB ab der P4-Adresse 0xfd000000, dies entspricht der Area7 Adresse 0x1d Für das PCI-System mit all seinen Komponenten benötigt das Targtesystem jedoch 256 MB Adressraum und ist somit um ein Vielfaches größer bemessen als der tatsächlich abgebildete Adressraum. Für eine vollständige Funktion des Targetsystem war es somit nötig, dem PCI-Controller zur Laufzeit immer wieder einen neuen Adressraum zuzuweisen, je nachdem auf welchen Bereich zugegriffen werden soll. Die aktuelle Lösung, welche im QNX-Targetsystem enthalten ist, beruht auf einer Abänderung der MMU-Routinen, die im QNX-Kernel eingesetzt werden. So wird der PCI- Adressraum als virtueller Adressraum abgebildet und je nachdem, auf welchen Bereich zugegriffen wird, wird geprüft, ob der angeforderte Adressraum verfügbar ist oder ob gerade ein anderer Adressraum eingebunden ist. Bei nicht eingebundenem Adressraum verhält sich das System ähnlich dem Nichtvorhandensein einer Speicherseite und erzeugt einen Pagefault. Dieser wird dann durch die MMU-Routine abgefangen und als Konsequenz, wird der PCI-Controller umkonfiguriert, indem er einen neuen Adressraum zugewiesen bekommt, den er einblenden soll. Durch dieses "Sliding Window" wird die Gesamtsystemperformance beeinträchtigt und schnelle Zugriffe auf unterschiedliche Ressourcen am PCI-Bus sind nur noch bedingt möglich. 4.4 FPGA Device Treiber Das FPGA auf dem Target bietet verschiedene Geräte als eine Singlechip Lösung an. So beinhaltet der FPGA unter anderem die Realisierung des MOST-Controllers, die IDE- Schnittstelle für Festplatte und DVD-Laufwerk und die Anbindung der PCMCIA Schnittstelle. Für das Betriebssystem QNX existieren einzelne Treiber für MOST und PCMCIA (devmost-mops, devp-hbpcc16), diese Treiber wurden von der Firma Harman Becker entwickelt. Bei dem MOST-Treiber wird das Hardwareinterface, Oasis OS8104, über das Interface im FPGA gesteuert und somit eine Kommunikation mit dem automotiven Bus ermöglicht. Der Treiber bietet weiterhin ein Device unter /dev/most0 an, durch welches über den Treiber Zugriff auf die Hardwareressourcen genommen werden kann. Diese Softwareschnittstelle steht nach dem Laden des Treibers der Applikation zur Verfügung. Als weiterer Treiber für den FPGA ist auf dem Target der so genannte "PowerMgr" realisiert, dieser bietet ebenfalls Zugriff auf interne Ressourcen des FPGA. Er beinhaltet auch verschiedene Funktionen zur Steuerung des kompletten Targetsystems, so kann über den PowerMgr die Konfiguration der Grafikkarte angepasst werden und somit Auflösung und Bildwiederholrate geändert werden. Als weitere Features des PowerMgr stehen einzelne Zugriffe auf die WakeUp-Funktionen zur Verfügung, über die das Target in seinen Eigenschaften beeinflussen kann und einzelne Komponenten aktivieren und deaktivieren kann. Der Powermgr ist das Konfigurationstool des FPGA und des SH-4 Targetsystem.

37 4. Analyse des QNX-Systems Ergebnis der QNX Systemanalyse Durch die Analyse des unter QNX betriebenen Systems wurden die einzelnen Schritte sichtbar, welche für eine Portierung nötig sind. Als erkannte Schritte wurden in einer ersten Analyse folgende Punkte eingeordnet: Der Bootloader muss soweit angepasst werden, dass das zukünftige Betriebssystem in den Arbeitsspeicher geladen und von hier gestartet werden kann. Dazu ist die genaue Adresse des ersten Kernelabschnittes zu ermitteln, von welcher aus der Kernel gestartet wird. Weiterhin muss die Parameterübergabe an den Kernel für den Bootloader realisiert werden, um den Bootvorgang über Parameter steuern zu können. Die serielle Schnittstelle des Targetsystems wird vom IPL aktiviert und steht dort schon für frühe Debugausgaben zur Verfügung. Es ist für die Portierung eines Betriebssystems unabdingbar, schon zu einem frühen Zeitpunkt eine funktionierende Debugausgabe zu besitzen, um Fehler und Erfolge erkennen zu können. So ist dieser Schritt ebenfalls eines der ersten Tätigkeiten, welche für die erfolgreiche Portierung eines Betriebssystems von Nöten sind. Der PCI-Server des QNX-Systems ist ein erster Anhaltspunkt für das Initialisieren des PCI-Controller auf dem SH-4-System. Da der PCI-Bus auf dem System als zentraler Datenbus eingesetzt ist, wird diese Implementierung eine der Hauptpunkte für das neue Betriebssystem sein. Das Interruptsystem ist bei QNX eng mit dem PCI-Server gekoppelt, so registriert der PCI-Server die Interrupts für die einzelnen PCI-ID s im System. Diese Registrierung zeigt, welche ID auf welchen IRQ gemappt wird, und ist somit ein wichtiger Anhaltspunkt für die Registrierungsprozedur in einem anderen Betriebssystem. Hieraus resultiert ein funktionierendes Interruptsystem, was für eine Portierung unabdingbar ist. Die FPGA-Gerätetreiber bieten einzelne Zugriffe auf dedizierte Einzelressourcen innerhalb des FPGA, so ist es für eine Portierung von Interesse, jedes einzelne Gerät in all seinen Funktionen innerhalb eines eigenständigen Gerätetreibers abzubilden und damit Schnittstellen für die Systemsoftware anzubieten. Als logische Konsequenz aus den Funktionen des Powermgr ist eine funktionsähnliche Implementierung für ein anderes Betriebssystem wünschenswert.

38 5. Realisierung des Linux-Systems Seit den frühen Anfängen im Jahr 1991 wurde das Betriebssystem Linux als monolithischer Kernel konzipiert und im Oktober 1991 als erster Betriebssystemkern unter zuerst proprietären und bald einer freien Lizenz von Linus Torvalds veröffentlicht. Durch die Entscheidung, Linux unter die Open Source Lizenz GPL zu setzen, startete er einen Automatismus in der Kernelentwicklung. So schlossen sich sehr schnell verschiedene Entwickler der Linux-Kernelgemeinde an und erweiterten den Kernel um diversen Abschnitte, angefangen bei Memory-Management bis hin zu unterschiedlichen Treibern. Durch diese sehr gemischte Entwicklergemeinde wurde der Kernel auch früh für die unterschiedlichste Hardware portiert. Es entstand die Notwendigkeit, den Kernelcode zu separieren, um die verschiedenen Hardwareplattformen übersichtlich und sauber in den Kernel zu integrieren. Zu Beginn rein auf die x86 Plattform ausgelegt, wurde kurz nach der Veröffentlichung damit begonnen, andere Plattformen wie alpha, m68k, mips, ppc und sparc einzubinden, so dass der Linux-Kernel sehr bald den Ruf hatte, auf jedem Gerät laufen zu können. Durch diese vielfältige Prozessorunterstützung wurde auch bald die erste Unterstützung für Embedded Hardwareplattformen in den Linux-Kernel aufgenommen. Durch diese Entscheidung öffnete sich Linux ein sehr weites Einsatzgebiet. Durch die Anlehnung von Linux an ein UNIX Betriebssystem und der damit verbundenen Tatsache, dass Unix-Programme einfach zu übertragen sind, um auf einem Linux-Kernel zu agieren, war das Interesse in der IT-Welt sehr schnell geweckt. Für die Verbreitung des Linux-Kernels sorgten das Internetzeitalter und die Freie Software Lizenz. Diese Arbeit setzt das Open Source Betriebssystem Linux als Grundlage für ein neues Automotives System ein. Der eingesetzte Kernel basiert auf der Version , welche am 02.März 2005 erschien. Während der Arbeit wurden keine Updates des Kernels vorgenommen, obwohl etliche neue Versionen veröffentlicht wurden, doch eine stabile Arbeitsbasis sollte der Ausgangspunkt sein.

39 5. Realisierung des Linux-Systems Das Arch Verzeichnis Die Tatsache, dass der Linux-Kernel schon früh auf verschiedenen Plattformen portiert wurde, machte es nötig, eine Architekturverwaltung für den Kernel zu erstellen, damit die verschiedensten Plattformen einfach integriert werden konnten. So wurde ab Version das Arch Verzeichnis für diese Aufgabe eingeführt und jegliche spezifische Anpassung für einen CPU-Typ einzeln eingeordnet. So besteht das Verzeichnis linux/arch/ aus einzelnen Unterverzeichnissen, welche die verschiedenen Hauptplattformen benennen und deren Implementierung beinhalten. tree -L 1 -d. -- alpha -- arm -- arm26 -- cris -- frv -- h i ia64 -- m32r -- m68k -- m68knommu -- mips -- parisc -- ppc -- ppc64 -- s sh -- sh64 -- sparc -- sparc64 -- um -- v x86_64 Listing 5.3: Das Architektur-Verzeichnis Der in dieser Arbeit genutzte CPU-Typ gehört zur Familie der SH-Prozessoren und wird deshalb unterhalb des sh/ Verzeichnis angesiedelt. Ein erster Blick auf das sh Verzeichnis zeigt schon, welche Unterteilung hier einzuhalten ist.

40 5. Realisierung des Linux-Systems 29 tree -L 1 -d. -- boards -- boot -- cchips -- configs -- drivers -- kernel -- lib -- mm -- oprofile -- ramdisk -- tools Listing 5.4: Das SH-Verzeichnis Die einzelnen Entwicklungsplattformen werden unterhalb des Verzeichnis boards/ angesiedelt, dort wird auch das Arbeitsverzeichnis für eine plattformspezifische Änderung und Anpassung für diese Arbeit erstellt. Jedes Verzeichnis bezeichnet entweder direkt die Plattform oder den Arbeitstitel des Arbeitszweigs unter welchem gearbeitet wird. So ist das Verzeichnis in dieser Arbeit becker/b1/, dort werden alle boardspezifischen Anpassungen getroffen. sergio@veriton:/usr/src/linux/arch/sh$ tree -L 3 -d. -- boards -- adx -- becker -- b1 -- bigsur -- cat cqreek -- dmida -- dreamcast Listing 5.5: Das Board-Verzeichnis Das Verzeichnis boards/ beinhaltet aber nur spezifische Teile der Portierung, so wird hier zum Beispiel definiert, wie die einzelnen Zugriffe auf dieser Architektur und diesem Board im genaueren durchgeführt werden. Für die Basisportierung auf die Prozessorfamilie werden alle Kernelfunktionen unterhalb von arch/sh/kernel/ erstellt. Hier findet man folgende Dateien:

41 5. Realisierung des Linux-Systems 30 tree -L 1 grep \.c. -- asm-offsets.c -- cf-enabler.c -- cpufreq.c -- early_printk.c -- init_task.c -- io.c -- io_generic.c -- irq.c -- kgdb_stub.c -- module.c -- process.c -- ptrace.c -- semaphore.c -- setup.c -- sh_bios.c -- sh_ksyms.c -- signal.c -- smp.c -- sys_sh.c -- time.c -- traps.c Listing 5.6: Die Kernelplattform für SH Wie man an der Aufstellung im Listing 5.6 erkennt, werden hier Basisfunktionen des Betriebssystems aufgeführt und deren genaue Umsetzung auf einer SH-basierten Architektur. Um einen lauffähigen Kernel für eine spezielle CPU zu erhalten, müssen die verschiedenen Implementierungen eingeteilt werden, welche von der CPU-Familie abhängig sind und diejenigen Implementierungen, welche nur von einer CPU unterstützt werden. sergio@veriton:/usr/src/linux/arch/sh/kernel/cpu$ tree. -- Makefile -- adc.c -- bus.c -- init.c -- irq_imask.c -- irq_ipr.c -- rtc.c -- sh2 -- Makefile -- probe.c -- sh3

42 5. Realisierung des Linux-Systems Makefile -- ex.s -- probe.c -- sh4 -- Makefile -- ex.s -- fpu.c -- irq_intc2.c -- probe.c -- sq.c -- ubc.s Listing 5.7: Die CPU Portierung 5.2 Der angepasste Bootloader Das Booten wird bei Desktop-PC-Systemen über das BIOS veranlasst. Nachdem das BIOS das System minimal initialisiert und damit in eine definierte Ausgangslage bringt, wird meist die erste Instruktion im Master-Boot-Record der Festplatte ausgeführt. Dort befindet sich meist ein weiterer Bootloader an der ersten Stelle des MBR, so dass dieser genaue Methoden kennt, um das genutzte Betriebssystem zu laden und zu starten. Bei dem eingesetzten Target und bei den meisten Embedded Systemen ist diese Zweiteilung nicht nötig und meist auch nicht erwünscht. Da ein Embedded System, anders als ein PC-System, ein bestimmtes, für die Aufgaben angepasstes, Betriebssystem einsetzt, wird der Bootloader meist um die BIOS-Funktionen erweitert. So ergibt sich ein kompakter IPL, der nur die nötigen Funktionen für das eingesetzte Betriebssystem mitbringt. Der auf dem Target eingesetzte IPL basiert auf der QNX ipl-library und bietet die nötige Funktionalität, um einen QNX-Kernel auf der Hardwareplattform zu starten. Trotz der angeschlossenen Festplatte am Targetsystem wird das Betriebssystem aus dem verfügbaren Flash geladen. Dies erleichtert die Aufgaben für den IPL der dadurch nicht allzu komplex wird. Um nun den Linux-Kernel auf dem Target auszuführen, ist es nötig, ein passendes Kernelbinary an die Flash-Adresse zu schreiben, an welcher der IPL ein passendes Image sucht. Durch die Analyse des QNX-IFS hat sich gezeigt, dass sich dieser prinzipiell aus zwei Teilen zusammensetzt, erstens die Daten, welche für einen Systemstart genutzt werden und zweitens dem Datei-Header, bestehend aus verschiedenen Einträgen, welche von dem IPL genutzt werden. Um einen Linux-Kernel auf diesem System zu starten, ist es nötig, diesen Header für das Linuxbinary zu erstellen. Aus diesem Grund ist eine genauere Analyse der IFS-Header

43 5. Realisierung des Linux-Systems 32 nötig, um eine genauere Informationen über die einzelnen Felder zu erhalten. Der 256 Byte große Header unterteilt sich in verschiedene Bereiche, welche in Listing 5.8 aufgeführt sind. struct startup_header { unsigned long signature; /*I Header sig, see below*/ unsigned short version; /*I Header vers, see below*/ unsigned char flags1; /*IS Misc flags, see below*/ unsigned char flags2; /* No flags defined yet*/ unsigned short header_size; /*S sizeof(struct startup_header)*/ unsigned short machine; /*IS Machine type from sys/elf.h*/ unsigned long startup_vaddr; /*I Virtual Address to transfer*/ /* to after IPL is done*/ unsigned long paddr_bias; /*S Value to add to physical address*/ /* to get a value to put into a*/ /* pointer and indirected through*/ unsigned long image_paddr /*IS Physical address of image*/ unsigned long ram_paddr; /*IS Physical address of RAM to copy*/ /* image to (startup_size bytes copied)*/ unsigned long ram_size; /*S Amount of RAM used by the startup*/ /* program and executables contained*/ /* in the file system*/ unsigned long startup_size; /*I Size of startup (never compressed)*/ unsigned long stored_size; /*I Size of entire image*/ unsigned long imagefs_paddr; /*IS Set by IPL to where the imagefs is when startup runs*/ unsigned long imagefs_size; /*S Size of uncompressed imagefs*/ unsigned short preboot_size; /*I Size of loaded before header*/ unsigned short zero0; /* Zeros */ unsigned long zero[3]; /* Zeros */ unsigned long info[48]; /*IS Array of startup_info* structures*/ }; Listing 5.8: Der IFS Header Da der QNX-IPL normalerweise eine Prüfsummenberechnung beinhaltet, um nur zugelassene Kernel zu starten, müsste dieses Verfahren in der Headergenerierung berücksichtigt werden. Auf Grund der Entwicklungsversionen des IPL und ebenfalls des Targets wird dieser Punkt im QNX-IPL nicht berücksichtigt, sondern eine feste Signatur eingetragen. Für ein Produktivsystem ist ein solcher Sicherungsmechanismus dringend zu empfehlen. Als eine Möglichkeit der Realisierung könnte eine Mischung aus Prüfsumme des Binary und PKI-Verfahren Verwendung finden. Durch die steigende Multimedialeistung eines automotiven Systems wird es in Zukunft vermehrt Anforderungen an verschiedenste Multimedia-Codecs geben und somit ebenfalls eine erhöhte Anforderung an ein "Digital

44 5. Realisierung des Linux-Systems 33 Rights Management" für ein solches System. Solche Systeme müssen Sicherungsverfahren schon zum Systemstart berücksichtigen, was heutzutage durch besonders intensive Verschlüsselungsverfahren erreicht wird. Solche Verfahren sind nicht nur heutzutage besonders sicher, sie benötigen auch eine gewisse Zeit, um ein verschlüsseltes System zu entschlüsseln. Somit wird es in zukünftigen IPL s besonders wichtig sein, ein schnelles und sicheres Verfahren für solche DRM-Anforderungen zu implementieren. Der Linux-Kernel nutzt verschiedene Informationen zum Booten auf einem System. Zwar ist es möglich, ein System ohne jegliche Parameterübergabe zu starten, doch ist für eine effizientere und komplettere Nutzung der Kernelfunktionen eine Parameterübergabe unabdingbar. Diese Anforderung an den Kernel wurde untersucht und verschiedene Möglichkeiten für die Parameterübergabe gefunden. So besteht grundlegend die Möglichkeit, dem Kernel all seine Bootparameter schon während der Kompilierungszeit fest vorzugeben (siehe Abb. 5.1). Diese erste Parameterübergabe wird in der Kernelkonfiguration über das Buildsystem eingetragen und wird in der start_kernel() Funktion, aufgelistet im Listing 5.12, des Kernels als char * command_line; gelesen. Abbildung 5.1: Konfiguration der Parameterübergabe im Linux-Kernel Da diese Methode unabhängig von einem Linux-konformen Bootloader arbeitet, ist diese Art der Parameterübergabe insbesondere bei den Anfängen der Portierung zum Einsatz gekommen, da es hierbei auf genau definierte und hundertprozentig funktionierende Kernelafunktionen ankam. Eine Implementierung der Linux-Bootumgebung wurde erst nach der erfolgreichen Basisportierung angegangen. Hierbei halfen die Erkenntnisse aus Kapitel 5.3, um das genaue Bootverhalten des Kernels bei einer IPL-basierten Parameterübergabe zu bestimmen. Da der Kernel nicht wie ein Programm mit einer bestimmten Übergabe an Kommandos gestartet wird, haben die Kernelentwickler eine feste Struktur entwickelt und ihr einen definierten Platz im Speicher zugewiesen. Die nötige Struktur wird in Listing 5.9 dargestellt. Diese Parameter werden einzeln benötigt, um dem Kernel mitzuteilen, wie er geladen wurde und was er noch zu tun hat, zum Beispiel benötigt der Kernel MOUNT_ROOT_RD- ONLY, um über den Bootloader mitgeteilt zu bekommen, ob das rootfs / Filesystem im Nur-Lesen-Modus eingebunden werden soll.

45 5. Realisierung des Linux-Systems 34 /* * This is set up by the setup-routine at boot-time */ #define PARAM ((unsigned char *)empty_zero_page) #define MOUNT_ROOT_RDONLY (*(unsigned long *) (PARAM+0x000)) #define RAMDISK_FLAGS (*(unsigned long *) (PARAM+0x004)) #define ORIG_ROOT_DEV (*(unsigned long *) (PARAM+0x008)) #define LOADER_TYPE (*(unsigned long *) (PARAM+0x00c)) #define INITRD_START (*(unsigned long *) (PARAM+0x010)) #define INITRD_SIZE (*(unsigned long *) (PARAM+0x014)) /*... */ #define COMMAND_LINE ((char *) (PARAM+0x100)) Listing 5.9: Bootparameter und Commandline Adressen Was man ebenfalls an dem Listing 5.9 erkennt, ist ein #define PARAM, hier ist ein konfigurierter Platzhalter im Kernel Binary enthalten, damit ein Offset geschaffen werden kann der immer gleich ist für den eingesetzten Bootloader. Diese empty_zero_page ist standardmäßig bei Speicheradresse 0x1000 und muss natürlich bei einem Linux-konformen Bootloader entsprechend berücksichtigt werden. *(long *)basereg = 1; /* Read only mount? */ *(long *)(basereg+4) = 0; /* RAMDISK Flags */ *(long *)(basereg+8) = 0x0301; /* Root device: XXX should get from cls.. */ *(long *)(basereg+12) = 1; /* Loader type (LILO = 1) */ *(long *)(basereg+16) = 0; /* Initrd start */ *(long *)(basereg+20) = 0; /* Initrd size */ *(long *)(basereg+24) = 0; /* Not defined yet */ char *commandline = (char *)(basereg+256); /* Commandline */ Listing 5.10: Bootparameter zur Initialisierung Um nun eine funktionierende Commandline für den Kernel bereit zu stellen, muss ein nullterminierter String an die Speicheradresse geschrieben werden. Dieser wird dann von parse_cmdline() in die verschiedenen Einzelparameter unterteilt und somit alle Funktionen und Treiber mit den richtigen Angaben initialisiert. Der vorliegende IPL wurde um Debug-Ausgaben, Parameterübergabe und einigen nützliche Bibliotheksfunktionen erweitert. Ab diesem Zeitpunkt kopiert der IPL den Linux Kernel an die dafür vorgesehene Adresse, übergibt die Kernel Comandline, setzt die Bootflags und springt an den Kernelanfang, dieser Vorgang ist in Listing 5.11 zu sehen.

46 5. Realisierung des Linux-Systems 35 Welcome to minicom 2.1 OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n Compiled on Mar , 09:39:09. Press CTRL-A Z for help on special keys FPGA configuration skipped! Loading Header to 0x Loading Image to 0x for length 0x00224A06 Loading BaseParams to 0x Loading Commandline to 0x Writing Commandline console=ttysc0,57600 nfsroot= :/opt/nfsroot root=/ dev/nfs rw ip= : : : Lenght of Commandline is Bytes Executing from 0x Listing 5.11: IPL Bootausgabe 5.3 Lowlevel Linux-Kernelstart Nachdem der IPL den Linux-Kernel an die im IPL-Header angegebenen Speicheradresse kopiert hat, wird die CPU-Rechenzeit an den Linux-Kernel übergeben und die ersten Instruktionen des Kernels werden ausgeführt. Diese ersten Befehle sind in der Datei arch/sh/kernel/head.s enthalten. Hier findet sich auch das, in Kapitel 5.2 angesprochene, Parameterkonstrukt für die Kernelinitialisierung. In Darstellung 5.2 wird der Speicherbereich ersichtlich. Während die Datei arch/sh/kernel/head.s abgearbeitet wird, wird die plattformabhängige Initialisierung getätigt, wie z. B. Basisregister initialisieren und den Prozessor in den passenden Supervisormodus schalten. Nachdem diese Architekturinitialisierung erfolgt ist, startet der spezifische Code die eigentliche Kernelbasisfunktion start_kernel(). Dies ist der Anfang des Kernels, jegliche vorangegangen Initialisierung dient dem Zweck, einen definierten Systemstatus zu haben, um somit den Kernel sauber starten zu können. Bei Targetsystemen mit kleinem Kernel werden die Basisinitialisierungen vom IPL getätigt und die Datei arch/sh/kernel/head.s um diesen Code gekürzt. Diese Kürzung sollte jedoch nur dann berücksichtigt werden, wenn es besonders auf Performance ankommt. Es ist empfehlenswert die Initialiserung hier zu belassen, da hierdurch eine definierte Bootsituation eingestellt wird. Da der Kernel zu diesem Zeitpunkt noch keinerlei Ausgabemedium, wie serielle Schnittstelle, kennt, ist bei diesem Schritt nur das Debuggen über LEDs möglich. Dazu standen leider keine Informationen zur Verfügung, um eventuell über Memoryread/write eine LED ein- oder auszuschalten.

47 5. Realisierung des Linux-Systems 36 0x x x Initial Program Loader Field Programmable Gate Array Image File System IFS Header head.s 0x Linux Kernel Embedded File System 0x7FFFFFFF Abbildung 5.2: Memorymap des Linux-Kernels Während des Abarbeitens der Funktion start_kernel() werden verschiedenste Funktionen aktiviert, wodurch das System immer komplexer wird. Jegliche Textausgabe wird vom Kernel über die printk() Funktion getätigt, welche bei der Initialisierung ihre Ausgaben auf /dev/console umleitet. Sobald sich im Kernel ein Treiber für das entsprechende Gerät anmeldet, werden die Ausgaben an diesen übergeben und erst dann erscheint etwas auf der Schnittstelle. Bevor es überhaupt zu diesem Schritt kommt, stehen weitere Initialisierungen an. Wie man anhand der Funktion start_kernel() erkennt (Listing 5.12) werden vor der eigentlichen Initialisierung der seriellen Schnittstelle über die Funktion console_init() noch verschiedene Funktionen aufgerufen, welche alle erfolgreich zurückkehren müssen. Da bei einer Kernelportierung auf ein unbekanntes Target vor allem eine funktionierende Debugausgabe zum frühestmöglichen Zeitpunkt nötig ist, stellt dies eine anspruchsvolle erste Hürde dar. asmlinkage void init start_kernel(void) { char * command_line; extern struct kernel_param start param[], stop param[]; /* * Interrupts are still disabled. Do necessary setups, then * enable them */ lock_kernel(); page_address_init(); printk(linux_banner); setup_arch(&command_line); setup_per_cpu_areas();

48 5. Realisierung des Linux-Systems 37 /* * Mark the boot cpu "online" so that it can call console drivers in * printk() and can access its per-cpu storage. */ smp_prepare_boot_cpu(); /* * Set up the scheduler prior starting any interrupts (such as the * timer interrupt). Full topology setup happens at smp_init() * time - but meanwhile we still have a functioning scheduler. */ sched_init(); /* * Disable preemption - early bootup scheduling is extremely * fragile until we cpu_idle() for the first time. */ preempt_disable(); build_all_zonelists(); page_alloc_init(); printk("kernel command line: %s, %s \n", saved_command_line, command_line ); parse_early_param(); parse_args("booting kernel", command_line, start param, stop param - start param, &unknown_bootoption); sort_main_extable(); trap_init(); rcu_init(); init_irq(); pidhash_init(); init_timers(); softirq_init(); time_init(); /* * HACK ALERT! This is early. We re enabling the console before * we ve done PCI setups etc, and console_init() must be aware of * this. But we do want output early, in case something goes wrong. */ console_init(); if (panic_later) panic(panic_later, panic_param); profile_init(); local_irq_enable(); #ifdef CONFIG_BLK_DEV_INITRD if (initrd_start &&!initrd_below_start_ok && initrd_start < min_low_pfn << PAGE_SHIFT) { printk(kern_crit "initrd overwritten (0x%08lx < 0x%08lx) - " "disabling it.\n",initrd_start,min_low_pfn << PAGE_SHIFT); initrd_start = 0;

49 5. Realisierung des Linux-Systems 38 } #endif vfs_caches_init_early(); mem_init(); kmem_cache_init(); numa_policy_init(); if (late_time_init) late_time_init(); calibrate_delay(); pidmap_init(); pgtable_cache_init(); prio_tree_init(); anon_vma_init(); #ifdef CONFIG_X86 if (efi_enabled) efi_enter_virtual_mode(); #endif fork_init(num_physpages); proc_caches_init(); buffer_init(); unnamed_dev_init(); security_init(); vfs_caches_init(num_physpages); radix_tree_init(); signals_init(); /* rootfs populating might need page-writeback */ page_writeback_init(); #ifdef CONFIG_PROC_FS proc_root_init(); #endif check_bugs(); acpi_early_init(); /* before LAPIC and SMP init */ /* Do the rest non- init ed, we re now alive */ rest_init(); } Listing 5.12: Die start_kernel() Funktion Da weder LED noch textuelle Debugausgabe zu diesem Zeitpunkt möglich war, wurde die "In Circuit Debug" Methode getestet. Für diese Debug-Art muss das Targetsystem mit dem "JTAG Power Debugger" verbunden sein und der Debugger muss aktiviert sein, damit ein Online-Debug möglich ist. Nachdem der IPL den Kernel startet, befindet sich der Processcounter (PC) an der Speicheradresse 0x Durch die komfortable Oberfläche Trace32 für die JTAG Schnittstelle wird der Speicherinhalt direkt in dissassemblierter Form dargestellt (siehe

50 5. Realisierung des Linux-Systems 39 Abb 5.3 und ist hierdurch sehr gut zu lesen. Um eine Codeverifizierung durchzuführen und verlässliche Ergebnisse zu erhalten, ist es nun noch nötig, das Elf-File des Kernels zu dissassemblieren und somit eine Vergleichsbasis (vgl. Listing 5.13) zu erhalten. -D vmlinux vmlinux: file format elf32-sh-linux Disassembly of section.empty_zero_page: <empty_zero_page>: : word 0x : word 0x : word 0x : word 0x : word 0x a: word 0x c: word 0x e: word 0x : word 0x : mov.l : word 0x : 0a 00 sts mach,r0... Disassembly of section.text: <_stext>: : 0b d0 mov.l <_stext+0x30>,r0! 0x400080f : 0e 40 ldc r0,sr : 00 e0 mov #0,r : ee 40 ldc r0,r6_bank : 0a d0 mov.l <_stext+0x34>,r0! 0x a: 03 6f mov r0,r c: 20 e1 mov #32,r e: shll8 r : sub r1,r : fe 40 ldc r0,r7_bank : 0b d0 mov.l <_stext+0x44>,r0! 0x : 0b : nop a: 07 d1 mov.l <_stext+0x38>,r1! 0x c: add #4,r e: 07 d2 mov.l c <_stext+0x3c>,r2! 0x88245b : 00 e0 mov #0,r : cmp/hs r2,r : fd 8f bf.s <_stext+0x22> Listing 5.13: Dissassembliertes Kernelbinary

51 5. Realisierung des Linux-Systems 40 So erkennt man an diesem ersten Stück Assemblercode in der Funktion _stext die Codeteile aus der Datei arch/sh/kernel/head.s. Anhand der Funktionsnamen in < > kann man die einzelnen Funktionen im dissassemblierten Code erkennen und daraufhin die entsprechende Speicheradresse über das JTAG-System auslesen. Mit Hilfe dieser Vergleichsmöglichkeit und dem Einblick in den Sourcecode des Kernels und insbesondere in die start_kernel() Funktion ergibt sich die Möglichkeit, die einzelnen Funktionen schrittweise zu debuggen. Schon früh, nachdem die ersten Funktionen innerhalb start_kernel() abgearbeitet wurden, sind die Interrupts und die MMU auf dem Target aktiviert, wodurch der Kernel nicht mehr einzeln getraced werden kann, da z. B. der Timerinterrupt regelmäßig zwischen den Einzelschritten ausgelöst wird und so das Singlestep-Trace erheblich erschwert. Um die Funktionen zu debuggen, welche in der start_kernel() Funktion aufgerufen werden und somit einen möglichen Fehler zu entdecken, werden einzelne Breakpoints gesetzt, wodurch ein ähnliches Schrittverhalten erreicht wird. Abbildung 5.3: Trace32 Speicherausschnitt Durch dieses "In Circuit Debuggen" hat man die Möglichkeit zu erkennen, in welchem Teilabschnitt sich der Kernel gerade befindet und somit mögliche Probleme aufzudecken. Als weitere Aufgaben ergeben sich die Adaption der nötigen Basiselemente, welche der Kernel für weitere erste Startschritte benötigt. Als mögliche Problempunkte wurden insbesondere die Timer Initialisierung eingeordnet und durch das JTAG-Debuggen wurde bestätigt, dass der Kernel genau an dieser Stelle auf ein Problem gestoßen ist.

52 5. Realisierung des Linux-Systems Timer Beim ersten Bootvorgang wurde mit Hilfe der JTAG-Schnittstelle ermittelt, dass die Initialisierung nicht die console_init() Funktion ausführt, weil die time_init() Funktion zuvor nicht von ihrer Verarbeitung zurückkehrte. Da diese Funktion durch architekturspezifischen Code dargestellt ist, welcher die Hardwaretimer ausliest und diese dann dem Kernel zur Verfügung stellt, ist hier eine Anpassung für das Target nötig. Durch genaueres Analysieren der Targethardware und insbesondere der Timer wurde festgestellt, dass auf der eingesetzten Hardwareplattform keinerlei Realtime Clock (RTC) zum Einsatz kam und somit auch dieser Baustein nicht initialisiert werden kann. Als Konsequenz der fehlenden RTC wurde die RTC-Initialisierung übergangen und die Uhr im Softwaresystem auf den initialisiert, doch nicht in der Hardwareuhr abgespeichert. Durch diese fehlende Uhr im System muss für eine Uhrzeit bei jedem Booten die Zeit über ein Zeitprotokoll wie NTP oder ähnliches aktualisiert werden. Mit dem Fehlen der RTC besteht aber keine Einschränkung in der Systemfunktion, da diese nur zum Auslesen der Uhrzeit genutzt wird. Für ein vollwertiges System benötigt der Linux-Kernel lediglich einen funktionierenden Timerbaustein, welcher regelmäßig einen Interrupt generiert. Anhand dieses Timers werden dann innerhalb des Kernels die Jiffies bei jedem Interrupt erhöht und somit ein regelmäßiger Event erzeugt. Der Hardwaretimer hat nur auf dieses Ereignis Einfluss, alle anderen Timer innerhalb des Kernels bauen auf den Jiffies auf. Der Jiffie-Timer wird durch den Kernel initialisiert und stellt einen bestimmtes Zeitintervall bereit, so ist bei der eingesetzten SH4 Plattform dieses Intervall 10 ms pro Jiffi. Für einen schnelleres Jiffie Intervall kann in der Datei include/asm/param.h die Konstante HZ angepasst werden. Bei Kernelversion ist die Konstante auf 100 gesetzt, für den aktuellen Linux-Kernel in der Version wurde auf der x68 Architektur dieser Wert auf 250 gesetzt. Durch die Jiffies wird unter anderem die minimale Zeitscheibe für den Scheduler festgelegt. Nachdem alle Timer initialisiert sind und ein Datum im System verankert ist, kehrt die Funktion time_init() erfolgreich zur Funktion start_kernel() zurück und hier kann der nächste Schritt aufgerufen werden. 5.5 Basissystem Initialisierung Nachdem die Grundlagen für den Linux-Kernel auf dem Target konfiguriert wurden, kann der Kernel erfolgreich fertig booten und somit seinen Arbeitsbetrieb aufnehmen. Sobald der Schritt zur Timer-Initialisierung erfolgreich durchgeführt wurde, lässt sich anhand der JTAG-Schnittstelle feststellen, dass das System nun auf das Filesystem wartet. Da aber noch keinerlei Debug über ein Terminal möglich ist, kann man nur mit sehr viel Aufwand und mit Hilfe der JTAG ermitteln, welche Geräte auf dem Target initialisiert wurden und welche von dem laufenden Kernel nicht beachtet wurden. Um dieses Hindernis aus dem

53 5. Realisierung des Linux-Systems 42 Weg zu räumen muss der Treiber für die serielle Schnittstelle auf dem Target dementsprechend angepasst werden. Da auf dem Target zwei serielle Schnittstellen in der CPU integriert sind, muss vor der Benutzung die richtige Schnittstelle ermittelt werden. Bei den beiden Geräten handelt es sich einerseits um standardisierte Schnittstellen, genauer um ein Serial Communication Interface (SCI) und andererseits um ein Serial Communication Interface mit FIFO (SCIF). // serial interface for welcome message and image download #define DEBUG_INTFC 1 // 1 = SCI, 2 = SCIF #define DEBUG_BR 57600U // baudrate Listing 5.14: Serielle Schnittstellen Konfiguration im IPL Über den IPL wird während des Bootvorgangs das SCI konfiguriert und genutzt. Diese Schnittstelle wird auf dem Target als einzige nach außen geführt, auf das SCIF hat man im Moment keinerlei direkten Zugriff. Um das SCI über den Linuxtreiber nutzen zu können, wird die passende Konfiguration benötigt. Die Parameterübergabe kann durch den modifizierten IPL über die Commandline erfolgen. static struct uart_driver sci_uart_driver = {.owner = THIS_MODULE,.driver_name = "sci", #ifdef CONFIG_DEVFS_FS.devfs_name = "ttsc/", #endif };.dev_name = "ttysc",.major = SCI_MAJOR,.minor = SCI_MINOR_START,.nr = SCI_NPORTS,.cons = SCI_CONSOLE, Listing 5.15: SCI-Gerätetreiber im Linux-Kernel Hieraus ergibt sich ein erster Parameter für die Übergabe, console=ttysc0, Sobald diese Änderungen im IPL stehen und an den Linux-Kernel übergeben werden, zeigt sich zum allerersten Mal die Bootsequenz des Linux-Kernels.

54 5. Realisierung des Linux-Systems 43 Loading Header to 0x Loading Image to 0x for length 0x000D9865 Executing from 0x Linux version (root@veriton) (gcc version 3.4.1) #12 Tue Apr 12 15:18:36 CEST 2005 Kernel command line: console=ttysc0,57600 PID hash table entries: 1024 (order: 10, bytes) SH RTC: invalid value, resetting to 1 Jan 2000 CPU clock: MHz Bus clock: MHz Module clock: 60.00MHz Interval = Console: colour dummy device 80x25 Dentry cache hash table entries: (order: 5, bytes) Inode-cache hash table entries: (order: 4, bytes) Memory: k/131072k available (698k kernelcode, 2180k reserved, 123k data, 36 k init) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: SH7751R SH Virtual Bus initialized shwdt: initialized. heartbeat=30 sec (nowayout=0) Serial: 8250/16550 driver $Revision: 1.90 $ 6 ports, IRQ sharing disabled bad PC-like io name for port 0x3f9 at 0x880895d4 Fault in unaligned fixup: 0000 [#1] Pid : 1, Comm: swapper PC is at sh7751b1_inb+0x38/0x60 PC : 8800b558 SP : 88249f4c SR : f1 TEA : f9 Not tainted R0 : R1 : R2 : R3 : R4 : 880b165c R5 : R6 : ffffffff R7 : fffffffb R8 : f9 R9 : 880e8018 R10 : e4 R11 : 880b96ec R12 : 880e8018 R13 : R14 : 880e8058 MACH: MACL: GBR : PR : 8800b556 Call trace: [<880895d4>] serial_in+0x78/0x88 [< c>] serial_in+0x0/0x88 [<8808ab1e>] serial8250_config_port+0x96/0x6ac [< c>] serial_in+0x0/0x88 [<8808cb54>] device_add+0xa8/0xe8 [<88088cd8>] uart_configure_port+0x60/0x150 [<880890c6>] uart_add_one_port+0x96/0x134 [<880020fe>] init+0x6e/0x1c4 [< >] kernel_thread_helper+0x4/0x10 Listing 5.16: Trace einer fehlgeschlagenen Schnittstellekonfiguration

55 5. Realisierung des Linux-Systems 44 Mit Hilfe dieser ersten Ausgabe lässt sich nun der Kernel in allen gewünschten Bereichen über ein einfaches printk() debuggen. Wie man schon an diesem Trace erkennt, ist der Kernel nicht vollständig gebootet, sondern hat einen Fehler beim Schreiben einer bestimmten Speicheradresse erhalten. Diese Art von Fehlermeldung ist meist die letzte Aktion des Kernels nach einem Absturz und liefert als Debug noch die genaue Stelle des Fehlers und einen Backtrace zu der aufrufenden Funktion. Hierdurch lassen sich Fehler in der Entwicklung und Anpassung erkennen und auch nach einem Systemabsturz noch nachverfolgen Erste proprietäre Anpassungen Wie im vorhergehenden Kapitel gezeigt wurde, ist die serielle Schnittstelle konfiguriert und erste Ausgaben sind das Ergebnis dieses Schrittes. Ebenfalls wird aber deutlich, dass die einzelnen Schreibzugriffe einen Systemfehler verursachen, wodurch sich keine einwandfreie Funktion herstellen lässt. Um diese IO-Schreib- und Lesezugriffe richtig zu mappen, muss für das Target die entsprechende io.c Datei erstellt werden, in welcher die passenden Zugriffe auf Memory und Ressourcen definiert sind. unsigned char sh7751b1_inb(unsigned long port) { if (PXSEG(port)) return *(volatile unsigned char *)port; else if (CHECK_SH7751_PCIIO(port)) return *(volatile unsigned char *)PCI_IOMAP(port); else if (port <= 0x3F1) return *(volatile unsigned char *)ETHER_IOMAP(port); else return (*port2adr(port))&0xff; } Listing 5.17: Definition eines Lesezugriff Da diese Modifikationen von Target zu Target unterschiedlich sind, wird es ab diesem Schritt nötig, die unterschiedlichen Anpassungen des Linux -Kernels in einem eigenständigen Verzeichniszweig abzubilden. Wie in Kapitel 5.1 erwähnt, wurde für diese Arbeit ein Verzeichnis becker/b1/ erstellt, in welchem nun alle zugehörigen Targettreiber abgelegt werden. Da dieses Verzeichnis und damit alle Treiber nicht im Kernel-Buildsystem eingetragen sind, werden sie auch nicht berücksichtigt. Um das Target als eigenständiges Board beim Kernel einzufügen und somit ein eigenständiges Targetverzeichnis zu haben, müssen verschiedene Schritte unternommen werden. Um in der make config Umgebung als System bekannt zu sein, muss unterhalb des Verzeichnis arch/sh/ die Kconfig Datei angepasst werden und das neue Board hinzugefügt werden. Dies zeigt das Listing 5.18.

56 5. Realisierung des Linux-Systems 45 config SH_BECKER_B1 bool "BeckerOsgi" help Select BeckerB1 if configuring for a Becker OSGI B1 SH7751r board. Listing 5.18: Konfigurationsoption für Becker B1 Durch diesen Eintrag kann man nun den Kernel so konfigurieren, dass das Target Becker- Osgi ausgewählt werden kann, zu sehen in Abbildung 5.4. Als nächstes müssen die Kompilebefehle für das Target erstellt werden. Abbildung 5.4: Linux System Konfiguration Hierfür muss in dem architekturspezifischen Makefile die Angabe über machdir-y erfolgen. Als korrekter Eintrag wird hier das genaue Verzeichnis erwartet, in dem sich die Dateien befinden.