[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

successes on several fronts

I wanted to wait until I was next to the machine in question to
write this, but now that might not be for a while.  The idea is to
report various successes and some info that might help other people.

1.  I succeeded in getting the PM7600/120, which the OF reports as
really being a 7500, go figure, to work with quik using some of the
suggestions from other people.  One of the biggest problems turned
out to be that the OF doesn't initialize the video hardware/memory
correctly %90 of the time, so you can't even see what might be an
error message or anything else.  A poster yesterday not only informed
us that this is a generic bug in 1.0.5 OF, but supplied some fixes!
I hope to try those fixes soon.  In order to get working, there
were several things I learned:

   + in addition to the list of nvsetenv commands Rick Cook listed, I
     also had to use this one to get the keyboard working:

       nvsetenv input-device kbd

     I tried to use the serial port and minicom and microcom, but that
     failed miserably, as if the mac wanted a baud rate that Linux
     couldn't supply.  I tried all that my serial port would do from
     1200 to 115200.  According to OF the documentation at

     it should be 38400 by default, but no go.  Possibly a cable

   + most of the time, it doesn't work right when you try to
     boot up, and you have to use the [CMD]-[OPT]-O-F to get
     the OF prompt, whence I immediately just type "boot" and it
     boots.  No idea what really causes this, but I assume it
     has something to do with the fact that the OF is not accustomed
     to waiting for a drive to spin up.  The boot-command from
     the nvsetenv man page that keeps retrying every ten seconds
     does not successfully work around this problem on my system.

   + on OldWorld macs like this (7200,7300,7500,7600), doing
         nvsetenv boot-device `ofpath /dev/sda4`
     does not work, because OF only has nodes in its device tree
     for individual disks (individual SCSI IDs), but no nodes for
     disk partition numbers, so that will never work, unless the
     partition in question is partition 0, which is kinda impossible,
     nes paux?  Like Rick Cook advised, use
         nvsetenv boot-device scsi/sd@M:0
     where M is the SCSI ID of the drive.  or something thereabouts.
     It doesn't hurt to run ofpath and see what it says, and use that
     as a starting point, but change the partition number to a zero.

   + using scsi-int or scsi didn't make any difference on my system.
     use the devalias OF command to find out what your system likes.

   + I had the infamous bad block problem as well.  Here
     is my take on it:
     Inside the machine there are two SCSI connectors on
     the mobo, one says fast SCSI, the other says normal.
     I was hooked to the fast, and everything worked fine
     until I was booting the stock kernel (2.2.18pre21)
     which is compiled with the MESH driver with a max
     sync xfer rate of 5MBs.  But my fancy-schmancy drive
     from 1996 was negotiating with the OF for 10MBs, and then
     the kernel took over, and "hilarity ensued."  I plugged
     the cable into the "normal" slot and had no more troubles
     with that.  I also built my own kernel (more on that
     below) but as yet have not had a chance to try it back
     on the "fast" connector.  also, these machines are quite
     old and my scsi cable was crumbling and in bad shape.
     i got another one from the dust covered spares box and I
     would advise people to inspect these cables as they are
     fairly suspect as well.

   + anybody want to take a stab at writing another boot-command
     that first tries the floppy drive, then the boot-device,
     then drops to the prompt?  ~:^)  I'm no good with forth.

2.  Building a customer kernel from the sources.
    I don't know if anyone else had a problem with this, but I sure did.
    It took a lot of T&E to find out the following:

    + to get the mouse and kbd working like in the stock kernel, you
    have to do the following:
      - enable USB (which is a bit counter-intuitive, since these
        oldie Macs don't have USB)
      - in USB, enable HID, *not as a module*
      - in USB, enable keyboard and mouse devices.  The HIDKeyboard &
	mouse selections should be greyed out if you configured HID
	*not* as module, which is required.
      - in USB, enable the event handling driver.  at some point the
	adbhid stuff refused to compile without it.
      - this turns on the options inside the Mac area for enabling the
	input layer mouse and keyboard. enable this.
      - enable "user raw adb codes" or whatever it's called.  this has
        to be enabled or it won't work.  why this is a separate option
	at this point, I can't even guess.
      - don't enable the ADB keyboard and mouse labeled as old drivers.
	these may be greyed out at this point, I can't remember.
      - I need to do more hacking to get my 3-button adb mouse to use
	all it's buttons.

3.  A boot floppy that works with these OldWorld Macs:
	I made my own from the boot-floppies source package and
	about 3 hours of computer time on a 601:


	Please don't /. this site as my ISP will not be very
	nice to me if that happens.  ~:^)

	This floppy is a working substitute for the boot floppy
	on the 2.2r2 release.  The root.bin floppy with that
	release worked fine for me with this floppy.  This is
	not the rescue floppy, which doesn't work at all AFAIK.
	Maybe it works on New World Macs.

4.  SMP support works fine!  Makes kernel builds go twice as
fast which is a good thing on these old 200MHz 604e classics!

Reply to: