An english version is not yet available...
Herzlich willkommen, lieber (potenzieller) Besitzer eines BeagleBoards. Diese Seite soll soweit wie möglich über aktuelle Entwicklungen rund um RISC OS auf dem BeagleBoard unterrichten (und ist deshalb auch focussiert auf die RISC OS-Situation, insbesondere was Kommentare zu Performance und Features angeht). Die Szene ist momentan noch recht überschaubar, und einen zentralen Anlaufpunkt für deutsche Benutzer gibt es noch nicht.
Die RISC OS-Entwicklung für das BeagleBoard findet hauptsächlich via RISC OS Open Ltd. statt. Das dortige Forum ist ein steter Quell relevanter Informationen.
Für die restlichen Dinge, die das BeagleBoard so kann, wenn man sich mit Linux zufrieden geben will (;-)), findet man z.B. hier ein deutschsprachiges Forum.
Hier die Einkaufsliste - die Auswahl der Bezugsquellen ist rein subjektiv! Die genannten Geräte funktionieren bei mir absolut zuverlässig. Abweichungen auf eigene Gefahr :-)
Alles in allem beginnt der Aufbruch in die neue RISC OS-Hardware-Welt also mit einer lächerlich geringen Investition von knapp über 200 EUR - ein echtes Schnäppchen gegenüber IYONIX pc und A9home. Gut, man hat nur die nackte Platine ohne Gehäuse, aber wer würde sich von sowas aufhalten lassen.
Das BeagleBoard ist ein für die Community gebautes kleines ARM-Entwicklungsboard mit einem TI-OMAP3530-Prozessor, der auf einem ARM Cortex-A8-Kern basiert. Obwohl ähnlich getaktet (600 MHz, bzw. bis zu 720 MHz bei Rev. C4) wie ein IYONIX pc, rennt es diesem auf und davon - einmal weil der Prozessor superskalar arbeitet, außerdem ist die RAM-Anbindung deutlich schneller und es steht ein 2nd level cache zur Verfügung.
Etwas im Hintertreffen gegenüber dem IYONIX pc ist das BeagleBoard bezüglich I/O. Es ist faktisch nur USB2.0 verfügbar, darüber müssen dann sowohl Massenspeicher (Festplatte, USB-Stick, CD/DVD-Laufwerk) als auch Netzwerk laufen. Durch den USB-Overhead und die relativ niedrige maximale Übertragungskapazität kann man hier keine großen Sprünge machen. Hier kommt uns allerdings zugute, dass RISC OS-Software üblicherweise nicht sehr I/O-lastig ist und für typische Anwendungen (Programm laden, Daten speichern) die rund 40 MB/s von USB2.0 gerade so ausreichen.
Auf den ersten Blick ebenfalls zu wünschen übrig lässt die Grafikleistung. Hier bringt das BeagleBoard einen Imagination Technologies PowerVR SGX530 mit, der das Videosignal ausschließlich digital über einen HDMI-Ausgang bereitstellt, der aber kein vollständiges HDMI unterstützt, sondern lediglich den Videoteil davon (sprich DVI-D) und über übliche HDMI-DVI-D-Adapter an den Monitor angeschlossen wird. Es wird "shared memory" für die Grafik verwendet. Im Gegensatz zu Risc PC-Zeiten ist aber nicht die RAM-Bandbreite und der maximal allokierbare Speicher das limitierende Element, sondern der maximale Pixeltakt - dieser ist mit 65 MHz spezifiziert, scheint aber ganz gut bis etwa 75 MHz zu funktionieren. Spezifiziert ist die maximal mögliche Auflösung offiziell mit 1024x768@60Hz@TrueColour - wenn der Monitor mitspielt, ist auch 1280x1024@50Hz möglich, damit hängt man immerhin einen Risc PC mit 2 MB VRAM ab, aber ist natürlich weit von den Fähigkeiten eines ViewFinders oder IYONIX pcs weg. Allerdings hilft uns hier die moderne Unterhaltungselektronik: die heute typischen FullHD-LCDs verkraften dank Blu-Ray-Spezifikation üblicherweise "FULL HD 24p", also 1920x1080@24 Hz. Auch viele FullHD-TVs der neueren Generation kommen mit dieser Auflösung klar.
Wer ein BeagleBoard aktuell kaufen will, sollte darauf achten, auf jeden Fall ein Revision C3- oder C4-Board zu bekommen. Frühere Revisionen hatten doch einige Macken, und bis zur B-Revision gab es nur 128 MB RAM. Rund um das BeagleBoard gibt es inzwischen ein recht großes Angebot an Zubehör und auch eine Menge Nachbauten und Varianten. Google hilft. Für die Nutzung unter RISC OS sollte man aber darauf achten, dass entsprechende Treiber vorhanden sind (z.B. fehlen diese noch für die Ethernet-Schnittstelle des IGEPv2-Boards, des DevKit8000 oder des Zippy2 Extension Boards).
Eine Bezugsquelle in Deutschland ist beispielsweise Watterott Elektronik, ansonsten einfach direkt beim Hauptdistributor Digi-Key bestellen.
Technische Daten in Kurzform:
Seit kurzer Zeit liefert Digi-Key die ersten Exemplare des BeagleBoard-xM aus. Den Early Adopter erwartet hier eine schnellere CPU (1 GHz OMAP3 mit DSP), mehr und schnelleres RAM (512 MB, 200 MHz), Ethernet und einen 4-Port-USB-Hub on board. Außerdem ist ein Standard-9polSubD-Anschluss für die serielle Konsole vorhanden statt dem unhandlichen Pin-Header des Original-BeagleBoards. Der Preis liegt bei 179 US$ zzgl. Einfuhrumsatzsteuer (aka Zoll).
Statt von SD-Karte wird das Betriebssystem nun von einer MicroSD-Karte gelesen, eine 4GB-Karte ist im Lieferumfang enthalten.
Seit gestern gibt es ein RISC OS-ROM-Image, welches mit dem BeagleBoard xM zusammen läuft. Allerdings fehlt noch der SmartReflex-Treiber, der den angegebenen Takt von 1 GHz tatsächlich ermöglicht. Das OnBoard-Ethernet wird noch nicht von RISC OS unterstützt.
Zwei blind herausgegriffene Datenpunkte: der Redraw bei Artworks ist bedeutend schneller als auf dem IYONIX (etwa Faktor 2), ebenso die Wiedergabe eines MPEG2-Videos über KinoAMP mit Ton - hier werden rund 25 fps erreicht, d.h. endlich Full Speed Video. Was auch knapp Faktor 2 bedeutet.
Michael Kübels Fraktal-Benchmark FixFrac läuft etwas langsamer als auf dem IYONIX - warum, ist noch nicht ganz klar.
Die Dateisystemperformance lässt noch zu wünschen übrig gegenüber dem IYONIX, dürfte aber durchaus auf dem Niveau des Risc PC oder A9home liegen. Es sind hier noch reichlich Optimierungen auf allen Ebenen denkbar, das SCSIFS-SCSISoftUSB-USBDriver-Konglomerat benutzt momentan noch nicht mal background operations und buffering.
Einige Befehle scheint der TI-OMAP/Cortex-A8 etwas langsamer abzuarbeiten als der XScale des IYONIX, das hängt eventuell mit der Branch Prediction zusammen - ich arbeite noch an einer genaueren Analyse. Zumindest bei der Grafikausgabe hat das BeagleBoard jedenfalls die Nase weit vorne.
Meines Erachtens ist das BeagleBoard auf einem guten Weg, für viele Besitzer älterer RISC OS-Hardware eine attraktive Umsteigemöglichkeit zu werden. Während die Basis gesund ist und schon ganz gut läuft, gibt es natürlich noch Feinheiten, an denen gefeilt werden sollte, bevor der einfache User mit der Hard- und Software glücklich wird.
Hier eine Übersicht über die Dinge, die meines Erachtens noch fehlen:
Die Wunschliste bzw. Roadmap von RISCOS Open Ltd. ist schonmal ein guter Anfang.
M.E. sind Projekte zu bevorzugen, die für alle bzw. die meisten RISC OS-Nutzer direkt oder indirekt von Vorteil sind. Eins der übergreifenden Ziele muss die universelle Verwendbarkeit von RISC OS 5 sein - vom Risc PC bis zum IYONIX, vom BeagleBoard bis zum Omega, vom A7000 bis zum A9home. Und natürlich RPCemu als universelle Emulationsplattform für alle Nicht-ARM-Hardware.
Wichtig sind auch die Querschnittsanwendungen. Dazu gehören z.B. GCC oder das Packaging Project. Quasi die Infrastruktur von RISC OS. Nur dann ist es möglich, zu verhindern, dass jeder Entwickler das Rad wieder neu erfindet.
Meine persönlichen Lieblingsprojekte:
RISC OS hat eine etwas merkwürdige Struktur bei Dateisystemen. Fileswitch ist die unterste Abstraktionsebene. Darauf aufbauend gibt es vollständig eigenständige Dateisysteme (z.B. CDFS und auch alle Image-Filing-Systeme wie SparkFS und DOSFS) sowie Filecore, welches das native RISC OS-Dateisystem abstrahiert bereitstellt. Der eigentliche Hardwarezugriff steckt nun typischerweise im Filecore-Client (beispielsweise ADFS, SCSIFS, IDEFS). 3rd party Dateisysteme wie z.B. Fat32FS nutzen deshalb Filecore (bzw. damit den Filecore-Client) für Block-/Sektorzugriffe oder bringen wie CDFS ihren eigenen Hardwarezugriff mit. Das Resultat ist irgendwas zwischen Verhau und umständlich. Jedenfalls ist es nicht so einfach möglich, auf bereits unterstützter Hardware (z.B. einem IDE-Controller oder auch USB) ein neues Dateisystem einfach zu implementieren.
Früher war die Idee, einfach ein Image-Filing-System zu schreiben (DOSFS, MacFS), welches dann automatisch über den Filecore-Client Zugriff auf die Hardware hatte. In Zeiten des 2 GB-Limits ist das aber nur noch als schlechte Idee zu bezeichnen, und auch die Art und Weise, wie RISC OS entscheidet, welches Image-Filing-System Zugriff auf ein Volume hat, ist etwas undurchsichtig.
Der Ausweg: ein richtiger Device-Manager, der den Zugriff auf beliebige Hardware auf Block-/Sektorebene regelt. Für jede Hardware gibt es einen kleinen Treiber, der erkannte Hardware an den Device-Manager meldet mit den entscheidenden Parametern (z.B. Read-Only oder Read-Write, Blockgröße, Volumes, wechselbares Medium oder fest etc.).
Die Dateisysteme werden dann auf den Zugriff über den Device-Manager umgebaut. Für Legacy-Anwendungen kann der Device-Manager auch die Anmeldung von Filecore-Clients akzeptieren, um so nahtlose Rückwärtskompatibilität zu gewährleisten. Es braucht dann nur noch einen generischen Filecore-Client, der über den Device-Manager auf die Hardware zugreift. Hier können dann auch endlich zentrale Dinge wie Partitionierung etc. untergebracht werden. Im Device-Manager ist auf Blockebene auch sehr einfach ein Cacheing implementierbar.
Es gibt in der weiten EDV-Welt eine ganze Menge interessanter Dateisysteme, die auch RISC OS gut zu Gesicht stehen würden. Mittelfristig muss Filecore als natives Dateisystemformat dringend abgelöst werden, da es jenseits der 256 GB wieder sehr ineffizient wird (LFAU und/oder Map-Größe). Außerdem gibt es da ja noch das Problem, dass auf Sicht 4KB-Sektoren bei Festplatten Standard werden, und die unterstützten Sektorgrößen bei Filecore leider nur 512 bytes und 1024 bytes umfassen.
Linux kennt zwei prinzipielle Schnittstellen, um Dateisysteme anzubinden: VFS und FUSE. Schick wäre eine FS-Bridge, die auf der einen Seite das Interfacing mit Fileswitch erledigt, und auf der anderen Seite eine VFS- und/oder FUSE-artige Schnittstelle anbietet, um eine Portierung vorhandener Dateisysteme so unproblematisch wie möglich zu machen.
Zum Test bieten sich dann ext3, UDF, XFS und JFS2 als Dateisysteme an. Wenn die alle problemlos laufen, kann das Projekt als abgeschlossen gelten ;-)
Aus lizenztechnischen Gründen wäre wohl ext3 das Dateisystem der Wahl für das neue native RISC OS-Dateisystem. Oder man leiht sich mal wieder etwas BSD-Code und setzt auf FFS und puffs, dem BSD-FUSE-Äquivalent.
Bekanntlich krankt Fileswitch (und damit alle Dateisysteme unter RISC OS) am 2-GB-pro-Datei-Limit. Damit verbunden ist auch das unangenehme 2-GB-Limit für Image-Filing-Systeme.
Wer es schafft, Fileswitch derart umzubauen ohne die ursprüngliche Funktionalität und damit die Rückwärtskompatibilität zu ruinieren, hat einen Platz in der RISC OS Hall of Fame redlich verdient. Zusatzpunkte für die transparente Abbildung von großen Dateien auf alten Dateisystemen.
Viele Programme sollten unverändert auf dem BeagleBoard laufen, vor allem sobald Jeffrey Lee den Unaligned Exception Handler funktionsfähig hat. Nachfolgend eine Liste von Software, die explizit als ARMv7-kompatibel upgedatet werden muss, mit passenden Links zum Download:
| Home | © 2010 Steffen Huber, steffen@huber-net.de |