Firmware-Entwicklung für einen KI-entworfenen Computer: Vom Bootvorgang bis Google Meet (Teil 5/5)

Project Speedrun ist unsere Herausforderung, so schnell wie möglich einen kompletten Computer mithilfe unserer physikbasierten KI zu entwickeln. Diese Blogserie dokumentiert die Entwicklung des Systems und die technischen Entscheidungen dahinter. Beginnen Sie mit dem Überblick über Project Speedrun und seine Ergebnisse.

Die Teile 1 bis 4 befassten sich mit dem PCB-Design: Vorbereitung des Schaltplans, Ausführung von Quilter, Bereinigung der Ergebnisse und Validierung der Hardware unter realen Arbeitslasten. Beide Platinen kamen von Sierra Circuits zurück, ließen sich sofort einschalten und booteten beim ersten Versuch Linux.

Damit war bewiesen, dass das Layout funktionierte. Dieser Beitrag beschreibt, was nötig war, damit sich das Speedrun-Board wie ein echter Computer anfühlt.

Die Spezifikationen

Project Speedrun sollte nie nur ein Board hervorbringen, das elektrische Tests besteht. Das Ziel war, wie Sergiy es zu Beginn des Projekts formulierte:

„Es muss einen Desktop booten, Chromium ausführen und an einem Google Meet-Anruf teilnehmen können. Ich möchte eine Demo geben und am Ende sagen: ‚Oh, und übrigens, ich spreche gerade über diesen Computer mit Ihnen.‘“

Damit war die Messlatte klar definiert. Der Speedrun-Computer musste:

• Linux mit einer benutzerfreundlichen Desktop-Umgebung ausführen.
• Den Chromium-Browser mit hardwarebeschleunigter Videowiedergabe nutzen.
• An einem Live-Google Meet-Anruf mit Kamera und Audio teilnehmen.
• Wie ein Computer aussehen und funktionieren, den man tatsächlich benutzen möchte.

Keine dieser Anforderungen ist bei einem Quad-Core ARM Cortex-A53 mit einer Vivante GLES 2.0 GPU trivial. Jede einzelne erforderte fundierte Entscheidungen in der Firmware-Entwicklung.

Warum die Software für die Hardware-Geschichte entscheidend ist

Eine Leiterplatte, die den ersten Einschalt-Test besteht, ist ein notwendiger Meilenstein. Eine Leiterplatte, auf der ein Google-Meet-Anruf läuft, ist der Beweis dafür, dass das Layout unter dauerhaften, realen Bedingungen tatsächlich funktioniert: stabiler DDR4-Speicher bei voller Geschwindigkeit, zuverlässige USB- und MIPI-Schnittstellen, funktionierende Audiowege und ein Stromversorgungssystem, das auch unter Last stabil bleibt.

Jede in diesem Beitrag beschriebene Softwarefunktion beansprucht einen anderen Teil der von Quilter entwickelten Hardware. Der Chromium-Browser belastet das Speichersubsystem und die GPU-Schnittstelle. Video-Encoding und -Decoding fordern den VPU-Bus und die Stromschienen. Die Audiowiedergabe validiert das Codec-Routing. Selbst Doom, das wir teilweise aus Spaß hinzugefügt haben, beansprucht die GPU und den Framebuffer auf eine Weise, wie es ein einfaches Testmuster niemals könnte.

Die Firmware ist nicht von der Hardware-Validierung getrennt. Sie ist die Hardware-Validierung selbst.

Das Build-System: Yocto und das NXP BSP

NXP unterstützt den i.MX 8M Mini durch ein Yocto Board Support Package (BSP), das auf dem Walnascar-Release (6.12) basiert. Yocto ist das Standard-Build-Framework für eingebettetes Linux auf NXP-Anwendungsprozessoren. Es stellt ein vollständiges Linux-Image aus „Rezepten“ zusammen, die definieren, wie jedes Paket konfiguriert, gepatcht und kompiliert wird.

Das Standard-NXP-Image wird mit Weston als Compositor ausgeliefert, enthält Qt-Demo-Apps und verwendet RPM-Paketierung. Es ist darauf ausgelegt, die Funktionen des Siliziums zu demonstrieren, nicht als nutzbarer Desktop zu dienen. Um die Speedrun-Spezifikationen zu erfüllen, mussten wir den gesamten Desktop-Stack austauschen.

Dies erreichten wir durch die Erstellung eines benutzerdefinierten Yocto-Layers namens meta-quilter, der auf Priorität 99 gesetzt wurde, damit er die NXP-Standardeinstellungen überschreibt. Der Layer enthält alle Rezepte, Patches und Konfigurationen, die erforderlich sind, um das Standard-BSP in das Speedrun-Image zu verwandeln. Ein besonderer Dank geht an Brandin Claar von remodulate LLC für die Unterstützung bei der Zusammenstellung dieses Rezepts.

Hier ist eine Übersicht der Änderungen gegenüber dem Standard:

Fast jede Zeile in dieser Tabelle erforderte Patches, Konfigurationsanpassungen oder Workarounds für die Vivante-GPU. Das Standard-BSP ist auf den Weston-Compositor und die Demo-Anwendungen von NXP ausgelegt; der Betrieb eines vollständigen GNOME-Desktops geht daher weit über die Referenzkonfiguration hinaus.

Der Desktop: GNOME 48 auf einer Vivante-GPU

Wir haben uns für GNOME entschieden, weil es das ist, was die meisten Linux-Nutzer kennen. Eine Weston-Sitzung mit Terminalfenstern und Qt-Demos erfüllt nicht den Anspruch eines „Computers, den man tatsächlich benutzen möchte“. GNOME bietet eine Taskleiste, einen Dateimanager, eine Systemleiste und die Erwartung eines vertrauten Desktops.

Um dies zu erreichen, mussten wir ein echtes Problem lösen. Die Vivante GC NanoUltra unterstützt nur GLES 2.0, während Mutter (der Compositor von GNOME) in mehreren Codepfaden GLES 3.0+ voraussetzt. Frühere Builds mit Mutter 46 litten unter ständigem Bildschirmflackern, das durch Mutters Multi-GPU-Erkennung verursacht wurde. Der i.MX 8M Mini verfügt über eine geteilte DRM-Architektur: ein Gerät für den LCDIF-Display-Controller und ein weiteres für die Vivante-GPU. Mutter behandelte dies als Multi-GPU-System und konkurrierte ständig mit sich selbst, um zu entscheiden, auf welcher Karte gerendert werden sollte.

Das Upgrade auf Mutter 48, das Upstream-Triple-Buffering enthält, behob das Flackern. Doch der Betrieb von GNOME 48 auf GLES 2.0 erforderte dennoch eine Reihe gezielter Workarounds:

• Erzwingen der Nutzung des Cairo-Renderers für GTK4 anstelle des GL-Backends, da dieses GLES 3.0-Funktionen aufruft, die vom Vivante-Treiber nicht unterstützt werden.
• Explizite Konfiguration von COGL und Clutter für die Verwendung des GLES2-Treibers.
• Einschleusen eines EGL-Mesa-Stub-Header-Files in den Mutter-Build. Mutter 48 bindet bedingungslos einen Mesa-spezifischen Header ein, den Vivante EGL nicht bereitstellt.
• Lockern der Typkompatibilitätswarnungen in gnome-session, da sich die nativen EGL-Typen von Vivante von denen von Mesa unterscheiden.

Das Ergebnis ist ein reaktionsschneller GNOME 48-Desktop unter Wayland mit GLES2-Rendering. Sie melden sich über GDM an, öffnen einen Dateimanager, starten ein Terminal und interagieren mit dem System genau wie auf einem Standard-Linux-Desktop.

Die Herausforderung: Chromium und Hardware-Video

Chromium war das Herzstück der Speedrun-Spezifikation. Ohne ihn kann man an keinem Google Meet-Anruf teilnehmen, und die Mic-Drop-Demo funktioniert nicht.

Chromium auf dem Speedrun-Board zum Laufen zu bringen, war der einfache Teil. NXP stellt bereits 22 Patches im BSP für die V4L2-Videodekodierungspipeline von Chromium bereit, die Amphion- und Hantro-Dekoder, HEVC-Unterstützung, G2D-Integration und NV12-Zero-Copy abdecken. Mit diesen Patches läuft Chromium 129 auf Wayland/Ozone und kann Videos über die Hardware-Dekoder wiedergeben.

Doch die Videodekodierung ist nur die halbe Miete bei einem Videoanruf. Google Meet erfordert zudem, dass der lokale Kamera-Feed kodiert und an andere Teilnehmer übertragen wird. Das ist der Kodierungspfad, und dieser wird von den NXP-Patches nicht abgedeckt.

Der i.MX 8M Mini enthält einen Hantro H1-Hardware-Videokodierer, aber Chromium bietet keine integrierte Unterstützung für V4L2-Hardwarekodierung auf dieser Geräteklasse. WebRTC, der Echtzeit-Kommunikations-Stack von Chromium, verwendet standardmäßig Software-VP8- oder VP9-Kodierung. Auf einem Cortex-A53 mit 1,8 GHz ist die Software-Kodierung bei einer für Meetings geeigneten Auflösung zu langsam für den Echtzeiteinsatz.

Wir haben 3 benutzerdefinierte Chromium-Patches geschrieben, um dies zu lösen:

Patch 1: V4L2 MMAP Hardware-Kodierung. Dies ist der Haupt-Patch, der 8 Chromium-Quelldateien betrifft. Er zwingt V4L2 dazu, den MMAP-Speichertyp für den Hantro H1-Kodierer zu verwenden, fügt Stride-bewusstes Pufferkopieren hinzu, entfernt den VP9-Software-Kodierer, um die Auswahl des Hardware-Codecs zu erzwingen, priorisiert Hardware-Formate bei der WebRTC-Aushandlung und deaktiviert den Software-Fallback für niedrige Auflösungen, der sonst den Hardware-Pfad umgehen würde.

Patch 2: Codec-Debug-Flags. Fügt CLI-Flags wie --webrtc-disable-vp8 und --webrtc-disable-h264 hinzu, damit wir Codec-Probleme während der Entwicklung isolieren konnten. Wenn man bei der Fehlersuche herausfinden muss, warum ein Videoanruf Frames verliert, spart es Stunden, wenn man einen bestimmten Codec-Pfad erzwingen kann.

Patch 3: GLES 2.0 Null-Pointer-Fix. Die GPU-Erweiterungsaufzählung von Chromium ruft glGetStringi auf, eine GLES 3.0+-Funktion. Beim Vivante-Treiber ist dieser Funktionszeiger NULL. Chromium prüft nicht auf NULL, bevor es die Funktion aufruft, da es von GLES 3.0 als Minimum ausgeht. Unser Patch installiert bei der Initialisierung einen sicheren Stub. Der Fix musste in der Treiber-Bindungsschicht erfolgen, da Thin LTO über Kompilierungseinheiten hinweg inlined, was Schutzmaßnahmen an der Aufrufstelle wirkungslos macht.

Mit allen 3 angewendeten Patches läuft Chromium auf dem Speedrun-Board mit hardwarebeschleunigter Videodekodierung und -kodierung. Das Board kann an einem Google Meet-Anruf teilnehmen, Kameravideo übertragen und das Video der entfernten Teilnehmer empfangen – alles gerendert über die Hardware-Pipeline.

Boot-Sequenz und Branding

Wir wollten, dass sich das Speedrun-Board vom ersten Einschalten an wie ein fertiges Produkt anfühlt und nicht wie ein Entwicklungsboard mit einem zusammengebastelten Image. Die Boot-Sequenz spiegelt das wider:

U-Boot zeigt ein Quilter-Splash-Logo und gibt „Project Speedrun“ im Device-Tree-Modell-String aus. Der Kernel bootet im Hintergrund mit unterdrückter Konsolenausgabe und verzögerter Übernahme der Framebuffer-Konsole. Plymouth übernimmt nach U-Boot mit einer Ladeanimation und einem Quilter-Wasserzeichen auf dem DRM/KMS-Display. Schließlich präsentiert GDM einen Anmeldebildschirm. Der Standardbenutzer ist „speedrun“ und der Hostname lautet „speedrun“.

Diese Branding-Anpassungen erforderten den Austausch des U-Boot-Logos, die Modifikation des Device-Tree-Strings, eine Konfiguration der Kernel-Kommandozeile zur Unterdrückung von Meldungen und Aktivierung von Plymouth sowie systemd-Drop-ins zur Koordination der Übergabe zwischen Plymouth und GDM. Kleine Details, aber sie machen den Unterschied zwischen einer Demo und einem echten Produkt aus.

Der Spaßfaktor: Doom, Quake und Medienwiedergabe

Nicht alles auf dem Speedrun-Board ist zwingend notwendig. Einiges ist nur deshalb vorhanden, weil wir es konnten und weil es die Demo einprägsamer macht.

GZDoom mit Freedoom WADs. Eine vollständige Doom-Engine, die auf dem Vivante GLES2-Renderer läuft. Freedoom bietet Open-Source-Spielinhalte für Episode 1 und Episode 2. Wenn Ihr KI-entworfener Computer Doom ausführen kann, ist das ein Proof-of-Concept, der bei Ingenieuren gut ankommt.

Quake. Ein SDL-basierter GLES1-Port, der für die Kompatibilität mit GCC 14 gepatcht wurde. Ein weiterer Klassiker, der die GPU auf andere Weise fordert als Doom.

mpv und ffmpeg. Beide wurden mit V4L2 M2M-Hardware-Dekodierung erstellt, sodass die Hantro VPU die Videodekomprimierung übernimmt, anstatt CPU-Zyklen für die Software-Dekodierung zu verschwenden. mpv ist so konfiguriert, dass die OpenGL-API erzwungen wird, da der Vivante Vulkan ICD fehlerhaft ist.

Firefox 147. Ein vorinstalliertes ARM64-Binary, das neben Chromium bereitgestellt wird und dem System einen zweiten Browser für allgemeine Webanwendungen bietet.

PulseAudio. Audio-Unterstützung, konfiguriert für die EVK Line-Out-Buchse über den WM8524-Codec. Das Standard-BSP wird mit PulseAudio ausgeliefert, musste jedoch für GNOME erst aktiviert werden.

Erweiterung des BSP

Ein wesentlicher Teil der meta-quilter-Layer dient dazu, das BSP an einen Anwendungsfall anzupassen, für den es ursprünglich nicht konfiguriert war. Das ist bei der Entwicklung für eingebettete Linux-Systeme völlig normal. Die BSPs der Chiphersteller sind auf ihre Referenzkonfigurationen optimiert. Sobald man über diese Basis hinausgeht (etwa durch den Einsatz von GNOME anstelle von Weston), stößt man auf Annahmen, die angepasst werden müssen.

Einige Beispiele: Das Standard-BSP deaktiviert PulseAudio- und X11-Unterstützung in GTK3, da die Standard-Weston-Konfiguration diese nicht benötigt. Der Betrieb von GNOME erfordert die Reaktivierung beider Komponenten. Ein im BSP enthaltener systemd-Patch zielt auf eine ältere systemd-Version ab und steht im Konflikt mit 257.6. Die Prüfsumme einer Unicode-Lizenzdatei aus dem Upstream hat sich zwischen den Releases geändert. Die mitgelieferte Version von libdisplay-info ist älter als das, was Mutter 48 voraussetzt.

Die meta-quilter-Layer adressiert jeden dieser Punkte mit gezielten bbappend-Dateien. Zwei BSP-Quelldateien erfordern zudem direkte Patches, da sie den :remove-Operator von Yocto verwenden, der von einer nachgelagerten Layer aus nicht überschrieben werden kann. Die vollständige Liste der Anpassungen ist dokumentiert im GitHub-Repository.

Open Source

Das vollständige Firmware-Rezept ist öffentlich zugänglich. Das Repository enthält die meta-quilter-Yocto-Layer, alle benutzerdefinierten Patches, Build-Konfigurationsdateien sowie eine Schritt-für-Schritt-Anleitung für den Build-Prozess. Wenn Sie ein i.MX 8M Mini EVK (oder das Speedrun-Board) besitzen, können Sie das gesamte Image aus dem Quellcode reproduzieren.

Repository: https://github.com/xjordanx/speedrun

Wir haben dies aus demselben Grund veröffentlicht, aus dem wir auch die PCB-Designdateien für Speedrun bereitstellen: Transparenz schafft Vertrauen. Ingenieure können die Firmware genauso prüfen wie das Layout. Jeder Patch, jeder Workaround und jedes Build-Flag ist einsehbar.

Was die Software über die Hardware beweist

Die Teile 1 bis 4 dieser Serie dokumentierten einen Layout-Prozess, der 428 veranschlagte Stunden auf 38,5 Stunden menschlichen Arbeitsaufwands komprimierte. Das ist die Geschichte der Effizienz. Dieser Beitrag ist die Geschichte der Leistungsfähigkeit.

Das Speedrun-Board betreibt einen GNOME 48-Desktop mit hardwarebeschleunigtem Chromium, nimmt an Live-Videoanrufen teil, spielt Doom, dekodiert Videos über die Hardware-VPU und streamt Audio via Bluetooth. All das leistet es auf Boards, die von Quilter entworfen, bei Sierra Circuits gefertigt und beim ersten Anlauf erfolgreich gebootet wurden.

Nichts davon würde funktionieren, wenn das zugrunde liegende Layout Probleme mit der Signalintegrität, der Stromversorgung oder Routing-Fehler bei den Hochgeschwindigkeitsschnittstellen aufweisen würde. Die Firmware ist nicht nur eine Ebene über der Hardware-Geschichte. Sie ist der ultimative, anspruchsvollste Test dafür, ob das KI-entworfene Layout tatsächlich hält, was es verspricht.

Das tut es.