Subject: Re: Installing again...
To: David Jones <dej@achilles.net>
From: Jason Thorpe <thorpej@SJ.Xenotropic.COM>
List: port-sparc
Date: 11/16/1995 19:09:18
On Thu, 16 Nov 1995 20:50:02 -0500 (EST) 
 dej@achilles.net (David Jones) wrote:

 > - The generic kernel has no support for the si board.  My drives are on
 >   the si, and I don't have the cable required to hook up to the sw.
 >   Can someone compile me a kernel with si support (polled will do!)?

My 4/260's kernel won't go on a 4/1xx ... I can compile one for you, but 
it might take a while...However, looking at /sys/arch/sparc/conf/GENERIC:

si0     at vmes0 addr 0xff200000 level 2 vect 0x40
sw0     at obio0 addr 0x0a000000 level 2

[ . . . ]

scsibus* at si? 
scsibus* at sw?

[ . . . ]

If you have a 4/1xx (I think I remember that what you said you had...), 
the SCSI controller on obio is called `sw' ... it's a little different, 
but I frobbed the old `si' driver to talk to it...You've probably looked 
at the evil in sireg.h that I did :-)

Of course, I could be speaking pure gibberish, but my experience on Sun 
4s is that `si' only exists on VME, and if you have a 5380 in obio space 
it's a "SCSI Weird".

 > - The system wants to give me parity after the kernel finishes coming up.
 >   How do I stop this?  Copying a gettytab with "np" into /etc didn't help.
 >   With parity enabled I can't see certain error messages which may help
 >   with these problems!

This is after the rcons gets attached no doubt.  I'll attach my gettytab 
below which works peachy on my 4/260.

 > - If the console is put on the cg2 board, the system panics immediately.
 >   No panic if I boot using ttya as the console.  Cool - something for me
 >   to fix once I get the system up and si DMA working. :-)
 > 

Eww.  What's the panic?  If you match a bwtwo and a cgtwo, you're bound 
to lose ... Take a look at fb_attach() in sparc/dev/fb.c:

----- snip -----

void
fb_attach(fb)
	struct fbdevice *fb;
{

if (devfb) panic("multiple /dev/fb declarers");
	devfb = fb;
}

----- snip -----

That routine is pretty much bogus, but I'm not sure what the correct 
semantics should be ... maybe it should attach the framebuffer which 
corresponds to the console value in the EEPROM, and if the console is 
serial, maybe it should use the last one after printing a warning, 
including which was the displaced device.  Maybe I'll work up some code 
to do this tonight ...

------------------------------------------------------------------------------
Jason R. Thorpe                                         thorpej@Xenotropic.COM

           Just me and my collection of obsolete computer gear(s).