Subject: VAX 6000-460 booting saga continues ...
To: None <port-vax@netbsd.org, classiccmp@classiccmp.org>
From: Gunther Schadow <gunther@aurora.regenstrief.org>
List: port-vax
Date: 12/30/2001 01:36:31
Hi,
after a quick excursion in getting a PDP8/A up and running (as far
as that gets without any peripherals other than the programmers
console :-), I'm now back to the big toy. The 6460 is still waiting
to boot Ultrix.
Recap: it's up and running from VMS 7.2 or VMX 5.6 from RA90
disks through KDB50 and KDM70. I don't have any working IP
communication because the VMS 5.6 just doesn't have anything
and 7.2 has MULTINET which just refuses to run with the old
license key, nor with a cheat hack, nor with a hobbyist
license key. So I'm now down to transferring files through
modemspeed. (I could write a TK70 or 9-track tape at my
workplace, but that's a hassle by itself, so I keep that as
a last restort.) Luckily I have kermit on the VMS 7.2 so
I have a convenient yet slow way of transferring files.
I also have a boot tape from Isildur. That's Ultrix 4.1.
That version seems to not support the 6400, it boots up
until a certain point and then simply halts. I'm very
sure it is *not* a tape read error and that the boot
process fails somewhere after the VMB is loaded and probably
at the point where vmunix is started. I assume it just can't
get a hold of the console at that time to put out an error
message and just dies. Even the primary ultrixload will
dump an error message before it halts.
The more recent developments:
I also have an Ultrix-4.5 CD. But no CD ROM hooked to the
VAX and no other VAX (InfoServer) with CD ROM and so I
cannot boot that. I could possibly just write the CD ROM
image onto a disk verbatim and fingers crossed boot from
it. However, I cannot pump the 178 MB through the 9600
b/s line, or else I have to have that thing up for 2
days and two nights only for something that might just
plain not work.
Interestingly this CD is not an ISO file system but a
simple UFS written to the CD in 10 kB blocks. FreeBSD's
mount unfortunately cannot mount that. However, I just
dd'ed an image onto disk and vnconfig - mount form there.
It's read-only and disklabel doesn't make any sense out
of it, but I can read everything just fine.
Today's news:
So, I decided I make myself a bootable tape from the
reverse engineered Ultrix 4.1 boot tape and the new
4.5 files from the CD. The Ultrix boot tape comes with
a vmunix that apparently has some sort of standalone
memory root file system. Then it supposedly is able to
set up a disk and install a dump backup onto that disk.
That dump backup contains mkfs, disklabel, ifconfig, rcp,
uncompress, and tar, so I have everything to set myself
up even if the autoinstaller cannot deal with my hack.
The boot tape I could read from VMS.
$ MOUNT/FOREIGN/BLOCKSIZE=512/RECORD=512 MUC6
$ COPY MUC6: FILE.00
$ COPY MUC6: FILE.01
$ COPY MUC6: FILE.02 --> ERROR
$ DISMOUNT MUC6:
$ MOUNT/FOREIGN/BLOCK=10240/RECORD=10240 MUC6
$ SET MAGTAPE /SKIP=FILE:2
$ COPY MUC6: FILE.02
$ COPY MUC6: FILE.03
$ COPY MUC6: FILE.04
$ COPY MUC6: FILE.05
...
and so on. It's got some 40 or so files on it. What there
files are we are being told from the ultrixload.c source
code.
FILE.00 is the ultrixload image, about 18 kB in size.
Ultrixload is said to load either vmb.exe or a
standalone kernel from a non-file structured device.
The layout of the boot device is descibed as:
FILE.00 - ultrixload
FILE.01 - a combo consisting of
- descriptor block 1 512 byte block
- vmb.exe (optional)
- vmunix (compressed if not a TK50)
This magic descriptor block is described as:
struct desc {
union {
char pad[512];
struct {
struct exec x; /* a.out image header */
int nblks; /* num of 512 byte blocks on medium */
int vmbblks; /* size of VMB in 512 byte blocks */
int compressed; /* 1 = compressed, 0 = not compressed */
} d
} un
};
By loading the initial portions of the other files down
to my BSD system and using file and stuff, I figured the
other files:
FILE.02 - the ROOT file system dump
FILE.03 - an uncompressed tar of the instctl files (on the CD)
FILE.04 - a compressed tar that is called ULTBASE450 on the CD
FILE.05 - a compressed tar that is called ULTBIN450 on the CD
...
and so on. The instctl tar begins with a file called ULT.image
and that is just a list of files beginning with ROOT, ULTBASE,
ULTBIN, that apparently correspond with the files on the tape
in that order.
So, my plan is to fiddle with files 0 and 1 only and keep the
rest, as it should be compatible with the 4.5 kernel. That
reduces the amount of data to transfer tremendously.
Quickly I found that I have no ultrixload on the CD, so the
old version will have to do. As I have strong indication that
that works, I can leave it at that.
Remains to work on file 1, that funny combo of descriptor,
vmb.exe and vmunix. The tar file 4 (ULTBASE) contains a
vmb.exe as well and so I could compare the two files that
came with ultrix 4.1 and 4.5 respectively. They were both
the same size and actually both the same. I successfully
extracted another exact copy of vmb.exe using
dd if=file.01 bs=512 of=vmb.exe skip=1 count=86
So, whatever VMB.EXE is for (sounds like a VMS boot block),
I can reuse the old one. Given that I have a standalone vmunix,
all I'd need to do is cut and paste that somewhere after
block 86 to the end of file 1 with a few cat and dd operations.
But here the problem starts. I cannot interpret the descriptor
block very well. It tells me that the VMB.EXE is 86 blocks
in size and that is exactly 44032 bytes, that corresponds
with the actual size of the vmb.exe file from the tar archives.
Good, but apparently the vmunix is not a complete piece.
Apparently that descriptor block's a.out header slot actually
holds the a.out header from the vmunix file and the vmunix
file is right after the vmb.exe without it's a.out header.
I also see a lot of 0 data in that region. So apparently I
will have to fiddle with that a.out header and need to know
just where to cut vmunix. That is a problem.
I will try to figure that out somehow. My hunch is that the
a.out block (which I haven't been fiddling with since I
ported Kyoto Common Lisp to 386/BSD 0.1) allows for the
executable to actually have some other stuff like that vmb.exe
before the actual start of the executable image. I have no
idea though what the purpose of this stupid vmb.exe is.
All in all I'm optimistic. I'd love to make a boot tape with
4.5 Ultrix that I could then share with my friends (that
is you) who also want to get their 6400s converted to Unix.
As always I'd be thankful for any helpful ideas you might
have.
regards,
-Gunther
--
Gunther Schadow, M.D., Ph.D. gschadow@regenstrief.org
Medical Information Scientist Regenstrief Institute for Health Care
Adjunct Assistant Professor Indiana University School of Medicine
tel:1(317)630-7960 http://aurora.regenstrief.org