Okay, it looks like I'm about to get a working NetBSD/macppc system on
my 7500, but it's still in the act of installing, so I'm not positive
yet.

On Keiki Sunagawa's advice, I re-downloaded the 1.4.1 boot.fs - it
must be necessary to specifically set your ftp client to binary mode
before downloading this file, because I *did* get a distinctly
different file when I did that (2880 sectors to write, 1474560 bytes
big). This disk boots flawlessly and doesn't hang anywhere near as
much as the 1.4 boog floppy did (which would periodically choke up
during the boot sequence for no apparent reason).

I also downloaded all of the 1.4.1 sets and burned them to a CD-R in
case the new boot floppy could not intialize mc0 properly either...
and, as it turns out, it also fails. It does not, however, hang when
doing so - it makes it to the test ping, transmits 0 packets, receives
0, and then lets you continue(!?!).

Deciding it would be a bad idea to try to use a network that wasn't
responding, I went ahead an mounted my CD-R thusly:

# mount_cd9660 /dev/cd0a /mnt

(Stop me if you've heard this one, it's pretty funny...)

I then did a ./sysinst, selected install, happily puttered through the
creating of an ffs system on my 6 GB drive (sd1), selected to install
from a local drive, and picked /mnt/binary/sets (since that's where
the sets are on the CD I burned)... only to be told that
/mnt/binary/sets wasn't a directory. Huh? So I ^Ced out and did an ls
/mnt/binary/sets. Gee, sure looks like it's there to me...

So I go back through the install process (including re-writing the
drive information - is there a way to skip this step? Guess not,
because of what I found...), get to telling sysinst that I want to
install from a local directory, give it /mnt/binary/sets, and am again
told that it's not a directory. This time, though, I get smart and do
a ^Z before my ls /mnt. Hey, look, that's not my CD anymore! Oh, wait,
that makes perfect sense, since sysinst just put the drive it's
installing onto there! Doh!

Unfortunately, I can't now remount /dev/cd0a, as the device is
predictably busy (we've mounted over it, but we never unmounted it).
So I have to drop all the way back out of sysinst, umount /mnt ; mkdir
/my-mnt ; mount_cd9660 /dev/cd0a /my-mnt ; /sysinst, and we're off!

This works, and we can read happily from /my-mnt/binary/sets to
perform the install. After it's done, I do the installboot routine...
Hrm. Have to manually mount the drive before I can actually cp
/usr/mdec/ofwboot to it. Might want to add that to the FAQ about
making a disk bootable, David. I also did a mv /mnt/boot
/mnt/boot.sysinst just to be on the safe side (but I'm paranoid). So,
in sum, I did this:

# mount /dev/sd1a /mnt
# mv /mnt/boot /mnt/boot.syinst
# cp /usr/mdec/ofwboot /mnt/boot
# /usr/mdec/installboot /mnt/boot /usr/mdec/bootxx /dev/rsd1a

[Note that I installed on sd1 - that last item will probably be
different for you if you're reading this in the mailing list archive
looking for help... and it would probably be extremely bad joo joo to
specify your MacOS disk at that point. Ewww. Evil.]

Morals of the story (at this point):

- 1.4 boot.fs is flaky, 1.4.1 is (fairly) stable.
- neither 1.4 nor 1.4.1 can properly initialize (my) ethernet hardware
  (I'm still willing to investigate that further if anyone would like
  me to and can tell me what they want to see)
- don't mount things on /mnt that you want while sysinst is running

So, I reboot the computer, come up in OF, and do a boot
scsi-int/sd@1:0 and NetBSD 1.4.1 starts to boot... and immediately
panics, like this (I'm transcribing this, but it's short, so it's okay
- is there a way to get a dump of this off onto some useful media?):

0 > boot scsi-int/sd@1:0
>> NetBSD/macppc OpenFirmware Boot, Revision 1.1
>> (tsubai@mint.iri.co.jp, Tue Jul 20 01:13:42 JST 1999)
Booting scsi-int/sd@1/netbsd
1874636@0x100000+189564@0x2c9acc
console keyboard type: ADB
Copyright (c) 1996, 1997, 1998, 1999
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 1.4.1 (GENERIC) #1: Wed Aug 11 18:08:32 JST 1999
    tsubai@mint.iri.co.jp:/usr/src/sys/arch/macppc/compile/GENERIC
CPU: 604 (Revision 305)
real mem = 201326592
panic: startup: cannon allocate VM for buffers
Stopped in  at  0x234914:       lwz r0, r1, 0x14,
db>

So, what's my new problem? Do I have two much physical RAM for the
GENERIC kernel to address? (I didn't really think 192 MBs was all that
much, but...) What should I do at this debugger prompt?

If it helps, / is 2048 MBs, swap is 384 (double the physical RAM -
that's still the prescribed size to make swap, right? it was the
suggested value), and /usr is 3715 (the balance of the disk). I also
have two external SCSI disks that were on my mac68k machine, which is
back home (my parents are using it in MacOS for a home computer right
now - I intend to mount the disks long-term on this macppc machine so
I have access to all my old stuff). (Those aren't currently mounted,
of course, or even on the SCSI chain.)

If I need to do some kind of cross-compilation, I *might* (but no
guarantees) be able to dig out a 68k mac and boot from those drives
(one is /, the other /usr) to do it (presuming someone's willing to
walk me through it - compiling NetBSD kernels isn't something I have
experience with, though I do with Linux).

I'm going to leave the machine exactly as it is till I get some
responses. Big thank yous are already owed to Makoto Fujiwara, David
Brownlee, Dave Inskeep, and Keiki Sunagawa, who helped me get this
far, and of course to all the kernel folks. I'm feeling pretty good
about things right now, and expect that this panic is a jumpable
(though conceivably high) hurdle.

When all this is done, I'd be happy to compile/clean up my emails if
this information is wanted for the FAQ and submit any changes I have
to make to get this to boot. Also, my offer about figuring out what's
failing in the initialization of mc0 on this machine still stands, but
someone needs to tell me what they want me to look for.

       ~ g r @ granularity.net