port-vax email draft

gistfile1.txt

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]         ncmdr@soapmaker.lan:/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

Getting this to work was effort and not a fun debug session. 

This manifested itself as the INSTALL kernel loading properly from MOP, but the system falling over with garbage on the console when loading GENERIC. 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 hijacks the console and spits out what I assume are DEC graphic commands out on the console port
Looking at the driver itself, and what locore.c does for platform detection, I think lcgcnprobe is broken.
voidlcgcnprobe(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 (I'm still learning NetBSD's internals), 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 though is there probably needs to be an additional check that checks SIE to deteremine VAXstation vs. MicroVAX and bail out.

Any assistance in creating an acceptable patch is welcome.
~ N