I should say straight up that I'm not much (if any) further ahead on
rebuilding a 1.1-alpha user-level than anyone else on the list.  I've
had problems sup'ping too. :).

There are a couple of things I can offer some advice with.


Old-style config doesn't work any more.  In fact, it never *did* work
completely correctly.  It's unlikely that anyone tripped over the
old-config bugs unless they used TurboChannel option cards -- which I
do.

Second, it's been ages since I tried buiding kernels for only a 3100,
or only TurboChannel machines.  This may not work any more.  The
simplest thing is simply build  a  kernel with TurboChannel support
as well.

If you *do* want to try and configure a minimal 3100 kernel, I'd
advise copying NEWCONF to some other, local configuration file, and
removing the Turbochannel devices.  That is, asc, scc, cfb, mfb, sfb.

The only devices a 3100 has (or can have) are the devices in the
2100/3100 `stanza' in NEWCONF, i.e.,

    ########################################################################
    # Decstation 2100/3100 (aka PMAX aka KN01) configuration.              #
    # (these don't really have any options except a framebuffer.)          #
    ########################################################################
    clock0	at mainbus0			# RTC
    pm0	at mainbus0			# 3100 onboard fb
    dc0	at mainbus0			# dc7083 four-port DZ device
    le0	at mainbus0			# 3100 onboard lance
    sii0	at mainbus0			# onboard scsi


Third, the compile-time conditionalization is a mess.   THe "DS5000"
preprocessor token sometimes means ``compiling for a TurboChannel machine''
and sometimes means ``compiling for a 5000/200''.  This should be
fixed, but it won't be fixed for 1.1.

fourth:

>(3) on ../../../../../../lib/libkern/scanc.c, bfd assertion fail elfcode.h:644
>2
>       libkern/skpc.c, bfd assertion fail elfcode.h:6442
>       libkern/strcat.c, bfd assertion fail elfcode.h:6442
>       libkern/strcpy.c, bfd assertion fail elfcode.h:6442
>       libkern/strncmp.c, bfd assertion fail elfcode.h:6442
>
>[Could this just be that I have to grab a newer toolchain?]

Ted Lemon says these are  benign.  So far, it seems to be.


Fifth: cpu_cons.c errors.  The consprobetc() function could be renamed
to something more sensible, and could also profitably be
conditionalized with #ifdef DS5000 (but see above for whatever that
means).

If and when I had time, I'd considered moving the interrupt- and
trap-handling code into a file for each cpu: kn01.c for the 3100,
kn02.c for the 5k/200, kmin.c for the 3MIN, maxine.c for the Personal
Decstation (MAXINE), and kn03.c for the 5k/240 (3MAXPLUS). If I did
that, I'd be inclined to change the config tokens for each cpu
to be (e.g.) KN01, KN02,  KMIN, MAXINE(?) and KN03.



Sixth: I can't tell if the problems with 2100/3100 mono frambeuffers
is due to the framebuffer driver, or to the glass-tty emulation code.
I don't have access to one to test.  It would really, really help me
if someone could try starting an X server on a mono 3100 (e.g., from a
network login or a serial terminal) and see if that works at all.


Seventh:  remote consoles don't yet work with newconfig.  This is
lower down my priority stack than fixing the SCSI driver.  If I
continue to hear requests for serial console support, it'll get pushed
up.  (Are people only running NetBSD on machines they've already
ripped the framebuffers out of and put in other machines, or what?)

thanks
--Jonathan