Subject: Serial console on 5000/240 success
To: None <port-pmax@NetBSD.ORG>
From: Arne H. Juul <arnej@pvv.unit.no>
List: port-pmax
Date: 11/10/1995 02:11:36
Endre Angelvik and me sat down a night and looked a bit
harder on the serial console business for his 5000/240.
The good news is we actually got it to work.  The bad news
is that it's a totally evil kludge :-(

The way the code is right now is, as far as I understand
it, like this:

consinit() is run very early, figures out that we want to
use serial console, and leaves vectors pointing at the ROM
routines until the serial console is enabled, and leaves
cn_tab->cn_dev as 0.

sccattach() comes along, and tries to figure if
cn_dev points to 'this' serial line, or to keyboard.
However, cn_dev is still 0 so the logic in this
file doesn't work right.  The code
         if (SCCUNIT(cn_tab->cn_dev) == unit)
will trigger because cn_dev is 0 - this was maybe
meant to be CONSOLE_ON_UNIT(unit), but that wouldn't trigger
at all.

xconsinit is called after the complete autoconfig is done.
This routine sets the vectors etc. right according to
built-in knowledge of the various boardtype layouts.
It seems like sccattach() expects to have this done
beforehand.

What I've done to get things work is to hard-code in
sccattach() that I want no special handling of unit 0, but
all the special console-handling (from both sccattach()
and xconsinit() routines) if it's unit 1.  This will
obviously only work on 5000/240, it's very hard coded at
the monent. Probably the entire xconsinit() functionality
would need to be merged into sccattach() to get this
more right - does this sounds viable?

The scc.c has a lots of ifdefs which makes it a bit hard to
follow, but the main problem is that it has to take care of
both keyboard, mouse, serial consoles, dumb-glass consoles
and raster consoles all at the same time, essentially.
While I think I understand the prom->serial transition
OK right now, I don't have a good feel on how the
rcons or virtual console (like xconsole) should work.

Maybe we should just hack it for now and wait for cgd
to design a `right' solution for alpha, then we can snarf
that one...

If anyone else needs serial consoles on 5000/240, feel
free to try the code below.  It could probably also be
hacked to support other scc-driver console by hard-coding
a bit differently. The debug output included may also
be interesting for others.

 - Arne H. J.

--- scc.c	Sat Oct 14 03:18:56 1995
+++ scc.c.ahj	Wed Nov  8 20:19:29 1995
@@ -70,6 +70,8 @@
  */
 #ifdef pmax
 #define TK_NOTYET
+extern int pending_remcons;
+extern int pmax_boardtype;
 #endif
 
 #include <scc.h>
@@ -390,8 +392,17 @@
 	 * complete.
 	 */
 #ifdef TK_NOTYET
-	if (CONSOLE_ON_UNIT(unit) && (cn_tab->cn_pri == CN_REMOTE))
-		DELAY(10000);
+	printf("\nIn sccattach: cn_dev = 0x%x\n", cn_tab->cn_dev);
+	printf("pending_remcons = %d\n", pending_remcons);
+	printf("Boardtype = %d (3maxplus = %d)\n",pmax_boardtype,DS_3MAXPLUS);
+	printf("Unit = %d\n", unit);
+
+	DELAY(10000);
+
+	/*
+	 * if (CONSOLE_ON_UNIT(unit) && (cn_tab->cn_pri == CN_REMOTE))
+	 *	DELAY(10000);
+	 */
 #else
 	if ((cputype == ST_DEC_3000_500 && sc->sc_dv.dv_unit == 1) ||
 	    (cputype == ST_DEC_3000_300 && sc->sc_dv.dv_unit == 0))
@@ -418,6 +429,33 @@
 	/*
 	 * Special handling for consoles.
 	 */
+#define EVIL_AHJ_HACK
+#ifdef EVIL_AHJ_HACK
+	
+	if (cn_tab->cn_dev == 0 && unit == 0)
+		return;
+
+	if (cn_tab->cn_dev == 0 && unit == 1)
+	{
+                cn_tab->cn_dev = makedev(SCCDEV, SCCCOMM3_PORT);
+                cn_tab->cn_getc = sccGetc;
+                cn_tab->cn_putc = sccPutc;
+                cn_tab->cn_pri = CN_REMOTE;
+
+		s = spltty();
+		ctty.t_dev = cn_tab->cn_dev;
+		cterm.c_cflag = CS8;
+		/* XXX -- why on pmax, not on Alpha? */
+		cterm.c_cflag  |= CLOCAL;
+		cterm.c_ospeed = cterm.c_ispeed = 9600;
+		(void) sccparam(&ctty, &cterm);
+		DELAY(10000);
+		splx(s);
+		printf(": console\n");
+		return;
+	}
+#endif
+
 #ifdef TK_NOTYET
 	if ((cn_tab->cn_getc == LKgetc)) {
 		/* XXX test below may be too inclusive ? */