Embedded Systems:Teil Linux (KT1)
Folien: ebssd_Präs_2_Betriebssystemvarianten_Lizenzen_Echtzeit Versuch1: Installation des Hostsystems Versuch2: Linux from Scratch – Teil 1 Versuch3: Linux from Scratch – Teil2 _Linux_Realtime- Fähigkeiten(Stefan Agner, 2009).pdf" Kapitel 3 und 4.
Folien: ebssd_Präs_2_Betriebssystemvarianten_Lizenzen_Echtzeit Versuch1: Installation des Hostsystems Versuch2: Linux from Scratch – Teil 1 Versuch3: Linux from Scratch – Teil2 _Linux_Realtime- Fähigkeiten(Stefan Agner, 2009).pdf" Kapitel 3 und 4.
-
- 1 / 82
-
Flashcards
Welche Konfig wird verwendet bzw. existieren? (+Befehl)
Für das Wandboard eignet sich sowohl multi_v7_defconfig, eine etwas aufgeblasene universelle Konfig für diverse Boards mit ARMv7 CPU-Architektur, als auch imx_v6_v7_defconfig für einige Boards mit Freescale IMX 6 und 7 SoC. Wir verwenden als Basis letztere, da diese schlanker ist:
$ make ARCH=arm imx_v6_v7_defconfig
Was heisst -rc?
wie kann man versteckte Dateien anschauen?
Wie kann man Default-Konfiguration betrachten?Was macht man wenn das nicht klappt?
allerneuesten Release Candidates
'ls -a'
make ARCH=arm menuconfig
Falls kein „Menu“ angezeigt wird, fehlt vermutlich noch die „ncurses“ Bibliothek, welche sich über das
Ubuntu-Package libncurses5-dev installieren lässt.
Wann kommt der Fehler BAD MAGIC NUMBER?
Ist der hier ausgewählte Kompressionsalgorithmus in der u-boot Konfig nicht enthalten, kann u-boot den Kernel nicht erkennen, was er dann mit 'BAD MAGIC NUMBER' quittiert.
Was ist unter „Device Tree Source“ -Dateien zu findne?
In so genannten „Device Tree Source“ -Dateien (unter arch/arm/boot/dts/...) erfolgt die so genannte „Board-Konfiguration“, also die Zuordnung von Hardware-Adressen, Buszuordnungen etc. etc. aller zu aktivierenden Peripherieblöcke (also was auf dem Board und dem SoC wohin „verdrahtet“ ist).
In so genannten „Device Tree Source“ -Dateien (unter arch/arm/boot/dts/...) erfolgt die so genannte „Board-Konfiguration“, also die Zuordnung von Hardware-Adressen, Buszuordnungen etc. etc. aller zu aktivierenden Peripherieblöcke (also was auf dem Board und dem SoC wohin „verdrahtet“ ist).
Der aktivierte Kernelrelease beinhaltet Device Tree Source- und Include-Dateien (*.dts, *.dtsi) für diverse Wandboard Releases. Falls die Device Tree Dateien nicht haargenau zum Board passt – was insbesondere bei ultraneuen Board-Releases problematisch sein kann – müssten diese manuell angepasst (resp. „gepatched“) werden. Unser v4.10.0 Kernel unterstützt aber zum Glück unser Wandboard-Dual Rev C1 Boards.
Per 'make ... dtbs' werden die Device Tree Sources in Device Tree Binary Dateien (dtb) übersetzt...
Was ist unter Kernel Hacking --> ?
Wie kann man die aktualisierte Kernel-Konfig-Datei anschauen?
Hier könnten verschiedene Kernel-Debug-Features ein-/ausschaltet werden. Eingeschaltete Debug-Tests verlängern ev. die Latenzzeiten des Kernels, was insbesondere für Realtime-Anwendungen berücksichtigt werden sollte...
less .config #in der .config sind immer noch einige unnötige ladbare Module ausgewählt; dies stört aber nicht weiter, ausser dass später die Kompilation etwas länger dauert.
Wie kann der Kernelrelease String anzeigen werden?
Kopieren des Kernels und des Devicetrees auf die SD-Karte?
- entweder: $ cat include/generated/utsrelease.h --> Anzeige von: #define UTS_RELEASE " 4.10.0-wb" oder: $ make ARCH=arm kernelrelease --> Anzeige von: 4.10.0-wb
Name vmlinuz-<kernelrelease> : $ sudo cp arch/arm/boot/zImage /media/$USER/rootfs/boot/vmlinuz- 4.10.0-wb
kopieren des „Binary Device Tree“ ?
- unter das Verzeichnis boot/dtbs/<kernelrelease>/ :
sudo mkdir -p /media/$USER/rootfs/boot/dtbs/4.10.0-wb
Busybox wird wie verwendet?
und was ist es?
- „Busybox“ wird gelegentlich bei super-schlanken Embedded Systemen direkt als „Root-Filesystem“ verwendet, andererseits bei den meisten Linux-Distributionen im „Initial RAM-Disk Image“ als temporäres Rootfilesystem, zwecks Laden der benötigten Disk-Treiber und -Filesysteme für das definitive Rootfilesystem.
- Busybox selbst ist eine Toolsammlung von gängigen UNIX resp. POSIX Commandlinetools (ls, mount, vi, sh, ...), wobei als Spezialität alle Commands in nur einem einzigen Binary namens 'busybox' enthalten sind.
Die aufrufbaren Commands sind deshalb bloss symbolische Links auf dieses eine 'busybox' Binary. Ähnlich wie der Linux-Kernel lässt sich auch busybox ab Quellcode generieren und über ein
'make menuconfig' „customizen“.
Für unser Versuchszenario verwenden wir jedoch nicht direkt „busybox“ sondern im nächsten Versuch „buildroot“, welches selbst ebenfalls „busybox“ verwendet...
Was wird in Rootfilesystem gespeichert?
Was ist das schlankeste RFS?
Was sind Alternativen?
Auf unserem Zielsystem benötigen wir nebst Bootloader und Kernel ein Rootfilesystem (RFS), in welchem alle auszuführenden Programme sowie die Systemkonfiguration gespeichert ist. Bei einem normalen Linux-System füllen tausende von Programmen und Hilfsprogramme schnell mal einige GB im Rootfilesystem. Für ein schlankes Embedded System ist dies zuviel des Guten, zumal ein Embedded System ja mit nur einem klar begrenzten Umfang über viele Jahre problemlos und sicher laufen soll...
Busybox wird nicht nur bei schlanken Embedded-Systemen sondern auch bei den meisten Linux- Distributionen für die so genannte „Initial Ramdisk“ verwendet, zwecks laden von Disk- und Filesystem-Treibern für das Mounten des Rootfielsystems. Busybox selbst ist dabei eine kompakte Tool-Sammlung, welche in ein einziges Programm namens „busybox“ gepackt ist und die Grundfunktionalität vieler nützlicher Linux/UNIX/POSIX-Commands beinhaltet. Busybox ist dabei wie der Kernel GPL lizenziert1. Nur für minimale Linux-Systeme ist Busybox jedoch eine gute Wahl, denn sobald viele zusätzliche Programme oder Funktionalitäten wie WLAN benötigt werden, ist dieser Weg steinig, da alle zusätzlich benötigten Programme und Zusatz-Libraries eigenhändig crosscompiliert werden müssten.
Einen wesentlichen Schritt weiter geht das Build-System Buildroot. Prinzipiell ähnlich aber nochmals deutlich aufwändiger verfahren Build-Systeme wie Android, Yocto und OpenEmbedded.
Die Wahl der Basis für das Root File System...
Was ist der Unterschied zwischen Android, Yokto, Poky und Angstrom?
Die Wahl der Basis für das Root Filesystem ist also ein Kompromiss zwischen Komfort, Funktionalität, Aufwand und (langfristiger) Wartbarkeit.
Prinzipiell ähnlich aber nochmals deutlich aufwändiger verfahren Build-Systeme wie Android, Yocto und OpenEmbedded. Typischerweise hosten diese den Sourcecode vieler anderer Opensource Projekte selbst. Mittels Yocto lassen sich dabei auch „eigene“ modulare Embedded Linux Distributionen generieren. Poky und Angstrom sind solche. Yocto basiert übrigens auf das ältere OpenEmbedded Project.
Was ist in gitignore enthalten?
Weiter wird in der versteckten Datei .gitignore festgelegt, welche Dateien und Ordner im Git-Tree nicht erfasst werden: insbesondere die Quellpakete anderer Sourcen sowie der Build Output..die Pfadangaben beziehen sich relativ zum lokalen Buildroot Repository
Was wird unter $ make menuconfig angezeigt?
Target options --->
> Target Architecture ---> ARM (little endian)
> Target Architecure Variant ---> cortex-A9
> [*] Enable NEON SIMD extension
> [*] Enable VFP extension support
> Target ABI ---> (X) EABIhf (also Hardware-Floating Point – analog unserer Toolchain) > support Floating point strategy ---> VFPv3
> ARM instruction set ---> Thumb2
Was ist der Unterschied zwischen einer externen Toolchain?
Eine „externe“ Toolchain zu verwenden geht schneller als diese von Buildroot ab Source compilieren zu lassen. Wir verwenden im folgenden die beim letzten Versuch auf /opt installierte Toolchain, da mit dieser auch der Kernel compiliert wurde. Alternativ und wenn jene Toolchain beim Compilieren von Buildroot zu Problem führen würde, könnte man unten stehend auch eine vorkompilierte Toolchain von Buildroot herunterladen....
Toolchain --->
> Toolchain type --> External toolchain (wir verwenden die bereits auf /opt installierte Toolchain...)
> Toolchain --> Custom toolchain
> Toolchain origin → (X) Pre-installed toolchain
Toolchain path → /opt/gcc-linaro-5.3.1-2016.05-x86_64_arm-linux-gnueabihf
Toolchain prefix --> arm-linux-gnueabihf
> External toolchain gcc version ---> 5.x
> External toolchain kernel headers series ---> 4.0.x > [*] Purge unwanted locales
> External toolchain C library ---> glibc/eglibc
> [*] Toolchain has C++ support?
> [*] Copy gdb server to the Target
Was ist ALSA?
ALSA ist der Audio Stack welchen wir verwenden werden
Wie generieret man buildroot?
Wieso stimmen die Datenrechte nicht?
- $make (verwenden Sie keine Option -j, buildroot macht dies selbst...)
- bei ersterem (unter output/target/) stimmen die Dateirechte nicht und es fehlen die vordefinierten Device Nodes – make lief ja unter Ihrer User-ID und absichtlich nicht unter root UID!
Wo findet man die generierten Root-Files?
mit welchem Befehl findet man heraus, welche Gruppe auf diesem Devicenodedefiniert ist?
- output/target/ sowie gleiches auch als Tar-Archiv gepackt unter output/images/rootfs.tar Achtung: bei ersterem (unter output/target/) stimmen die Dateirechte nicht und es fehlen die vordefinierten Device Nodes – make lief ja unter Ihrer User-ID und absichtlich nicht unter root UID!
- Verifizieren Sie mittels 'ls -l /dev/ttyUSB0' , welche Gruppe auf diesem Devicenode definiert ist. Angenommen es ist dialout, nehmen Sie Ihre UID in diese Gruppe auf mit: 'sudo usermod -a -G dialout $USER' . Danach müssen Sie aus- und neu einloggen.
Wie erstellt man ein Schreib-/ Leserecht?
„udev Rule“
# File: /etc/udev/rules.d/99-usb-serial
# FTDI FT232 (Virtual Com Port)
SUBSYSTEMS=="usb-serial", MODE="666"
Was ist ein Devicenode?
Was hat es mit Major Nr 10 (misc) auf sich?
- Ein Devicenode ist also kein Treiber, sondern identifiziert diesen bloss, und zwar mithilfe zweier Id- Nmmern, genannt Major und Minor Number. Im einfachsten Fall werden diese wie folgt verwendet:
- - die Major Number als Treiber-Id, unter welcher sich der Treiber beim Kernel registriert sowie
- - die Minor Number treiberspezifisch, sodass der betreffende Treiber selbst nochmals zwischen verschiedenen gleichartigen Ressourcen unterscheiden kann. Dadurch kann ein Treiber z.B. für mehrere Partitionen oder mehrere RS232-Schnittstellen zuständig sein – die Interpretation von Minor ist also treiberspezifisch! Major- Nummern von 254 rückwärtszählend sind dabei dynamisch vom Kernel zugeordnet, die anderen hingegen statisch d.h. direkt im Treiber.
Treiber können sich auch die gleiche Major number teilen, im Falle die Minor-Node Funktionalität nicht oder nur teilbereiche benötigt werden. Insbesondere ist dies bei der Major Nr 10 (misc) der Fall.
Was gibt es neben Major und Minor-Nummern?
den Devicenodes auch die Zugriffsrechte auf das Device (d.h. Read-/Write-/Execute-Rechte auf Owner, Group und Others) definiert sowie der Devicetyp (b=Blockdevice also für blockweise adressierbare resp. im Dateisystem mountbare Geräte (Harddisks, Memory-Sticks,...) sowie c=Characterdevice für Stream-orientierte Devices (wie serielle Schnittstellen, Soundkarten etc. etc.)
Wie erkennt man ein Pseudofilesystem?
Dass es sich dabei um Pseudofilesysteme handelt, ist an der 3. Spalte erkennbar. Die erste Spalte hat bei Pseudofilesystemen meist keine Bedeutung (nur Platzhalter), weshalb sie auch oft 'none' lautet.
Was kann über Pseudo-Filesystem proc ausgelesen werden?
Das Pseudo-Filesystem proc ( “process information pseudo-file system“) wird immer auf /proc gemountet. Über dieses erhält man zur Laufzeit im Usermode Informationen über den Kernel und Prozesse (viele Commands wie 'ps', 'mount' etc. nutzen die unter /proc bereitgestellten Informationen). Weiter können auch gewisse Kernel-Eingenschaften über /proc dynamisch (also zur Laufzeit) gesetzt werden.
Was ist das Pseudo-Filesystem sysfs?
Das Pseudo-Filesystem sysfs, wird immer auf /sys gemountet und exportiert Informationen aus dem so genannten „Linux Device Tree“ in den Userspace. Der Device Tree ist eine im Kernel unterhaltene Datenstruktur, in welchem alle Devices erfasst werden (vgl. The Linux Device Model 2). Einige (insbes. einfache) Devices können via /sys auch angesteuert werden (so z.B. LEDs ein-/ausschalten, Digitale Ein-Ausgabe, die CPU in den Standby versetzen etc.).
Was ist tmpfs und was ist devtmpfs?
Mittels tmpfs können RAM-Disks an beliebiger Stelle im Verzeichnisbaum eingebunden werden. U.a. wird auf unserem Zielsystem eine RAM-Disk für temporäre Daten auf das Verzeichnis /tmp gemountet: diese ist schneller und verhindert unnötige Schreibvorgänge resp. Abnutzung der SD.
Via Pseudofilesystem devtmpfs werden in unserer Konfiguration die Devicenodes unter /dev
direkt vom Kernel bereitgestellt. Die Einträge (Devicenodes) sind also nicht wirklich statisch auf dem Root Filesystem sondern erst bei Zugriff vom Kernel dynamisch erstellt. Die betreffende Info stammt ebenfalls aus der oben erwähnten „Linux Device Tree“ Datenstruktur. Da devtmpfs gleich- zeitig auch eine RAM-Disk ist, können Einträge unter /dev beliebig geändert oder ergänzt werden.
Wo ist eine eine „permanente“ Konfiguration abgelegt?
Eine „permanente“ Konfiguration ist hingegen SysV Konform in /etc/network/interfaces einzutragen, wobei eine definierte Struktur einzuhalten ist. Diese sehen Sie auf dem Hostsystem mittels 'man interfaces' .
Aber Achtung, Busybox unterstützt nur die wichtigsten Optionen und leider ist die einzige „Dokumentation“ der entsprechende Busybox Quellcode (ifupdown.c) sodass auch hier googlen meist schneller zum Ziel führt.
Wie kann man das Ethernet-Interface aktivieren/deaktivieren?
Wie macht man IP-Adresse statt statisch dynamisch?
- 'ifup eth0' resp. 'ifdown eth0' .
- Natürlich ist es auch möglich, die IP-Adresse statt statisch dynamisch per DHCP zu beziehen. Hierzu in /etc/network/interfaces einfach dhcp statt static definieren sowie address und netmask weglassen.
Erreichen Sie vom Hostsysteme aus per 'ssh [email protected]' das Zielsystem?
Nein es klappt nicht - und zwar weil auf dem Zielsystem noch kein root-Passwort definiert ist, denn „kein Passwort-Eintrag“ (in /etc/passwd resp. /etc/shadow) ist nicht identisch mit einem „leeren Passwort“. Definieren Sie auf dem Zielsystem (also via picocom) mittels Command 'passwd' entweder ein eigenes Passwort oder durch zweimal <Enter> ein leeres Passwort.
Wieso wird nicht Telnet verwendet?
Was wird anstatt Telnet verwendet?
- Telnet ist aber ein äusserst unsicheres Protokoll (da alles, auch das Passwort im Klartext übertragen wird), weswegen hier keine „Werbung“ dafür gemacht werden soll.
Eine sichere Remote-Shellist hingegen via SSH möglich. Auf „ausgewachsenen“ Systemen wird hierzu normalerweise das Open-SSH Package verwendet. Für schlanke Embedded Systeme gibt es aber das einfach Crosscompilierbare „Dropbear“, welches wir bei der Buildroot menconfig ja schon zugefügt haben und gemäss 'ps' bereits auch läuft.
Normalerweise benötigt ein SSH Daemon so genannte „Hostkeys“. Aufgrund der Option -R werden diese bei dropbear aber bei jedem Start neu generiert und nur im RAM gehalten.
Was istt der Unterschied zwischen Soft und Hard Realtime?
muss anwendungsspezifisch rechtzeitig auf Ereignisse regieren − Unter „Ereignisse“ verstehen wir MCUinterne/externe HWSignalisation (z.B. Timer)
bei SoftRealtime meistens, bei “HardRealtime” immer!!
SoftRealtime („weiche“ Echtzeitbedingungen) Die anwendungsspezifischen zeitlichen Anforderungen werden
in der Regel eingehalten
HardRealtime („harte“ Echtzeitbedingungen)
Die anwendungsspezifischen zeitlichen Anforderungen werden
immer und unter allen Umständen immer eingehalten
Grundsätzliche Betriebssystem-Varianten? (5)
- Betriebsystemloses System
- Echtzeit-Multitasking-Betriebssystem (RTOS)
- Normales"Ausgewachsenes"Desktopbetriebsystem
- "Abgespecktes" Desktopbetriebsystem
Desktop-Betriebssystem (“normal” oder “abgespeckt“) mit Echtzeit- Multitasking-Erweiterung (wie RT-Patch oder Co-Kernel)
Was sind die Vorteile und Nachteile eines Betriebsystemlosen Systems?
Vorteile:
Kleinst möglichster CPU- und Memory- Ressourcenbedarf (im KB- Bereich)
(sofern optimal programmiert) deshalb speziell geeignet für kleine Mikrocontroller (AVR, PIC, MSP430, ARM Cortex-M,...) mit (nur) internem Flash und RAM Interrupt-gesteuert oder pollendes System
relativ kurze (Interrupt-) Latenzzeit relativ „deterministisch”
Nachteile
Problematik Hardware-Treiber... oft Eigenentwicklung nötig (Anpassung ab Application Notes oder Code-Fragmente) kaum geeignet für komplexe Projekte / Anford. − Andernfalls Entwicklungsaufwand zu hoch!
Normales “General Purpose” Betriebssystem
Vor und Nachteiler
Vorteile:
Komfortable Entwicklungsumgebung,
Riesiges SW-Angebot...
Gute Security – aber auch verbreitete Angriffsziele Riesiges Schnittstellen- und Protokoll-Angebot
Gute “Soft-Realtime” Eigenschaften
Nachteile:
Schlechte “Hard-Realtime” Eigenschaften
Hoher CPU-/Memory-/Disk-Ressourcen-/Energie-bedarf (Läuft bestenfalls ab SSD –> Langzeit-Zuverlässigkeit)
ev. Komplex (sofern Treiber etc. entwickelt werden müssen) → lange Einarbeitungszeit etc.
ev. Lizenz- u. Supportkosten?
„Abgespecktes“ Desktop-Betriebssystem
Vor und Nachteile
Weglassen nicht benötigter Betriebssystem- Mechanismen
− Schlankerer Kernel: nur effektiv benötigte Treiber
− Nur Minimum an Systemcommands
− Reduzierter Bibliotheksumfang
Vorteil:
Wodurch weniger Prozessor- u. Speicherressourcen nötig...
Unterstützt trotzdem Standard-Libs (z.B. libc, POSIX...)
Immer noch grosses SW-Angebot
Ev. auf Ressourcenfressende x86-Architektur verzichten, statt dessen z.B. ARM-Architektur
Schnittstellen-Treiber i.d.R. direkt verwendbar
Nachteil:
Echtzeitfähigkeit dadurch kaum besser
ev. Lizenzkosten?
Co-Kernel Approach
Ansatz, Vorteile und Nachteile
Ansatz:
gepatchtes Desktop-Betriebssystem läuft als niedrig priorisierter Prozess unter Kontrolle eines Echtzeit-Multitasking-Micro-Kernels
z.B. RTAI, RTLinux, Xenomai, ...
Vorteile
gute RT-Eingenschaften
Nachteiler
Abhängigkeiten zw. RTOS und gepatches Desktop-Betriebssystem...
meist werden nur wenige und rel. alte Kernelversionen unterstützt Upgrade / Security-Upgrade deshalb problematisch....
CPU für RT-Tasks reservieren
Ansatz, Vorteile und Nachteile
Ansatz
nur bei Multicore-CPUs möglich: eine CPU exclusiv für RT-Tasks reservieren...
Vorteile
unter Windows die einzige Möglichkeit um RT-Eigenschaften zu verbessern
Nachteile
Zugriff aus RT-Task auf Peripherieressourcen welche auch vom Desktop-OS genutzt werden
− z.B. separate Netzwerk-Interfaces nötig etc. RT-Eingenschaften im Vergleich zu vollwertigem
RTOS trotzdem recht begrenzt
Multitasking
Non-Preemtive Multitasking und Preemtive Multitasking
Non-Preemtive Multitasking (== Cooperative M.T.)
- laufende Tasks können nur durch Interupts unterbrechen werden, nach der Interrupt-Behandlung läuft jedoch immer der zuvor unterbrochene Task weiter
→ kein Task-Rescheduling aufgrund von Interrupts möglich
− Damit ein Taskswitch stattfinden kann, muss also jeder Task im System “kooperativ” sein
− z.B. bis Windows 3.x
Preemtive Multitasking:
− Der Kernel (resp. der Scheduler im Kernel) kann bei Eintreffen eines (Hardware-)Interrupts wenn nötig einen Tastswitch (Rescheduling) forcieren.
− Tasks können somit aufgrund eines Interrupt-Ereignisses aktiviert werden
− Als (Interrupt-)Ereignisquellen: Peripherie wie Schnittstellen, HW-Timer, ADC, ...
Timeslicing
Voraussetzungen für Time Slicing...
Wie funktioniert Timeslicing?
Voraussetzungen für Timeslicing:
Hardwaretimer, entweder welcher periodisch resp. bei Bedarf (Tickless) Interrupts generiert
Kernel mit Preemtive Multitasking
Aus der Timer-Interrupt-Routine kann dann bei Bedarf ein Rescheduling erfolgen
Funktion:
- aufgezwungenes Rescheduling in einem vordefinierten Zeitintervall (z.B. alle 10ms)
- Sofern das Betriebssystem streng prioritätsgesteuert ist, erfolgt das Rescheduling nur zwischen gleich priorisierten Prozessen niedriger priorisierte werden also komplett zurückgehalten, solange höhere die CPU verlangen
− Desktop-Betriebssysteme haben hingegen normalerweise “weiche” Prioritäten, d.h. niederiger priorisierte Prozesse erhalten auch etwas Rechenzeit, auch wenn höher priorisierte “ready” sind(vergleichsweise jedoch weniger).
Damit wird eine Blockieruen bei nicht kooperativen Prozessen verhindert Hingegen sind damit harte Echtzeitfähigkeiten erst recht nicht zu erfüllen!
Technische Daten über das Wandboard
System On Chip: Freescale i.MX6 Duallite → industrietauglich, auch Doku
CPU: Cortex-A9 Dual core, ink. FPU and NEON SIMD
Graphics Engine und reichlich Peripherie-Schnittstellen
alle Treiber Open Source bootet ab MicroSD (Booten via SD nicht ganz industrietauglich)
1GB DDR3 RAM
Was beinhaltet GNU GCC Toolchain?
C sowie C++ Cross-Compiler
Target-Libraries + zugehörige Headerfiles
GNU Debugger (gdb)
sonstige “binutils” wie
Linker ld, assembler as, objcopy, objdump, ...
Bootvorgang beim PC-Systemen ...
- BIOS (Power On Self Test) oder EFI/UEFI − Ermittelt bootbare Devices sowie Bootreihenfolge ...
BIOS → lädt / startet Bootloader aus MBR (1. Sektor der Harddisk)
UEFI-Partition → lädt / startet Bootloader aus EFI-Part.
− Dieser Bootloader lädt den Bootmanager aus der Betriebssystem o. EFI-Partition ins RAM
- Ein Bootmanager lässt eine (gewisse) Auswahl zu − Lädt z.B. gewünschtes Linux-Kernel-Image und Bootparameter von der HD ins RAM− lädt üblicherweise ein Initial RAM Disk Image (Initrd resp. initramfs) ins RAM
- Kernel wird gestartet (per JMP auf Startadresse)...
− dekromprimiert sich selbst
− initialisiert CPU- und Memory Management
− startet die (wenigen) statisch fix im Kernelimage zugelinkten Treiber (z.B. für Memory u. CPU-Verwaltung, Console)
Prüft, ob im RAM eine “Initial RAM Disk Image” geladen ist und mountet ggf. dieses temporär ; aus dieser Ramdisk werden die zum Booten nötigen Disk+FS-Treiber geladen
− Mountet darauf (gem. Bootparameter) die Rootpartition als Rootfilesystem '/' (zuoberst ins VFS)
− Der Kernel startet darauf den ersten Usermode-Prozess: /sbin/init
Der Weitere Start des System erfolgt durch den init-Prozess entweder “SysV konform” (altes Konzept) oder via “Upstart” (Ubuntu) oder via “systemd” (anderen Linux Distributionen)
Bootvorgang Embedded Linux...
- Partitionen sind auf Flash (SD, eMMC oder “raw” Flash)Bootloader ev. ausserhalb einer Partition z.B. an fixer Stelle
- Bei “Reset” wird Bootloader ab Flash (resp. SD) gestartet
− dieser lädt Linux-Kernel aus separater Flash-Partition ins RAM
oder bei Netzerkboot z.B. von einem TFTP-Server ins RAM
Bei Embedded Systemen wird meist kein “initrd” verwendet: Der Kernel wurde ja schon “customized” für das Zielsystem, d.h beim “Kernel-Build” wurden dem dem Kernel-Image alle zum Booten benötigten Treiber statisch zugelinkt
Ein initrd kann verwendet werden für Rootfilesystem im RAM (statt auf Flash-Part.)
- Nach Kernel-Start/-Dekompression/-Init ...
− mountet der Kernel das Root-Filesystem gem. Kernel-Bootparameter 'root=' z.B. eine Flash-EEPROM-Partition oder eine NFS-Netzwerkfreigabe
− und startet daraus den ersten (Usermode-)Prozess: /sbin/init
/sbin/init führt die Systeminitalisierung durch...
bei sysV-konformer Initialisierung...
interpretiert init-Prozess zuerst das File /etc/inittab ...in welchem z.B. auf das Start-Script /etc/init.d/rcS verweisen wird,
gem. welchem dann weitere Scripts und Programme entweder direkt aus rcS oder indirektz.B. über Verzeichniseinträge in /etc/rcS.d/* gestartet werden (keine Runlevels...)
