Man, I feel like such an idiot.  The largest issue keeping me
from getting my Blue G3 booting is something I should have been more
suspicious about 2 weeks ago.  I now have my Blue G3 running userland
off bm0 or my internal Zip drive.  What is not working (still) is pciide,
so no internal IDE HD yet, and booting with my ADB keyboard connected
causes the kernel to trap in the middle of wscons code.

	There were two interrupt-related issues, one is resolved, the
other is more or less worked around.  It turned out the check for
/pci/mac-io that I caught in one place in the kernel happens in another
place as well.  After fixing the second instance interrupts from
Paddington started working just fine.

	Diffs for each of the files I changed are available at
http://www.meer.net/~wferry/NetBSD/BlueNWhite/, as well as a kernel that
boots my machine (no ramdisk, haven't tried to build one of those yet).

	The remaining interrupt issue has to do with OF, and the fact
that it doesn't seem to provide the info that it used to.  The
"interrupts" property on a PCI device simply seems to say "00000001" now,
rather than giving the IRQs.  Tsubai had a hack for the iMac that caught
the IRQ 1 for the USB controller and hard wired it to 28 instead, a
similar fix got USB working for the Blue G3 as well.  At present the
Firewire controller, CMD0646, and ATI chip are all set to IRQ 1.  I
suspect a machine with the SCSI card or any other PCI card will have the
same problem.  I do not know what values these SHOULD be set to, or what
alternative methods of finding the IRQs exist.  If anybody can make
progress with the 0646 they'll probably have to see where the interrupts
are coming in and hardwire that value in as well.  Seems we cannot rely
on OF to tell us the IRQs anymore though..  =(  The Xmacppc driver seems
to work just fine even with the video IRQ as it is.  I tried looking at
the Darwin sources to see how they set their IRQs, but those .m files
are like Greek to me, I really was not able to get any useful information
from them.

	To fix the mac-io problem, I changed the checks to simply look
for "mac-io", not "/pci/mac-io".  At least on the few machines I looked
at there was always an alias for mac-io that pointed to the right place,
so this seems a slightly safer way to do it.  If there are some machines
that do not have the alias then I guess both code segments, or an
entirely different method, would have to be used.

	I am not sure what is up with my ADB keyboard.  I am fairly sure
I was able to boot with it connected on my PowerBook earlier.  But I
tried this new kernel on my PB with the keyboard connected, and it got
up to "adb0 at obio0 offset 0x16000" then froze.  So it failed in a
different place than the Blue G3 did, but it still failed.  If I
disconnect this keyboard it seems to work just fine.  FWIW it's an
AppleDesign keyboard.  If I have just my Logitech mouse connected to ADB
both machines seem to boot just fine.

	As far as pciide goes, I have played with this for a few days
with no real luck.  I threw in the macppc glue, and it gets up to
wdcprobe(), then fails with a trap 200 (these happen WAY too often..  =).
The trap occurs on the first bus_space_read_1() in wdcprobe().  I am
suspicious of the values wdc gets, but do not know just what they should
be instead.  Hopefully somebody else might have some ideas.  For the
obio wdc, cmd_iot is 80820004, and cmd_ioh is ef927000.  The write for
register 6 and read for 7 equate to the addresses ef927060 and ef927070.
For pciide, cmd_iot ends up being 80000000, ioh is ef921090, and the
addresses turn out to be ef921096 and ef921097.  I suspect these
addresses are not what they should be, but I do not know how to go about
fixing this.  I can dig up any other values anybody wants if they think
they know what's going wrong here.  (FWIW, the pa_tag value is 80010800)


                                                          Will Ferry

-----------------
woferry@iname.com