Os

Es ist schon fast ein Jahr her, als ich über den aktuellen Stand von RISC OS 5.xx auf dem Raspberry Pi 4 berichtet hatte. Damals noch sehr rudimentär ausgeprägt, zwar lauffähig aber wegen unvollständiger USB-Unterstützung fingen die Probleme schon bei der Stromversorgung an.

Die meisten der unvollständigen Dinge wurden schon mit RISC OS 5.28 gelöst – USB tut nun ohne Tricks, d.h. man kann USB-C wie gedacht für die Stromversorgung nutzen und die “normalen” USB-Ports eben für USB. Auch das Ethernet ist inzwischen stabil und auch recht schnell, und die 4 GiB-Variante funktioniert nun auch problemlos. Selbst die 8 GiB-Variante tut nun, aufgrund seiner 32bit-Natur kann RISC OS aber in Ermangelung einer Unterstützung der Aarch32-“Large Physical Address Extension”-Technik nur 4 GiB nutzen. Fehlt also nur echte USB3-Unterstützung, aber da braucht es wohl das Großreinemachen im USB-Stack (also z.B. die Neuportierung des aktuellen BSD-Stacks, wie in diesem ROOL-Bounty skizziert).

Kurz nach dem Release von 5.28 kam dann die Raspberry Pi Foundation um die Ecke mit ihrer neuesten Kreation, dem Raspberry Pi 400. Erstmalig eine Abkehr des Konzepts “nackte Platine, der Rest findet sich”. Das hatte sich ja schon abgezeichnet, gibt es doch inzwischen ein “offizielles Netzteil”, ein “offizielles Gehäuse”, eine “offizielle Tastatur” und eine “offizielle Maus”. Wenn man das jetzt alles kombiniert und im Hinterkopf behält, warum seit der ersten Variante des Raspberry Pi es ein “Model A” und ein “Model B” gibt – fertig ist das neue Produkt “Raspberry Pi 400 Kit”. Man könnte es die “jüngste Hommage an die große Zeit der 8/16-Bit-Heimcomputer” nennen. Oder auch der 32bit-Heimcomputer, wenn man an den Acorn A3010 oder 3020 denkt.

Wer es nicht mitbekommen hat: der Pi 400 ist im Prinzip ein Pi 4 in der 4 GiB RAM-Variante in einem kompakten Tastaturgehäuse. Alle Anschlüsse befinden sich auf der Rückseite, der analoge Soundausgang ist weggefallen, sonst alles da – vom GPIO über die 2 microHDMI bis zum Ethernet. Und nur 3 statt 4 USB-Buchsen, weil die Tastatur ist ja schon integriert. Auch die microSD-Karte wird hinten eingesteckt, und endlich mal wieder mit einem vernünftigen Feder-Slot-Mechanismus wie es zuletzt beim RPi B+ zu finden war. Dank der intern verbauten Kühlbleche konnte man den Takt etwas höher ansetzen, 1,8 GHz gegenüber 1,5 GHz. Man kann den 400 in zwei Varianten kaufen, als nacktes Gerät oder als “Kit” inklusive gedrucktem Einsteiger-Handbuch, Netzteil, microSD-Karte mit vorinstalliertem Raspbian und microSD-SD-Adapter mit Raspberry Pi-Logo, microHDMI-Kabel und der bekannten himbeerrot-weißen USB-Maus. Verschiedene lokalisierte Varianten sind verfügbar, was bei einer integrierten Tastatur ja auch eine gute Idee ist. Ich habe mich für die DE-Variante entschieden.

RISC OS Open Ltd. hat kurz nach Weihnachten verkündet, dass es eine entsprechende Distribution von RISC OS Pi auf Basis eines leicht aktualisierten RISC OS 5.28 mit einem fancy pinboard backdrop zur Verfügung steht – und das auch über den offiziellen Raspberry Pi Imager. D.h. der RISC OS-Installationsvorgang kann über einen PC der Wahl über den Imager mit wenigen Clicks erfolgen. Das habe ich tatsächlich mal ausprobiert, und es funktioniert völlig problemlos. Profi-Tipp: Linux herunterfahren, Karte tauschen und wieder die Power-Taste drücken reicht nicht, vermutlich weil der Rechner nur in einer Art Standby-Modus ist. Man muss das Dingens kurz stromlos machen, dann wird die RISC OS-Karte klaglos akzeptiert.

Leider haben die fertigen Images den Makel, dass sie die Kapazität der microSD-Karte in keinster Weise ausnutzen können – es bleibt stets bei der vom Image vorgedachten Größe, im vorliegenden Fall knapp 2 GiB. RISC OS unterstützt noch immer keine echten Partitionen (sonst könnte man ja den restlichen Platz einfach als zweite Partition einrichten), und das Filecore-Format ist der Alptraum einer jeden Partition-Resizer-Anwendung, weshalb es schlicht keine gibt. Deshalb taugt aus meiner Sicht für RISC OS im Moment weiterhin nur das Vorgehen “von Hand”: vorhandenen Pi mit RISC OS drauf nehmen, microSD-Karten-Leser und leere große microSD-Karte, SystemDisc, microSD entsprechend einrichten (ich empfehle einen großen FAT-Bereich, den kann man prima für Datentransfer mit anderen Betriebssystemen nutzen, solange das Netzwerk noch nicht funktioniert), config/txt und cmdline/txt anpassen, HardDisc4-ZIP entpacken. Wie immer hatte ich bei meinem Setup wenig Glück mit EDID und der RISC OS-Idee der automatischen Bildschirmerkennung, und so konfiguriere ich den richtigen Bildschirmmodus immer fest in die config/txt und verwende disable_mode_changes, weil das für ADFFS in Verbindung mit AnyMode der viel problemlosere Betriebsmodus ist.

Die “Power”-Funktion über die Tastatur (Fn + F10) erfordert übrigens die Mitarbeit des Betriebssystems, unter RISC OS gibt es hier noch keine Unterstützung. Schade, Shutdown mit nachfolgendem Power-Off wäre schön.

Auch in die Raspbian-Distribution – inzwischen “Raspberry Pi OS” genannt – habe ich einen Blick geworfen, finde es aber nach wie vor für ein Massenprodukt erstaunlich unrund, was hauptsächlich zu merken ist, wenn man “Deutsch” als Sprache auswählt. Denn auch danach geht es erschreckend oft in Englisch weiter. Ganz gut gelungen ist hingegen die deutsche Übersetzung des dem “Kit” beliegenden Einsteiger-Handbuchs (auch wenn ich nie auf die Idee gekommen wäre, das urdeutsche Wort “Overscan” durch “Übertastung” zu ersetzen). Interessierte können es als PDF runterladen, dafür muss man nicht das “Kit” kaufen. Man beachte, dass auch viele der Screenshots die jeweilige deutsche Version zeigen, da hat jemand mitgedacht und mit Plan gearbeitet. Wenn jetzt noch jemand ein entsprechendes Handbuch, angepasst an RISC OS und mit BBC BASIC-Beispielen schreiben würde…

Und die Hardware? Macht alles einen recht soliden Eindruck. Die Tastatur ist Laptop-artig mit hartem Anschlag und kurzen Tastenwegen, jedoch für meinen Geschmack etwas zu steil im Winkel angestellt – aber klar, irgendwo muss ja auch die Hauptplatine hin. Es ist ein sehr kompaktes Layout, und für RISC OS-Zwecke nervig, da es nur Platz für 10 F-Tasten hat und so die oft genutzte F12-Taste nur per Modifier (hier “Fn” genannt, in Kombination mit F2 ergibt sich dann die F12-Taste) zugänglich ist. Aber immerhin wird das Auge nicht durch ein Windows-Logo beleidigt, denn dort befindet sich logischerweise die allseits beliebte Himbeere. Die Maus ist im besten Sinne unspektakulär, höchstens das etwas kurze Kabel könnte nervig sein. Die microSD-Karte ist ein Markenprodukt von SanDisk, stellt aber keine Geschwindigkeitsrekorde auf. Das Netzteil funktioniert wie zu erwarten prima, genau wie das (auch eher kurze) microHDMI-HDMI-Kabel.

Ist der Pi 400 – ob nackt oder als “Kit” – nun sein Geld wert? Das muss jeder selbst entscheiden, der Aufpreis gegenüber der nackten 4 GiB-Platine hält sich schließlich in Grenzen. Wer wie ich das Basteln gewöhnt ist, und wenn das Rechner-Setup rund um einen KVM-Switch gebaut ist und deshalb die integrierte Tastatur keinen Vorteil darstellt – nun gut, wie gesagt der Aufpreis hält sich in Grenzen, und wenn man den Rechner “mal schnell” woanders mit hinnehmen will, ist das All-in-one-Design vielleicht doch von Vorteil. Schade ist aus meiner Sicht, dass man den neu gewonnenen Platz nicht dafür genutzt hat, die frickeligen microHDMI-Ports durch ihre Full-Size-HDMI-Pendants zu ersetzen. Man muss nicht jeden Holzweg konsequent zu Ende gehen – bei der nacken Pi4-Platine gab es immerhin noch die “wir hatten keinen Platz”-Ausrede.

Vielleicht passt eines der neueren Pi 4-Gehäuse besser zu meinen Ansprüchen – liegt inzwischen mit allen notwendigen Materialien hier rum und wartet auf Zusammensetzung: ein Alu-Gehäuse mit USB3-M.2-SATA-Adapter und Power-Taster namens “Argon One M2”, ein Pi 4 in der 8 GiB-Variante, und eine Samsung M.2-SATA-SSD mit 512 GiB die hoffentlich gut ins Gehäuse passt. In diesem Falle ein Gehäuse mit zwei Full-Size-HDMI-Buchsen, dazu ein eingebauter IR-Sensor, ein softwaresteuerbarer Lüfter, und der analoge Soundausgang bleibt auch erhalten. Dazu eine recht intelligente Lösung für die GPIO-Pins. Vielversprechend.

Nachdem nun schon Aemulor in einer RPi 4-kompatiblen Version verfügbar ist, wie steht es derzeit denn um RISC OS selbst auf dieser vielversprechenden Plattform?

Zunächst eine kurze Zusammenfassung, warum man überhaupt einen RPi 4 haben will gegenüber einem seiner zahlreichen Vorgängern. Die CPU ist deutlich schneller, sowohl pro Takt als auch im Maximaltakt, und die Caches sind größer. Speicher ist deutlich schneller und bis zu 4 GiB groß (das vermutlich wichtigste Feature für die Linux-Jünger, und das vermutlich unwichtigste Feature für RISC OS-Nutzer). Gigabit Ethernet über einen schnellen internen Bus. USB3 über PCIe. Offizielle Unterstützung für 4K@60Hz-Bildschirmauflösung (früher war das eher Glücksache @30Hz). Dual-Head-Unterstützung.

Schon der derzeitige Zustand von RISC OS zeigt deutliche Fortschritte in den Benchmarks. Man darf sich also nicht nur auf theoretische Performancegewinne freuen, sondern tatsächlich auf spürbare Verbesserungen in der Praxis. Die CPU liegt auf einem Niveau mit den bisher schnellsten RISC OS-tauglichen Boards mit TI OMAP5 (Cortex-A15-Basis – Titanium und IGEPv5). An der Grafikbeschleunigung lässt sich sicher noch arbeiten, aber das ist “nur” eine Softwarefrage.

Und wie weit ist diese Praxis nun noch entfernt? Es fehlt prinzipiell an zwei Dingen: USB3 und Ethernet. D.h. man kann sich heute “from source” ein RPi 4-kompatibles ROM bauen, aber man muss Ethernet über das alte USB2.0 anbinden, ebenso wie zusätzliche Massenspeicher jenseits des microSD-Slots. Das ist aber nicht ganz einfach, weil alle “normalen” USB-Ports des Boards über den kombinierten USB3/USB2-Chip (VIA VL805) gehen, für den es eben noch keinen Treiber gibt. Das alte USB2.0 ist nur über den USB-C OTG verfügbar, über den auch die Stromversorgung normalerweise läuft. Deshalb sind bei der Inbetriebnahme noch ein paar Handstände vonnöten, beispielsweise indem man die GPIOs für die Stromversorgung nimmt und den USB-C stattdessen als USB-Port statt zur Stromversorgung.

Wer eher Code-affin ist, kann hier in Gitlab die Entwicklung nachverfolgen. Wer eher auf verständlichere Prosa setzt, verfolgt die Entwicklung im ROOL-Forum oder schaut sich den Port-Status im ROOL-Wiki an.

Bleibt noch die Frage: warum dauert es denn nun so lange? Da gibt es eine Vielzahl an Gründen. Beispielsweise hatte RISC OS bisher keinen XHCI-USB-Treiber (für USB3). Beispielsweise ist die Memory Map für die 4-GiB-Variante zu berücksichtigen (alle bisherigen 4 GiB-Plattformen hatten die “oberen” 2 GiB außerhalb des 4 GiB-Adressbereichs). Beispielsweise sind die Datenblätter bis heute nicht in der notwendigen Ausführlichkeit zu haben. Beispielsweise scheint es im PCIe-Bereich interessante Bugs in der Pi-Firmware gegeben zu haben. Selbst die Aktivierung des UARTs für serielles Debugging gestaltete sich als schwierig. Letztlich also eine ungewöhnliche Anzahl von nicklichen Detailproblemen, die dem geneigten Entwickler den Tag vermiesen. Aber wenn ich die Commits richtig deute, ist die Zielgerade nicht mehr weit entfernt.

Und dann wird es spannend, inwiefern RISC OS ebenfalls – vor allem in schlecht kühlbaren Gehäusen – in “thermal throttling”-Probleme laufen wird, die so manchem experimentierfreudigen RPi4-Besitzer fast schon klassisches PC-Feeling inklusive Lüfter eingebrockt hat. Gut gekühlt kann der RPi4 wohl durchaus 2 GHz und mehr ab, bei Einsatz aller 4 Cores. Ungekühlt in den üblichen beinahe dichten Plastikgehäusen könnte es eher schwierig werden mit den neuen Performance-Höhen.

Zum Pi-Day (14.3. – mathematisch vorgebildete Leser müssen die englische Datumsnotation berücksichtigen, um den Gag zu kapieren, alle andern müssen zusätzlich Pi auf zwei Nachkommastellen genau kennen) hat die Raspberry Pi Foundation mal wieder nachgelegt und eine neue Modellvariante des allseits beliebten “SBC” auf den Markt geworfen. Gegenüber dem Vorgänger hat sich der maximale Takt leicht von 1,2 GHz auf 1,4 GHz erhöht, der SoC hat einen metallischen Headspreader bekommen um die Wärme besser abführen zu können, WLAN wurde verbessert indem ac unterstützt wird und auch das 5 GHz-Band bedient wird, und es ist nun endlich Gigabit Ethernet an Bord – da gibt es zwar den kleinen Haken, dass es intern weiterhin am USB2.0 hängt und damit physisch auf 480 MBit/s abzüglich USB-Protokolloverhead abzüglich der Bandbreite anderer angeschlossener USB-Geräte limitiert ist, aber nichtsdestotrotz sind die erreichbaren Übertragungsraten dadurch trotzdem deutlich höher als zuvor.

Seit wenigen Tagen gibt es nun im RISC OS-Nightly-Build die erweiterte Version von EtherUSB, die in der Lage ist den Netzwerk-Chip korrekt anzusteuern. Gelegenheit für mich, eine frische RISC OS-Version auf die Pis zu bringen und gleichzeitig mich mal um die passende Ansteuerung meines nagelneuen 4K-Monitors (iiyama G-MASTER GB2888UHSU-B1, ein 28-Zöller mit besagten 3840×2160 Pixeln Auflösung).

4K ist leider keine Auflösung, die der Pi “einfach so” kann, da muss man frickeln. Außerdem hatte ich noch kein passendes MDF für die RISC OS-Seite, und dann war da noch die potenzielle Problematik inwiefern die HDMI-Kabel das mitmachen und inwiefern der HDMI-Switch (nominell 4K-fähig) in die Suppe spuckt.

Der HDMI-Switch machte keine Probleme, die Kabel konnten es ebenfalls, und so präsentiere ich hier nun den 4K@24Hz MDF-Eintrag, erzeugt mit Chris Gransdens Portierung von cvt http://www.riscosports.co.uk/cvt.zip, der zusätzlich MDF-Einträge erzeugen kann (läuft offenbar noch nicht auf dem Pi 3):

# 3840 x 2160 (24.00Hz) Reduced Blanking (CVT)
startmode
mode_name:3840x2160 CVT
x_res:3840
y_res:2160
pixel_rate:209750
h_timings:32,80,0,3840,0,48
v_timings:5,17,0,2160,0,3
sync_pol:3
endmode

Damit der Pi diese Auflösung kann, muss man folgendes in die config.txt bringen (komplette für RISC OS geeignete config.txt, nicht nur die für 4K notwendigen Teile!):

fake_vsync_isr=1
init_emmc_clock=100000000
kernel=RISCOS.IMG

# needed for correct RGB ordering for RISC OS
framebuffer_swap=0

# disable overscan
disable_overscan=1

# Ignore EDID
hdmi_ignore_edid=0xa5000080

# no disabling of HDMI in DPMS mode
hdmi_blanking=0

# 1 = DVI, 2 = HDMI (with sound)
hdmi_drive=2

# 0-11 - 5 is default, try 7 if interferences are seen
config_hdmi_boost=5

# force HDMI screen mode
# group=0: EDID auto detect, group=1: CEA, group=2: DMT
hdmi_group=2

# screen mode
# CEA modes:
# 16 = 1920x1080@60
# 16,31,32,33,34 = 1920x1080@60,50,24,25,30 Hz
# DMT modes:
#  4 = 640x480@60 Hz
#  9 = 800x600@60 Hz
# 16 = 1024x768@60 Hz
# 77 = 2560x1600@60 Hz
# 84 = 2048x1152 reduced blanking
# completely custom mode definition:
# hdmi_cvt=<width> <height> <framerate> <aspect> <margins> <interlace> <rb>
# margins=0 no margins, 1=margins
# aspect=3 16:9, 1 4:3, 5 16:10
# interlace=0 progressive
# rb=1 reduced blanking
# hdmi_mode=87 selects this custom mode for DMT, 65 for CEA
hdmi_cvt=3840 2160 24 3 0 0 1
hdmi_mode=87

# special timings - sometimes needed for specific monitor needs if generic CVT does not work
# hdmi_timings=<h_active_pixels> <h_sync_polarity <h_front_porch> <h_sync_pulse> <h_back_porch> <v_active_lines> <v_sync_polarity> <v_front_porch> <v_sync_pulse> <v_back_porch> <v_sync_offset_a> <v_sync_offset_b> <pixel_rep> <frame_rate> <interlaced> <pixel_freq> <aspect_ratio>
hdmi_timings=3840 1 48 32 80 2160 1 3 5 54 0 0 0 24 0 211190000 3

# only provide the modes specified above
hdmi_force_mode=1

# force larger framebuffer - includes possible overscan!
framebuffer_width=3840
framebuffer_height=2160
max_framebuffer_width=3840
max_framebuffer_height=2160

# pixel frequency limit
hdmi_pixel_freq_limit=400000000

# GPU memory in megabytes, default is 64, minimum is 16
gpu_mem=64

# Set USB power limit to 1,2A for all ports
max_usb_current=1

Es gibt keine Garantie, dass der Pi das abkann. Es gibt Berichte im Netz, dass man das Dingens zusätzlich übertakten muss, sowohl CPU als auch GPU. Bei mir war das im Falle des Pi 3B+ nicht notwendig, bei den anderen Modellen steht der Test noch aus.

Und dann noch für unfallfreie ADFFS-Anymode-Unterstützung folgendes in die cmdline.txt:

disable_mode_changes

Mit diesem Eintrag nagelt man den Pi-Videooutput auf genau eine Auflösung fest und überlässt dem Videoscaler des Pi die Anpassung der RISC OS-Auflösung an die Hardware-Auflösung.

4K ist echt super…auf 28″ vielleicht ein wenig klein, aber ich bin ja noch jung 🙂 Mit demselben MDF-Eintrag kann übrigens auch der ARMX6 (Wandboard Quad) 4K@24 Hz.

Inwiefern höhere Bildwiederholraten funktionieren, muss ich noch prüfen. In Zeiten von LCDs ist deren Nützlichkeit ja aber eher begrenzt, solange der Monitor es syncen kann, da scheint der Iiyama sehr flexibel.