![[OpenBSD]](../images/smalltitle.gif){kind=small}
OpenBSD/mvme88k ist ein Versuch, OpenBSD auf die Systeme zu portieren, die auf der 88xxx-basierten VME Motherboard-Familie von Motorola aufbauen.
Eine Mailingliste für die m88k-basierten Portierungen ist unter m88k@openbsd.org erreichbar. Um die OpenBSD/m88k-Mailingliste zu abonnieren, sende eine E-Mail mit dem Inhalt »subscribe m88k« an majordomo@openbsd.org. Bitte lies vorher unsere Mailinglisten-Richtlinien.
Dem Motorola-88k-Prozessor wird nachgesagt, der beste RISC-Prozessor zu sein, der jemals erdacht wurde. Seine Einfachheit und Eleganz ergänzen sich und machen den mvme88k zu einer aufrichtigen, robusten Plattform.
Leider nutzte die erste Design-Generation (88100) ein gemeinschaftliches Layout für den Cache und die virtuelle Speicherverwaltung, was das Hardware-Design unangenehm komplex (und teuer, zu dieser Zeit) machte. Die zweite Generation (88110) nahm sich dieser Problematik an, wurde aber von Statbilitätsproblemen geplagt. Letztendlich ergriff Motorola die Möglichkeit, so schnell wie möglich die 88000er Designlinie zu Gunsten des PowerPC aufzugeben, obwohl auch heute noch einige Teile des 88110 in Prozessoren der PowerPC-Familie weiterleben.
Nivas Madhur begann die erste mvme88k-Portierung für die MVME187-Karte, aufbauend auf dem CMU Mach-Programmkode, der auf den 88100-basierten Omron Luna88k-Systemen lief. Jedoch wechselte er den Arbeitgeber bevor die Arbeit bereit zur Einbindung in den OpenBSD Quelltextbaum war.
Dies blieb dann Dale Rahn vorbehalten, der die Integrationsarbeit beendete, jedoch nicht genügend Zeit hatte, weiter an der Portierung zu arbeiten. Steve Murphree Jr. hat die Portierung für die MVME187 im November 1998 letztendlich abgeschlossen.
Leider hat eine Aktualisierung des Übersetzers, von gcc 2.8.1 zu egcs, der zur gleichen Zeit stattfand, eine Menge Probleme in der mvme88k-Unterstützung des gcc offengelegt, welche nicht rechtzeitig korrigiert werden konnten, als dass mvme88k ein unterstütztes OpenBSD-2.5-Release hätte werden können.
Das fehlen einer Werkzeugkette innerhalb des Quelltextbaums hielt weitere Arbeit an dieser Portierung nicht ab und viele Änderungen wurden an der Quelltextbasis durchgeführt, wie zum Beispiel die Überarbeitung von autoconf und dem on-board SCSI-Treiber, die große Erweiterung der VME-Bus-Unterstützung, eine funktionsfähige Installationsroutine, die auf korrekte Weise einen Motorola-VID-Block auf der Platte erstellt und Unterstützung für MVME188 und besserer Unterstützung für MVME197.
Während des Sommers 2003 führte letztendlich eine Bemühung, die Werkzeugkette zu korrigieren, zu einem funktionionsfähigen gcc-2.95-Übersetzer und ermöglichte es der Portierung wieder, selbsterzeugend zu sein. Mit der Hilfe von Mark Kettenis hat die Bemühung um die Werkzeugkette schlussendlich dazu geführt, dass binutils und gdb seit dem späten Mai 2004 funktionieren.
Im Sommer 2005 wurde mit der Arbeit zur Unterstützung von Multiprozessoren auf MVME188-Boards begonnen und wurde schließlich nach vielen langwierigen Fehlerbereinigungen kurz nach der Veröffentlichung von 4.2 im November 2007 beendet.
Der nächste Schritt war, die 88110-basierten MVME197-Designs einsetzen zu können. Einprozessor-Kernel können seit Dezember 2007 zuverlässig betrieben werden; Mehrprozessor-Unterstützung wurde im März 2009 abgeschlossen, hörte aber nicht auf, obskure Fehler zu produzieren, die schließlich auf einen Prozessor-Platinenfehler zurückgeführt werden konnten, welcher wiederum seit April 2010 als »abgehakt« betrachtet werden kann.
Der lang erwartete Wechsel vom a.out Binärformat hin zu ELF wurde nach dem Release 5.2 vollzogen, verbunden mit einem Upgrade des Übersetzers gcc auf Version 3.3.6. Diese Arbeit ebnete den Weg für die Unterstützung von gemeinsam genutzten, dynamischen ELF Bibliotheken, an der im Moment gearbeitet wird, verbunden mit der Hoffnung, dies rechtzeitig für das bevorstehende Release 5.3 bereit und zuverlässig abgeschlossen zu haben.
Zurzeit starten MVME187-, MVME188- und MVME197-Boards sowie ähnliche Designs und unterstützen die meisten on-board Geräte. Es gibt allerdings immer noch ein paar kleine Probleme; je nachdem, wie dein exakter Hardwareaufbau ist, kann die Anzahl dieser variieren. Es wird daran gearbeitet, die übrig gebliebenen Probleme zu lösen und weitere Boards zuverlässig zu unterstützen.
Neben den Komplettsystemen von Motorola (M8120, Series 900 etc.), läuft diese Portierung ebenfalls auf dem MVME187-basierten Triton Dolphin System 100.
Diese Boards werden zurzeit nicht unterstützt. Abgesehen von fehlender Hardware gibt es allerdings keinen Hinderungsgrund, warum sie nicht eines Tages unterstützt sein sollten.
Das neueste unterstützte OpenBSD/mvme88k-Release ist OpenBSD 5.2. Hier sind die OpenBSD/mvme88k 5.2-Installationsanweisungen.
Schnappschüsse werden von Zeit zu Zeit hier zur Verfügung gestellt, sowie auf ein paar Spiegelservern. Hier sind ebenfalls die OpenBSD/mvme88k Schnappschuss-Installationsanweisungen verfügbar.
Da VME-Hardware bei den typischen Verkäufern recht ungewöhnlich ist und Motorola-881x0-basierte Hardware noch seltener ist, existiert diese Sektion, um die häufig anzutreffende Kuriosität über die mvme88k-Hardware zufrieden zu stellen.
Bilder des Motorola-900-modular-Gehäuses, mit einem 33-MHz-MVME187-CPU-Board, 32 MB RAM, 4 MVME332XT seriellen Boards und einem Archive-250-MB-QIC-Bandlaufwerk.
Dies ist die Aufzeichnung des Systemstarts eines MVME197DB-Systems.
[ using 205464 bytes of bsd a.out symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2010 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 4.7-current (GENERIC.MP) #308: Thu Apr 15 21:09:19 GMT 2010
miod@arzon.gentiane.org:/usr/src/sys/arch/mvme88k/compile/GENERIC.MP
real mem = 134217728 (128MB)
avail mem = 125927424 (120MB)
mainbus0 at root: Motorola MVME197, 50MHz
cpu0: M88110 version 0xf, 8K I/D caches
cpu0: external M88410 cache controller
cpu1: M88110 version 0xf, 8K I/D caches
cpu1: external M88410 cache controller
bussw0 at mainbus0 addr 0xfff00000: rev 4
pcctwo0 at bussw0 offset 0x0: rev 0
nvram0 at pcctwo0 offset 0xc0000: MK48T08
cl0 at pcctwo0 offset 0x45000 ipl 3: console
osiop0 at pcctwo0 offset 0x47000 ipl 2: NCR53C710 rev 2, 50MHz
scsibus0 at osiop0: 8 targets, initiator 7
osiop0: target 0 now using 8 bit 10 MHz 8 REQ/ACK offset xfers
sd0 at scsibus0 targ 0 lun 0: <SAMSUNG, WN34324U (gm030), 0105> SCSI2 0/direct fixed
sd0: 4120MB, 512 bytes/sec, 8438976 sec total
osiop0: target 1 now using 8 bit 10 MHz 8 REQ/ACK offset xfers
sd1 at scsibus0 targ 1 lun 0: <QUANTUM, FIREBALL_TM3200S, 300X> SCSI2 0/direct fixed
sd1: 3067MB, 512 bytes/sec, 6281856 sec total
vme0 at pcctwo0 offset 0x40000
vme0: using BUG parameters
vme0: 1phys 0x08000000-0xefff0000 to VME 0x08000000-0xefff0000
vme0: vme to cpu irq level 1:1
vmes0 at vme0
vmel0 at vme0
ie0 at pcctwo0 offset 0x46000 ipl 3: address 08:00:3e:23:ed:e8
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
boot device: sd0
root on sd0a swap on sd0b dump on sd0b
Automatic boot in progress: starting file system checks.
/dev/rsd0a: file system is clean; not checking
/dev/rsd0f: file system is clean; not checking
/dev/rsd1a: file system is clean; not checking
/dev/rsd0d: file system is clean; not checking
/dev/rsd0h: file system is clean; not checking
/dev/rsd0e: file system is clean; not checking
/dev/rsd0g: file system is clean; not checking
setting tty flags
ddb.console: 0 -> 1
kern.splassert: 1 -> 2
starting network
starting system logger
starting initial daemons: portmap ypbind rdate ntpd.
savecore: no core dump
checking quotas: done.
building ps databases: kvm dev.
clearing /tmp
starting pre-securelevel daemons:.
setting kernel security level: kern.securelevel: 0 -> 1
creating runtime link editor directory cache.
preserving editor files.
starting network daemons: sendmail inetd sshd.
starting local daemons:.
standard daemons: cron.
Thu Apr 15 21:12:51 GMT 2010
OpenBSD/mvme88k (arzon.gentiane.org) (console)
login:
