Embedded Linux lernen mit dem Raspberry Pi (eBook)

Linux-Systeme selber bauen und programmieren
eBook Download: PDF | EPUB
2014 | 1. Auflage
306 Seiten
dpunkt (Verlag)
978-3-86491-509-3 (ISBN)

Lese- und Medienproben

Embedded Linux lernen mit dem Raspberry Pi -  Jürgen Quade
Systemvoraussetzungen
Systemvoraussetzungen
29,90 inkl. MwSt
  • Download sofort lieferbar
  • Zahlungsarten anzeigen
Im Bereich eingebetteter Systeme ist Linux weit verbreitet. Und in Kombination mit der Embedded-Plattform Raspberry Pi bildet es ein optimales Gespann, um sich praxisorientiert Kenntnisse und Techniken anzueignen, die für die Entwicklung eingebetteter Systeme notwendig sind. Dieses einführende Lehr- und Arbeitsbuch beschreibt daher Aufbau, Konzeption und Realisierung eingebetteter Linux-Systeme am Beispiel des Raspberry Pi. Zahlreiche Beispiele sowie Tipps und Tricks machen das Thema anschaulich und erleichtern die Umsetzung in die Praxis. Nach der erfolgreichen Lektüre können Sie - einfache eingebettete System planen und realisieren - eine Cross-Entwicklungsumgebung im Rahmen einer Host-Target-Entwicklung aufsetzen - Systemsoftware konfektionieren und zu einem Embedded-Linux-Gesamtsystem zusammenbauen - die Einschränkungen bei der Applikationserstellung im Umfeld eingebetteter System einschätzen und Anwendungssoftware erstellen - den grundlegenden Aufbau von Treibersoftware nachvollziehen und einfache Treiber programmieren - die Anforderungen an Security verstehen und durch geeignete Techniken gewährleisten. Vom Systemanwender zum Systementwickler: Während die meisten Bücher rund um den Raspberry Pi zeigen, wie Sie vorhandene Systemsoftware einsetzen und für Ihre Anwendung nutzen, entwickeln Sie mit diesem Mitmach-Buch ein optimal auf Ihre eigenen Bedürfnisse angepasstes Embedded Linux!

Jürgen Quade studierte Elektrotechnik an der TU München. Danach arbeitete er dort als Assistent am Lehrstuhl für Prozessrechner (heute Lehrstuhl für Realzeit-Computersysteme), promovierte und wechselte später in die Industrie, wo er im Bereich Prozessautomatisierung bei der Softing AG tätig war. Heute ist Jürgen Quade Professor an der Hochschule Niederrhein, wo er u.a. das Labor für Echtzeitsysteme betreut. Seine Schwerpunkte sind Echtzeitsysteme, Embedded Linux, Rechner- und Netzwerksicherheit sowie Open Source. Als Autor ist er vielen Lesern über das dpunkt-Buch 'Linux-Treiber entwickeln' und die regelmäßig erscheinenden Artikel der Serie 'Kern-Technik' im Linux-Magazin bekannt.

Jürgen Quade studierte Elektrotechnik an der TU München. Danach arbeitete er dort als Assistent am Lehrstuhl für Prozessrechner (heute Lehrstuhl für Realzeit-Computersysteme), promovierte und wechselte später in die Industrie, wo er im Bereich Prozessautomatisierung bei der Softing AG tätig war. Heute ist Jürgen Quade Professor an der Hochschule Niederrhein, wo er u.a. das Labor für Echtzeitsysteme betreut. Seine Schwerpunkte sind Echtzeitsysteme, Embedded Linux, Rechner- und Netzwerksicherheit sowie Open Source. Als Autor ist er vielen Lesern über das dpunkt-Buch "Linux-Treiber entwickeln" und die regelmäßig erscheinenden Artikel der Serie "Kern-Technik" im Linux-Magazin bekannt.

Vorwort 5
Inhaltsverzeichnis 7
1 Einleitung 11
2 Gut zu wissen 19
2.1 Die Architektur eingebetteter Systeme 21
2.1.1 Hardware 21
2.1.2 Software 24
2.1.3 Auf dem Host für das Target entwickeln 29
2.2 Arbeiten mit Linux 31
2.2.1 Die Shell 33
2.2.2 Die Verzeichnisstruktur 34
2.2.3 Editor 35
2.3 Erste Schritte mit dem Raspberry Pi 36
2.3.1 System aufspielen 37
2.3.2 Startvorgang 39
2.3.3 Einloggen und Grundkonfiguration 40
2.3.4 Hello World: Entwickeln auf dem Raspberry Pi 40
3 Embedded von Grund auf 43
3.1 Der Linux-Kernel 44
3.2 Das Userland 51
3.2.1 Systemebene 53
3.2.2 Funktionsbestimmende Applikationen 69
3.3 Cross-Development für den Raspberry Pi 74
3.3.1 Cross-Generierung Kernel 74
3.3.2 Cross-Generierung Userland 77
3.3.3 Installation auf dem Raspberry Pi 81
3.4 Bootloader »Das U-Boot« 86
3.4.1 Kernel von der SD-Karte booten 90
3.4.2 Netzwerk-Boot 94
3.5 Initramfs: Filesystem im RAM 96
4 Systembuilder Buildroot 105
4.1 Überblick 105
4.2 Buildroot-Praxis 109
4.2.1 Installation auf der SD-Karte 111
4.2.2 Netzwerk-Boot per U-Boot 114
4.3 Systemanpassung 120
4.3.1 Postimage-Skript 121
4.3.2 Postbuild-Skript 123
4.4 Eigene Buildroot-Pakete 141
4.4.1 Grundstruktur 141
4.4.2 Praxis 147
4.5 Hinweise zum Backup 151
5 Anwendungsentwicklung 153
5.1 Cross-Development 154
5.2 Basisfunktionen der eingebetteten Anwendungsprogrammierung 157
5.2.1 Modularisierung 158
5.2.2 Realzeitaspekte 160
5.3 Hardwarezugriffe 165
5.3.1 Systemcalls für den Hardwarezugriff 166
5.3.2 GPIO-Zugriff über das Sys-Filesystem 172
6 Gerätetreiber selbst gemacht 177
6.1 Einführung in die Treiberprogrammierung 178
6.1.1 Grundprinzip 179
6.1.2 Aufbau eines Gerätetreibers 180
6.1.3 Generierung des Gerätetreibers 183
6.2 Schneller GPIO-Treiberzugriff 186
6.2.1 Digitale Ausgabe 187
6.2.2 Digitale Eingabe 195
6.2.3 Programmierhinweise zum Hardwarezugriff 202
7 Embedded Security 207
7.1 Härtung des Systems 209
7.1.1 Firewalling 210
7.1.2 Intrusion Detection and Prevention 222
7.1.3 Rechtevergabe 223
7.1.4 Ressourcenverwaltung 229
7.1.5 Entropie-Management 234
7.1.6 ASLR und Data Execution Prevention 235
7.2 Entwicklungsprozess 236
7.3 Secure-Application-Design 239
7.3.1 Sicherheitsmechanismen in der Applikation 240
7.3.2 Least Privilege 241
7.3.3 Easter Eggs 243
7.3.4 Passwortmanagement 243
7.3.5 Verschlüsselung 245
7.3.6 Randomisiertes Laufzeitverhalten 246
8 Ein komplettes Embedded-Linux-Projekt 247
8.1 Hardware: Anschluss des Displays 248
8.2 Software 250
8.3 Systemintegration 259
Anhänge 267
A Crashkurs Linux-Shell 269
A.1 Elementare Kommandos zur Dateiverwaltung 271
A.2 Systemkommandos 274
A.3 Grundlegende Befehle zum Netzwerkmanagement 277
B Crashkurs vi 279
C Git im Einsatz 283
C.1 Unterschiedliche Git-Bereiche 283
C.2 Dateizustände 284
C.3 Änderungen anzeigen 285
C.4 Branching und Merging 285
C.5 Remote-Repository 286
D Die serielle Schnittstelle 289
Literaturverzeichnis 293
Stichwortverzeichnis 297
www.dpunkt.de 1

2 Gut zu wissen


Eine integrierte, mikroelektronische Steuerung wird als eingebettetes System (embedded system) bezeichnet. Es erfüllt meist eine spezifische Aufgabe und hat sehr häufig — man denke beispielsweise an das Antiblockiersystem im Auto — kein ausgeprägtes Benutzerinterface.

Abb. 2-1 Klassifizierung eingebetteter Systeme

Beispiele für eingebettete Systeme gibt es zuhauf: WLAN-Router, Navi-Systeme, elektronische Steuergeräte im Auto, die Steuerung einer Waschmaschine, Handy und so weiter. Man kann eingebettete Systeme unterklassifizieren in offene (open) und in Deeply Embedded Systems. Deeply Embedded Systems sind typischerweise für genau eine einzelne Aufgabe konstruiert und benötigen dafür einfache Hardware, meist basierend auf einem 8- oder 16-Bit-Mikrocontroller. Sie kommen oftmals ohne spezifische Systemsoftware aus. Offene eingebettete Systeme sind für komplexe Aufgaben gedacht, setzen immer häufiger auf 32-Bit-Prozessoren und auf standardisierte Systemsoftware. Die Grenze zwischen den beiden Kategorien ist fließend.

Eingebettete Systeme lassen sich durch eine Reihe unterschiedlicher Anforderungen und Eigenschaften von Standardsystemen abgrenzen. Tabelle 2-1 zeigt, dass eingebettete Systeme neben den üblichen Anforderungen an Kosten und Funktionalität zusätzliche Kriterien erfüllen müssen. So wird in vielen Einsatzbereichen ein Instant on benötigt; das Gerät muss also unmittelbar nach dem Einschalten betriebsbereit sein. Dazu muss das eingesetzte Betriebssystem kurze Boot-Zeiten garantieren, sodass beispielsweise bei einem Pkw direkt nach dem Einsteigen das (elektronische) Cockpit zur Verfügung steht.

Umgekehrt muss das Betriebssystem aber auch damit zurechtkommen, dass es ohne Vorwarnung stromlos geschaltet wird. Das ist der Fall, wenn der Strom ausfällt, beispielsweise weil der Anwender den Stromstecker zieht.

Wer an Smartphones oder Uhren denkt, dem wird sehr schnell klar, dass auch die räumlichen Ausmaße (Größe) und das Gewicht ein Kriterium sind. Oftmals ist der Einbauplatz begrenzt. Denkt man an elektronische Steuergeräte im Automobil (ECU, Electronic Control Unit), wird klar, dass diese eingebetteten Systeme meist kein Benutzerinterface, keinen Bildschirm und erst recht keine Tastatur haben. Man spricht hier auch vom Headless-Betrieb. Dieser geht häufig einher mit dem Non-stop-Betrieb, bei dem Geräte 24 Stunden am Tag und 365 Tage im Jahr betrieben werden; nicht selten sogar über 20 oder gar 30 Jahre. Außerdem wird Robustheit gefordert, werden die Geräte doch oft im rauen Umfeld eingesetzt.

Aus diesen Anforderungen ergibt sich, dass für ein eingebettetes System typischerweise weniger Ressourcen zur Verfügung stehen. Daher wird oft eine auf die Gerätefunktion angepasste Hardwareplattform entwickelt und die Systemsoftware wiederum auf die Hardware und die gewünschte Funktionalität angepasst. Die Systeme werden diskless aufgebaut, bewegte Teile, wie beispielsweise Festplattenlaufwerke, versucht der Entwickler zu vermeiden.

Tabelle 2-1 Anforderungen an eingebettete Systeme

Anforderung

Funktionalität

Preis

Robustheit, funktionstüchtig im rauen Umfeld

Instant on, kurze Boot-Zeiten

Fast poweroff, ohne Vorwarnung stromlos

Räumliche Ausmaße

Kein oder eingeschränktes GUI

Headless-Betrieb: keine Tastatur, kein Bildschirm

Nonstop-Betrieb (Dauerbetrieb)

Lange Lebensdauer (hohe Standzeit)

2.1 Die Architektur eingebetteter Systeme


Ein eingebettetes System besteht aus Hardware (CPU, Speicher, Sensorik, Aktorik) und Software (Firmware, Betriebssystem, Anwendung).

2.1.1 Hardware

Die Hardware eines eingebetteten Systems entscheidet über Leistung, Stromverbrauch, Größe und Robustheit. Ein Embedded System wird unter anderem dadurch robust, dass es ohne bewegte Teile, also ohne Lüfter oder Festplatte, auskommt, möglichst wenig Steckverbindungen aufweist, für eine optimale Temperatur ausgelegt (eventuell klimatisiert) und gekapselt ist, sodass mechanische Beanspruchungen abgewehrt werden.

Abb. 2-2 Der Raspberry Pi

Im Kern besteht die Embedded-Hardware aus einem Prozessor (CPU), dem Hauptspeicher (RAM), dem Hintergrundspeicher (Festplatte, Flash, SD-Karte) und diversen Schnittstellen (Abb. 2-2). Hierzu gehört klassischerweise die serielle Schnittstelle, zunehmend auch USB. Darüber hinaus findet sich häufig eine Netzwerkschnittstelle (Ethernet), WLAN, Grafikausgabe (VGA oder HDMI) und eventuell auch Audio. Zur Ankopplung weiterer Peripherie werden einige Leitungen, Pins beziehungsweise Steckverbinder eingesetzt, die digitale Signale übertragen (General Purpose Input Output, GPIO). Da diese Leitungen typischerweise eine nur begrenzte Leistung haben, werden sie über Treiber mit beispielsweise LEDs oder Relais (Ein-/Aus-/Umschalter) verbunden. Häufig ist noch eine galvanische Entkopplung (über Optokoppler) notwendig, damit die Embedded-Hardware vor Störungen aus Motoren oder Ähnlichem geschützt sind.

Die Prozessoren in eingebetteten Systemen sind häufig als System on Chip (SoC; monolithische Integration) ausgeprägt. Bei diesen befindet sich nicht nur die eigentliche CPU auf dem Chip, sondern zusätzlich noch die sogenannte Glue-Logic (Interrupt-Controller, Zeitgeber, Watchdog), Grafikcontroller, Audio, digitale Ein-/Ausgabeleitungen (GPIO), Krypto-Module und so weiter. Bei einer CPU plus Peripherie spricht man auch von einem Mikrocontroller.

Als CPU wird zunehmend ein ARM-Core eingesetzt. Alternativ sind noch PowerPC, Mips und x86-Architekturen im Einsatz. Für Deeply Embedded Systems werden gerne ATMEGA- und PIC-Prozessoren ausgewählt, wie sie beispielsweise auf einem Arduino-Board anzutreffen sind. Häufig bieten die eingesetzten Prozessoren keine Gleitkommaeinheit (Floating Point Unit). Zusätzlich werden sie durch digitale Signalprozessoren unterstützt, die beispielsweise Sprachverarbeitung oder Krypto-Funktionen übernehmen.

Hintergrund: ARM

Die zurzeit wohl wichtigste Prozessorarchitektur am Markt ist Advanced Risc Machine, ARM. Pro Jahr werden etwa 6 Milliarden Prozessoren dieses Typs hergestellt. Damit liegt ihr Marktanteil bei fast 50%. Rund 62% der Cores gehen in den Mobilfunkbereich, wobei ein modernes Smartphone mehrere ARM-Prozessoren beherbergt. ARM-Prozessoren finden sich in beinahe sämtlichen Smartphones oder in Navigationsgeräten.

ARM-Prozessoren haben sich in vielen Bereichen durchgesetzt, da sie hohe Leistung bei gleichzeitig niedrigem Energieverbrauch bieten. Da der Prozessor aus vergleichsweise wenig Transistoren aufgebaut ist, wird auch wenig Chipfläche (Silizium) benötigt. Das wirkt sich positiv auf den Herstellungsprozess und auf den Preis aus.

Die Entwicklung begann 1983, der erste Prozessor, ARM2, wurde 1987 fertiggestellt. Das Design, der Schaltplan also, man spricht auch vom Core, wird von der Firma ARM Ltd. (Advanced Risc Machine Ldt.) hergestellt. Lizenznehmer übernehmen dann den Core in eigene Designs. Dabei gibt es Objekt-Lizenzen und Source-Lizenzen. Die Lizenzkosten liegen derzeit bei etwa 10 Cent pro Core.

ARM-Prozessoren tauchen im Markt unter verschiedenen Namen auf. Die Prozessoren der Firma Qualcomm beispielsweise firmieren unter dem Namen Snapdragon, Nvidia vertreibt seine Prozessoren unter dem Namen Tegra. Mit der Zeit haben sich unterschiedliche Architekturen entwickelt, die von ARMv1 bis aktuell (Stand 2013) ARMv8 reichen. ARMv8 ist die 64-Bit-Variante. Jeweils mehrere Prozessorfamilien implementieren die jeweilige Architektur.

Die aktuelle 32-Bit-Architektur ARMv7 wird beispielsweise durch die Designs Cortex A9 oder auch Cortex A15 realisiert. Die Bezeichnung »A« (Cortex A15) steht für Application. Daneben gibt es auch spezielle Designs für Realtime (»R«) und Mikrocontroller (»M«). ARM bietet zwar direkt keine Floating-Point-Kommandos an, hat aber die Möglichkeit, den Befehlssatz über bis zu 16 Coprozessoren hard- oder auch softwaretechnisch zu erweitern.

ARM-Prozessoren sind ursprünglich 32-Bit-Prozessoren, es gibt aber bereits erste 64-Bit-Versionen, wie beispielsweise im iPhone 5s. Auch die 64-Bit-Version hat 32-Bit breite Befehle, die weitgehend mit dem Befehlssatz A32 identisch sind. Die Befehle bekommen 32 oder 64 Bit breite Argumente übergeben. Adressen sind grundsätzlich 64 Bit breit. Der Adressraum ist erweitert.

Die ARM-Architektur beruht auf einer 3-Register-Maschine. Bei dieser wird das Ergebnis einer Operation, beispielsweise der Addition zweier Register (Variablen), einem dritten Register zugewiesen: add r1, r2, r3; r1=r2+r3. In der typischen 32-Bit-Variante gibt es 16 Register. 15 davon sind sogenannte General Purpose Register, das 16. Register ist der Program Counter. Die neue 64-Bit-Variante verfügt über 32...

Erscheint lt. Verlag 8.5.2014
Verlagsort Heidelberg
Sprache deutsch
Themenwelt Mathematik / Informatik Informatik Betriebssysteme / Server
Schlagworte Embedded Systems • Linux • Realzeitsysteme • Treiberprogrammierung
ISBN-10 3-86491-509-0 / 3864915090
ISBN-13 978-3-86491-509-3 / 9783864915093
Haben Sie eine Frage zum Produkt?
Wie bewerten Sie den Artikel?
Bitte geben Sie Ihre Bewertung ein:
Bitte geben Sie Daten ein:
PDFPDF (Wasserzeichen)
Größe: 7,0 MB

DRM: Digitales Wasserzeichen
Dieses eBook enthält ein digitales Wasser­zeichen und ist damit für Sie persona­lisiert. Bei einer missbräuch­lichen Weiter­gabe des eBooks an Dritte ist eine Rück­ver­folgung an die Quelle möglich.

Dateiformat: PDF (Portable Document Format)
Mit einem festen Seiten­layout eignet sich die PDF besonders für Fach­bücher mit Spalten, Tabellen und Abbild­ungen. Eine PDF kann auf fast allen Geräten ange­zeigt werden, ist aber für kleine Displays (Smart­phone, eReader) nur einge­schränkt geeignet.

Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen dafür einen PDF-Viewer - z.B. den Adobe Reader oder Adobe Digital Editions.
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen dafür einen PDF-Viewer - z.B. die kostenlose Adobe Digital Editions-App.

Zusätzliches Feature: Online Lesen
Dieses eBook können Sie zusätzlich zum Download auch online im Webbrowser lesen.

Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.

EPUBEPUB (Wasserzeichen)
Größe: 8,2 MB

DRM: Digitales Wasserzeichen
Dieses eBook enthält ein digitales Wasser­zeichen und ist damit für Sie persona­lisiert. Bei einer missbräuch­lichen Weiter­gabe des eBooks an Dritte ist eine Rück­ver­folgung an die Quelle möglich.

Dateiformat: EPUB (Electronic Publication)
EPUB ist ein offener Standard für eBooks und eignet sich besonders zur Darstellung von Belle­tristik und Sach­büchern. Der Fließ­text wird dynamisch an die Display- und Schrift­größe ange­passt. Auch für mobile Lese­geräte ist EPUB daher gut geeignet.

Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen dafür die kostenlose Software Adobe Digital Editions.
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen dafür eine kostenlose App.
Geräteliste und zusätzliche Hinweise

Zusätzliches Feature: Online Lesen
Dieses eBook können Sie zusätzlich zum Download auch online im Webbrowser lesen.

Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.

Mehr entdecken
aus dem Bereich
Das Praxisbuch für Administratoren und DevOps-Teams

von Axel Miesen

eBook Download (2022)
Rheinwerk Computing (Verlag)
39,90