micro-code upgrade

[Chris Torek]

In article <485 at cs.wmich.edu> dodgson at cs.wmich.edu (Harry Dodgson) writes:
>We have a VAX 11/750 ...  We run BSD 4.3 Unix -Generic-.
(which I assume means a kernel compiled from /sys/conf/GENERIC;
you really should compile a machine-specific kernel.)
>The system currently sets the microcode rev level at 98.

>The DEC rep will be in this Tuesday to upgrade the microcode to
>level 103.  He doesn't know anything about Unix. ...

He can find out, via DEC's internal courses on Ultrix.  As far as
I know, the Ultrix boot code still uses the 4BSD-style microcode
patch sequence.

At any rate:

If you look at /sys/stand/boot.c, you will find a section of code
labelled with the comment `750 Patchable Control Store magic'.  This
code attempts to open the file `/pcs750.bin' on the same partiton from
which will read `/vmunix'.  If the file exists, it is assumed to
be a PCS file and its contents are stored to the PCS.  The file
/pcs750.bin that came with your 4.3BSD tape is the rev 98 patch.

You have several alternatives.  You can (a) ignore the new microcode;
(b) load the new microcode from TU58 every boot; or (c) copy the new
microcode to /pcs750.bin.  I think we can skip (a).  (b) is painfully
slow.  That leaves option (c), which is the best all around.

The first trick is reading the microcode from TU58.  This is best
done with the machine up in single user mode.  The `arff' utility
can read TU58 cassettes.  Type

	# mount /tmp		(if you keep /tmp on another partition)
	# cd /tmp
	# arff tvf /dev/tu0	(print a list of what is on the TU58)

(you do not actually need the f option and /dev/tu0; arff normally
looks at /dev/floppy, which is the same device anyway.  Maybe some
day I will fix this to be `/dev/console-media' :-) .)

At this point, you have to find the patch file yourself.  I have no
real idea what it will be called, just a guess: `pcs750.bin' or
`pcs103.bin'.  Assuming the latter:

	# arff xvf /dev/tu0 pcs103.bin

You now have a file /tmp/pcs103.bin.  Assuming this is in the same
format as /pcs750.bin, you can then do the following:

	# cd /
	# mv pcs750.bin pcs750.bin.rev99
	# cp /tmp/pcs103.bin pcs750.bin.103
	# ln pcs750.bin.103 pcs750.bin

This leaves the original in pcs750.bin.rev99, in case you need it
later.  The only thing left then is to reboot.

There is one problem.  If the new pcs750.bin makes the machine fail
to boot, you need some way to recover.  One is to go back to the
distribution tape and load a mini-root.  This is painful.  There are
some nicer alternatives.  The simplest depends on the fact that you
have two disks.  Instead of putting pcs750.bin.103 in ra0a:/, you can
put it in ra1a:/ (along with a copy of /vmunix), and then boot from ra1a:

	>>>B/3
	Boot
	: ra(0,8)vmunix
	loading 11/750 microcode: new rev level = 103
	240096+114004+106828 start 0x16a4
	...

This assumes you have an ra1a.  (We make a practise here of keeping an
alternate root file system on one other drive wherever we have at least
two drives.  If you have /tmp on ra1a, that would suffice too.)  If the
RA81 partitions in /boot match those in your kernel, you can put the
microcode in any partition of either drive and boot from there.  (Some
boots have different ideas; check the offsets in /sys/stand/uda.c vs.
those in /sys/vaxuba/uda.c.  Yet another reason for disk labels....)
If all else fails, you can cheat and put it in a partition that starts
at offset 0 on ra1, and boot from ra1c (ra(0,10)).

If, for some reason, you choose option (b), you will have to rename
or remove (renaming is suggested) /pcs750.bin, or /boot will promptly
downgrade your machine before loading /vmunix.

One other alternative is to build a new /boot, installed as /boot1
or /boot.new or ..., which reads pcs750.bin.103 (an easy change to
/sys/stand/boot.c), and boot /boot1:

	>>>B/3
	Boot
	: ra(0,0)boot1
	Updating 11/750 microcode: new rev level = 98
	Boot
	: ra(0,0)vmunix
	Updating 11/750 microcode: new rev level = 103
	[sizes, etc]

When you decide that everything works, rename pcs750.bin.103 as
pcs750.bin, remove /boot1, and you are all set.  (The `boot1' technique
works well for testing new /boot programs as well; it is what I used
for testing my QDSS standalone console driver.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris