Updated 20191124
Help yourself!
Despite what has happened a bit more than five years ago, I am still tinkering
with the OpenBSD codebase, to the point I'm seriously considering resuming
maintainence of it, but outside the OpenBSD umbrella.
I am currently building a release built upon the OpenBSD 6.6 codebase, with a
few features disabled (no kernel relinking or shared library randomization at
boot) because their cost is not acceptable on slow hardware.
The MVME327 and MVME328 SCSI drivers are currently disabled, as I need to rework
them to fit the current state of the OpenBSD midlayer. Which means MVME141 and
MVME165 will have to run diskless for the time being. I hope to fix this soon
(and publish my code).
The mvme68k port will be dropped from OpenBSD after the 5.5 release (and has already been removed from the trunk). It was not worth the effort anymore.
MVME147 boards switch to the machine-independent WD33C93 SCSI driver, finally!
I had been plotting this for years, but did not find time to write the new MD
backend (and test it) until today.
Next item on the mvme68k todolist is to port the new mvme88k S-Records boot
loader. This would allow MVME141 and MVME165 to boot from S-Records (as
well as later 162/166/167/172/176/177, but those are supposedly able to
netboot already).
It's been a long time. mvme68k systems are still running peacefully, but as ELF citizens now!
Kernel parts commited. Now I need to clean rough edges and work on the s-records code.
Been playing with s-records a bit. The 141 will happily load and run the code, but it needs to be taught how to handle MVME376 boards of course. On 165 (and apparently all 16x/17x boards), loading sboot will hang the machine. It turns out that we are stomping over the BUG image in memory, so I need to relocate the code elsewhere. 1MB instead of 16KB should be fine on all boards.
MVME141 kernel polished; now I need to work on a proper installation
sequence, since apparently neither the 141 nor the 165 can netboot, and
the current s-records bootloader is 147-specific.
I'll probably work on an improved s-records bootloader able to netboot
off MVME376 boards, which should be enough to netboot an installer on
these boards, for people who can't create bootable tapes.
A good night of thought, sometimes, is all you need. I figured how to tame
the MVME141 board this morning. Since it has no timer source, we have to use
the one found on the MC68681 chip which provides the two serial ports - this
is similar to how statclock is found on MVME188.
And then, it was somehow obvious how to debounce the abort switch interrupt,
which was stuck yesterday.
A bit more tinkering to enable the use of the 32KB onboard memory as
cache (since main memory is on the VME bus, access to it is uncached), and I
was happily running in single user mode.
However the clock was running too slowly, by a factor of 16.
After all, there is always a bug ahead...
After toying with my boards recently,
I figured I could document work in progress in mvme68k land as well.
Almost 3 years ago, I wrote code to support the MVME165 board, which has
a specific interrupt logic, completely alien to the other MVME1x2 and MVME1x7
boards. However, when I gave that code a try, the kernel hung very early at
boot, without being able to output anything to the console.
A few days ago, I figured this was caused by a stupid typo in my code
causing the kernel to send output to the wrong serial port address. With
this minor issue fixed, the kernel worked fine - except for another bug
in clock programming, causing the clock to interrupt every 100 nanosecond
instead of every 10 millisecond. Yet the machine was running, its clock
going mad in the future. Nothing a few edit-compile-test cycles couldn't fix
(I had to fix the reboot sequence as well).
OpenBSD 5.5 is the last release.
Between releases, -CURRENT snapshots are available and will occur on
a regular basis.
Supported cards:
Not supported yet: