Today and yesterday I've committed changes to -current that change the
pmax kernel to using rcons, an ANSI-compatible glass-tty console
device driver for framebuffers. This is largely Ted Lemon's doing; I
took a copy of the port of the Sparc rcons code which Ted did some
time ago, and bashed it into the new-config drivers.

A driver for the sfb framebuffer is included in these changes.

Note that X11 colormaps now come out wrong :).

I've also changed the pmax kernel to use the "standard" NetBSD console
driver (/sys/dev/cons.c), instead of the pmax-specific console driver,
which didn't know about vnodes, and broke in strange ways when
redirected consoles were closed.

I don't know if all the changes necessary to compile a kernel with
rcons and the standard console code have been committed. The
framebuffer drivers still need another round of revision to remove the
last vestiges of the old pmax framebuffer console code.

I've seen a couple of messages about remote (serial) consoles.
In summary, the serial device drivers need to be redone before
remote serial consoles will work. Any console device needs to
be initialized early in boot, so that output from configuration
gets to the console. Doing this for serial ports requires
some non-trivial changes to the scc and dc drivers, which is
hard given that the scc driver doesn't yet work reliably.

I don't recall seeing Simon Burge's message before, but his
diagnosis sound absolutely correct.  Reverting to PROM
I/O loses as soon as the kernel re-initializes the scc chips.

One possibility is, when the when the serial chip is reset by the
new-style auto-confguration code, to delay to give the PROM
a chanced to drain out pending output, and then  to change
the console device to point at the scc driver instead of into
the PROM.   There's already code in scc.c that does just this for
the Alpha, which I can munge if someone who wants serial consoles
can agree to test it.

--Jonathan