Subject: 11/750 microcode weirdies (long)
To: 'port-vax@netbsd.org' <port-vax@netbsd.org>
From: James Lothian <simul8@simul8.demon.co.uk>
List: port-vax
Date: 08/22/1998 15:34:05
summary: v99 pcs750.bin on 4.4bsd lite cdrom appears to be bad.

I apologise in advance for the slight irrelevance of this message. I'm 
still a 4.3 bsd person, but this might be useful to netbsd people as 
well. 

Being at a bit of a loose end, and considering that I used to write microcode
for a living, I thought I would build a writable control store for my 750, and then have
a go at a device driver to let me use it. So I added the WCS parts to the L0008 board
(let me know if you want the gory details of the upgrade), and started off my driver-
writing efforts by writing a routine that maps the WCS memory into kernel VA space,
checks to see if the WCS is present, and tests each location of WCS memory if it
is. Rebuild kernel, boot, BANG. Mr 750 says:
trap type 8, pc 0, dumping to (&c).
Oh dear. Carefully check code. Add lots of printfs. After a lot of farting around and
a week of incredibly late nights, it turns out that the machine is trapping
attempting to access physical longword addresses F00FE0 to F00FEC,
which are in the WCS memory. Address F00FDC works fine, as does F00FF0.
Verified this from the console. Lots of head-scratching. Could I have screwed up
in doing the upgrade, and shorted an address line or something? More fiddling
around. Verified that writing to the WCS is definitely not affecting the PCS. Got another
spare L0008 and re-jumpered it to respond to the WCS addresses, without adding the
other WCS parts. Got the same problem with this board. Eventually discovered
that the problem only occurs with the control store patches loaded. (I've been running
with the pcs750.bin off the 4.4bsd lite CD, since it's v99 and the pcs750.bin that came
with 4.3bsd was v97, and I thought it would be a good idea to run with the more recent
version). After investigations with the RDM, found that there are five locations in the v99
patch microcode that yield control store parity errors, and that these are definitely not due 
to hardware problems. Dug around in a pile of TU58s and found a v98 pcs750.bin. With 
this version installed, machine can see F00FE0 and friends, and it doesn't show up any 
parity errors when tested with the RDM. I haven't tried re-installing the v97 patches, since 
this would involve digging out the bsd distribution tapes. 

So, I tentatively conclude that the v99 pcs750.bin in /usr/src/etc/etc.vax on the CD is
mangled or corrupted in some way. 

James Lothian