wjm 12-feb-1999: KA420-ROM-PATCH V1.0
These are some PATCHes to the boot ROMs of various
KA420/KA430-based VAXen (Vs3100/xx, uVAX3100/10).
Some of them have actually been tried out already ...
Background:
Boot-ROMs for Vs3100 (and early uVAX3100 models) traditionally
do not allow for SCSI system (boot) disks >1 GB, because they
exclusively use 6-byte SCSI READ and WRITE commands.
This patch to ROM code (always the same, only with some offsets
adapted to the different ROM & VMB versions) provides for
10-byte SCSI commands in case the LBN to be accessed is .ge. 2^21 .
So it ought to allow booting and dumping from/to larger disks.
In order to make room for the new code, I sacrifice
the very last portion of the debug code contained within
the boot driver (i.e. the code that writes out a screen
titled 'DKBTDRIVER halting ...' and then HALTs).
That last portion would dump 6 words of the VAX stack;
since that's where SP points in case of a HALT anyway,
no information is actually lost.
And btw, I didn't see that screen displayed yet - I know it
from TVBTDRIVER & MKBTDRIVER, which halt this way when you try
to boot from e.g. MUA0 or MKA100, and SCSI unit 1 is in fact
a disk drive ...
Files:
KA42AROM13W.COM is for Vs3100/30 & /40 "KA42-A V1.3".
KA42AROM16W.COM is for Vs3100/30 & /40 "KA42-A V1.6".
KA43AROM12W1.COM and KA43AROM12W2.COM, both applying
the same patches, are for Vs3100/76 "KA43-A V1.2".
KA41AROM14W1.COM and KA41AROM14W2.COM, also both having
the same effect, are for uVAX 3100/10 "KA41-A V1.4".
KA42BROM13W2.COM is for Vs3100/38 & /48 "KA42-B V1.3"
(this patch happens to be identical to KA41AROM14W2).
KA4ROM_READ.EXE reads the boot ROM from within VMS.
Needs PFNMAP privilege. Usage:
$ MCR dev:[dir]KA4ROM_READ outputfile
KA4ROM_CKSUM.EXE checks, and optionally 'fixes', the checksum(s)
in a disk copy of the boot ROM (in the format produced by KA4ROM_READ).
KA4ROM_SPLIT.EXE splits a disk copy into two files
that might be useful for actually 'burning' new ROMs.
[.TOOLS] has sources and .OBJ for the KA4ROM_* utilities.
Typically, there's no need to re-built the .EXE which I've
found to work on VMS V5.3 and higher.
'Upgrade' procedure (No support, no warranty, no guarantees!):
(1) Find out boot ROM version (so far I *believe* this to be uniquely
specified by the 'short' id ala "KA42-A V1.3" which is displayed
at power-on, and by ">>> T 50" (?)). Note that there's also
a longer id, which can be had from ">>> SHOW VER"; the latter
does *not* have the same "Vm.n" in it.
(2) Copy boot ROM to disk, using KA4ROM_READ.EXE . Best to stick to
the naming convention exemplified by the PATCH command files ...
(3) If the ROM version from (1) is one of the 'known' ones, apply
the corresponding 'patch command file' via
$ PATCH @KA%%%ROM%%W*
(Note that the command files provided 'know' the file names:
input is KA%%%ROM%%.BIN , output is KA%%%ROM%%W.BIN ).
If you have an 'unknown' ROM version, look at KA41AROM14W1.COM ,
and see if it can be adapted by fixing up the offsets in the lines
marked "???". (I did so for KA41AROM14 and KA43AROM12). Once you
have figured out the offsets to VMBVERS and DKBTDRIVER, you may
wish to plug them into one of the *W or *W2 files which then might
work also, as a sort of 'proof' that your DKBTDRIVER is in fact
identical to a know one ...). There are some text strings that
should be easy to locate in a full DUMP of the ROM contents ...
Sure I'd like to know what you find out in this step!
Do *not* proceed if fixing "???" lines doesn't work out completely!
You boot ROM may support booting from big SCSI disks already, or
have an 'unknown' (to me) boot driver ...
(4) Once the PATCH has been successfully applied, run KA4ROM_CKSUM
on the *output* file, and answer 'y' to the question posed ...
This will update the ROM checksums.
(5) Somehow 'burn a new boot ROM'. In the Vs3100s that I have looked at,
this is actually 2 chips, each 64k*16 bit. The one closer to the
'front' (i.e. memory connector side of the board) has the low 16 bits,
the other one ('rear', i.e. ethernet connector) has the high 16 bits
of each 32-bit longword. Both 27C210[A] and 27C1024 chips have been
seen, even as a mixed pair, so apparently they're all the same ...
(6) Tell me about your experiences ...
Wolfgang J. Moeller, GWDG, D-37077 Goettingen, F.R.Germany, <moeller@gwdg.de>
