lcg0 framebuffer driver breaks on MicroVAX 3100 M40 (and probably others)

NCommander <[email protected]>
Newsgroups gmane.os.netbsd.ports.vax
Message-ID <CAEMRDeF-eOQZ0MEr4pxrgO5=o74Jc0vpaMTk4-Ona4bEgeMODw@mail.gmail.com>
I was recently given remote access to a MicroVAX 3100 M40, and I've been
spending the last week or so getting NetBSD 10/vax going. The good news is
that I've thus been rewarded with the following:


soap$ dmesg | head -n20

[     1.000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002,
2003,

[     1.000000]     2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012,
2013,

[     1.000000]     2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022,
2023,

[     1.000000]     2024

[     1.000000]     The NetBSD Foundation, Inc.  All rights reserved.

[     1.000000] Copyright (c) 1982, 1986, 1989, 1991, 1993

[     1.000000]     The Regents of the University of California.  All
rights reserved.


[     1.000000] NetBSD 10.99.10 (GENERIC) #18: Tue Apr 30 01:57:43 UTC 2024

[     1.000000]         [email protected]
:/home/ncmdr/netbsd-src/sys/arch/vax/compile/obj/GENERIC

[     1.000000] MicroVAX 3100/m{30,40}

[     1.000000] total memory = 32508 KB

[     1.000000] avail memory = 26920 KB

[     1.000000] timecounter: Timecounters tick every 10.000 msec

[     1.000000] Kernelized RAIDframe activated

[     1.000000] mainbus0 (root)

[     1.000000] cpu0 at mainbus0: KA48, SOC, 6KB L1 cache

[     1.000000] vsbus0 at mainbus0

[     1.000000] vsbus0: 32K entry DMA SGMAP at PA 0x580000 (VA 0x80580000)

[     1.000000] vsbus0: interrupt mask 0


The bad news is that my initial attempts at getting this machine were
greeted with a dead console, gibberish, or bootlooping. This combined with
the fact that I'm MOP booting off Ultrix (and Linux originally) on a
machine that's physically in a different country has largely led to what
can be described as a deeply magical debugging experience.


Part of the problems are likely related to the Linux mopd port, but the
largest hurdle was that through a lot of trial and error that the GENERIC
kernel on NetBSD 10 is busted due to the lcg driver being broken on
MicroVAX 3100. This code is almost unchanged since 2014, so this has been
broken for awhile.


NetBSD 7 has lcg.c, but its disabled in GENERIC, so that's why it worked.


On NetBSD 10, this manifested itself as the INSTALL kernel loading properly
from MOP, and being able to run the full install but the system falling
over with garbage on the console when loading GENERIC. I could reproduce
these results both off HDD boot, and MOP boot. I had found through trial
and error that NetBSD 7-GENERIC worked. I ended up tracking the problem to
the lcg driver, and what appears to be faulty platform detection code.


Looking through CVS, on -current, revision 1.219, the lcg0 driver is
enabled for GENERIC


lcg0 at vsbus0 csr 0x21801000 # VS4000/60 (or VLC) graphics


It's disabled on the INSTALL kernel. lcg0 support was added on GENERIC in
Revision 1.195.


As a MicroVAX, this machine doesn't have a framebuffer, so this driver
shouldn't trying to attach, but when it does, it appears to cause a bad
poke somewhere and the entire system goes down in flames. I sometimes get
kicked back to the >>> prompt, but I can't INITIALIZE< and its essentially
dead until I physically powercycle it to bring it back.


Looking at the driver itself, and what locore.c does for platform
detection, I think lcgcnprobe is broken. This also accounts for it kealing
over before even printing the copyright string.


void

lcgcnprobe(struct consdev *cndev)

{

extern const struct cdevsw wsdisplay_cdevsw;


if ((vax_boardtype != VAX_BTYP_46) && (vax_boardtype != VAX_BTYP_48))

return; /* Only for VS 4000/60 and VLC */


if (vax_confdata & 0x100)

return; /* Diagnostic console */


lcg_init_common(NULL, NULL);


/* Set up default LUT */


cndev->cn_pri = CN_INTERNAL;

cndev->cn_dev = makedev(cdevsw_lookup_major(&wsdisplay_cdevsw), 0);

}


https://github.com/NetBSD/src/blob/trunk/sys/arch/vax/vsa/lcg.c#L948


Looking at locore, platform detection between a MicroVAX and a VAXstation
in locore.c is looking at vax_siedata. This check is used for quite a few
different MicroVAX vs. VAXStation determinations.


Looking at smg.c and and gpx.c, they have more complex checks which
correctly detect that the framebuffer is not present and thus don't cause
an issue. Conversely, lcg.c thinks we're a VS 4000/60 (or VLC), and tries
to load.


Unfortunately, just adjusting the if statements in either lcg_match or
lcgcnprobe didn't seem to be enough - I just get new and interesting
failure modes if I try that in and of itself.


I haven't managed to figure out how to fix the driver, but I did manage to
basically patch out enough of the driver so it at least loads in on the
MicroVAX while doing nothing at all. This patch is
https://gist.github.com/NCommander/3659937fa10444805637b08b1e871ef0.


For actually fixing lcg.c, I couldn't find anything documenting what would
be in vax_confdata. My initial thought is there probably needs to be an
additional check that checks SIE to determine VAXstation vs. MicroVAX and
bail out.

Any assistance in creating an acceptable patch is welcome.
~ N
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.