Was könnte getan werden, um den Bootvorgang von Embedded Linux zu beschleunigen?

Was könnte getan werden, um den Bootvorgang von Embedded Linux zu beschleunigen?

Mein Team entwickelt eine Software für eine Embedded-Linux-Lösung. Das Problem dabei ist, dass es zu lange dauert, bis das System bereit ist, unsere gewünschten Apps auszuführen (das heißt, es dauert zu lange, den Linux-Kernel zu laden). Normalerweise dauert es zwischen 38 und 43 Sekunden, bis das passiert. Wir haben die Kernel-Konfiguration bereits überarbeitet und die Dateien entfernt, von denen wir wussten, dass wir sie nicht brauchen, aber es dauert trotzdem so lange.

Meine Fragen: Was kann man sonst noch tun, um den Kernelstart zu beschleunigen (vorzugsweise ohne Änderungen an der Hardware)? Ist es normal, dass ein Embedded Linux so lange zum Laden braucht? Ist es möglich, den Linux-Kernel anzuweisen, unsere Apps zu starten, bevor der Kernel vollständig geladen ist?

Das System ist ein Texas InstrumentsOMAP L138.

Es folgen Bilder mit den wichtigsten Meldungen, die im Terminal angezeigt werden, wenn der Kernel bootet. Wer keine (allgemeingültige) Antwort auf meine Fragen hat, aber etwas zu einer der Zeilen weiß, das dabei helfen könnte, die Bootgeschwindigkeit des Kernels zu verbessern, kann ebenfalls gerne antworten!

Erster Teil Zweiter Teil Dritter Teil Vierter Teil Fünfter Teil

Antwort1

In Ihrer Ausgabe ist dieser Punkt, an dem der Kernel tatsächlich geladen wird:

Init version 2.86 booting

Das ist nach 23 Sekunden. Danachdrin, ein Userspace-Prozess, übernimmt und beginnt mit der Konfiguration des Userspace, was allerdings unvermeidlich die Aktivierung verschiedener Kernel-Treiber nach sich zieht, möglicherweise einschließlich des Ladens geeigneter Module.

Sie haben nicht gesagt, um welche Plattform es sich handelt, aber auf dem 700-MHz-Single-Core-Raspberry-Pi dauert es beispielsweise ca. 4 Sekunden. Das ist also immer noch sehr langsam und deutet auf ein Problem hin.

Wenn wir die Lücke zwischen 0 und 19 Sekunden abziehen, kommen wir auf das, was zu erwarten wäre. Diese Lücke endet mit einem Kommentar zu MII PHY -Dies ist ein Ethernet-Gerätetreiber. Wenn es möglich ist, das System ohne Netzwerk zu booten, können Sie dies bestätigen, indem Sie den Ethernet-Treiber aus dem Kernel heraus konfigurieren und prüfen, ob es dadurch initschneller geht.

Nach 23 Sekunden wird der größte Engpass wahrscheinlich die E/A auf dem Root-Dateisystem sein. Aus irgendeinem Grund gibt es zwischen 25 und 30 Sekunden eine 5-Sekunden-Lücke, die mit einem Kommentar über einen FAT-Dateisystemfehler endet. Tatsächlich gibt es dort einige FS-Fehler. Dies bedeutet, dass das Init-System versucht, nicht vorhandene Dateisysteme zu mounten, was Zeitverschwendung ist.

Zwischen 33 und 37 Sekunden gibt es mehr Fehler, die auf Pannen hinweisen, bei denenwie Dateisysteme angeordnet sind und/oder wie Software, die davon abhängt, konfiguriert istEine dieser Abhängigkeitenkönnteein tmpfs-Dateisystem sein, das eigentlich im RAM erstellt werden sollte, aber fehlgeschlagen ist (daher fehlen Dateien in /var/und /tmp). Sie könnten eine separate Frage stellen, indem Sie Ihre eigene posten /etc/fstabund jemanden bitten, sie zu erklären, wenn der Punkt hier nicht klar ist.

verwandte Informationen