Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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@localhost:/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



Home | Main Index | Thread Index | Old Index