Startseite > Embedded > Software > Tipps zur unkomplizierten Bootzeit-Optimierung

Turbo für Embedded Linux

Tipps zur unkomplizierten Bootzeit-Optimierung

7. Januar 2011, 10:42 Uhr | Von Robert Schwebel

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Tipps zur unkomplizierten Bootzeit-Optimierung

Architektur-Optimierungen

Optimierung auf Bootzeit allein ist oft nur unter akademischen Aspekten relevant. Zwar lassen sich Systeme erreichen, die in unter 1 s in eine grafische Applikation booten, jedoch gehen dabei viele der sonst auf einem Linux- System gewünschten Eigenschaften wie Wartbarkeit und Software-Updates verloren. Die Optimierung der Flash- Blöcke ist beispielsweise aufwendige Handarbeit, so dass nicht einfach eine neue Version der gleichen Software ins System eingespielt werden kann. Hier müssen Bootzeit und Komfort gegeneinander abgewogen werden. Aus diesem Grund sind die Entwickler der gängigen Open-Source- Komponenten seit einigen Jahren konsequent dabei, die Komponenten selbst zu optimieren. Während in den letzten Jahren der Kernel im Fokus stand, wird nun an einem performanten und leistungsfähigen Ersatz von System V Init gearbeitet.

Das Programm „Upstart“ hat im letzten Jahr zwar den Weg in die meisten Distributionen gefunden, wird jedoch in Kürze vermutlich durch „systemd“ abgelöst, das einige sehr effiziente Maßnahmen anwendet, um den Start der Systemdienste zu beschleunigen: `` Die Startscripte werden von Shell in C portiert. `` Dienste, die auf Netzwerk-Sockets basieren, werden erst On-Demand gestartet. Daneben sorgt eine saubere Integration in die Linux-Standard-Middleware D-Bus dafür, dass Management-Applikationen eine moderne, introspektierbare Schnittstelle zum Init-System bekommen. Dieser Ansatz scheint unter den Distributoren derzeit auf Akzeptanz zu stoßen, so dass erwartet wird, dass die kommende Generation der Linux-Distributionen auf systemd basieren wird.

Problem: Bildschirm-Flackern

Ein anderes Problem beim Starten von Embedded-Linux-Geräten mit Display ist das Flackern beim Starten, das oft als störend empfunden wird. Dabei ist der Ablauf wie folgt: `` Das Backlight wird eingeschaltet. `` Das Display ist noch uninitialisiert und blitzt auf. `` Der Bootloader übernimmt die Kontrolle und schaltet das Display dunkel oder gibt ein Bootmenü aus. `` Der Kernel startet. `` Beim Start des grafischen Systems (x.org) wird wiederum umgeschaltet, was ein weiteres Flackern nach sich zieht. ``x.org meldet sich. ``Die Applikation startet. Viele Embedded-Geräte zeichnen sich dadurch aus, dass lediglich eine einzige Applikation auf der grafischen Oberfläche läuft. Dies macht den Einsatz von x.org oft überflüssig, denn viele grafische Toolkits wie etwa Qt^[4] bieten die Möglichkeit, direkt auf einem Framebuffer zu laufen.

Bei der Optimierung eines solchen Systems muss bereits bei der Hardware- Entwicklung begonnen werden: Der Entwickler muss sicherstellen, dass die Hinterleuchtung zu Beginn ausgeschaltet ist und erst per GPIOPin aus der Software aktiviert werden kann. Nun initialisiert der Bootloader die Grafikkarte, stellt einen Splash Screen dar und schaltet jetzt erst das Backlight ein. Damit erscheint in wenigen Millisekunden nach dem Start ein Splash-Screen. Ein weiterer Trick ist, den Bootloader zunächst einen Overlay-Framebuffer nutzen zu lassen. Dies hat den Vorteil, dass die eigentliche Applikation, vor allem auf langsamen Prozessoren aus der 400-MHz-ARM-Klasse, im Hintergrund unsichtbar starten kann.

Jobangebote+ passend zum Thema

MACNICA ATD EUROPE - Ihre berufliche Zukunft

MACNICA ATD Europe GmbH, Ingolstadt

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Wenn die Applikation vollständig aufgebaut ist, schaltet sie dann beispielsweise mit Alpha-Blending weich zwischen Splash-Screen und Applikation um. Modernere Prozessoren, etwa aus der ARM11- oder Cortex-A8- oder A9- Kategorie, booten hingegen so schnell, dass sich die Anzeige des Splash- Screens bereits unter Linux erreichen lässt, ohne dass der Anwender eine störende Verzögerung bemerkt. Ein Beispiel für eine moderne Visualisierung zeigt Bild 3. Einige Videos, die dieses Verhalten zeigen, finden sich in^[5]. In der Praxis hat sich herausgestellt, dass sich auch mit konventionellen, updatefähigen Root-Dateisystemen Bootzeiten von 6 s erreichen lassen, ohne dass allzu tief in die Trickkiste gegriffen werden muss. Diese Zeit wird von vielen Anwendern als gerade optimal zur Anzeige eines Firmenlogos empfunden, so dass sich hier ein guter Kompromiss erzielen lässt.

Die „Boot Time Critical Services“

Eine weitere Möglichkeit wird derzeit vor allem für den Automotive-Bereich entwickelt: Hier stellt sich oft die Forderung, auf CAN-Bus-Nachrichten auf bereits in weniger als 200 ms antworten zu können. Für viele SoC-CPUs ist diese Zeit zu kurz, um bereits ein Linux so weit gebootet zu haben, dass der SocketCAN-Stack des Kernels diese Aufgabe übernehmen kann. Derzeit wird an einem System gearbeitet, bei dem bereits im Bootloader Routinen angemeldet werden können, die sich etwa um den CAN-Controller kümmern können. Da im Bootloader noch keine Interrupts zur Verfügung stehen, werden diese in kurzen Abständen per Polling aufgerufen. Die Routinen selbst werden in einem Speicherbereich untergebracht, in dem sie nicht vom startenden Kernel überschrieben werden.

Auch während der Boot-Phase pollt der Kernel weiterhin den Boot Time Critical Service (BTCS). Ist der Kernel so weit lauffähig, dass er sein konventionelles Interrupt-System aktiviert hat, läuft der Service als gewöhnliche Interrupt-Routine weiter. Diese Methode erlaubt es, die Anforderungen aus dem Automobilsektor zu erfüllen. Allerdings sind noch nicht alle dafür benötigten Komponenten in die jeweils veröffentlichten Versionen von Bootloader und Kernel eingeflossen, so dass der Anwender hier zur Zeit noch selbst mit Patchen nachhelfen muss. Letztlich bedeutet auch der Einsatz von modernen Betriebssystemen wie Linux nicht, dass Embedded-Systeme minutenlang und flackernd booten müssen. Mit dem richtigen Knowhow können sie so optimiert werden, dass lediglich für wenige Sekunden ein Splash-Screen angezeigt und dann nahtlos in die Applikation übergeleitet wird.

Und Systeme, die nicht auf der grafischen Oberfläche, sondern auf Kommunikationsbussen wie CAN schnell reagieren müssen, können mit Hilfe von Boot Time Critical Services so stark beschleunigt werden, dass sie in wenigen 10 ms bereits reaktiv sind. Allerdings schreitet bei Linux die Entwicklung rasant voran, so dass sich der Einsatz aktueller Versionen des Kernels und von Userspace-Komponenten empfiehlt.