Bachelorarbeit
Total Page：16
File Type：pdf, Size：1020Kb
Fachbereich 3 - Informatik und Mathematik Bachelorarbeit Studiengang Informatik Eine Plattform für Bare-Metal-Programmierung und die Entwicklung eines Hard-Realtime-Operating-Systems Christian Manal [email protected] Matrikelnummer 3005022 Gutachter Prof. Dr. Jan Peleska [email protected] Prof. Dr. Rolf Drechsler [email protected] 7. Januar 2019 Eidesstattliche Erklärung Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig angefertigt, nicht anderweitig zu Prüfungszwecken vorgelegt und keine anderen als die angegebenen Hilfsmittel verwendet habe. Sämtliche wissentlich verwendete Textausschnitte, Zitate oder Inhalte anderer Verfasser wurden ausdrücklich als solche gekennzeichnet. Bremen, 7. Januar 2019 Christian Manal i Zusammenfassung In dieser Arbeit geht es um die Auswahl einer Plattform, die sich für die Bare-Metal- Programmierung im Kontext einer Hochschullehrveranstaltung eignet. Insbesondere soll es möglich sein, zu Lehrzwecken ein minimales Betriebssystem zu entwickeln, das ggf. auch Hard-Realtime-Eigenschaften hat. Zu diesem Zweck wurden verschie- dene Single-Board-Computer (SBC) bzw. System-on-a-Chip (SoC) nach ausgewählten Kriterien bewertet und auf ihre Eignung untersucht. ii Inhaltsverzeichnis 1. Einleitung 1 2. Grundlagen 2 2.1. Bare-Metal-Programmierung ....................... 2 2.2. Hard-Realtime-Operating-System ..................... 4 3. Verwandte Arbeiten 6 3.1. Betriebssysteme in der Hochschullehre .................. 6 3.2. Hard-Realtime-Betriebssysteme in der Lehre ............... 7 4. Auswahlprozess 9 4.1. Kriterien ................................... 9 4.2. Evaluierte Plattformen ........................... 17 4.3. Ergebnis ................................... 33 5. Realtime-Eigenschaften 35 5.1. Versuchsaufbau ............................... 35 5.2. Auswertung der Ergebnisse ........................ 39 5.3. Versuchsfazit ................................ 44 6. Fazit und Ausblick 46 Anhänge 48 A. Abbildungsverzeichnis 49 B. Tabellenverzeichnis 50 C. Glossar 51 D. Abkürzungen und Akronyme 53 E. Literaturverzeichnis 55 iii 1. Einleitung Im Modul Entwicklung von Betriebssystemen (VAK 03-ME-702.02) an der Universität Bremen wurde bisher der Linux-Kernel als Anschauungsobjekt verwendet, um zentra- le Konzepte von Betriebssystemen zu vermitteln. Dabei geht es unter anderem um Inter-Process-Communication (IPC), Nebenläufigkeiten, Scheduling und dergleichen. Da der Linux-Kernel aber an einigen Stellen immer komplexer wird und sich im Laufe eines Jahres der Code stark verändern kann, entstehen Schwierigkeiten für Dozenten, auf dem Laufenden zu bleiben und für die Studierenden, sich durch komplexen Code zu arbeiten, um die relevanten Inhalte herauszufiltern und zu verstehen. Im Rahmen dieser Arbeit wird deshalb eine Hardwareplattform gesucht, die es ermög- licht, einen schlanken Mikrokernel zu entwickeln, der anstelle von Linux benutzt wer- den kann, um die Kernkonzepte von Betriebssystemen zu vermitteln. Weiterhin soll die Plattform geeignet sein, ein Hard-Realtime-Operating-System (HRTOS) zu entwi- ckeln, um ggf. weiterführende Inhalte im Kontext von Betriebssystemen zu vermitteln oder zu erforschen. 1 2. Grundlagen 2.1. Bare-Metal-Programmierung Bei Programmierung im herkömmlichen Sinne wird Software für ein oder mehrere Betriebssysteme entwickelt. Die Betriebssysteme stellen dabei abstrakte Application- Programming-Interfaces (APIs) bereit, die unter anderem von Hardware, der unter- liegenden Architektur usw. abstrahieren, sodass sich ein Entwickler beispielsweise nicht darum kümmern muss, welches Dateisystem für die Datenspeicherung genutzt wird oder mit welcher Schnittstelle das unterliegende Speichermedium angeschlos- sen ist. Desweiteren kümmern sich Betriebssysteme um die Verwaltung von Ressour- cen, wie beispielsweise Hauptspeicher und Rechenzeit einzelner Prozesse, sowie di- verse Schutzmechanismen, die verhindern sollen, dass einzelne Prozesse sich gegen- seitig behindern oder unbefugt auf Ressourcen anderer Prozesse zugreifen. Ein solcher Schutzmechanismus ist z.B. das Bereitstellen eines virtuellen Adressraumes. Gleichzei- tig werden aber auch Mechanismen bereitgestellt, die es Prozessen erlauben, gezielt und kontrolliert miteinander zu kommunizieren (auch IPC genannt). Im Gegensatz dazu entwickelt man bei Bare-Metal-Programmierung ohne ein Be- triebssystem, direkt auf der Hardware, sodass ein Entwickler sich um all diese Dinge selbst kümmern muss. In der Regel kommt diese Art der Programmierung bei Micro- Controller-Units (MCUs) zum Einsatz, da diese meist für gezielte, eingebettete Ein- satzzwecke verwendet werden, die mit möglichst wenigen Ressourcen erfüllt werden sollen um beispielsweise Kosten und Energie zu sparen. Da man bei Bare-Metal-Programmierung direkt auf der Hardware arbeitet, ist es au- ßerdem sehr wichtig, dass entweder eine fertige Hardware-Abstraction-Layer (HAL) für die Plattform zur Verfügung steht oder zumindest eine ausreichende Dokumen- tation um die benötigte Hardware manuell ansteuern zu können. Letzteres passiert i.d.R. durch das Lesen und Schreiben von in den Adressraum abgebildeten Registern [51, Kap. 5.1.3]. Anzahl, Adresse, Funktion usw. solcher Register, für alle auf einem SBC oder SoC verbauten Komponenten ohne Dokumentation in Erfahrung zu bringen ist fast unmöglich bzw. mit erheblichem Aufwand verbunden. Eine weitere Eigenschaft von Bare-Metal-Programmierung ist, dass, insbesondere wenn MCUs mit sehr geringen Ressourcen zum Einsatz kommen, häufig in Assembler programmiert wird. Wenn es Compiler mit entsprechenden Backends gibt, kann 2 KAPITEL 2. GRUNDLAGEN 2.1. BARE-METAL-PROGRAMMIERUNG man jedoch auch Hochsprachen, wie z.B. C, benutzen. Bei der Verwendung von Hochsprachen muss jedoch weiterhin darauf geachtet werden, dass es ohne Betriebs- system auch keine Systemaufrufe gibt und somit die meisten (Standard-)Bibliotheken nicht ohne weiteres funktionieren. Weiterhin kann man für einige Funktionen nicht vermeiden, Assembler zu benutzen, wenn es für diese keine allgemeine Umsetzung in der genutzten Hochsprache gibt. Ein Beispiel dafür ist das Wechseln des Prozess- kontextes auf der CPU, da dieser Vorgang stark von der CPU bzw. dessen Architektur abhängt. Unabhängig davon, ob man in Assembler, C oder einer anderen Sprache program- miert, muss man sich bei der Bare-Metal-Programmierung auch Gedanken um die Bootphase des Systems machen. Joachim Wietzke betrachtet diesen Vorgang im Kontext eingebetteter Systeme in [56, Kap. 6.1]. Bevor ein Programm gestartet werden kann, muss gemäß Wietzke die Hardware initialisiert werden. Das umfasst nicht nur Peripheriegeräte, sondern ggf. auch einen Speicher-Controller, ohne den der Hauptspeicher nicht verfügbar ist. Stack- und Program-Counter müssen gesetzt und Interrupt-Service-Routines (ISRs) definiert werden. Bei Hochsprachen, und insbesondere beim Cross-Kompilieren, muss der Compiler bzw. Linker außerdem wissen, wie der verfügbare Adressraum genutzt werden soll. Hierbei spricht man auch von Startup-Code oder auch einem Bootloader. Eine weitere Schwierigkeit bei der Bare-Metal-Programmierung ist das Debuggen von Programmen. Häufig entwickelt man sein Bare-Metal-Programm für eine andere Platt- form, als auf der man das Programm schreibt, sodass man seinen Code nicht einfach lokal ausführen und debuggen kann (z.B. mit GNU-Debugger (GDB)). Hinzu kommt, dass man, wie bereits mehrfach erwähnt, sowieso stark von der Hardware abhängig ist, für die man gerade entwickelt. Idealerweise möchte man also gerne direkt auf der Zielhardware debuggen, sodass man keine extra Software zwischenschalten muss. Zu diesem Zwecke gibt es sogenannte On-Chip-Debugger (OCD), mit dessen Hilfe man einen Debugger direkt mit der Zielhardware verbinden, und so z.B. Haltemarken setzen und Register- und Speicherinhalte inspizieren kann. Eine gängige Schnittstelle hierfür ist beispielsweise Joint Test Action Group (JTAG). Sofern man aber keine Hardware kauft, die einen integrierten Debugger hat, können hier zusätzliche Kosten für die Anschaffung eines kompatiblen externen Debug-Gerätes entstehen. Zusammenfassend ist Bare-Metal-Programmierung somit deutlich komplexer als her- kömmliche Programmierung und setzt sehr genaues Wissen über die unterliegende Hardware voraus. 3 KAPITEL 2. GRUNDLAGEN 2.2. HARD-REALTIME-OPERATING-SYSTEM 2.2. Hard-Realtime-Operating-System Shin und Ramanathan [46] bezeichnen Realtime-Systeme als Systeme, die bestimmte Aufgaben zuverlässig innerhalb bestimmter Deadlines erfüllen. Dabei unterscheiden sie zwischen drei Arten von Deadline: hard, firm und soft. Eine Hard-Deadline defi- nieren sie so, dass ein Verpassen dieser katastrophale Folgen hätte, z.B. weil dies zu einem Fehler im unterliegenden System führen würde, durch den im schlimmsten Fall sogar Personen- oder Sachschäden entstehen könnten. Von einer Firm-Deadline reden sie, wenn das zu der Deadline erwartete Ergebnis nach Verpassen dieser nutzlos wird, aber nicht zu einem Fehlerfall führt und schließlich von einer Soft-Deadline, wenn nach dessen Verstreichen die Nützlichkeit des Ergebnisses mit der Zeit abnimmt. Ein Realtime-Operating-System (RTOS) ist im Allgemeinen somit ein Betriebssystem, das als Softwaregrundlage für Realtime-Systeme dienen kann, da es bestimmte Realtime-Eigenschaften erfüllen kann und ein HRTOS eine Steigerung, die insbeson- dere Hard-Deadlines einhalten kann. Dabei müssen sowohl wiederkehrende Aufgaben beachtet werden, die regelmäßig zur selben Zeit erfüllt werden müssen, als auch irreguläre Aufgaben, die nur unter bestimmten Bedingungen