(Follow this link to go back to the main m88k page, and this link to go back to the previous part.)
Did you notice a new name in the To: line of one of the previous emails? This is because, a few days before, out of the blue, Paul Weissmann had pointed me to Kenji Aoyama's work on porting OpenBSD to the Luna-88K!
Date: Sun, 14 Mar 2004 19:18:50 +0000 From: Miod Vallat To: Paul Weissmann Subject: Re: openbsd/luna88k > seen this already: > <http://www.nk-home.net/~aoyama/luna/openbsd-luna88k.html> Wow, what a pleasant surprise! I'm contacting this guy asap... Thanks for the hint Miod
<miod> omfg. http://www.nk-home.net/~aoyama/luna/openbsd-luna88k.html
<beck> holy crap miod.
<beck> I bet that site just gives you a woody wishing you had one.
<miod> not even.
<deraadt> luna heh
<beck> I've never seen one.
<miod> only seen pictures too
<drahn> hey if that luna88k has a 1280x1024 mapped display, wsfb could be
made to run on it reasonably easily.
<miod> i suppose so - the guy has wscons for the console after all.
<miod> i'll contact him and ask him whether he wants to share the code.
<miod> but he's more into netbsd.
[...]
<miod> ok, contacted the luna88k guy, since it's about to be monday morning in .jp...
<miod> ... and it bounced )-:
<pval> w/ "sun not up yet" ?
<miod> no, some ipv6 error. 2nd try seems to have been successfull though.
ASAP, on this day, apparently meant "about three hours":
Date: Sun, 14 Mar 2004 22:33:44 +0000 From: Miod Vallat To: Kenji Aoyama Subject: OpenBSD/luna88k Hello, I am the person responsible for most of the m88k code activity in OpenBSD lately. A friend of mine just pointed me to your OpenBSD/luna88k port page, and I must say I am quite impressed by your work. Would you be interested in publishing this code, so that it can be commited to OpenBSD's CVS tree and improved there? If so, I'll start splitting the current OpenBSD/mvme88k codebase into common m88k code, and mvme-specific parts, in order to ease the integration work. You might also be interested knowing that my post-3.5 todo list for OpenBSD/mvme88k includes a full bus_space/bus_dma implementation (though you might have already one, to port the NetBSD/luna68k drivers), and SMP work. Also, your sample dmesg shows some parts of your tree are a bit outdated (since the copyright line ends in 2003) - you should make sure you have at least pmap.c 1.107 (1.110 preferred), or you'll encounter nasty bugs while building the system... Looking forward for your reply, Miod
The answer was quite positive, as expected.
Date: Tue, 16 Mar 2004 10:43:31 +0000 From: Miod Vallat To: Kenji Aoyama Subject: Re: OpenBSD/luna88k > I am very glad to receive an E-mail from you, the mvme88k port > maintainer. Without your GCC work, my luna88k did not revive. Thanks! The road to a good compiler is still very long - at the moment -O2 is broken with gcc 2.95, and the problem looks like a known gcc 2.95 bug, which has been fixed in gcc 3; however, gcc 3 will not work at all on mvme88k, because the md parts have not been fixed to meet gcc 3 requirements... I'm working on this as time permits. > Of course yes. At this moment there are so many quick and dirty > codes, but I would like to publish them in the near future. I will > tell you when I finish some cleaning and I am ready. Is it better to > let you see my codes before publishing? Quick and dirty code which works is always better than no code at all, and can be improved once it's in the tree. Don't feel pressured, though, although I'd love to see your code ASAP, I am working on release work at the moment. The tree will be unlocked around mid-april, maybe slightly earlier, which would be the perfect time to import your luna88k work. > Thank you very much for your advice. Now my OpenBSD/luna88k uses > OpenBSD/mvme88k binaries as of August or September 2003. Yes, I need > to catch up to -current source... Oh, definitely. I have fixed a lot of bugs in libc and in the kernel since then! When looking back, we've been quite lucky that the 3.4 codebase worked so well... > Again, thank you very much for you mail. You're welcome. Miod
While Kenji Aoyama was now working on updating and cleaning up his code, I was working with Peter Valchev on the ports packages builds for the upcoming 3.5 release.
The build logs had their fair share of failures, including some ICEs (internal compiler errors), which I started to investigate.
Most of them were caused by unusual C code, such as the use of bitwise operators instead of logical operators in transfig or teTeX:
When optimizing a logical arithmetic operation, which operands are both
comparisons using different operators, make sure to generate an insn
with the correct mode.
This means that constructs like
if (c != -1 & i < 9999)
and
if ((i<=7) | (value != 0))
as found in transfig and teTeX, respectively, will now compile with
optimization.
Note the single & or | in these constructs - this kind is rare enough for
this bug to have remained unnoticed until now...
In GO_IF_LEGITIMATE_ADDRESS(), use RTX_OK_FOR_BASE_P() to check for a valid base register for indexed addressing, rather than providing an incomplete inline version. This allows constructs such as (plus:SI (reg:SI (subreg:SI (reg:DI 1)))) to properly pass through the reload phase if optimization is enabled. Such a construct can be generated with buf[index + index2] = value; if either index or index2 are long long. Fixes the ICE in zsh Src/Zle/computil.c.
Meanwhile, the OpenBSD/luna88k work was making good progress.
Date: Tue, 13 Apr 2004 21:31:56 +0000 From: Miod Vallat To: Kenji Aoyama Subject: Re: OpenBSD/luna88k Hello, I have seen you have updated your OpenBSD/luna88k status page. I'm glad to see that you are running more recent code now! Can you give me a rough estimate of when you intend to publish your code? Regards, Miod
Date: Sat, 17 Apr 2004 21:43:07 +0000 From: Miod Vallat To: Theo de Raadt Subject: OpenBSD/luna88k The developer eventually published his code; I sent him minor changes and bugixfes. [sic] When he'll report my diffs work, I would like to commit this in our tree. And of course he will want to continue working on this... are you willing to give him an account for this? dmesg, code, boot session logs, everything is available: http://www.nk-home.net/~aoyama/luna/openbsd-luna88k.html Miod
Date: Sat, 17 Apr 2004 23:14:27 +0000 From: Miod Vallat To: Kenji Aoyama Cc: Theo de Raadt Subject: OpenBSD cvs account Theo is thrilled by your work, and would like you to send him a blowfish password line as soon as possible... Miod
The OpenBSD/luna88k port was then imported on april 21st by Kenji Aoyama himself.
In may, out of frustration at not being able to get the 88110-based MVME197 running, I undressed my MVME197 boards to spank them:
Date: Wed, 5 May 2004 21:19:14 +0000
From: Miod Vallat
To: Paul Weissmann
Subject: mvme197 trivia
Hello,
I finally have been curious enough to remove the metal covers for all
my 197 boards, and look at what was under... So for the first time, I
have met a 88110, face to face!
Ok, actually I needed to know which clock was the SCSI chip on the
various 197, I was not sure whether it was 2xCPU MHz a la 187, or fixed
50 MHz a la 177, or 1xCPU MHz (turns out this was the latter).
The fun part is that, the difference between a 40MHz 197LE and a 50MHz
197LE is... only a clock! The 40MHz one has the same "XC88110RS50E"
processor as the 50MHz model. This backs up the fact that the early
models were 40MHz because of reliability issues, while the goal always
had been to ship 50MHz processors ONLY.
For the record, here are my processor numbers:
XC88110RS50E
72E66S
CWE319424 for both 197LE
CANADA
XC88110RS50E
72E66S
CWE369433 for both CPU of my 197DP
CANADA
XC88410RS50E
70F37G
CWE249436 for both 88410 of my 197DP
CANADA
Miod
With the import of the luna88k port, I started to work on factoring the common parts (which had been duplicated as part of the luna88k porting effort) and move them to a common location, sys/arch/m88k. Things were getting better, kernels were becoming more reliable, and I asked Mark Kettenis for help in getting proper m88k support in gdb. In return, he asked for details on the function calling convention on that platform.
Date: Sat, 22 May 2004 00:10:44 +0000
From: Miod Vallat
To: Mark Kettenis
Subject: m88k calling convention
Ok, you asked for it... here is a very short description of the 88100
registers and the calling convention. The 88110 is a superset of the
88100, but is not correctly supported under OpenBSD yet, and to the best
of my knowledge has never been supported by binutils.
- general registers: r0-r31
r0: always zero
r1: return address (return from subroutines are simply "jmp r1")
r2-r9: first 32 bytes of function arguments (see below)
r10-r13: scratch registers not preserved across function calls
r14-r25: scratch registers preserved across function calls (saving
and restoring them is the responsibility of the callee)
r26-r29: ABI reserved, not necessarily preserved across function
calls
r30: frame pointer
r31: stack pointer
except r0 and r1 usage, all of this is a _software_ convention - an
embedded system could choose different usage, but gcc honours this
ABI.
- control registers: cr0-cr20, fcr0-fcr63
these are control registers and their use is not possible in user mode
(i.e. not supervisor mode), except for fcr62 and fcr63 which are the
floating point status and control register, respectively, and are not
privileged.
- calling convention: arguments
Theoretically:
- the first arguments are passed through registers r2-r9, then the
remainder is put on the stack.
- long long or long double (8 bytes, hence 2 registers) are aligned on
an 8 byte boundary on stack (of course) or an even register number
when passed in registers. i.e. foo(int, long long) causes the first
argument to be passed in r2, and the second in r4 and r5; r3 is not
used.
- arguments larger than 8 bytes (hence 2 registers) are passed on
stack.
- arguments passed on the stack are aligned to their natural
alignment, without exceeding 8 bytes (i.e. arguments of 4 bytes or
less and arrays of them are aligned to 4 bytes, everything else goes
8 bytes). Nothing new.
In practice, all of this applies, plus:
- there have been several bugs in gcc/m88k (see FUNCTION_ARG and
FUNCTION_ARG_ADVANCE history), so older compilers will not respect
this in all cases.
- due to the way varargs work, any argument of 32 bytes or larger
(which will be passed on the stack) causes every subsequent argument
to be passed on the stack, even if not all registers are used
- it is legal to have arguments in registers, then on stack, then on
registers. Although right now a bug in gcc causes a second set of
arguments passed on the stack to be misread via va_arg().
- calling convention: return value
- if the return value is an int or any type of 4 bytes or less, it is
returned in r2.
- if it needs 8 bytes but is not a structure (long long, long double),
it is returned in r2 and r3.
- if it is a structure, it is returned on the stack, in an area pre
allocated by the caller, which address is passed in r12.
- stack management
- the caller is responsible for allocating stack for the arguments
- prologue/epilogue
A sample routine code will be as this:
subu r31, r31, locals ; allocate room for local variables
st r22, r31, 0 ; save r22
st r23, r31, 4 ; save r23
st r24, r31, 8 ; save r24
...
or r2, r0, r0 ; r2 = 0
ld r3, r31, offset ; r3 = something on stack
br subroutine ; subroutine(r2, r3)
...
or r2, r0, r0 ; return 0
ld r24, r31, 8 ; restore r24
ld r23, r31, 4 ; restore r23
ld r22, r31, 0 ; restore r22
addu r31, r31, locals ; restore stack
jmp r1 ; and return
Of course, when optimized, it will use delay slots, double stores,
etc, so that this looks like RISC assembly code, not a scholar
assignment...
Miod
Proper m88k support for OpenBSD in gdb was then implemented by Mark Kettenis during the next few days.
Meanwhile, I was still trying to get the compiler optimizations to work at -O2.
Date: Wed, 7 Jul 2004 22:07:33 +0000
From: Miod Vallat
To: Theo de Raadt, Kenji Aoyama
Subject: gcc scares me
m88k, kern_fork.c -O2, comments by hand:
[...]
global _fork1
type _fork1 , @function
_fork1:
subu r31,r31,96
st.d r22,r31,64
or r22,r0,r2 ! p1
st.d r20,r31,56
or r20,r0,r3 ! exitsig
st.d r18,r31,48
or r19,r0,r4 ! flags
st.d r14,r31,32
or r14,r0,r9 ! retval
or.u r13,r0,hi16(_maxproc)
or.u r11,r0,hi16(_nprocs)
ld r9,r13,lo16(_maxproc) ! maxproc
ld r10,r11,lo16(_nprocs) ! nprocs
or r15,r0,r5 ! stack
or r18,r0,r7 ! func
st.d r16,r31,40
or r16,r0,r8 ! arg
st r1,r31,80
st.d r24,r31,72
st r6,r31,112 ! stacksize
ld r12,r22,16 ! p1->p_cred
subu r13,r9,5 ! maxproc - 5
cmp r13,r10,r13 ! vs nprocs
ld r23,r12,4 ! p1->p_cred->p_ruid
bb0.n ge,r13,@L174 ! nprocs < maxproc - 5 > L174
or r21,r0,r11 ! hi16(_nprocs)
@L174:
bcnd.n ne0,r23,@L253 ! uid != 0 > L253
or.u r2,r0,hi16(_lasttfm.114)
[...]
[...]
The last [st instruction] is wrong. It saves a value in an unnamed
local variable, except not at a correct stack location.
All the time we were running at -O0 or -O1, gcc was not aggressive
enough to eventually store data in its own allocated locals. So we did
not hit that bug.
It took me countless hours of comparing various kern_fork.s outputs with
various options, which all were correct, until I realized that the only
real diff between them was that -O2 would put stacksize in a newborn
stack local...
I have no idea how much time it will take me to fix this. In the
meantime, -Os or -O2 -fno-gcse seem to always behave. At least for most
of the C files you can throw at the compiler.
Miod
After many unsuccessful attempts at solving this problem, I admitted defeat and used a large hammer to solve my problem: remove the feature I could not make work, in this case, the 32 bytes of stack reserved for function call arguments being passed in registers (REG_PARM_STACK_SPACE.) This was however an ABI-breaking change.
Date: Mon, 12 Jul 2004 22:37:09 +0000 From: Miod Vallat To: Theo de Raadt, Kenji Aoyama, Henning Brauer Subject: Pending gcc/m88k changes Here is a preview of the gcc diff I am working on since, oh, a whole week. This basically rewrites the stack usage to be more sane, and avoid the "store nameless locals outside your own stack frame" problem we have for example in kern_fork.c!fork1() when compiling with -O2. The bad part is that change, in turn, requires the varargs/stdarg code to be rewritten (both caller code, callee initialization, and va_foo() macros). This is the real hurdle and the reason why it took me so much time for so few lines of code. A compiler built with this diff, not only will use systematically less stack space (at least 32 bytes per function call, and often more for stdarg or varargs functions), but will also pass a complete stdarg/varargs regression suite (consisting of most of the gcc testsuite varargs tests, as well as a few of my own), whereas the in-tree compiler was still failing on one test. Of course, there is a chicken-and-egg problem to bootstrap this correctly, as this breaks the ABI - not that we care much about non-OpenBSD m88k systems anymore now... Don't try this diff at home! I don't need you to test it now, though you might want to read it and comment if you feel brave. The reason why I am mailing it out is that I know from experience that, at some point, I can't find bugs in my diffs until I have mailed them out, which I am doing now, hoping I will see the light. I have not yet produced a working kernel with this diff anyways - until this morning, my kernels would die in printf() due to this #$%@! varargs code, which caused me to basically rewrite the whole diff this evening... There are a few minor optimizations in the diff as well, which I might commit earlier to make the final diff more readable. Oh, and there is no way this will go in ``as is'', since the last two lines of __va_start_common() can now be moved to the compiler side, which will result in shorter code. And now I'm going to sleep (-: [...]
Date: Thu, 22 Jul 2004 09:22:35 +0000
From: Miod Vallat
To: Kenji Aoyama, Theo de Raadt, Henning Brauer, Nick Holland
Subject: new OpenBSD/mvme88k snapshot available
Hello,
a new snapshot is available in cvs:~miod/mvme88k as usual, from
sources of about 72 hours ago, plus the latest gcc changes.
I hope this will be the last snapshot before the ABI change. My gcc diff
seem to be solid enough now; I have rebuilt some parts of the system in
order to test the bootstrapping procedure, and it works well.
You will find the diff below; here is an explanation of it.
The 88Open ABI mandates that every function call reserve a 32 byte area
on the stack, so that parameters passed through the registers (r2-r9,
hence 32 bytes) can be also passed on the stack in this area, should the
compiler decide so (the canonical exemple being functions with a
variable number of arguments).
This is why every C function call from assembly code had to make room
for 32 bytes on the stack, even if it was not passing any argument on
stack...
Our real problem is that the compiler would rely upon the existence of
this area to also put temporaries in it... and this triggers a shitload
of minor issues, which sometimes cause bad code to be generated.
If you remember our kern_fork.c problem of the last month, gcc at -O2
would eventually put a temporary on the stack, 16 bytes over the stack
pointer as it was when the function was called:
sub r31, r31, 96
...
st r6, r31, 112
This was harmless, because this was in this 32 byte area, and was not
cloberring valuable data from the caller. However, this was not the
place where the compiler intended to put the variable...
So the diff below defines this area to being 0 bytes now, which makes
all computations correct, at the expense of breaking the 88Open ABI,
which I don't care about - I'd trade an official ABI against a working
compiler anytime...
Because of this, it becomes impossible to mix old code and new code,
since they use different stack layouts. But as m88k are still using
static libraries, it is relatively easy to get past this hurdle.
Once a system with this diff completes two builds in a row, I'll put
this in the tree.
The fastest upgrade path should be:
- apply diff
- rebuild C compiler
cd /usr/src/gnu/egcs/gcc
make -f Makefile.bsd-wrapper -DBOOTSTRAP clean depend all install
- make new includes
cd /usr/src
make includes
- make new libc and libiberty
cd /usr/src/lib/libc
make NOMAN= clean all install
cd /usr/src/gnu/lib/libiberty
make -f Makefile.bsd-wrapper clean depend all install
- rebuild all compilers
cd /usr/src/gnu/egcs/gcc
make -f Makefile.bsd-wrapper clean depend all install
- rebuild whole system
cd /usr/src
make build
- enjoy a slightly faster system (less stack usage, hence fewer page
faults to grow the stack) with slightly shorter binaries (less stack
management instructions) !
Miod
[...]
These changes were committed on july 28th.
After that, I spent some time again on MVME188 support. The systems which had been tested, first by Steve Murphree, then later by me, were the "common" 2P256 systems, with 2 processors having a pair of 88204 CMMUs each, for a total of 256KB of cache memory. I wanted to check that all my HYPERmodule processor daughterboards were in working condition; and one of them is a 2P128, with two processors, each connected to four 88200 CMMUs, for a total of 64KB of cache memory per processor. As usual for 88100 designs, half the CMMUs are used for instruction cache and MMU, and the other half are used for data cache and MMU.
This had the interesting side effect that, when a memory fault occurred (because a memory page was not mapped yet, or a copy-on-write page was written to for the first time and needed to be marked "dirty"), the fault was reported by the CMMU which detected it, and this might not be the first one... in this case, the kernel, when servicing the exception, would not find anything to do, and would fault again immediately upon return from the exception handler, causing the userland process to be stuck.
Once I recognized that condition, I put a quick fix to let that particular board run.
But this was not enough, as if the second CMMU faulted after the first one had faulted, the kernel would still read fault status from the first CMMU, and attempt to service that fault again; this proved that fault registers had to be cleared after being read.
A final cleanup made the 2P128 HYPERmodule run multiuser reliably.
From then on, there was not much m88k related activity in OpenBSD, besides the occasional bugfix, and a bit more factorization of code common to luna88k and mvme88k.
In 2005, I was busy with quite a lot of real-life considerations which distracted me from working on OpenBSD as much as I would have liked to. I somehow found time to start working on SMP support for the MVME188 systems during the summer; the first bits of it were committed in december, with the multiprocessor kernel able to spin up all the processors of a MVME188 system, and reach single-user mode. But the kernel would not run for long until it would panic in random ways, showing that much more work was needed.
With the revival of the mvme88k port, and more recently the addition of the luna88k, I was being asked, from time to time, whether I would be interested in porting to the Data General AViiON systems.
Every time, I would politely answer that I was not interested in AViiON hardware. (The main reason being that, apart from a few entry-level systems running only at 16.67 or 20MHz, such as the AV300 pictured at the beginning of this story, these systems are deskside chassis and take much more room than the MVME boards.)
This topic was also recurring on the port-m88k NetBSD mailing list. Allen Briggs, a NetBSD developer (who had also been involved in OpenBSD in the early years), was really fond of AViiON hardware after having completed an internship at Data General a long time ago, and was longing for a BSD port to these systems (preferrably NetBSD, of course.)
In april 2006, I was idling between jobs for a short while, and nedeed a short project to keep me busy.
I remembered that, in autumn 2003, Chris Tribo had published part of the programming documentation for AViiON 400 systems on his own page.
Glancing through these documents, I quickly realized that it was very close to the MVME188 design, albeit with a slightly different interrupt controller (and either on-board processors, or processor daughterboards being different from Motorola's HYPERmodule series for the MVME188.)
With the MVME188 support in good state, I thought this could be a fun project for a few days... as long as I could get someone with the appropriate hardware to agree to test my work.
Date: Tue, 18 Apr 2006 21:16:11 +0000 From: Miod Vallat To: Chris Tribo, Allen Briggs Subject: BSD on DG AViiON Hello folks, shortly after Chris had posted his AV400 documentation snippets, I had a look and realized that the DG design is largely based upon the MVME188 design. So all it took was an afternoon of me being bored and in the mood for marginal hacks, and I got an OpenBSD/dg88k kernel off the ground. Of course, this is not the NetBSD kernel you guys would like to see, but this can be a convenient start. Plus, as long as I am working on this, I am not working on the ELF toolchain Allen is waiting for (-: But then, this is pure theoretical work so far - I don't have any DG hardware here. While this kernel has good chances to work to some extent, I wouldn't be surprised if it would need some touches to really work. And then the documentation on Chris' site is not enough to get anything but serial ports going on an AV400 - either the onboard ethernet is wired to trigger a fixed interrupt, which value I don't know, or there are other registers needed to control its interrupt, and they don't appear to be documented. Before I invest more time in this, I would like to know if you guys are interesting in playing with this. If you still have sort-of-working DG/UX setups on your 4xx/4xx0, I wouldn't mind getting a tarball of it (or at least important sources of knowledge, such as /usr/opt/sdk/ or /usr/include, /usr/stand/, /usr/src/, /dgux, /etc/dgux.*), this may shed more light on the hardware. And then I'll cook a simple a.out to ECOFF kernel translation tool, so that you can attempt to netboot it, and see how far it goes until it crashes. And how much of my debug printf it will spit. Miod PS: Here's a teaser... this is just a timid start to get the 88100-based 400 and 4k series to run. [...] miod@arzon OpenBSD/mvme88k [/usr/src/sys/arch/dg88k] $ cat conf/GENERIC # $OpenBSD$ # # For further information on compiling OpenBSD kernels, see the config(8) # man page. # # For further information on hardware support for this architecture, see # the intro(4) man page. For further information about kernel options # for this architecture, see the options(4) man page. For an explanation # of each device driver in this file see the section 4 man page for the # device. machine dg88k m88k include "../../../conf/GENERIC" maxusers 32 # estimated number of users # Processor type option M88100 # Supported models option AV400 # 400, 410, 41x0 # Define this if your processor has the xxx.usr bug (mask C82N) option ERRATA__XXX_USR config bsd swap generic # # devices # mainbus0 at root # AV400 onboard devices syscon0 at mainbus0 addr 0xfff00000 clock0 at syscon0 ipl 5 nvram0 at syscon0 offset 0x80000 dart0 at syscon0 offset 0x82000 ipl 3 #vme0 at syscon0 offset 0x85000 #avfb0 at syscon0 offset 0x89000 #aic0 at syscon0 offset 0x8a000 le0 at syscon0 offset 0x8c000 #vmes0 at vme0 #vmel0 at vme0
Chris Tribo told me he would be interested in testing, and then I started coding. Less than one week later, I had a kernel waiting to be tried.
Date: Mon, 24 Apr 2006 18:56:35 +0000 From: Miod Vallat To: Chris Tribo, Allen Briggs Subject: First dg88k binary to test Hello, after enough tinkering and coping with m88k specific changes to the ECOFF binary layout, I came with a binary which will hopefully be able to display a few things before it dies. Could you give it a run on your machines? You can fetch the binary from http://XXX.XXX.XXX.XXX/dg88k/bsd-ecoff (there is a link from http://XXX.XXX.XXX.XXX/dg88k/ as well). The kernel will use the PROM console services for the first messages, which will honour your console settings. then assuming it runs smoothly and probes the on-board ethernet and serial ports, it would switch to its own routines which are serial-only for now, and panic for not being able to find which device it has been booted from and where its root device is. I'd suggest configuring your machines for serial console anyway, so that you can send me a log of what happened with all the messages. Hoping the kernel will not die so early it won't be able to print anything... Thanks for testing, Miod
Of course, it was to be expected that things would not be that easy. First, I had to tweak my a.out to ECOFF binary converter a few times to get the PROM to accept the file as being worthy of load and execution.
Then, the kernel died very early, and it took me few tries in order to be able to reach the point where printf in the kernel would work.
From then on, I could at least let the kernel tell me what it was doing.
Of course, living in different timezones, there was quite some latency; I would usually send Chris Tribo my latest kernel in the evening (in Europe), for him to tinker in the evening (in USA); I would read his feedback for breakfast, tell him what I thought of it, have the whole day to think some more, and work on a new kernel in the evening.
After three days, I had the kernel running happily until it was time to enable the MMU, at which point it would crash, because I had not mapped the serial port correctly.
That took some time to figure out, and on may 7th, the kernel was still panicing, but this time with the MMU enabled. Since this was a sunday, Chris Tribo had more time available, and I could have him try my kernels almost in real time, with one new kernel about every 30 minutes. In the evening, the kernel had run much further, and was now panicing upon receiving its first clock interrupt.
I reworked that code on monday, and in the evening, I received that success message.
From: Chris Tribo
Date: Mon, 08 May 2006 21:23:05 -0400
To: Allen Briggs
Cc: Miod Vallat
Subject: Welcome to multiuser
Allen Briggs wrote:
>On Mon, May 08, 2006 at 06:35:58PM -0400, Chris Tribo wrote:
>>I've made it that far, I see a call to mountd on the NFS server and then
>>the client panics with nfs_boot: mountd root, error=13 which probably
>>indicates an error in configuration on my end.
>
>Ensure that you're exporting the root of a filesystem or
>have -alldirs if you're using *BSD as the NFS server.
Yeah I had a silly exports entry I had to fix, and here's the result
(after me editing /etc/rc to not to try to create openssh and openssl
keys because that was taking an eternity on a 20 MHz CPU)
Hooray! Beers for Miod next time I'm in France!
Booting inen()
Local Ethernet address is 8:0:1B:18:3C:FD
Local Internet address is 192.168.1.155, or C0A8019B hex.
Trying server at 192.168.1.1, or C0A80101 hex for TFTP transfer.
[PROM banner at 0x27ff4c4: ]
CPU0 is associated to 2 MC88200 CMMUs
CPU1 is associated to 2 MC88200 CMMUs
[ 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-2006 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 3.9-current (GENERIC) #32: Mon May 8 10:32:20 GMT 2006
miod@arzon.gentiane.org:/usr/src/sys/arch/dg88k/compile/GENERIC
real mem = 41943040
avail mem = 33697792 (8227 pages)
using 537 buffers containing 2199552 bytes of memory
[Boot device information: args 0x27ff37c (inen()) dev 0 unit 0 part 0]
mainbus0 (root): , cpuid 0x7908
cpu0: M88100 rev 0xb, 2 CMMU
cpu0: M88200 (16K) rev 0x9, full Icache, M88200 (16K) rev 0x9, full Dcache
syscon0 at mainbus0 addr 0xfff00000
nvram0 at syscon0 offset 0x80000 ipl 0: MK48T02
dart0 at syscon0 offset 0x82000 ipl 3: console
le0 at syscon0 offset 0x8c000 ipl 1: address 08:00:1b:18:3c:fd
le0: 32 receive buffers, 8 transmit buffers
vme0 at syscon0 offset 0x85000 ipl 0
vme0: A32 10000000-7fffffff
vme0: A32 90000000-fdffffff
vme0: A24 fe000000-feffffff
vme0: A16 ffff0000-ffffffff
boot device: <unknown>
root device : le0
/dev/ksyms: Symbol table not valid.
nfs_boot: using network interface 'le0'
nfs_boot: client_addr=192.168.1.155
nfs_boot: server_addr=192.168.1.1 hostname=AViiON.
root on 192.168.1.1:/home/exports/av400/root
swap on 192.168.1.1:/home/exports/av400/swap
Automatic boot in progress: starting file system checks.
setting tty flags
ddb.console: 0 -> 1
kern.splassert: 0 -> 2
starting network
starting system logger
starting initial daemons:.
swapctl: adding 192.168.1.1:/home/exports/av400/swap as swap device at
priority 0
savecore: no core dump (no dumpdev)
checking quotas: done.
building ps databases: kvmkvm_mkdb: can't open /dev/ksyms
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.
starting local daemons:.
standard daemons: cron.
Mon May 8 21:09:00 EDT 2006
OpenBSD/dg88k (AViiON.) (console)
login: root
Password:
Last login: Wed Dec 31 20:43:51 on console
OpenBSD 3.9-current (GENERIC) #32: Mon May 8 10:32:20 GMT 2006
Welcome to OpenBSD: The proactively secure Unix-like operating system.
Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code. With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.
You have mail.
Terminal type? [unknown] vt100
# ls -al /
total 266292
drwxr-xr-x 15 root wheel 512 May 8 21:04 .
drwxr-xr-x 15 root wheel 512 May 8 21:04 ..
-rw-r--r-- 1 root wheel 578 Mar 3 10:51 .cshrc
-rw-r--r-- 1 root wheel 292 Mar 3 10:51 .profile
drwxr-xr-x 2 root wheel 512 Mar 3 10:51 altroot
drwxr-xr-x 2 root wheel 1024 Mar 3 11:30 bin
-rwxr-xr-x 1 root wheel 2142485 May 8 20:57 bsd
drwxr-xr-x 3 root wheel 12288 May 8 21:13 dev
drwxr-xr-x 18 root wheel 2048 May 8 21:13 etc
drwxr-xr-x 2 root wheel 512 Mar 3 10:51 home
drwxr-xr-x 2 root wheel 512 Mar 3 10:51 mnt
drwx------ 2 root wheel 512 May 8 20:00 root
drwxr-xr-x 2 root wheel 1536 Mar 3 12:30 sbin
drwxr-xr-x 2 root wheel 512 Mar 3 10:51 stand
-rw-r--r-- 1 root wheel 134086656 May 8 18:56 swap
drwxrwxrwt 2 root wheel 512 May 8 21:14 tmp
drwxr-xr-x 15 root wheel 512 Mar 3 10:51 usr
drwxr-xr-x 22 root wheel 512 Mar 3 10:51 var
# swapctl -l
Device 512-blocks Used Avail Capacity Priority
/swap 261888 0 261888 0% 0
# top
load averages: 1.38, 0.69, 0.2821:09:37
8 processes: 7 idle, 1 on processor
CPU states: % user, % nice, % system, % interrupt, %
idle
Memory: Real: 3084K/13M act/tot Free: 23M Swap: 0K/128M used/tot
PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND
15356 root 18 0 704K 400K sleep pause 0:02 4.00% ksh
16119 root 57 0 524K 376K onproc - 0:00 3.08% top
1 root 10 0 540K 240K idle wait 0:00 0.24% init
9229 root 2 0 412K 228K idle select 0:00 0.00% inetd
23848 _syslogd 2 0 524K 268K sleep poll 0:00 0.00% syslogd
30827 root 2 0 496K 336K idle select 0:00 0.00% cron
30683 root 2 0 1928K 760K sleep select 0:00 0.00% sendmail
13317 root 2 0 500K 268K idle netio 0:00 0.00% syslogd
# vmstat -i
interrupt total rate
irq3/dart0 172 1
irq1/le0 8437 49
irq5/clock 17076 100
Total 25685 151
# shutdown -h now
... the usual shutdown sequence progresses and then we hit a death trap
trying to halt to the SCM. Reboot seems to work however.
Shutdown NOW!
shutdown: [pid 23769]
#
*** FINAL System shutdown message from root@AViiON. ***
System going down IMMEDIATELY
System shutdown time has arrived
/etc/rc.shutdown in progress...
/etc/rc.shutdown complete.
syncing disks... done
( level 247 )
Jp#0 Trap occurred at 0xFFC00050: Trap on Frozen Shadowing - trap#10
( level 248 )
Jp#0 Trap occurred at 0xFFC00018: Data Access Exception - trap#3
( level 249 )
Jp#0 Trap occurred at 0xFFC00018: Data Access Exception - trap#3
( level 250 )
Jp#0 Trap occurred at 0xFFC00018: Data Access Exception - trap#3
( level 251 )
Jp#0 Trap occurred at 0xFFC00018: Data Access Exception - trap#3
( level 252 )
Jp#0 Trap occurred at 0xFFC00018: Data Access Exception - trap#3
( level 253 )
Jp#0 Trap occurred at 0xFFC00018: Data Access Exception - trap#3
( level 254 )
Jp#0 Trap occurred at 0xFFC00018: Data Access Exception - trap#3
( level 0 )
Jp#0 Trap occurred at 0xFFC00018: Data Access Exception - trap#3
( level 247 )
Jp#0 Trap occurred at 0xFFC00050: Trap on Frozen Shadowing - trap#10
( level 248 )
Jp#0 Trap occurred at 0xFFC00018: Data Access Exception - trap#3
[infinite loop of traps omitted...]
Apart from the system halt not behaving correctly, this made my day. And also proved that, with good enough programming documentation and a person willing to test, it is possible to blindly port a BSD kernel to a new platform!
(Don't get fooled by the kernel number in the log above, #32. I had reset the counter at some point, and there had been about 65 kernels before that, so this was closer to the 100th kernel being tried on Chris Tribo's machine.)
Of course, there would be a lot of work needed, as this was currently running diskless, with no support for the AIC-6250 SCSI controller yet.
It was time to make a good backup of my code, and, as Linus Torvalds would tell you, the best backup mechanism is to put your data into a source code repository which gets mirrored all over the world.
Enter OpenBSD/aviion, a port to the m88k-based Data General AViiON workstations. Currently restricted to diskless serial console, tested on AV410 only; many thanks to Chris Tribo for documentation and testing.
Date: Tue, 9 May 2006 22:31:49 +0000 From: Miod Vallat To: misc@openbsd.org Subject: new port: OpenBSD/aviion Hello, As you may have noticed, a new port has been added to OpenBSD's portfolio: OpenBSD/aviion, addressing the older (Motorola-based) Data General AViiON workstations - more recent models are x86-based and will run OpenBSD/i386 flawlessly. This port is unique amongst all the OpenBSD ports, as it has been written without access to the hardware it runs on. This has been possible because, unlike modern hardware, these machines used to come with enough hardware documentation to allow the motivated programmer to write code for it. In this particular case, the documentation hinted that the design was close to another hardware design OpenBSD runs on, so it was worth giving the port a try. In less than two weeks, despite living in different time zones, Chris Tribo (who owns an AV410 machine) and I could get OpenBSD/aviion booting multiuser. I would like to extend the hardware coverage of this port by supporting more models and more on-board devices. But as long as I do not have AViiON hardware and rely on other people for testing, development will not progress very fast, and will hit on our nerves. So if you have an unused AViiON machine in your Attic you have no real use for, or if you know someone who wants to get rid of his... please get in touch with me. This would definitely help this emerging port a lot! Thanks, Miod
Date: Wed, 10 May 2006 20:04:42 +0000 From: Miod Vallat To: Chris Tribo Cc: Allen Briggs Subject: Re: Welcome to multiuser Hello, a few news and plans... First, I have renamed the port from ``dg88k'' to ``aviion'', and commited it into the OpenBSD repository (with http://www.openbsd.org/aviion.html as the initial port page). I have moved my resource page accordingly, now on http://XXX.XXX.XXX.XXX/aviion/ (until I am moving back to XXX.XXX.XXX.XXX). Then, excellent news as well, I have found a copy of the AIC 6250 datasheet! Fetch it from http://pdfold.icpdf.com/2005-9-27/4951/AIC-6_IcpdfCom.pdf which is really slow, but you'll eventually get the 2800KB pdf file. I'll have no excuse to skip writing the scsi driver now (I hope you have a spare SCSI disk for testing, as I'd rather not have the driver touch a DG/UX disk until it is deemed stable and safe for use). My short term plan is to write a short, standalone network bootloader, so that you can move the kernel to the nfs root area, and keep it in the native a.out format. This will give us kernel symbols, which will kill some warnings while booting and give us better tracebacks in the debugger (this will really be necessary while debugging the scsi driver). Once it is ready I'll start working on the scsi driver. In the meantime, I found a stupid bug in the VME code, which explains why the Hawk board was not found on Chris' machine. A (hopefully) fixed kernel is currently compiling, I will upload it later tonight (no more than two hours after sending this mail). Miod PS: After browsing through the port-m88k@ archives, I'm going to contact more people to ask whether they are interested by this work (I don't want to brag on port-m88k@, because I don't want to upset anyone or risk yet another NetBSD vs OpenBSD flamewar). Do you want to keep this development discussion ``as is'', with maybe more people added over time, or do you want this to be moved to a mailing list, for your own mail processing convenience?
Allen Briggs mentioned that work on the NetBSD port-m88k list.
Subject: AViiON progress From: Allen Briggs To: port-m88k Date: 05/11/2006 17:44:48 Hi folks, Miod Vallet [sic] has been doing a fantastic job on an AViiON port of OpenBSD/m88k with Chris Tribo working as remote hands for him. It turns out that the DG systems, at least some of them, are quite similar to the Motorola MVME systems. He's had a mailing list set up, m88k@openbsd.org, and will be discussing the status, progress, etc., over there. There's also a port page at http://www.openbsd.org/aviion.html. I'm glad someone's had the time to work on this. I wish we could get Miod to contribute to NetBSD. :-) -allen
On may 13th, I added a network boot loader, able to boot a.out format kernels, without needing that fragile a.out to ECOFF converter (which was still needed for the boot loader itself, but nothing besides it.)
And then, besides some sarcasm in the OpenBSD developers chatroom, nothing happened.
<espie> yeah, aviion sure is an odd platform. ;-) <miod> although it has an even number of vowels. <mbalmer> not even the number of consonants is odd
Still not having been able to find any AViiON hardware, and being busy with too many things to do in OpenBSD and an ever-growing todolist, I paid the new port not much attention.
At some point, though, I built an OpenBSD/aviion snapshot... but on an mvme88k system, running a special kernel which would report the machine as aviion, rather than mvme88k, to the uname function.
Date: Sun, 25 Mar 2007 14:55:37 +0000 From: Miod Vallat To: m88k@openbsd.org Subject: OpenBSD/aviion snapshot available Hello folks, as the subject says, I have built an aviion snapshot, which is now available on the master ftp site, as well as a few mirrors. As I still don't have any aviion hardware myself, this snapshot has been built on an MVME188 machine (with a special kernel which lies to the utsname system call, so that `uname -m' correctly reports `aviion'). There have not been any progress wrt hardware support in this snapshot, so it is basically the same kernels as the one Chris Tribo tested last spring, however updated to recent sources (and gaining a few bugfixes in the process). I would like to resume work on hardware support; my short term projects are: - bring a few mvme188 bug fixes to the aviion codebase. - on-board SCSI support on the AV400. - AV530 support. However, it does not make any sense to work on this if the current kernel does not work. So, if anyone is interested by this work, please step in and give this snapshot a try, and report how it works for you. Thanks! Miod
The remainder of 2007 brought its share of bad news, with the power supply of Kenji Aoyama's machine failing. The m88k status update was not as positive as I would have liked it to be.
Date: Mon, 29 Oct 2007 21:55:13 +0000 From: Miod Vallat To: m88k@openbsd.org Subject: m88k news Hello folks, your favorite m88k looney here. It's been a while since there has been any activity on this list. I figured I could wake it up, if only to know if there are still m88k sympathizers left out there... So I'll begin with a short status of the various OpenBSD ports to m88k hardware. Consider this a ``state of the m88k nation'' of sorts. * OpenBSD/mvme88k There has not been much activity on this port over the last ~12 months, mainly due to the usual shortage of spare time. 187, 188 and 8120 systems are running well. Device support is quite decent, although more VME devices could be supported eventually. * OpenBSD/luna88k The luna88k machine of our luna88k port maintainer Kenji Aoyama, is unfortunately no longer operational. These machines being really hard to find, even in Japan, it is not sure whether he will be able to either find a new, working machine, or have his own repaired. This is really sad. On the other hand, those machines are getting close to 20 years old, which is quite impressive. I don't think today's computers, even high-end ones, will run for 20 years before falling apart. * OpenBSD/aviion This port is probably even more insignificant than the luna88k port (no offense intended to the few luna88k users). I have not been able to find any aviion machine in Europe, and the only m88k-based aviion spotted on eBay was a 88110-based model, for which we have no hardware documentation at all. I still have a few pending diffs, and need to complete support for the 500 series, since I know of at least two potential users, but the motivation for this work has been pretty low those days. * generic m88k I occasionally stumble on compiler bugs. The good thing is that they become more and more difficult to reproduce and track down (the last one I am currently working on can only reproduced one time out of 50+ identical binary code runs, and is currently narrowed to a single .c file, which compiler assembly output (a few thousand lines) I need to analyze). 88110 support is still a no-go. I am still stuck at the point 88110 support has been since basically the beginning: userland copy-on-write process does not work, and causes the copies to be empty pages. Needless to say, this causes binary to fail very quickly. The fix for this is probably a one-liner, but I have been missing it since years. Sorry if the above sounds pessimistic. The main issue, as usual, is spare time; I wish to have more time to spend on m88k hacking, but you (might) know that I am busy doing many other things in OpenBSD, and I'm trying to keep whatever is left of my so-called ``social life'' (oh, and I'm spending more time than ever in the kitchen cooking group meals as well, which is another thing I enjoy doing). But there are good things which have been brewing recently! Here's a list of them: * 88100 SMP I wrote the basics of 88100 SMP (for luna88k and mvme88k MVME188) a bit more than two years ago, while I was unemployed. This code eventually was commited, but it did not work. I finally found and fixed the major showstopper bug yesterday (the interested reader can look at sys/arch/m88k/m88k/trap.c revision 1.41), and now all what's left is fixing the other bugs. More seriously, a quad-processor MVME188 system will boot multiuser. There are issues with the le(4) driver, which eventually cause panics after the network is used for a while, which I am looking into; that's nothing which won't get fixed eventually. I will enable building bsd.mp once the SMP kernel is a bit more stable; look forward to seeing it in the next OpenBSD/mvme88k snapshots. * ELF Tim McIntosh has been silently porting the OpenBSD/mvme88k code to NetBSD, adding ELF support to binutils. This will hopefully prove a good codebase to build on to also move the various OpenBSD/m88k ports to ELF binaries in a not-so-far future. However Tim needs to submit his changes to the FSF and do the necessary paperwork, so that his work does not get lost. * gcc 3 In addition to ELF, Tim ported part of my gcc 2.95 fixes to gcc 3. Last time I tried this, the compiler did not bootstrap due to linker bugs, which are likely to be fixed with the switch to ELF. Note that I do not plan to switch the m88k ports from gcc 2.95 to gcc 3 any time soon, due to performance issues (and also because I know the gcc 2 bowels much better than the gcc 3 internals), but it would be nice to have as an alternative compiler (and some C++ third-party software from the ports collection could benefit from this). * 88110 support I still have a long list of ideas and thinks to tinker with, to make progress on the 88110 support. And now that 88100 SMP is getting there, I'd love to work on 88110 SMP support (which will need a fair share of extra work, because the remote tlb and cache operations are completely different). So I hope to be able to announce good news on this list during this release cycle, as more hardware gets supported. Long, dark winter nights are coming... perfect time to replace the furnace with a 4x88100 room heater! But this should not prevent you from giving a hand, as well. Any help improving the m88k ports is welcome! Miod PS: Below is the dmesg of a 4-cpu MVME188 machine. Not the fastest kid in the block, but it's nice to see it churning on all its processors now. OpenBSD 4.2-current (GENERIC.MP) #154: Mon Oct 29 19:40:35 GMT 2007 miod@arzon.gentiane.org:/usr/src/sys/arch/mvme88k/compile/GENERIC.MP WARNING: Board Configuration Data invalid, replace NVRAM and restore values real mem = 134217728 (128MB) avail mem = 125906944 (120MB) mainbus0 at root: Motorola MVME188-2, 25MHz cpu0: M88100 rev 0xb, 2 CMMU cpu0: M88200 (16K) rev 0x9, full Icache, M88200 (16K) rev 0x9, full Dcache syscon0 at mainbus0 addr 0xfff00000 nvram0 at syscon0 offset 0x80000: MK48T02 dart0 at syscon0 offset 0x82000 ipl 3: console vme0 at syscon0 offset 0x85000: system controller vmes0 at vme0 le0 at vmes0 addr 0xffff1200 ipl 3 vec 0x60: address 00:00:77:83:ac:56 le0: 128 receive buffers, 32 transmit buffers vs0 at vmes0 addr 0xffff9000 ipl 2 vec 0x61 vec 0x62: SCSI ID 7/7 scsibus0 at vs0: 8 targets sd0 at scsibus0 targ 0 lun 0: <COMPAQPC, , > SCSI2 0/direct fixed sd0: 2006MB, 7936 cyl, 255 head, 63 sec, 512 bytes/sec, 4110000 sec total scsibus1 at vs0: 8 targets vmel0 at vme0 boot device: sd0 root on sd0a swap on sd0b dump on sd0b cpu1: M88100 rev 0xb, secondary, 2 CMMU cpu1: M88200 (16K) rev 0x9, full Icache, M88200 (16K) rev 0x9, full Dcache cpu2: M88100 rev 0xb, secondary, 2 CMMU cpu2: M88200 (16K) rev 0x9, full Icache, M88200 (16K) rev 0x9, full Dcache cpu3: M88100 rev 0xb, secondary, 2 CMMU cpu3: M88200 (16K) rev 0x9, full Icache, M88200 (16K) rev 0x9, full Dcache
It took two more weeks of debugging until the SMP code was stable, with a final horrible workaround committed on november 12th.
More good news were to come, as I finally found the cause of the bug which had plagued 88110 systems since the very beginning!
When starting a new process (except init, which is a bit special), the 88110 pipeline was not configured to fetch instructions from the right place. As a result, the first two instructions of the binaries were skipped. Due to the way the libc runtime startup code was written, this caused it to use the wrong address for the struct where its command-line arguments and process environment were found; this would be mostly harmless until the program would try to parse its commandline, or use malloc, which looks for a MALLOC_OPTIONS variable in the environment.
This was fixed with a crude change on november 20th.
Fix setregs() on 88110, so that binaries do not skip their first instruction. Makes binaries beyond init(8) running on MVME197, to some extent.
And, as prophetized years ago, this was indeed a two lines change (comments notwithstanding.)
This change was however not good enough, and further games with the way the instruction pipeline was handled on 88110 were necessary.
Another horrible, yet necessary change, was applied to the sigreturn code path. Further 88110 changes related to the pipeline would add much more lines of comments to explain the intent of the code, as I knew from experience my future self from only a few months away would be horribly confused when reading back this code, without them.
After the initial enthusiasm, the fun quickly stopped, as I faced the (many) 88110 processor erratas now.
I had been lucky to test on a MVME197LE board with a version 5 processor, which did not suffer from as many erratas as its predecessors; but, when I tried my other boards, some of which had version 4 processors, they would not run reliably, or not at all.
After a lot of tinkering, by the end of the year, I had all my MVME197LE boards working, with careful processor version-dependent logic to disable various processor features in order to get it to run stably, and some careful programming of the processor bus timeout limit.
It would, however, take another two and a half years until SMP support for the MVME197DP would work reliably.
Other good news happened during the end of 2007. On november 15th, I spotted an AViiON 4300 system on eBay, but needed a proxy as the seller would only accept to ship it within continental USA. Fellow OpenBSD developer Marco Peereboom volunteered to get it delivered to his place and have it then shipped overseas, after confirming the system was in working condition.
As I wrote in my notes:
[...] it's a major incentive to do some serious work on
the aviion port again (even though everyone seems to have moved to
a 530 model...)
<marco> miod around? <miod> i just came back from the pub. <marco> hey i am going to unpack that aviion tomorrow; anything i need to be aware of? <miod> insert standard static electricity disclaimer with sun ludicrous grounding bracelet item here. <miod> apart from ``be careful, it weights a dead donkey'', no/ <marco> ok <marco> just netboot the sucker? <miod> sure. need a prom crash course? <marco> yeah <marco> that would be helpful <marco> or if you are online tomorrow we can do it "live" <miod> too bad i did not write one yet. peek at the SCM chapters in chris tribo's docs. start from http://XXX.XXX.XXX.XXX/aviion/ <marco> i'll read that <marco> thanks
Then, some days later:
<marco> ok now i am going to really really unpack that aviion <marco> been procrastinating that due to the size of the box its in <miod> that's part of the fun. [9 minutes later] <marco> i hate you miod <marco> holy shit <marco> that thing is huge and impossible to lift <marco> net is also some old conector that i dont have <marco> will rs232 work? <marco> there's manuals too <marco> funny <marco> i shoul probably move the serial wire downstairs instead of the aviion though <marco> hahahah a mechanical switch <marco> ok miod it boots with 48m of ram <marco> it has dgux on it <djm> did you get one of the bar-fridge sized ones, or one of the family fridge sized ones? <marco> bar fridge <marco> whats the equivalent of dmesg? <marco> it even has the compiler <marco> # cc marco.c <marco> # size a.out <marco> 3464 + 1468 + 4 = 4936 <marco> # ./a.out <marco> hello world! <marco> alright miod i am packing it back up
I received the AViiON in mid-december. Then it was another case of doing a brainstorming session about the name of the SCSI driver.
<miod> who wants to help me name a mostly useless driver?
<otto> mud(4)
<miod> har har
<miod> it will be (it's not working yet) a driver for the aic-6250 scsi chip -
same as found in aha, but without the mailbox wrapper chip. we already
have aic(4) for aic-6360 which is not compatible, so i was thinking about
oaic (a la osiop), asc (adaptec scsi controller) or aaic (ancestor aic /
aviion aic)
<miod> but none of these names sound good enough to me.
<miod> (maybe because i'm an old fart)
<marco> laic legacy
<marco> whatever
<marco> call it oink
<martin> asc is the mac68k soundchip
<miod> whatever(4)?
<miod> martin, asc is a md driver.
<miod> aic(4) is mi so i can't use it as an md name.
<martin> mm right
<miod> asc is also an md name for esp on vax.
<miod> <timewarp time="before 2001"> and on pmax too </timewarp>
<martin> is there some project name in the docs for 6350?
<miod> 6360 you mean. no, there isn't.
<martin> actually i meant 6250
<miod> no. that's serious doc.
<martin> then my preference would be oaic
<millert> oaic is alright I suppose, since we don't seem to like to put numbers
in device names.
<miod> i don't want to put numbers in it
<miod> pnozz is already ueber ridiculous
(pnozz in the above conversation is a driver for the Weitek P9100 chip, and its author having no inspiration, got this horrible name which simply stands for P Nine One Zero Zero.)
(The driver would end up being named oaic, but would not be written until almost six years later.)
As is always often the case with machines using the infamous
Mostek
MK48Txx battery-backed real time clock with NVRAM to store their configuration,
the battery was long dead after the machine had been left powered off for years,
and its configuration had been wiped out. This is something I am used to on
almost all my machines using these chips (Sun machines, MVME boards, later SGI
machines too.) But at least on this AViiON system, when the NVRAM settings are
lost, netbooting uses the invalid 00:00:00:00:00:00 Ethernet address,
and I don't know how to fix this.
Fortunately, the machine was still able to boot DG/UX, at least in single-user mode, so I could download kernels to test, converted to ECOFF format, over the network (since both the PROM and DG/UX would find and use the proper Ethernet address.)
My first boot attempt panic'ed upon receiving the first clock interrupt, giving me a deja vu of the MVME188 revival work in 2003.
SCM>b sd(insc())bsd.ecoff
Booting sd(insc())bsd.ecoff
DG/UX System Release 5.4.2 Bootstrap
Loading image
.................................................................CPU0 is
associated to 2 MC88200 CMMUs
[ 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-2007 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 4.1 (GENERIC) #1: Thu Mar 15 02:56:54 GMT 2007
root@ramade.gentiane.org:/usr/src/sys/arch/aviion/compile/GENERIC
real mem = 50266112
avail mem = 41385984 (10104 pages)
using 639 buffers containing 2617344 bytes of memory
' dev 0 unit 0 part 0bsd.ecoff
mainbus0 (root): 100/200/300/400/3000/4000/4300 series, cpuid 0x7932, sysid f026120
cpu0: M88100 rev 0xb, 2 CMMU
cpu0: M88200 (16K) rev 0x9, full Icache, M88200 (16K) rev 0x9, full Dcache
syscon0 at mainbus0 addr 0xfff00000
nvram0 at syscon0 offset 0x80000 ipl 0: MK48T02
dart0 at syscon0 offset 0x82000 ipl 3: console
dart1 at syscon0 offset 0x82c00 ipl 3
le0 at syscon0 offset 0x8c000 ipl 1: address 08:00:1b:18:4a:1c
le0: 32 receive buffers, 8 transmit buffers
vme0 at syscon0 offset 0x85000 ipl 0
vme0: A32 10000000-7fffffff
vme0: A32 90000000-fdffffff
vme0: A24 00000000-00ffffff
vme0: A16 00000000-0000ffff
le1 at vme0 a16 0x4000 a32 0x55900000 ipl 1: address 00:00:77:82:fe:14
le1: 128 receive buffers, 32 transmit buffers
av400_intr: spurious interrupt, level 5, vec 0x56, mask 0x200000<CIOI>
av400_intr: spurious interrupt, level 5, vec 0x56, mask 0x200000<CIOI>
av400_intr: spurious interrupt, level 5, vec 0x56, mask 0x200000<CIOI>
av400_intr: spurious interrupt, level 5, vec 0x56, mask 0x200000<CIOI>
av400_intr: spurious interrupt, level 5, vec 0x56, mask 0x200000<CIOI>
av400_intr: spurious interrupt, level 5, vec 0x56, mask 0x200000<CIOI>
av400_intr: spurious interrupt, level 5, vec 0x56, mask 0x200000<CIOI>
av400_intr: spurious interrupt, level 5, vec 0x56, mask 0x200000<CIOI>
av400_intr: spurious interrupt, level 5, vec 0x56, mask 0x200000<CIOI>
av400_intr: spurious interrupt, level 5, vec 0x56, mask 0x200000<CIOI>
panic: av400_intr: broken interrupt behaviour
Stopped at 0x1c2728: tb0 0, r0, 0x84
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb>
This was quickly fixed and I could try a new kernel.
Mask the clock interrupts until cpu_initclocks() is invoked.
But then, once the kernel enabled interrupts, the internal speaker went full power, with a LOUD strong continuous beep, and I had no choice than reach for the power button and kill the machine.
I couldn't believe Chris Tribo didn't report this on his 410 - maybe the speaker is wired differently on his machine, or he could be deaf.
Thanks to the documentation, I found
which signal I had to flip
and it was a
matter of minutes to silence the evil naughty speaker.
Disable the built-in speaker when initializing the chip, before my neighbours start visiting me with large axes.
The machine then succeeded a multiuser boot, diskless.
I performed a few code cleanups, but nothing more, and it seemed like the AViiON port would once again be left in the dark, although, this time, I couldn't use the "I don't have access to the hardware" excuse anymore.
Later in december, though, I noticed another AViiON system, this time a multiprocessor 4605. It had unfortunately not been packed strongly enough, and the packaging was completely destroyed during its transportation by USPS. Yet, these machines being sturdy, the machine was still in working condition (I couldn't say the same of its feet, which were bent beyond recognition.)
Real-life events delayed the shipment of that system, and I only received it almost one year later.
In november 2008, Anders Gavare, the author of GXemul, after spending some time rewriting the 88100 emulation layer in his software, reported a jaw-dropping bug caught by his emulator: userland processes would start with all the instruction pipeline control registers marked as not valid, which caused his emulator to give up. Yet it worked on real hardware!
I made a quick fix to make the code more correct and make his emulator happy again.
On 88100 cpus, make sure userland processes start with SNIP and SFIP valid (i.e. with the valid bit set in them). Found the hard way by Anders Gavare trying his latest gxemul, proves the hardware is more permitting than one would expect it to be...
Not much happened on the m88k front until april 2010. I was building and uploading OpenBSD/mvme88k snapshots every few weeks, OpenBSD/luna88k was still stuck due to the lack of working hardware (well, a working power supply), and please do not mention OpenBSD/aviion.
Does this mean that the mvme88k port was mature and didn't need any more work? I wouldn't dare answer yes. Yet gone were the 2003 and 2004 days, when the compiler was still a moving target and the kernel would appear to have mood swings and could misbehave any time, if you were to look at sideways for long enough.
On april 2010, I decided to resume playing working with
the AViiON systems.
I had the bad surprise that, on the 4300, DG/UX would no longer be able to boot single-user. I hacked a special netboot binary which would accept being loaded using the 00:00:00:00:00:00 invalid Ethernet address, and then would switch to its real Ethernet address and perform the remainder of the boot sequence. This allowed me to have a working, yet diskless, OpenBSD/aviion machine again.
In order to be able to use disks and be in good conditions to start building OpenBSD/aviion snapshots, I had two choices: either write the SCSI driver for the 4300, or get the 4605 machine running.
There were, however, two problems with the 4605: first, although it had a different SCSI controller for which there was an existing driver in OpenBSD, there was no support for its on-board Ethernet chip, an AMD ILACC (79900), a 32-bit evolution of the 24-bit AMD LANCE (7990.) OpenBSD didn't have support for the ILACC, but NetBSD did, so porting that code could be reasonably easy. Second, that particular 4605 machine had an unusual CMMU configuration, with six CMMUs per processor: four instruction CMMUs, and two data CMMUs. Such a configuration had never been produced by Motorola (or, at least, never became a sold product), and the Data General programming documentation was unfortunately not giving any details about how these CMMUs were set up to distribute their work in this configuration.
On the MVME188 designs, there was a configurable register to control how accesses to the multiple CMMUs were split: on configurations with four CMMUs per processor (two instruction, two data), the choice could be done either on the supervisor (kernel) versus user mode of the memory access, or on the value of a particular bit of the address being sent on the address bus (A12 when using 88200 CMMUs, A14 when using 88204 CMMUs.) Configuration with eight CMMUs per processor would add an additional split on the A14 address bit (A16 for 88204 CMMUs.)
(For correctness' sake, I should mention that there was also a third option, which was to split depending on whether the memory access was targeting the on-board 128KB SRAM or not; I understand this could have been extremely useful to some particular embedded systems, but for an Unix-like operating system, using this mode was equivalent to disabling half of the cache, and definitely not a good idea.)
Years ago, when making sure MVME188 systems would work in such configurations, I had opted for the address split, rather than the supervisor/user split, expecting better results this way. I did not run any benchmarks to confirm this, though, but this made the code simpler, which is worth taking into consideration.
It sort of made sense to assume that, in these particular six-to-one settings used by Data General, the two data CMMUs would be split on an address bit, and the four instruction CMMUs would be split on two address bits: a cross between Motorola's eight-to-one and four-to-one configurations.
I quickly coded this, and was delighted (and relieved) to have the kernel boot successfully.
Jp#0/SCM>b dgen()
Booting dgen()
Local Ethernet address is 08:00:1B:33:14:30
Local Internet address is 10.0.1.194, or 0A0001C2 hex.
Trying server at 10.0.1.101, or 0A000165 hex for TFTP transfer.
CPU0 is associated to 6 MC88200 CMMUs
CPU1 is associated to 6 MC88200 CMMUs
[ 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-2010 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 4.7-current (GENERIC) #61: Sun Apr 18 21:25:16 GMT 2010
miod@arzon.gentiane.org:/usr/src/sys/arch/aviion/compile/GENERIC
real mem = 134217728 (128MB)
avail mem = 126234624 (120MB)
bootpath: 'dgen()' dev 0 unit 0 part 0
mainbus0 at root: 530/4600 series, cpuid 0x7930, sysid 373a3aac
cpu0: M88100 rev 0xb, 6 CMMU
cpu0: M88200 (16K) rev 0x9, split Icache, M88200 (16K) rev 0x9, split Dcache
cpu0: M88200 (16K) rev 0x9, split Icache, M88200 (16K) rev 0x9, split Dcache
cpu0: M88200 (16K) rev 0x9, split Icache, M88200 (16K) rev 0x9, split Icache
syscon0 at mainbus0 addr 0xfff00000
nvram0 at syscon0 offset 0x80000 ipl 0: MK48T02
dart0 at syscon0 offset 0x82000 ipl 3: console
dart1 at syscon0 offset 0x82c00 ipl 3
vme0 at syscon0 offset 0x85000 ipl 0
vme0: A32 40000000-7fffffff
vme0: A32 90000000-fdffffff
vme0: A24 00000000-00ffffff
vme0: A16 00000000-0000ffff
WARNING: SYSFAIL* ASSERTED
CPU 0 Reset Exception
R00-05: 0x00000000 0x001f28a8 0x0064ef40 0x00060000 0x0064ef60 0x00000003
R06-11: 0x00000000 0x00000004 0xfff8e000 0x00209488 0x00000000 0x00000000
R12-17: 0x001f4160 0x00260000 0x00270000 0x00260000 0x00200000 0x00250000
R18-23: 0x00260000 0x00260000 0x00250000 0x00260000 0x00240000 0x00262e98
R24-29: 0x00200fd0 0x00201594 0x00000000 0x00000001 0x00200000 0x00200000
R30-31: 0x07ffaff0 0x00200f60
sxip 1f8e52 snip 1f8e5e sfip 1f8e72
fpsr 1dec48 fpcr 260000 epsr 800003f0 ssbr 0
fpecr aaaaaaaa fphs1 250000 fpls1 1f89cc fphs2 0 fpls2 1f33a4
fppt 1f3318 fprh 1000 fprl 0 fpit 0
vector 0 mask aaaaaaaa flags 4 scratch1 10a8 cpu 0x0
panic: unrecoverable exception 0
Stopped at 0x1dae18: tb0 0, r0, 0x84
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb>
Ok, that's not exactly what I would call "successful". But that "Reset Exception" was actually an intentional NULL function pointer dereference, when initializing the clock, as I had not written proper code for the 4600 family yet.
But this was promising enough to keep me working.
<marco> hey miod <marco> how is that aviion coming? <miod> i am in a twisted maze of subtle bus_dma bugs, all allike <marco> oh fun <miod> not so
The next day, I had added support for the SCSI controller. Two days later, I was running multiuser, although I was using a LANCE-based VME Ethernet board (MVME376) instead of the ILACC-based onboard Ethernet interface.
Having disk support got me interested in the DG/UX partition scheme and boot mechanism. DG/UX, having a strong storage focus, was among the first Unix-like operating systems to have a volume manager, with the ability to resize partitions, or have partitions span multiple, non-contiguous, disk areas.
The volume manager code changed over the years, with older DG/UX systems using a volume manager called ``LDM'', and more recent versions using another volume manager called ``VDM''.
Helped with the DG/UX header files, I wrote a VDM layout groveller, to figure out the DG/UX partition table.
When run on the 1GB disk found on my 4605 system, it would spawn this:
found verification signature at alt offset
version 0000
disk boot info: sig 1234abcd start 00000008 size 000001f4 version 00000001
sector 00000001: vdit portion type 14, 0007 sectors, next portion at 00000208
sector 00000208: vdit portion type 13, 0009 sectors, next portion at ffffffff
vdit final size: 0x1e80 bytes
vdit entry: type 03 size 32
subdriver: version 00 id 6ba42ddb name "vdmphys"
vdit entry: type 03 size 32
subdriver: version 00 id 0c64a291 name "vdmpart"
vdit entry: type 03 size 32
subdriver: version 00 id 3027e8f3 name "vdmaggr"
vdit entry: type 04 size 3f
instance: version 00 name ""
subdriver id 6ba42ddb instance id 373a3aac export 0
vdmphys: version 00 mode 01
vdit entry: type 04 size 55
instance: version 00 name ".Bootstrap"
subdriver id 0c64a291 instance id 373a3aac export 0
vdmpart: version 00 child instance id 373a3aac
starting block 00000008 size 000001f4 remap instance id 00000000
vdit entry: type 04 size 55
instance: version 00 name ".Primary_Bad_Block_Table"
subdriver id 0c64a291 instance id 373a3aac export 0
vdmpart: version 00 child instance id 373a3aac
starting block 00000204 size 00000004 remap instance id 00000000
vdit entry: type 04 size 55
instance: version 00 name ".Remap_Area"
subdriver id 0c64a291 instance id 373a3aac export 0
vdmpart: version 00 child instance id 373a3aac
starting block 00000211 size 000000fc remap instance id 00000000
vdit entry: type 04 size 55
instance: version 00 name ".Secondary_Bad_Block_Table"
subdriver id 0c64a291 instance id 373a3aac export 0
vdmpart: version 00 child instance id 373a3aac
starting block 0000030d size 00000004 remap instance id 00000000
vdit entry: type 03 size 32
subdriver: version 00 id 1269c3d7 name "vdmremap"
vdit entry: type 04 size 55
instance: version 00 name ".Remap"
subdriver id 1269c3d7 instance id 373a3aac export 0
vdmremap: version 00 primary remap table instance id 373a3aac
secondary remap table instance id 373a3aac
remap area instance id 373a3aac
vdit entry: type 04 size 55
instance: version 00 name "swap"
subdriver id 0c64a291 instance id 373a3aac export 1
vdmpart: version 00 child instance id 373a3aac
starting block 00000320 size 0003e800 remap instance id 373a3aac
vdit entry: type 04 size 55
instance: version 00 name "root"
subdriver id 0c64a291 instance id 373a3aac export 1
vdmpart: version 00 child instance id 373a3aac
starting block 0003eb20 size 00027100 remap instance id 373a3aac
vdit entry: type 04 size 55
instance: version 00 name ""
subdriver id 0c64a291 instance id 373a3aac export 0
vdmpart: version 00 child instance id 373a3aac
starting block 00065c20 size 0000bc50 remap instance id 373a3aac
vdit entry: type 04 size 55
instance: version 00 name ""
subdriver id 0c64a291 instance id 373a3aac export 0
vdmpart: version 00 child instance id 373a3aac
starting block 00071870 size 00055730 remap instance id 373a3aac
vdit entry: type 04 size 55
instance: version 00 name ""
subdriver id 0c64a291 instance id 373a3aac export 0
vdmpart: version 00 child instance id 373a3aac
starting block 000c6fa0 size 00018da0 remap instance id 373a3aac
vdit entry: type 04 size 5b
instance: version 00 name "usr"
subdriver id 3027e8f3 instance id 373a3aac export 1
vdmaggr: version 00 count 03 stripe size 00000000
vdit entry: type 04 size 55
instance: version 00 name "swap1"
subdriver id 0c64a291 instance id 373a3aac export 1
vdmpart: version 00 child instance id 373a3aac
starting block 000dfd40 size 0003e800 remap instance id 373a3aac
vdit entry: type 04 size 55
instance: version 00 name "cmmtmp"
subdriver id 0c64a291 instance id 373a3aac export 1
vdmpart: version 00 child instance id 373a3aac
starting block 0011e540 size 000d763b remap instance id 373a3aac
vdit entry: type 00 size 00
sector 000001fc: vdit portion type 14, 0008 sectors, next portion at 00000311
sector 00000311: vdit portion type 13, 0009 sectors, next portion at ffffffff
vdit final size: 0x2068 bytes
bcmp of both vdit: 0
It would take a few hours and a bit more code to make sense of this raw data.
But then, nothing happened - was the AViiON port cursed to only see short spans of activity?
To be continued...