Hm, I seem to have bad luck with NetBSD and the pmap stuff on the Macs
I have :) NetBSD wasn't getting anywhere on my Powerbook 150, and I
wanted to figure out why... first thing I found is that since the
PB 150 is more like a Duo than like the rest of the PB 1xx, it works
better if the machine class is changed to be MACH_CLASSDUO. In
particular, VIA2 needs to be 0x13 like the Duos, not 1. So here's a
patch for that... :)

--- /usr/src/sys/arch/mac68k/mac68k/machdep.c	Thu Apr 24 06:18:46 1997
+++ machdep.c	Sun May 11 14:50:13 1997
@@ -1995,7 +1995,7 @@
 	/* PB 100 has no MMU! */
 	{MACH_MACPB140, "PowerBook", " 140 ", MACH_CLASSPB, &romvecs[1]},
 	{MACH_MACPB145, "PowerBook", " 145 ", MACH_CLASSPB, &romvecs[1]},
-	{MACH_MACPB150, "PowerBook", " 150 ", MACH_CLASSPB, &romvecs[10]},
+	{MACH_MACPB150, "PowerBook", " 150 ", MACH_CLASSDUO, &romvecs[10]},
 	{MACH_MACPB160, "PowerBook", " 160 ", MACH_CLASSPB, &romvecs[5]},
 	{MACH_MACPB165, "PowerBook", " 165 ", MACH_CLASSPB, &romvecs[5]},
 	{MACH_MACPB165C, "PowerBook", " 165c ", MACH_CLASSPB, &romvecs[5]},

So, now it at least clears the screen and prints stuff... it hangs
right after "Getting mapping from MMU." though. I traced through the
code, and it looks like get_pte() is the routine that it's unhappy
with, specifically the "pmove a0@,tt0" instruction at the top of the
routine. Now, I notice that back on Dec 31, Scott Reynolds posted a
patch that, among other things, did:

  -  Modify get_pte() so that it's not quite so intrusive.  The minimal
     use of the TT0 register should allow this to work on the Duo 2x0
     machines, now.  (I'm not sure about ADB, though, and it's late and
     I'm tired...)


Apparently, the minimal use of TT0 isn't minimal enough for a PB 150
though :) If I understand the code correctly, it's setting TT0 to
0x00ff8710, which transparently translates the whole 4 gig address
space for function code 1. FWIW, in MacOS, TT0 is 0x600f8507, which
transparently translates 0x60000000 through 0x6fffffff (internal
video, possibly other I/O stuff?) for all function codes. TT1 is
0x807f8507, which transparently translates 0x80000000 through
0xffffffff (dunno what that is, probably nothing :) for all function
codes.

Anyways, I have a feeling that MacOS set up some sort of mapping and
things crash badly when setting TT0 effectively disables it. Seems
kinda surprising that the PB150 would be the only machine with that
problem though, so I dunno :) Why does TT0 need to be messed with
anyways? Does the ptest stuff not work right if it isn't? (I guess I
can just try commenting out all the TT0 stuff and see what happens :)

Anyone got any ideas? :) Thanks...

BTW, it's a Powerbook 150, 16MB RAM, System 7.5.5, VM off, 32-bit on,
screen in 1-bit mode, I've tried shift-booting.

Name: Dave Huang     |   Mammal, mammal / their names are called /
INet: khym@bga.com   |   they raise a paw / the bat, the cat /
FurryMUCK: Dahan     |   dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 21 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++