Subject: Re: console stuff
To: Gordon W. Ross <>
From: Adam Glass <>
List: port-sun3
Date: 02/22/1994 11:15:16
> > Date: Tue, 22 Feb 1994 10:25:49 -0800
> > From: Adam Glass <>
> > 
> > Yeah...i tried a scheme like this using timeout(), and the prom
> > maygetchar() function.  it just didn't work, though i should probably
> > take another look at it.
> The maygetchar() function works fine with the NMI left active.
> I think the PROM console would be easiest to get working.
> Also, I have found it really handy to be able to stop the kernel
> in its tracks and poke around with the PROM. (i.e. see below)

Hmm...this really didn't work for me.  I'll have to investigate further.

> > I actually have a system alive enough to boot, exec /sbin/init which
> > opens /dev/console which (effectively) opens /dev/prom, requesting
> > single-user mode, execs /bin/sh, prints a shell prompt, and blocks on
> > read() afterwards.  I'll commit all of the changes necessary to get
> > that far as soon as I fix either the prom console driver or the zs
> > driver I ported such that /dev/console input/output actually works.
> The biggest problem I am encountering right now is that the kernel
> takes some vm_fault traps and then somehow jumps immediately to
> the PROM reset which clears the screen so I can't tell what's up.
> I was able to see some of what happened by hitting L1-A at just the
> right instant (before it does the reset).  I can get a stack trace
> at this point (using the PROM "g4" function) but I have not yet done
> the tedious conversion from hex to symbol+offset or source line.

trick is to use gdb on the netbsd.gdb output
and then do a 'break *0xaddr'

> I would find it very helpful to have any of the kernel bug fixes
> you've done so far, even if the drivers are not yet in place.
> (If you want to wait until it "works" I can understand.)
> Thanks,
> Gordon

I think i'll commit to committing all this stuff to the tree tomorrow
night late regardless of what is working/not working.

Adam Glass