![[OpenBSD]](http://www.openbsd.org/images/smalltitle.gif){kind=small}
Updated 20240224
Help yourself!
After a lot of inactivity, I've been recently seriously working again on AViiON
(and other m88k-based) hardware.
I had attempted to revive the aviion port in a private tree some years ago,
but kept getting disk I/O errors or kernel panics, whichever would come first.
I eventually I found out the disk I was using was dying, the I/O errors were
genuine, and the kernel panics were caused by a stupid bug in my code.
With a new disk and the bug out of the way, I thought the road was clear towards
building a recent aviion release. But after a short honey moon with my
new setup, disk I/O errors were back. And severe, to the point sometimes even
the PROM would refuse to boot.
At this point I realised that the fan of the external enclosure the new disk was
in did not spin (this is a quite old Sun 611 SCSI enclosure), and the disk was
getting to hot and its logic board would intentionally fail every operation
when the temperature reached a threshold. Removing the enclosure cover was
enough to make the disk happy again (yet hot, the disk surface is at about
45 Celsius degrees...)
Long story short, I now have a working 4605 system again and it runs the
OpenBSD 7.4 codebase. My current code, currently in a crude form, can be
found in a git repository at
Codeberg.
I don't know yet how I can conveniently make binaries available. In the
meantime, feel free to contact me if you want them.
I've been working on the IEEE754 code recently; more precisely, completion code
for edge cases where the FPU gives up and signals an exception.
These exceptions used to be serviced by arcane assembly code inherited from
Mach on the luna88k, and probably derived from Motorola-provided code.
Unfortunately, this code was far from perfect and caused wrong or imprecise
results to be returned in these cases; while not an issue for over 99% of
real-world applications, this was nevertheless a bug and fixing this had been
on my todolist for *years*.
I finally decided to bite the bullet and fix this, and replace that dusty code
with a thin wrapper over John Hauser's
SoftFloat code,
as previously done for the 88110 FPU.
Unlike the 88110, the 88100 has two kinds of FPU exceptions: precise and
imprecise. Precise exceptions are caused by unimplemented FPU opcodes
or reserved operands, and are similar to most 88100 exceptions in that the
instruction having triggered the exception is known, with all the pipeline
state, which makes this exception restartable. On the other hand, so-called
imprecise exceptions occur after the instructions have been considered as
executed, when it's write buffer flush time and the FPU suddenly realizes the
computed result can not fit in the required floating-point type without a loss
of precision; this is known, in IEEE754 terms, as an `inexact' exception
(which may be `extended' by an `overflow' or `underflow' exception).
Fixing the precise exceptions was almost a piece of cake, and mostly
required duplicating the 88110 floating-point completion code to support the
88100 FPU (which is a subset, both in opcodes and floating-point formats, of
the 88110 FPU), and then identifying the common parts and factoring them
elsewhere, so that a 88100+88110 kernel could still link.
On the other hand, the only information available to service imprecise
exceptions are the intermediate result (not rounded yet), as well as
information about which register(s) it needs to be written to. A subset of the
opcode bits is also available, if the current rounding mode is not enough to
decide how to round the result.
Implementing this in C code was simple as well, once the proper internal
softfloat functions needed to perform the rounding from the intermediate
result were identified, as well as their prerequesites. After some trial and
error, the 900 lines of assembly code were replaced by 90 lines of C code
(including comments). Which works in all rounding modes.
And I finally could cross the 88100 floating-point line off my todolist...
My 4300 system froze while debugging my attempts at getting DMA working. I have been unable to restore it to life, so DMA support will wait. At least I got PIO SCSI to work, so these systems run, but with horrible SCSI performance.
I finally got standalone boot blocks to work on the 4600. Currently building a snapshot with a bsd.rd that ought to allow installing onto a disk.
While it is building, I'm tinkering with the 4300 (and working on the AIC-6250 SCSI driver again)... it turns out the installed disk uses LDM (pre-VDM) partitioning, so I will need to experiment and see how one may share an LDM disk with DG/UX as well...
I have completed the disklabel code, allowing disks to be shared with DG/UX (using a non-aggregated VDM partition), as well as being OpenBSD-specific (without any form of VDIT information).
As a result, we now have a native installboot, but no bootblocks to install... yet!
I have finally figured out how the 6:1 CMMU to CPU ratio designs split access to the CMMUs. Took quite its share of hair-pulling, but I'm really happy now.
Here is what the kernel now reports:
cpu0: M88100 rev 0xb, 6 CMMU cpu0: M88200 (16K) rev 0x9, A13* A12* Icache cpu0: M88200 (16K) rev 0x9, A13* A12 Icache cpu0: M88200 (16K) rev 0x9, A13 A12* Icache cpu0: M88200 (16K) rev 0x9, A13 A12 Icache cpu0: M88200 (16K) rev 0x9, A12* Dcache cpu0: M88200 (16K) rev 0x9, A12 Dcache cpu1: M88100 rev 0xb, secondary, 6 CMMU cpu1: M88200 (16K) rev 0x9, A13* A12* Icache cpu1: M88200 (16K) rev 0x9, A13* A12 Icache cpu1: M88200 (16K) rev 0x9, A13 A12* Icache cpu1: M88200 (16K) rev 0x9, A13 A12 Icache cpu1: M88200 (16K) rev 0x9, A12* Dcache cpu1: M88200 (16K) rev 0x9, A12 Dcache
One relocation later, and a few years of procrastination, and I am resuming work on this port. And this time, I don't intend to give up until the 530 family is self-hosting.
Recent m88k work has fixed the SCSI DMA corruption I had experienced 3 years ago; and further fixes have finally enabled an SMP kernel to rebuild the world, off local disk, using two processors, on the 4605.
I have added support for the onboard ILACC interface as well. All I need now, is to be able to share a disk with DG/UX, and standalone boot blocks. Hopefully completed within a few days!
Mandatory dmesg:
[ no symbol table formats found ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2013 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 5.4-current (GENERIC.MP) #7: Sat Sep 21 20:53:13 GMT 2013
miod@talaron.gentiane.org:/usr/src/sys/arch/aviion/compile/GENERIC.MP
real mem = 134217728 (128MB)
avail mem = 128430080 (122MB)
bootpath: 'dgen() -a' dev 0 unit 0 part 0
mainbus0 at root: 4600/530, cpuid 0x7930
cpu0: M88100 rev 0xb, 6 CMMU
cpu0: M88200 (16K) rev 0x9, split Icache
cpu0: M88200 (16K) rev 0x9, split Icache
cpu0: M88200 (16K) rev 0x9, split Icache
cpu0: M88200 (16K) rev 0x9, split Icache
cpu0: M88200 (16K) rev 0x9, split Dcache
cpu0: M88200 (16K) rev 0x9, split Dcache
cpu1: M88100 rev 0xb, secondary, 6 CMMU
cpu1: M88200 (16K) rev 0x9, split Icache
cpu1: M88200 (16K) rev 0x9, split Icache
cpu1: M88200 (16K) rev 0x9, split Icache
cpu1: M88200 (16K) rev 0x9, split Icache
cpu1: M88200 (16K) rev 0x9, split Dcache
cpu1: M88200 (16K) rev 0x9, split Dcache
syscon0 at mainbus0 addr 0xfff00000
nvram0 at syscon0 offset 0x80000: MK48T02
dart0 at syscon0 offset 0x82000: console
dart1 at syscon0 offset 0x82c00
le0 at syscon0 offset 0xb0100: address 08:00:1b:33:14:30
le0: 128 receive buffers, 32 transmit buffers
oosiop0 at syscon0 offset 0xb0000: NCR53C700 rev 0, 33MHz
scsibus0 at oosiop0: 8 targets, initiator 7
sd0 at scsibus0 targ 0 lun 0: <IBM OEM, 0662S12 IQ, DG06> SCSI2 0/direct fixed serial.IBM_OEM_0662S12_IQ_00491198
sd0: 1003MB, 512 bytes/sector, 2055035 sectors
sd1 at scsibus0 targ 1 lun 0: <SEAGATE, ST318417N, 0105> SCSI3 0/direct fixed serial.SEAGATE_ST318417N_3FA0CM7H00007236Q4DW
sd1: 17547MB, 512 bytes/sector, 35937501 sectors
st0 at scsibus0 targ 4 lun 0: <TANDBERG, TDC 3800, G03:> SCSI1 1/sequential removable
vme0 at syscon0 offset 0x85000
vme0: A16 0000-ffff
vme0: A24 000000-ffffff
vme0: A32 40000000-7fffffff
vme0: A32 90000000-fdffffff
/dev/ksyms: Symbol table not valid.
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
boot device: le0
root device (default le0): sd1a
swap device (default sd1b):
root on sd1a swap on sd1b dump on sd1b
OpenBSD snapshots are now built on a regular basis.
I don't know yet how I can conveniently make binaries available. In the meantime, feel free to contact me if you want them.
They are very similar to the 400 series, but with a completly different interrupt engine. I have added blind support for these series recently (2024), and am now looking for testers (or machines).
Graphics are not supported yet. SCSI is limited to PIO only.
The second UART in the "dual UART" models (300D, 300CD) is not supported yet, but this ought to be quite easy if someone has such a machine and can test kernels.
The design is based upon the well-known MVME188 design, with different devices.
Graphics are not supported yet. SCSI is limited to PIO only.
These are the systems I have (both a dual-processor 4605 in working condition and a single-processor 530 with graphics, waiting for a PSU repair at the moment). Here is the pdf documentation (which does not describe the 6:1 CMMU configuration with enough detail, though, but I eventually figured it out).
Graphics are not supported yet.
These machines may eventually run as well, but
lack of on-board device support could be a showstopper.
It seems that every device but the serial ports are VME boards.
Chris Tribo has documentation, who has machines?
These machines are apparently close enough to the 5000 design. We have documentation (which unfortunately does not explain L2 behaviour, and how to manage it, assuming it is not snooping to be coherent with L1). Who has machines?
I don't know if there are other 88100-based models (besides 8500 and 9500 series). They won't likely be supported anyway unless we know more about them, or someone is willing to test kernels and let me tinker...
These will necessarily use a different hardware design for which there might not be enough documentation (a quick glance already shows the PROM SCM interface is different from 88100 based designs) to be able to support them. Some reverse engineering work of DG/UX is likely to be required. Hard to tell without working hardware anyway!
It just need to be taught the DG jumper settings. The factory defaults are to set the dual-ported RAM at A32 0x00900000 (A24-compatible), and the short I/O space at A16 0x4000.
On Chris' machine, the dual-ported RAM is at A32 0x55900000, which matches one of the on-board Ethernet settings on series 5000.
There is an almost-MI driver for it on mvme68k and mvme88k ports, which I intend to eventually port (by completing my new MI VME code and have all VME-capable ports switch to it).
This effort owes a lot to Chris Tribo, for his publication of crucial parts of the hardware documentation, as well as countless hours of testing, and coping with my mistakes. If he had not started publishing key parts of the series 400 hardware documentation a few years ago, I would never have realized how close to the MVME188 the 88100 AViiON design was, and I would never have started this effort. After that, all it took was a boring day with no better thing to do than do a blind port to hardware I did not have... (-: