FenrirOS auf PowerPC – ein NAS von 2013 bootet unser System
Ein alter NAS-Mainboard mit Freescale P1010, ein Hersteller-U-Boot aus dem Jahr 2013, kein Debug-Komfort, und am Ende läuft FenrirOS mit RPM, dnf5, webctl und eigenem Bootloader aus dem NAND. Ein Bericht über eine Portierung, bei der fast jeder Schritt eine Überraschung bereithielt.
Bisher lief FenrirOS nur auf x86_64. Das Inventronics NAS ITX ist das genaue Gegenteil: ein 32-Bit-PowerPC, Big Endian, ohne Gleitkomma-Einheit im üblichen Sinn, mit MLC-NAND statt SSD. Wer ein Betriebssystem samt eigener C-Bibliothek auf so ein Board bringt, findet heraus, welche Annahmen sich still in den Code geschlichen haben.
🧠 Prozessor
Freescale P1010, e500v2-Kern mit 800 MHz, 32 Bit, Big Endian, Soft-Float.
💾 Speicher
2 GiB DDR3, 4 GiB MLC-NAND (Micron), zwei SATA-Ports über SiI-Port-Multiplier.
🔌 Rund ums Board
Zwei Gigabit-PHYs (Lantiq PEF7071), keine Echtzeituhr, ein PIC16F506 regelt Spannungen und Reset.
Erst die C-Bibliothek
FenrirOS baut auf systempp auf, unserer eigenen C- und C++-Laufzeit. Der Schritt nach PowerPC hieß: 32-Bit-Zeiger, aber 64-Bit-
time_t und Dateigrößen, Thread-Local-Storage nach Variante I, Secure PLT, Systemaufrufe über zwei Register pro 64-Bit-Argument. Unter qemu-ppc laufen inzwischen alle 155 End-to-End-Tests.Spannender waren die Fehler, die auf x86 nie auffallen konnten:
Der Kernel und das MLC-NAND
Linux 7.3 wird mit Clang und LLD gebaut. Weil der Hersteller-Bootloader den Speicher erst ab 0x40000000 einblendet, startet auch der Kernel dort. Das NAND ist MLC-Flash, und das will UBI eigentlich gar nicht: Ein kleiner Kernel-Patch (
ubi.allow_mlc=1) erlaubt es, und UBIFS hat die uid_r-Unterstützung bekommen, damit Dateien Benutzern mit UUID gehören können – wie bei ext4 und ksmbd unter FenrirOS.Kernel und Device Tree reisen als ein Multi-Image. Dabei gab es eine schöne Falle: libfdt verlangt, dass der Device Tree auf einer 8-Byte-Grenze liegt. Ob das passt, hängt davon ab, wie groß der komprimierte Kernel zufällig ist. Mit dem einen Kernel bootete das Board, mit dem nächsten „fand“ der Bootloader keinen Device Tree mehr.
Ein Bootloader ohne Autostart
Der Hersteller-U-Boot von 2013 hatte einen Haken: Autoboot ist schlicht nicht einkompiliert. Das Wort „bootdelay“ kommt im ganzen Binary nicht vor. Also bekam das Board unseren eigenen U-Boot 2027.01 – nicht an Stelle des Herstellers, sondern dahinter: Sein NAND-Lader richtet weiterhin den Speicher ein, danach übernimmt unser U-Boot mit Countdown, Netzwerk und Autostart von FenrirOS.
Bis das lief, war es Detektivarbeit, Zeichen für Zeichen über die serielle Konsole:
- Der Startcode schrieb einzelne Ziffern direkt in den UART, um zu sehen, wie weit er kommt. Einmal blieb er hängen, weil ein übrig gebliebener TLB-Eintrag des alten Bootloaders virtuell 0x41000000 auf physisch 0x40000000 abbildete.
- Der Device Tree von U-Boot kannte schlicht keinen UART – ohne den gibt es keine Konsole.
- Eine harmlos wirkende Prüfung vor der Relokation schrieb in den BSS-Bereich, und genau dort liegt in dieser Phase der Device Tree.
- Von den beiden SATA-Port-Multipliern lief nur einer. Die Reset-Leitungen sitzen auf vier GPIOs, die paarweise gepulst werden wollen – herausgefunden durch Disassemblieren des Hersteller-Codes.
Gebrickt – und per JTAG gerettet
Einmal ging es schief: Die neue U-Boot-Version lag im NAND und meldete sich nicht mehr. Der Hersteller-Lader verschiebt die Register-Basis (CCSR) nicht, unser U-Boot ging aber davon aus. Das Board war stumm.
Zurück ging es über einen USB-Blaster und JTAG-Boundary-Scan: Der Prozessor wird dabei nicht benutzt, die NAND-Leitungen werden direkt Bit für Bit gesteuert. Das Problem: So geschriebene Daten haben keine ECC, und der Boot-Lader im Chip prüft sie. Statt Widerstände auf das Board zu löten, haben wir die ECC des NAND-Controllers nachgebaut. Aus korrekt geschriebenen Seiten ergab sich: BCH mit t=8 über GF(2^13), Polynom 0x201b. Alle 1024 Sektoren stimmten Byte für Byte. Neun Minuten später war Block 0 neu geschrieben, das Board lief wieder.
Ein vollwertiges FenrirOS
Auf dem NAS läuft kein Spar-System, sondern dasselbe FenrirOS wie auf x86: aus RPMs gebaut und mit dnf5 aktualisierbar. Über 80 Pakete werden auf dem x86-Rechner mit dem normalen
rpmbuild und einer Cross-Toolchain für PowerPC übersetzt.📦 Kernel als RPM
kernel-nas-itx schreibt sein Boot-Image bei der Installation selbst ins NAND, mit flash_erase und nandwrite aus den neuen mtd-utils.🔐 SSH
OpenSSH auf PowerPC fand zwei Fehler: eine fest eingetragene x86-Architektur in der Sandbox und einen Fehler in OpenSSH selbst, der
futex_time64 blockiert.🛠️ LLVM 23
clang, lld und llvm-tools gibt es für PowerPC im Repository, mit den e500-Einstellungen als Standard. Sie sind nicht vorinstalliert.
🐳 Container
Die Images
fenriros und fenriros-devel gibt es jetzt auch für linux/ppc. containerd lehnt Images einer fremden Architektur ab.🏪 FenStore
Der App-Katalog nennt die Plattformen jeder App, damit ein PowerPC-NAS nur angezeigt bekommt, was darauf läuft.
⏰ Ohne Echtzeituhr
Das Board startet mit einer Uhrzeit weit in der Vergangenheit. syslite merkt sich die Zeit jetzt und stellt sie beim Start vor, sonst gelten Zertifikate als noch nicht gültig.
Was noch fehlt
Die Portierung ist ein großer Schritt, aber noch nicht fertig.
Ein alter NAS, ein neues Leben 🐺
Fragen, Ideen und Fehlerberichte bitte an: jan.koester@tuxist.de
Comments
No comments yet.
Leave a comment