Subject: Re: new r4k code problems
To: Toru Nishimura <nisimura@itc.aist-nara.ac.jp>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-pmax
Date: 06/17/1997 04:10:03
Toru Nishimura <nisimura@itc.aist-nara.ac.jp> writes:


> I've built a kernel for a 5000/260 from last night's SUP, and both
> booting of disk and diskless it hangs after the "root file system type"
> message.

>Is your 5000/260 "head-less"?  Your kernel does not recognize any
>framebuffer devices. 

Yes, that means it's headless.  There's nothing in the TC slots. If
there was an unrecognized device, the kernel would say so, e.g.,

	device T3PKT    at tc0 slot 2 offset 0x0 not configured

(which is from an experimental TC board in a machine here.)

>The messages "Using PROM serial output until serial drivers initialized"
>tells something wrong happened around pmax/pmax/cpu_cons.c.

>I'm very curious about;
>
>scc1 at asic0 offset 0x180000 priority  (In sccattach: cn_dev = 0x1102) (Unit = 
>1): console

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.)