Os

Entwicklungen im Betriebssystem selbst

RISC OS 5.24 ist da

Ich bin etwa 2 Wochen zu spät dran, RISC OS 5.24 wurde zur Wakefield-Show veröffentlicht. Aber besser spät als nie…hier das Original-Announcement von RISC OS Open Ltd.

Eine Menge Neues gibt es in RISC OS 5.24 (hier die Liste stellvertretend für die OMAP4-Plattform) – natürlich nicht für diejenigen, die öfter mal eine der Entwicklungsversionen mit Namen 5.23 verwenden, aber gegenüber der letzten Release-Version 5.22 ist der Fortschritt natürlich erheblich. Während 5.22  noch auf IOMD (Risc PC, A7000(+)), IYONIX, BeagleBoard (OMAP3) und PandaBoard (OMAP4) beschränkt war, gibt es 5.24 nun als offizielles Release auch für die diversen Raspberry Pi-Modelle sowie das Titanium-Board. Wandboard und OMAP5 (IGEPv5) haben es nicht ganz geschafft, aber CJE Micro’s (Rapido-Ig, also IGEPv5) und R-Comp (ARMX6, also Wandboard) haben für ihre Kunden natürlich eine Distribution äquivalent zu 5.24 auf Lager.

Kurz aus meiner Sicht die Highlights:

  • High-Vector-Konfiguration ist jetzt Standard, aus Kompatibilitätsgründen gibt es eine “compatibility page” anstelle der ZeroPage. Entwickler können weiterhin ZeroPain verwenden, um aussagekräftige Logs zu erhalten bei ZeroPage-Zugriffen
  • EDID-Unterstützung
  • 4K-Sektor-Unterstützung in FileCore für bis zu 2 TiB pro Partition
  • ARMv6/v7/v8- und VFP-Befehle in BASIC
  • diverse Verbesserungen für den UTF-8-Betrieb (!Chars, !Draw)
  • RAM-Disc-Größe bis 512 MiB
  • SpriteExtend unterstützt moderne JPEGs (und ChangeFSI ebenfalls)
  • OmniClient komplettiert durch den alten NFS-Kern und den nicht ganz so alten Access-Kern, so dass “Omni” nun wieder besser als Name passt
  • ein aktualisiertes Handbuch (der “User Guide”)

Vermutlich am Wichtigsten ist aber, dass es endlich nach der langen Zeit der Release Candidates für den Pi nun wirklich eine als stabil gekennzeichnete RISC OS-Version gibt – das wird es hoffentlich ermöglichen, wieder Teil des NOOBS-Images zu werden.

Jetzt werde ich nach und nach meine Systeme aktualisieren – die RPis, ARMX6, Titanium, PandaBoard ES, BeagleBoard-xM und BIK, IYONIX, RPCEmu und vielleicht teste ich auch auf einem der Risc PCs mal den Softload. Leider gibt es ja keine 32bit-Treiber für den ViewFinder, was die Nützlichkeit der Risc PC-Version für meine Zwecke doch ziemlich einschränkt.

Raspberry Pi 3 B+, 4K und RISC OS

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.

Neu im RISC OS-CVS: ADFS-Patches, OmniNFS, EtherUSB, VFP

Auch in 2018 habe ich ein Auge auf das ROOL-CVS-Repo, weil man dort aus den Commit-Kommentaren und den geänderten oder hinzugefügten Sources recht gut ablesen kann, wo in der RISC OS-Welt (m Sinne von Kern-OS) gerade Hand angelegt wird.

ADFS wurde gepatcht, um etwas unempfindlicher gegenüber neueren Devices zu sein – bekanntlich scheren sich viele Geräte nicht um Standards, vor allem nicht um veraltete wie den ATA-Standard aus der Zeit von PIO-Mode 0. Der Patch basiert auf Vorarbeiten und -Analysen von Jon Abbott mit RISC OS 3.1 und dem ewigen Rätsel, warum in A3020/A4000/A5000 das ADFS so wählerisch mit vielen CompactFlash-Karten und manchen Platten ist, während 3rd-party-IDE-Podules damit eher weniger Probleme haben. DRQ-Timeout-Handling ist das Stichwort. Jedenfalls steht jetzt ein ROMPatch für die ADFS-Versionen von RISC OS 3.50 bis 4.02 zur Verfügung.

Der NFS-Client für OmniClient wurde wiedererweckt – vermutlich ist jemand über eine Diskette mit Quellcode von 1992 gestolpert…alle normalen Menschen verwenden seit Urzeiten ImageNFS und etwas später dann Sunfish als NFS-Client.

Das EtherUSB-Backend für den Pegasus-Chipsatz wurde gefixed, da gab es seit dem letzten EtherUSB-Update Probleme. Wenn ich mich recht erinnere, betraf das u.A. das BeagleBoard-xM. Erfahrene RISC OS-Ethernet-Geschädigte haben natürlich immer eine große Auswahl an USB-Adaptern mit unterschiedlichen Chipsätzen in der Bastelkiste, um gegen derartige Unfälle gewappnet zu sein.

Im Bereich VFP gab es einen merkwürdigen Bug, wo das WIMP beim Taskswitching in Verbindung mit Poll-Post-Filtern den VFP-Kontext nicht richtig behandelte. Symptom: SciCalc semmelte bei Tastatureingabe ab, wenn gleichzeitig das KeyExtend-Modul (wird z.B. von StrongEd benötigt) aktiv war. Jeffrey Lee hat es souverän analysiert und gefixed – ich will nicht wissen, wie lange das gedauert hat, diese abstruse Kombination zu debuggen.

Weiterhin gibt es Bewegung und Aufräumen in Richtung RISC OS 5.24, vor allem beim Wandboard (aka ARMX6). Ich bin leider immer noch nicht dazu gekommen, einen der Nightly Builds fürs Wandboard auszuprobieren.

USB-Stack – des Updates erster Schritt

Das Bounty-System von ROOL ist nicht gerade erfolgsverwöhnt. Es mangelt neben Spendenbereitschaft vor allem an interessierten und ausreichend talentierten Entwicklern, die sich der zahlreichen Aufgaben annehmen wollen.

Eine der aus meiner Sicht wichtigsten Bounties kreist rund um USB. Bekanntlich stammt das RISC OS 5-USB-Subsystem genau wie der Netzwerkstack von *BSD ab, wurde aber schon längere Zeit nicht auf den aktuellen Stand der Dinge gebracht, abgesehen von gezielten Codeübernahmen aus dem Original. Hauptsächlich deshalb, weil es kein “plain port” ist, sondern aufgrund der maximalen nicht-UNIX-heit von RISC OS eben großflächig angepasst werden musste. Das erschwert das Synchronhalten mit der Quelle erfahrungsgemäß enorm.

Nun wurde für Teil 1 des USB-Bounties Vollzug gemeldet. Hier zum Nachlesen der Umfang von Teil 1. Neben den notwendigen strukturellen Änderungen, um näher am BSD-Original zu sein und eine saubere Trennung zwischen den Hardware-Treibern und dem eigentlichen Stack halte ich die Bereinigung des Chaos rund um das bisherige Schmalspur-USB-wenn-gebootet-wird für besonders erwähnenswert. Schon auf dem IYONIX pc war das ein Ärgernis – es funktionierten zum Boot-Zeitpunkt nur ganz einfache Tastaturen an einem ganz bestimmten USB-Port.

In Colin Granvilles USB-Ecke gibt es entsprechende Updates, um den Isochronous-Modus nutzen zu können. USB Audio ist weiterhin ein Stiefkind im RISC OS-Universum, aber irgendwann werden hoffentlich die entscheidenden Lücken geschlossen werden. Vermutlich um dieselbe Zeit, wenn USB3-, WLAN- und Bluetooth-Unterstützung Einzug in RISC OS hält.

Warten wir also geduldig und hoffen auf die alsbaldige Vollzugsmeldung bei USB-Bounty Teil 2!

Von RISC OS, ARMX6 und dem Wandboard Quad

Aufmerksame Beobachter der RISC OS-Szene kennen natürlich den ARMX6 von R-Comp, ein schönes wenn auch recht preisintensives Stück Hardware (auf Basis des Freescale i.MX6 auf einem Wandboard Quad sitzend) das als erster RISC OS-Rechner die Plattenperformance des IYONIX pc durch S-ATA zu übertreffen wusste. Schönheitsfehler war immer, dass R-Comp eine “commercial licence” von RISC OS 5 hatte und deshalb nicht verpflichtet war, sofort alle notwendigen Änderungen und Hardwaretreiber usw. an ROOL zurückzuspiegeln.

Offenbar ist jetzt die Zeitschranke für das Feedback der Anpassungen abgelaufen, denn es gibt nun im ROOL-Downloadbereich den i.MX6/Wandboard-Teil, wo ein aktueller Nightly Build zur Verfügung steht.

Endlich gibt es also (sofern das ROM vollständig alle Features abdeckt, das habe ich noch nicht geprüft) für Interessierte eine Low-Cost-Möglichkeit, sich ein RISC OS-Gerät mit anständiger Platten-I/O für überschaubares Geld zusammenzustöpseln. Das Wandboard Quad (die Variante, die S-ATA on board hat) liegt derzeit bei nominell 119US$, in Europa scheint eine noch lieferfähige Bezugsquelle Mouser Electronics zu sein, die haben es für knapp 150€ im Programm. Wobei ich überraschenderweise gesehen habe, dass Watterott im Moment das TI OMAP5432-EVM für unter 200€ verkauft. Aber soweit ich weiß gibt es dafür keine frei verfügbare S-ATA-Implementierung für RISC OS, ist also nur bedingt als Ersatz geeignet, von der Micker-Auflösungsproblematik der OMAP5-Reihe ganz abgesehen.

Inwiefern andere Boards mit i.MX6 damit funktionieren – keine Ahnung. CuBox-i4Pro, SABRE Lite oder das MarS Board wären interessante Kandidaten. Aus der Efika MX6-Serie ist wohl nie was geworden – schade, MX Smartbook und MX Smarttop sahen in der i.MX5-Variante schon sehr elegant aus.

Zero Page und RISC OS 5 – Update

Wer sich nicht mehr erinnert – seit Juli 2015 haben alle RISC OS 5-Development-Builds die Zero-Page verschoben und laufen in der sogenannten “high processor vectors”-Konfiguration. Das ermöglicht einen deutlich stabileren OS-Betrieb, führt aber dazu, dass so manche Software, die bisher einwandfrei lief, aufgrund von (vermutlich) unkritischen NullPointer-Zugriffen den Abgang macht. Auch zu Diagnosezwecken, aber auch zur Wahrung der Rückwärtskompatibilität wurde deshalb das ZeroPain-Modul erfunden, das Zugriffe auf die Zero Page loggt. So mancher Uralt-Bug wurde dadurch erfolgreich ausgemerzt.

Ursprünglich war angedacht, ab 1.1.2016 ZeroPain wieder abzuschaffen. Das war wohl viel zu optimistisch, und es gab meines Wissens erheblichen Widerstand von R-Comp und CJE, die bekanntlich fertige RISC OS-Rechner inklusive eigens getesteter RISC OS 5-Versionen für die weniger bastelfreudigen User verkaufen. Letztlich das alte RISC OS-Problem: zuwenige Entwickler, die sich um die Pflege der Software kümmern können, dazu einige Software ohne verfügbaren Quellcode.

Jetzt gibt es eine neue Marschrichtung: einen Kompatibilitätsmodus, “compatibility page” genannt. Per OS_Memory 20 auch softwaremäßig kontrollierbar. Ich denke, das ist ein guter Kompromiss – es ermöglicht allen Parteien, zu einem gemeinsamen ROM-Build zurückzukehren und je nach Zielgruppe zwischen maximaler Rückwärtskompatibilität oder gescheiter Entwicklerunterstützung einfach umschalten zu können. Software, die zu Emulationszwecken die Zero Page selbst simulieren will (ADFFS ist da ein Kandidat, siehe Post zur Verfügbarkeit von Version 2.62), kann ebenfalls entsprechend agieren. ZeroPain ist für Entwickler und Benutzer, die Entwickler unterstützen wollen, weiterhin verfügbar.

Neues vom ROOL-Repository

Immer wieder habe ich ein Auge auf das ROOL-CVS-Repo, weil man dort aus den Commit-Kommentaren und den geänderten oder hinzugefügten Sources recht gut ablesen kann, wo in der RISC OS-Welt (m Sinne von Kern-OS) gerade Hand angelegt wird.

Aktuell wird am Filecore nebst ADFS und HForm rumgeschraubt, um idlen auf 21 Bits zu erhöhen. Damit kann man dann die maximal erlaubte Anzahl von Objekten in einer Filecore-Partition hochschrauben, was es wiederum erlaubt, bei gleicher Partitionsgröße die LFAU etwas kleiner zu wählen, was wiederum die Platznutzung vor allem bei vielen kleineren Dateien (und was würde RISC OS mehr auszeichnen als die Vielzahl kleiner Dateien – nicht nur die !Run- und !Boot-Skripte sind sehr klein, sondern auch !Sprites und !RunImage und leider oft auch !Help – ich spreche aus Erfahrung) deutlich verbessert. Allerdings wird die Map auch wieder entsprechend größer.

Es scheint auch etwas in Richtung USB3-Unterstützung zu geschehen, am XHCI-Treiber wird gearbeitet. Ab und an sind auch Einsprenkel aus den Arbeiten rund um die Multicore-Unterstützung zu sehen. Und sogar der gute alte Maestro hat eine Pflegekraft gefunden. Wohl nur Teilzeit, aber immerhin.

Auch die Access-Einbindung in OmniClient könnte demnächst ein Comeback feiern – wenn ich mich recht erinnere, lagen die Rechte für den Code bei einer anderen Firma, offensichtlich hat man sich da nun geeinigt.

Es gibt nun ein BASICVFP-Modul, quasi ein BASIC64 mit VFP statt FPE.

Zuletzt wurde noch ein interessanter Bug im EDID-Umfeld gefixed – die Bootsequenz kam zum Erliegen mit einem bösen Absturz, wenn man keinen Monitor angestöpselt hatte bzw. dieser keine sinnvollen EDID-Daten zurücklieferte (z.B. EDID-Infos mit Länge 0, was laut Standard wohl valide ist). Es gibt jetzt einen sicheren Fallback in Form des klassischen Mode 27 – quasi wie beim PC-BIOS.

2 TiB auf einer FileCore-Partition

Limits von Hardware und Betriebs- sowie Dateisystemen haben in der IT eine lange Tradition. Die 32MiB-pro-Partition-Grenze von alten DOS-Versionen (ich glaube bis Version 3.2). Die 504MiB-Grenze der alten PC-BIOSe. Die 512MiB-Grenze von FileCore bis einschließlich RISC OS 3.5. Die 256GiB-Grenze von RISC OS ab 3.6. Die “DMA nur bis 128GiB”-Grenze des IYONIX pc wegen der ALi-Southbridge. Dazu die LBA28/40/48-Problematik.

ROOL hat angekündigt, dass ab demnächst die neue Grenze 2 TiB pro FileCore-Partition sein wird. Das geht ohne Änderung der internen FileCore-Adressierung, weil FileCore nun mit 4 KiB-Blöcken umgehen kann und ADFS nun auch die (S-ATA-)Hardware entsprechend ansteuern kann. Zuvor wurden 512 Byte-Blöcke verwendet, wie sie lange Zeit bei IDE- und S-ATA-Festplatten auch nativ verwendet wurden.

Bisher konnten derartige Plattengrößen nur bei Dateisystemen über SCSI (also aktuell vor allem USB-Massenspeicher) unter Benutzung von Fat32FS verwendet werden, und das war auch eher getrickst über eine clevere Verwendung von Partitionsoffsets in SCSIFS.

Jetzt noch Partitionsunterstützung unter Ausnutzung der neuen FileCore-Freiheiten seit RISC OS 5 (256 statt 8 “Laufwerke” aka dann hoffentlich Partitionen), dann könnte man ohne größere Verrenkungen Platten (ok, 256 Laufwerksicons…) bis 512 TiB verwenden. Im Moment sind gängige Retail-Größen mit gutem Preis-/Größenverhältnis 2 TiB und 4 TiB, d.h. man hätte sich wieder etwas Luft verschafft im RISC OS-Universum bevor man an den nächsten größeren FileCore-Umbau gehen muss.

RISC OS für Raspberry Pi RC15 verfügbar

Lange hat es gedauert. RC14 erschien im Februar 2015 noch basierend auf RISC OS 5.21 und war “out of the box” so richtig gut nur auf dem ersten RPi lauffähig – der RPi 2 war nominell unterstützt, aber es hakte an der ein oder anderen Stelle. Seither war die RPi Foundation nicht untätig und hat quasi im Jahresrhythmus neue Gerätschaften auf den Markt gebracht: RPi Zero, RPi 3, die aktualisierte Variante des RPi 2 auf Basis desselben SoCs wie RPi 3, und zuletzt den RPi Zero W.

Nun konnte natürlich jeder gefuchste Anwender mit Heimwerkerhintergrund “problemlos” (zumindest wenn man SystemDisc von Piccolo Systems hat) eine neuere RISC OS-Version für RPi 3 und Co zusammendengeln. Aber bekanntlich ist der RPi ja auch in den Händen von RISC OS-Noobs, die nur mal kurz unser schönes alternatives Betriebssystem ausprobieren wollen. Für die war die NOOBS-Distribution bisher große Klasse, aber leider basiert diese auch auf RC14. Der zweitbeste Weg um RISC OS auszuprobieren war das RC14-Disc-Image von ROOL selbst, aber wie gesagt – nicht wirklich tauglich für die neuen Modelle, und relativ kompliziert auf einen neueren Stand zu bringen.

Jetzt ist die Warterei vorbei, RC15 wurde veröffentlicht (hier die offizielle Ankündigung). Endlich ist also wieder eine Distribution verfügbar, die man “einfach so” auf alle aktuellen RPi-Modelle bringen kann. Super!

Jetzt muss man nur noch erklären, warum RISC OS nur 2 GiB der üblicherweise viel größeren (micro)SD-Karte nutzen kann – hoffentlich kann man diese Frage auch bald beantworten mit “geht doch”, sobald FileCore und die diversen Dateisysteme anständig mit Partitionen umgehen können.

iMX6-HAL erreicht das ROOL-Repository

Ich hatte es früher schon erwähnt: es lohnt sich immer, die Bewegungen im ROOL-Repository im Auge zu behalten. Seit einiger Zeit hat nun endlich der iMX6-HAL seinen Weg dorthin gefunden. Nebenbei: man hofft, dass der Code fehlerärmer ist als die Commit-Kommentare.

Der iMX6, der im Herzen des ARMX6 von R-Comp (und ja, ich würde gerne auf eine ARMX6-Seite verlinken, aber R-Comp ist eben R-Comp) in Form des Wandboard Quad schlägt, erhielt seine RISC OS-Weihen in proprietärer Form von R-Comp. Klar, wer entwickelt, will damit auch Geld verdienen. Die kommerzielle RISC OS-Lizenz von Castle hat für diesen Fall eine Spezialklausel: gegen ein paar Euro (maximal 10 UKP pro verkaufter Lizenz) müssen geänderte OS-Quellen zunächst nicht an ROOL zurückfließen, sondern man kann sich bis zu 2 Jahre Zeit erkaufen. Die waren im Falle des iMX6 jetzt rum.

Nächste Aufgabe: iMX6-ROM bauen aus den aktuellen Quellen.