>From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
>
>Those are currently normal for an ioasic-based machine.  I don't have
>a setup that lets me complete the scc driver.  Machines with serial
>console on an scc use the PROM for console output until the serial
>chip is autoconfigured.  Apparently the DELAY() in draining the PROM
>output is slightly too short on a r4400: the PROM is not printing the
>priority before the chip gets clobbered by the kernel driver.
>
>There is code in the scc driver to take over the serial chip very
>early in boot, but i haven't been able to test it. That would make a
>nice little kernel-hacking project for anyone who has handy access to
>the reset button on a 5000 (but not a 5000/200.)

I'd like to volunteer, but I'm nearly certain I don't have enough of a
clue to really be useful.

I can offer three different things:

1.  If you tell me explicitly what to try and how to do it, I can do
the necessary grunt work to try out code you have written and give an
"it works" or "it doesn't" work type of response.

2.  I might be able to give you access to 5000/120 via serial console
(via another nearby machine on my network that you could telnet into),
and allocate a day on a weekend where you could hack away and I could
push the reset button as necessary.

3.  I have two 5000/120's that have been stripped of various parts.  I
might be able to slap together a working machine and ship it to you.

Let me know how you want to proceed if any of this appeals.

--
entropy -- it's not just a good idea, it's the second law.

This message may refer to a product containing software developed by
Christopher G. Demetriou for the NetBSD Project.