Extreme Pi-Boot-Optimierung

 (kittenlabs.de)
4 Punkte von GN⁺ 2024-09-02 | 1 Kommentare | Auf WhatsApp teilen
  • SolarCamPi ist eine Off-Grid-Solarkamera, die den Raspberry Pi Zero 2 W nur zum Fotografieren ein- und danach wieder ausschaltet, daher bestimmt die Bootzeit direkt die Batterielaufzeit
  • Auf Basis von Debian 12 arm64 Lite verbraucht der erste Userspace-Code bei Messung mit /init.sh etwa 12 Sekunden und 9,5 Ws
  • Durch das Reduzieren von HDMI, LED, HAT/PoE/LCD, automatischer Kamera-/Display-Erkennung und initramfs wurden unnötige Wartezeiten und Erkennungen entfernt, und der Strom sank von 136,7 mA auf 120,6 mA
  • Nach dem Umstieg auf Buildroot 2024.02.1 und einen angepassten Kernel wurden Treiber, Komprimierung, KASLR und einige Mitigations entfernt, sodass Linux-Userspace-Programme in unter 3,5 Sekunden erreicht werden
  • Wird die Eingangsspannung von 5,0 V auf 3,6 V gesenkt, sinkt die Gesamtenergie von 1,754 Ws auf 1,438 Ws, allerdings bleibt die Stabilitäts- und Zuverlässigkeitsprüfung außerhalb der Spezifikation offen

Warum SolarCamPi die Bootzeit reduzieren musste

  • SolarCamPi ist eine solarbasierte WiFi-Kamera, die den Raspberry Pi Zero 2 W periodisch bootet, Fotos aufnimmt, sie per WiFi in einen Cloud-Service hochlädt und sich anschließend wieder abschaltet
  • In Umgebungen mit knappem Strom, etwa im westeuropäischen Winter, wird jede Sekunde, in der der Pi eingeschaltet ist, direkt zum Energiekostenfaktor
  • Die Serververbindung und der Foto-Upload der Userspace-Anwendung waren bereits so weit wie möglich optimiert, und auch die Elektronik war so ausgelegt, dass der Stromverbrauch im Schlaf minimiert wird
  • Es blieben zwei Wege zur weiteren Einsparung
    • Stromaufnahme senken
    • Laufzeit verkürzen
  • Nur den Strom zu senken ist nicht immer von Vorteil
    • Wenn CPU-Turbo deaktiviert wird und der Strom sinkt, die Laufzeit aber steigt, kann die Gesamtenergie sogar zunehmen
    • Das Ziel ist, die Fläche unter der Kurve aus Strom und Zeit zu minimieren

Messhardware und Testverfahren

  • Bei der Optimierung von Embedded-Bootzeiten ist es wichtig, Änderungen schnell im echten Lauf zu prüfen, daher sind Werkzeuge nützlich, die SD-Karten-Wechsel und Strommanipulationen reduzieren
  • Verwendet wurden folgende Geräte
  • Das Power Profiler Kit II versorgt das Testgerät mit Strom und misst gleichzeitig den zeitlichen Energieverbrauch sowie den Zustand von 8 digitalen Eingängen
    • GPIO-Pins des Raspberry Pi wurden mit den digitalen Eingängen verbunden
    • Als erste Aktion der Anwendung wurde ein GPIO umgeschaltet, um die Zeit von der Stromzufuhr bis zur Ausführung von Userspace-Code zu messen
  • USB-SD-Mux ist ein Interposer zwischen microSD-Karte und Gerät, sodass ein Computer die Karte übernehmen, den Inhalt neu schreiben und sie wieder an das Gerät zurückgeben kann
    • Das wiederholte Herausnehmen der Karte, Einstecken in einen Leser und Zurücksetzen ins Gerät entfällt
    • Über Onboard-GPIO lassen sich auch Reset oder Stromversorgung des Testobjekts automatisieren
  • Eine USB-UART-Konsole ist nötig, um den Zustand zu prüfen, wenn das System beschädigt ist, etwa bei Bootfehlern oder WiFi-Problemen

Boot-Messung mit Debian

  • In einem sauberen Debian-12-bookworm-arm64-Lite-Image wurde in /boot/firmware/cmdline.txt init=/init.sh ergänzt
  • Diese Einstellung sorgt dafür, dass der Kernel /init.sh vor systemd als ersten Prozess im Userspace ausführt
  • Ein Beispiel-init.sh schaltet GPIO4 um und setzt den Bootvorgang mit exec /sbin/init in systemd fort
  • Bei der ersten Messung wurde nach etwa 12 Sekunden ein low auf digitalem Eingang 0 erkannt, was die Ausführung von init.sh bestätigte
  • Dieser Bootvorgang verbrauchte insgesamt 1,90 Coulomb
    • 1.9As * 5.0V = 9.5Ws
    • Eine AA-Alkaline-Batterie kann ungefähr 13500 Ws Energie liefern

Stromaufnahme senken

  • Durch vollständiges Deaktivieren des HDMI-Encoders sank der Strom von 136,7 mA auf 122,6 mA
    • Da Kameradaten kodiert werden müssen, konnte die GPU selbst nicht abgeschaltet werden
    • Bei Anwendungen ohne Kamera oder GPU-Bedarf könnte auch das Deaktivieren der GPU versucht werden
  • Allein das Deaktivieren der Activity-LED sparte 2 mA, wodurch der Strom von 122,6 mA auf 120,6 mA sank
  • Falls eine Kamera-LED vorhanden ist, kann auch sie deaktiviert werden
    • Dadurch sinkt auch die Wahrscheinlichkeit, dass die LED im Bild reflektiert wird
  • Beim Test von Änderungen an den Turbo-Einstellungen verbrauchte der Pi im aktuellen geänderten Zustand 1,62 As
    • Ohne erzwungenen Turbo waren es 1,58 As
    • Aus unbekannten Gründen kehrte das Deaktivieren von Turbo/Boost den Standardzustand von GPIO4 um, sodass die Polarität in init.sh angepasst wurde

Bootzeit verkürzen

  • Der Strom war zwar um rund 13 % gesunken, aber bis zur ersten Linux-Ausgabe auf der Konsole vergingen weiterhin etwa 8 Sekunden, in diesem Abschnitt wurden ungefähr 1 As verbraucht
  • Bei der Raspberry-Pi-Familie wird zuerst die GPU initialisiert
    • Die GPU sucht auf der SD-Karte nach bootcode.bin
    • Beim Pi 4 und neuer wird EEPROM verwendet
  • Wird BOOT_UART in bootcode.bin aktiviert, lassen sich ausführliche UART-Logs sehen
    • Eine Sicherung des ursprünglichen bootcode.bin ist nötig, und der Änderungsprozess ist potenziell destruktiv
  • Der Bootloader versucht, die Videoparameter eines angeschlossenen HDMI-Monitors automatisch zu erkennen, und wartet dazu auf eine EDID-Antwort
    • Da HDMI nicht genutzt wird, wurde ein EDID-String fest kodiert, um die Erkennung zu vermeiden
  • Auch die Erkennung von I2C-EEPROMs für HAT, PoE-Lüfter, LCD und Touchscreen wurde deaktiviert
    • Diese Optionen warten auf Antworten auf dem I2C-Bus und sollten ausgeschaltet werden, wenn sie nicht benötigt werden
  • Die automatische Erkennung von MIPI-Kamera und Display kostet ebenfalls Zeit
    • Da als Kamera fest die HQ Camera IMX477 genutzt wird, wurden camera_auto_detect=0 und display_auto_detect=0 gesetzt und dtoverlay=imx477 direkt geladen
  • Durch diese Änderungen sank die selbst gemeldete Bootzeit von 5,38 Sekunden auf 4,75 Sekunden, und durch das Entfernen von auto_initramfs=1 fiel sie mit deaktiviertem initramfs auf 4,47 Sekunden
  • Das sdtweak-Verfahren, das das SD-Peripheriegerät auf 100 MHz übertaktet, brachte keinen messbaren Unterschied bei der Bootleistung
    • Wegen des Risikos von Datenkorruption bei Schreibzugriffen ist es für entfernte IoT-Geräte nicht wünschenswert

Kernel-Ladeengpass und Wechsel zu Buildroot

  • Zu diesem Zeitpunkt war das Laden des Kernels eine der langsamsten Aufgaben
    • Das Laden von kernel8.img mit 9.276.375 Byte dauerte etwa 1,54 Sekunden
    • Die Übertragungsrate lag bei etwa 6 MiB/s
  • Das Laden des Kernels erfolgt über die GPU, die den internen proprietären VideoCore IV-Prozessor verwendet
    • Es ist möglich, dass der Loader-Code ineffizient ist oder konservative Einstellungen nutzt, aber als Blackbox konnten Register oder Parameter nicht sinnvoll angepasst werden
  • Eine Übertaktung des GPU-Prozessorkerns war theoretisch möglich und reduzierte die Kernel-Ladezeit um 20 %
    • Wegen unbekannter Nebenwirkungen etwa auf die Zuverlässigkeit wird das nicht empfohlen
  • Das System wurde von Raspbian/Debian auf eine angepasste Distribution auf Basis von Buildroot 2024.02.1 umgestellt
    • mit nativer aarch64-Toolchain
    • glibc und Raspberry-Pi-Userland-Tools wurden beibehalten
  • Im angepassten Kernel wurde Folgendes entfernt oder reduziert
    • Audio-Unterstützung
    • die meisten Treiber für Blockgeräte und Dateisysteme, nur SD/MMC und ext4 blieben erhalten
    • RAID, USB, HID, DVB
    • Video- und Framebuffer-Unterstützung
    • erweiterte Netzwerkfunktionen wie Tunnel, Bridging und Firewall
    • Gzip-Kernel-Komprimierung und Modulkomprimierung
  • Kernel und Module gar nicht zu komprimieren war aus Sicht der Gesamtenergie vorteilhaft, auch wenn die GPU dadurch länger laden musste
    • Die Gzip-Dekomprimierung verbraucht viel Energie und beinhaltet praktisch einen zusätzlichen Relocation-Schritt
  • KASLR wurde ebenfalls deaktiviert
    • KASLR randomisiert die Speicheradresse, an der der Kernel geladen wird, um das Schreiben von Exploits zu erschweren, erfordert nach dem GPU-Laden aber eine Relocation des Kernels
    • In diesem Anwendungsfall ist die Angriffsfläche über das Netzwerk sehr begrenzt, und die gesamte Anwendungssoftware läuft als root
    • Auch Mitigations für spekulative Ausführung wie Spectre wurden deaktiviert
  • Das resultierende Kernel-Image war 8,5 MiB unkomprimiert, zum Vergleich betrug die Gzip-komprimierte Größe 4,1 MiB
    • Der ursprüngliche Raspbian-Kernel war 25 MiB unkomprimiert und 8,9 MiB Gzip-komprimiert

Endergebnis und Optimierung der Eingangsspannung

  • Am Ende wurde das Linux-Userspace-Programm in unter 3,5 Sekunden erreicht
  • Die im Linux-Kernel selbst verbrachte Zeit lag bei etwa 400 ms
  • Der gesamte Energieverbrauch betrug 0,364 As * 5,0 V = 1,82 Ws
    • Verglichen mit den 9,5 Ws von stock Debian bis zum Erreichen des Userspace entspricht das etwa einem Fünftel
  • Nach der Veröffentlichung wies Graham Sutherland / Polynomial darauf hin, dass der Regler des Pi Zero bei 5,0 V Eingang nicht effizient arbeitet
  • Im Testszenario und im fertigen Produkt konnte die Eingangsspannung auf 4,0 V gesenkt werden
    • 5,0 V: 350.94mAs * 5.0V = 1.754Ws
    • 4,0 V: 390.77mAs * 4.0V = 1.563Ws
    • 3,6 V: 399.60mAs * 3.6V = 1.438Ws
  • Wird die Spannung gesenkt, steigen mC bzw. mAs wegen des höheren Stroms, aber die Gesamtenergie sinkt deutlich
  • Der Betrieb bei 3,6 V senkte die Energie um weitere etwa 20 %, weil der Schaltregler näher an seinem idealen Arbeitspunkt lief, liegt technisch aber außerhalb der Spezifikation und erfordert weitere Validierung von Stabilität und Zuverlässigkeit

Veröffentlichtes Setup und Code

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-09-02
Hacker-News-Kommentare

  • Das Power-Management der Raspberry-Pi-Reihe ist definitiv eine ihrer Schwächen. Deshalb bin ich auf den neuen Pico 2 gespannt, weil es so aussieht, als ließe er sich auch ohne externe Hardware relativ leicht in einen ziemlich tiefen Energiesparzustand versetzen.
    Ich habe einmal eine Kamera für einen ähnlichen Einsatzzweck mit einem Google Coral mini gebaut; die Kamera ist zwar nicht so gut wie die HQ cam, aber dank eingebauter RTC waren Standby und Aufwecken sehr einfach unterstützt, sodass er für Apps mit periodischen Aufnahmen perfekt war. Es gab auch genug Leistung und 2 GB Speicher, um hochauflösende Bilder zu verarbeiten.
    Man kann die HQ camera zwar physisch anschließen, aber soweit ich weiß gibt es auf dem Coral keine Software-Pipeline, um sie zu verwalten.
    Das Raspberry-Pi-Ökosystem ist deutlich reifer, und ich vertraue eher auf die künftige Verfügbarkeit von Raspberry Pi als darauf, dass Google die Coral-Linie weiter liefert. Trotzdem habe ich deutlich gemerkt, wie nützlich gute Power-Unterstützung in der Hardware ist.
    Ironischerweise wurde die Kamera der nächsten Version von einem Auftragsunternehmen mit Raspberry Pi gebaut, und die Energieprobleme wurden durch einen deutlich größeren Akku kompensiert. Dadurch sitze ich jetzt auf einem ungeöffneten Coral dev mini und 100 Kameras und muss entweder eine gute Idee dafür finden oder sie verkaufen.

    • Die Coral-Linie ist doch vermutlich schon tot oder eingestellt, oder? Auch die coral.ai-Website scheint seit 2021 nicht mehr aktualisiert worden zu sein, und der Copyright-Hinweis ist ebenfalls von 2020.
      Ich habe nach "google coral twitter" gesucht, um den offiziellen Twitter-Account zu finden, und das zweite Ergebnis war zu meiner Verwirrung dein Tweet, in dem du 100 übrig gebliebene Boards verkaufen willst.
    • Ich habe Pi immer nur mit Netzstrom an der Steckdose verwendet, daher finde ich das interessant. Ich frage mich, ob die Pi-Hardware selbst Power-Optimierung wie beim Coral nicht kann oder ob eher die Software-Unterstützung für das Power-Management beim Pi unzureichend ist.
      Da du erwähnt hast, die Stromversorgung mit externer Hardware zu verwalten, scheint es nicht nur ein reines Softwareproblem zu sein.
    • Mich würde interessieren, ob du dir für Low-Power-Betrieb auch BeagleBone-Hardware mit PRU-Geräten angesehen hast. Die PRUs können wach bleiben, während das System schläft.
    • Mich würde interessieren, welche Aufgabe du erledigst, die mit heutigen Kameras von der Stange nicht möglich ist.

  • Wenn man die Anwendung als mit dem Kernel verlinktes initramfs bündelt, kann man sich in einfachen Fällen das Mounten eines Dateisystems sparen, was ziemlich viel einsparen kann.
    In manchen Fällen lässt sich sogar so etwas wie BusyBox init durch ein einfaches bash-Skript ersetzen, das nur das Nötigste für den Boot erledigt. Man kann devtmpfs, proc, sysfs usw. mounten und sollte auch erwägen, wenn möglich glibc wegzulassen.
    Es ist sinnvoll, vor dem Einbinden des initramfs in den Kernel per chroot zu testen, ob alle benötigten Anwendungsabhängigkeiten vorhanden sind. Wenn es im chroot läuft, kann der Kernel es beim Booten ebenfalls ausführen, und die Entwicklungsiterationen werden deutlich schneller.
    Wenn man Kernel-Module deaktiviert und nur die benötigten Funktionen direkt in den Kernel verlinkt, lassen sich Platzbedarf und Bootzeit weiter reduzieren. Es kann sich auch lohnen, zstd-Kompression statt gzip zu testen.

    • Umgekehrt kann es, wenn das Laden von Kernel und initramfs langsam ist, schneller sein, zunächst mit dem praktisch kleinstmöglichen Image zu booten und den Rest der Software erst nach dem Start des User Space nachzuladen.
      Das gilt für Fälle, in denen frühere Boot-Phasen die Hardwareleistung nicht ausreichend nutzen oder das Image so groß ist, dass es besser ist, während des Ladens parallel andere Dinge zu tun.
    • Man braucht nicht zwingend ein Shell-Skript, um mehrere Pseudo-Dateisysteme zu mounten. Das kann man auch direkt in der Anwendung erledigen.
      Dann bleibt nur ein initramfs mit einem einzigen statisch gelinkten Binärprogramm übrig.

  • Es gibt noch zwei weitere gute Artikel dazu, die Bootzeit des Pi zu verkürzen.
    https://www.furkantokac.com/rpi3-fast-boot-less-than-2-secon...
    http://himeshp.blogspot.com/2018/08/fast-boot-with-raspberry...
    Unter Bezug auf diese beiden Artikel habe ich mit einem Pi einen digitalen Bilderrahmen gebaut und sogar den Browser im Kiosk-Modus sehr schnell booten lassen. Wenn die Anforderungen sehr gering sind, kann man ziemlich beeindruckende Bootzeiten erreichen.

    • Nachdem ich den ersten Artikel gelesen habe, scheint es, als könnte auch der Originalbeitrag von start_cd.elf profitieren. Das ist ein Bootloader der dritten Stufe mit entferntem Grafik-Subsystem, und angeblich wurden dadurch 0,5 Sekunden Ladezeit eingespart.
    • Danke für die Links. Ist der Code für diesen Kiosk-Fotorahmen zufällig auch öffentlich?

  • Die eigentliche Tragödie ist, dass der bootcode.bin-GPU-Code eine proprietäre Blackbox ist und der Quellcode nicht verfügbar ist.
    Es ist schrecklich, dass Hacking- und Hobbyprojekte auf eine verborgene geheime Blackbox angewiesen sind, die man nicht verändern kann.

    • Die Pi-Firmware ist ThreadX, das später von Microsoft übernommen und in Azure RTOS umbenannt wurde.
      Inzwischen ist es freie Open-Source-Software.
      https://www.theregister.com/2023/11/28/microsoft_opens_sourc...
      Das bedeutet natürlich nicht automatisch, dass die gesamte Pi-Firmware freie Open-Source-Software wird, weil es sich nicht um Treiber handelt. Aber wenn man wollte, wäre es möglich.
    • Ich frage mich, ob eine Veröffentlichung des bootcode-Quellcodes so extreme Modifikationen ermöglichen würde, dass RPI den normalen Betrieb nicht mehr garantieren könnte. Oder vielleicht hängt es mit dem Laden proprietärer Treiber zusammen.
      Ich frage mich, was darin steckt, das geheim bleiben muss.

  • Insgesamt gefällt mir der Beitrag, aber bei diesem Punkt bin ich mir nicht sicher.
    Das Deaktivieren des CPU-Turbos, um etwas Strom zu sparen, scheint eine schlechte Wahl zu sein, und zwar wegen der Aussage, dass man dadurch mehr Energie verbraucht, als wenn man die Arbeit schnell beendet und dann abschaltet.
    Im Informatikunterricht habe ich gelernt, dass der Stromverbrauch proportional zum Quadrat der Taktfrequenz ist. Das heißt: Wenn man den Takt verdoppelt, vervierfacht sich der Stromverbrauch.
    Um also zu prüfen, ob der quadratische Anstieg durch höheren Takt größer ist als das Produkt aus festem Stromverbrauch und längerer Laufzeit, müsste man wohl den tatsächlichen Energieunterschied messen.
    In dem Zusammenhang wäre es schön, wenn die Pi-CPU detaillierte Leistungsaufnahmedaten bereitstellen würde, die sich aus dem Datenblatt ableiten lassen oder in Echtzeit über Register zugänglich sind.

    • Diese Erklärung ist nicht ganz korrekt. Die Schaltleistung eines Chips ist – abgesehen von statischer Leckage – proportional zu Spannung zum Quadrat mal Frequenz.
      Die meisten Chips benötigen für höhere Taktraten auch eine höhere Spannung, daher kommt dort die quadratische Beziehung her.
      Soweit ich weiß, hat der Raspberry Pi aber keine dynamische Spannungsregelung; wenn also nur der Takt gesenkt wird, ohne die Spannung zu verringern, sollte das keinen Einfluss auf den gesamten Schaltenergieverbrauch haben.
    • Das ist eine bekannte Strategie zur Leistungsoptimierung namens race to idle. Es gibt neben der CPU viele weitere Komponenten, die Strom verbrauchen, und sie lassen sich oft erst abschalten, wenn die CPU-Arbeit abgeschlossen ist – deshalb funktioniert das.
      Natürlich gibt es auch hier ein Optimum. Wenn man die CPU zu stark übertaktet, sinkt die Leistung pro Watt so stark, dass race to idle nicht mehr greift.
    • Für eine dauerhafte Arbeitslast ist das eine brauchbare Faustregel, aber nicht die ganze Geschichte. Komponenten haben auch dann einen konstanten statischen Stromverbrauch, wenn sie nur eingeschaltet sind.
      Deshalb nutzen moderne Embedded-Systeme oft Strategien wie "race-to-sleep" oder "race-to-halt": Die Arbeit wird sehr schnell erledigt, und danach werden die meisten Komponenten bis zum nächsten Ereignis abgeschaltet.
    • Ein Gerät hat auch dann einen grundlegenden Leistungs-Overhead, wenn es nichts tut. In Benchmarks zeigt sich ebenfalls, dass mit aktiviertem Turbo der Stromverbrauch um 10 % steigt, die Bootzeit aber um 11 % sinkt, sodass sich beim Gesamtenergieverbrauch ein kleiner, aber messbarer Unterschied ergibt.
    • Interessant, danke fürs Teilen.
      Wenn eine Berechnung, die 1 Sekunde dauert, 1 J benötigt – also zum Beispiel 1 W bei 1 GHz –, dann würde das in einem perfekten Kugelkuh-Modell wohl bedeuten, dass dieselbe Berechnung in 0,5 Sekunden 2 J braucht, also 4 W bei 2 GHz.
      Das betrachtet aber nur den CPU-Verbrauch. Wenn das Gesamtsystem zusätzlich einen festen Verbrauch von 4 W hat, dann kostet es bei 1 GHz insgesamt 5 J – 1 J für die CPU und 4 J für das System –, bei 2 GHz dagegen 4 J – 2 J für die CPU und 2 J für das System.
      Wenn ich das richtig verstehe, heißt das: Wenn der Gesamtstromverbrauch des Systems in etwa dem CPU-Verbrauch im Turbo-Modus entspricht, sollte man Turbo verwenden, sonst eher nicht?

  • Beeindruckend. Aber wann immer ich solche Beiträge lese, muss ich an die Aufnahme eines Plan-9-Boots auf einem Pi Zero denken: https://taoofmac.com/space/blog/2020/09/02/1900#resurrecting
    Das GIF zeigt die Ausgabe in Echtzeit.

    • Für sich genommen ist das cool.
      Aber ob sich die für das Projekt im Originalbeitrag nötigen Kamera- und Wi‑Fi-Treiber laden lassen, ist eine andere Frage.

  • Persönlich finde ich die Bootzeiten von Linux-Distributionen insgesamt ziemlich enttäuschend, und auf so schwacher Hardware fällt das noch viel stärker ins Gewicht.
    Ich habe ähnliche Optimierungen auch auf einem MQ-Pro SBC vorgenommen. Selbst auf Laptops merke ich das deutlich. Das MacBook ist vielleicht eine Ausnahme, aber insgesamt ist das einfach nervig.

    • Es hängt stark davon ab, wie man Bootzeit definiert. Windows optimiert zum Beispiel auf die Zeit bis zur ersten sichtbaren UI, lädt danach aber noch weiter, und der PC ist faktisch für einige Sekunden kaum benutzbar.
    • Mein M1 MacBook braucht beim Start um ein Vielfaches länger als mein Windows-Desktop-PC, obwohl beides noch im einstelligen Bereich liegt.
      Wenn es einmal läuft und man sich nur erneut anmeldet, geht es blitzschnell, aber ein Neustart dauert durchaus eine Weile.
    • Auch Linux kann ziemlich schnell booten, wenn man es passend konfiguriert. Ich habe dazu einmal etwas in [0] geschrieben.
      Distributionen bauen allerdings aus nachvollziehbaren Gründen sehr generische Kernel und initramfs, und diese Kombination ist beim Booten nicht besonders schnell.
      [0]: https://blog.davidv.dev/posts/minimizing-linux-boot-times/
    • Ich bin mir nicht sicher, wie viel Distributionen hier tatsächlich tun können. Die Bootzeit im User Space ist oft vernachlässigbar – sofern man keine schreckliche Fehlkonfiguration hat, bei der etwa NetworkManager 90 Sekunden lang auf ein nicht vorhandenes Wi‑Fi wartet. Mein Linux-Rechner braucht bis graphical.target etwa 4 Sekunden, und das meiste davon entfällt auf die Wi‑Fi-Verbindung und ntpd, beides prinzipiell optional.
      Wenn man wirklich maximale Bootgeschwindigkeit will, kann man Bootloader-Kompatibilitätsschichten, Abstraktionen, initramfs und andere dynamische Konfigurierbarkeit komplett aufgeben. Dann ist man aber vom Hardwareanbieter abhängig, und das ist es nicht wert.
    • Diese Aussage finde ich etwas merkwürdig. Bei mir bootet Linux selbst auf alten Maschinen und mit langsamen Speichergeräten sehr schnell.
      Auf meinem MacBook Air 11 mit Linux erscheint der Login-Screen zum Beispiel so schnell, dass ich die Bootmeldungen kaum sehen kann. Laut systemd-analyze sind es bis zum graphical target weniger als 4 Sekunden.
      Entscheidend scheinen mir zwei Dinge zu sein. Erstens nutze ich keine Desktop-Umgebung, sondern boote im Textmodus und starte bei Bedarf mit startx, oder ich boote mit einem schlanken Login-Manager wie lightdm direkt in X. Ohne Desktop-Umgebung sinkt die Zahl der Dienste um ein Vielfaches, was den I/O-Druck beim Booten auf alter Hardware stark reduziert. Selbst mit laufendem X bleibt das System unter 200 MB.
      Zweitens kann ein EFI-Stub den Start beschleunigen: https://wiki.archlinux.org/title/EFISTUB

  • Mein erster Gedanke war, ob man nicht einen anderen Core verwenden könnte. Braucht man für das Aufnehmen eines Fotos und das Hochladen in die Cloud wirklich Linux?
    Ich komme eher nicht aus der Hardware-Ecke, daher habe ich mich gefragt, wie man diese Aufgabe mit minimalem Budget umsetzen könnte. War ein interessanter Artikel.

    • Ich hatte anfangs genau denselben Gedanken.
      Liegt wohl auch nur daran, dass gerade zwei ESP32-CAMs auf meinem Esstisch liegen, aber ich habe mich gefragt, wie sich eine ESP32-CAM-Konfiguration im Vergleich schlagen würde. Wahrscheinlich wäre sie nur bis zu 2-Megapixel-Bildern brauchbar, aber Startzeit und Stromverbrauch dürften beide fast um eine Größenordnung niedriger liegen.
      Falls es jemanden interessiert, hier sind Details dazu: https://components101.com/modules/esp32-cam-camera-module
    • Das Problem bei diesem Projekt ist, dass es eine Kamera und ein drahtloses Netzwerk nutzt, und für beides sind ziemlich komplexe Treiber nötig.
      Prinzipiell ginge das auch Bare Metal, aber die erforderlichen Peripheriegeräte zum Laufen zu bringen ist nicht einfach.

  • Ich habe mich gefragt, warum ein Custom-Kernel erst so spät ins Spiel kam. Fängt man zum Optimieren nicht eher mit LFS oder einer quellbasierten Distribution an? Es scheint auch nicht so, als wären autonome Software-Updates für so ein Gerät unbedingt nötig.
    Außerdem habe ich mich gefragt, ob man bei so einem Gerät EFI/BIOS optimieren kann. Zumindest auf meinem normalen Arch-Linux-Desktop macht das einen beträchtlichen Teil der Bootzeit aus.
    $ systemd-analyze
    Startup finished in 10.076s (firmware) + 1.339s (loader) + 1.569s (kernel) + 2.974s (initrd) + 3.894s (userspace) = 19.854s

    • Das von ihnen verwendete Buildroot ist genau für so einen Zweck gedacht. In Buildroot konfiguriert man seine eigene „Distribution“ und erzeugt daraus ein einzelnes Boot-Image.
      Ich kenne die Raspberry-Pi-Hardware nicht im Detail, aber viele andere Embedded-SoCs haben einen ziemlich minimalistischen Bootloader auf Basis von u-boot und sind normalerweise sehr schnell. Vor allem dann, wenn die Verzögerung für das Warten auf Benutzereingaben auf 0 gesetzt ist.
    • In der Praxis würde man LFS wahrscheinlich nicht nach dem Handbuch des LFS-Projekts einsetzen wollen. Dafür müsste man einfach zu viel GNU kompilieren.
      Ein minimales Kernel- und BusyBox-System ist deutlich weniger schmerzhaft, und Gentoo wäre auch keine schlechte Wahl.
    • Das hat mir gezeigt, dass ich meinen Bootloader (systemd-boot) optimieren sollte und dass meine Firmware überraschend gut ist.
      > systemd-analyze
      Startup finished in 3.259s (firmware) + 35.127s (loader) + 1.823s (kernel) + 2.927s (userspace) = 43.138s

  • 3,5 Sekunden sind beeindruckend, aber wenn das Gesamtszenario wirklich darin besteht, sich alle paar Minuten mit Wi‑Fi zu verbinden und ein Bild hochzuladen, dann wäre ein ESP32 beim Stromverbrauch wohl die deutlich bessere Wahl gewesen.
    Es sei denn, man braucht auf dem Pi-Kameramodul zwingend bestimmte Funktionen, die es bei ESP32-CAM-kompatiblen Kameras nicht gibt.

    • ESP32 unterstützt nur PSRAM 4MB, aber schon ein einzelnes Standbild der RPi HQ Camera ist 18MB groß.
    • Ich könnte einen etwas leistungsfähigeren Mikrocontroller mit MIPI-CSI-Schnittstelle empfehlen, aber ansonsten stimme ich zu.
      Es wirkt so, als würde hier sehr viel Aufwand betrieben, um etwas zu tun, das ein Mikrocontroller fast mühelos erledigen könnte.