>> So, who is doing what?
>
> I'm trying to find time to work on the AViiONs.  I've also received
> a luna88k box, but I've not gotten it hooked up yet.  The person or
> persons who were/are working on the luna68k port have mentioned (and
> sparked some discussion about details regarding) a luna88k port.  I
> don't know what their schedule or status is.

During last weekend, I went back to my NetBSD/luna88k project, and
last night I could figure out what I have wanted to know.  Here goes
what I learned from Mach/luna88k source codes. 

LUNA88K can have upto 4 CPUs and has 4 different 32bit registers in
parallel to indicate which device requests for service at a certain
memory location.  Device interrupts is served only by master #0 CPU.
Slaves can take hardclock() and IPI requests.  After brainstorming of
interrupt service glue logic, I think I got the code for NetBSD/luna88k
at last.  The code is MP ready, but in this moment, I have no plan to
spin up slave CPUs, and kernel will be compiled for uni-processor
configuration with #define cpu_number() (0).

I still no access to m88k UM (users manual).  From a help from
conventional computer science textbook for general public, I learned
some about m88k.  Logic of exception service (enter & return) using
SXIP, SFIP, SNIP registers seem obscure, but managable, I think.
Scratch build of pmap.c seems not a terribly hard work (no code was
written in this area).  Another concern (what I don't learn yet) is how
to implement delayed lazy FPU context switch.

Anyway, NetBSD/luna88k got a bit concrate ficture, but before true
ELF/m88k toolchain the real output will not happen.  If someone wants
to see my fragmented codes, please drop me a message privately.

Tohru Nishimura
Information Technology Centre
Nara Institute of Science and Technology