info-vax@ucbvax.ARPA (05/03/85)
From: hadron!jsdy@seismo.ARPA (Joseph S. D. Yao)
On booting from a disk, using VMB.EXE (3.?), VMB is supposed to leave
a section of relocatable code in memory that can be used as a driver
for the boot disk. With the UDA50 driver, it's necessary to re-call
the initialisation routine after re-location to let the UDA know where
the new communications buffer area is. The initialisation code has a
bug in it, however, that only shows up when the bootstrap driver code
is relocated to a location whose last 9 bits are in the range 0xf8 -
0x147. In this range, the UDA communications buffer area falls across
a 0x200 boundary, so when you AND 0x1ff to different addresses for the
UNIBUS Map, you don't get sequential offsets!
In particular, after the UDA device register initialisation, the
following code:
MOVAB RSPPKT, R1
BICL BYTE_OFF, R1
BISL3 R6, R1, RD
MOVAB CMDPKT, R1
MOVL R1, R5
BICL BYTE_OFF, R1
BISL3 R6, R1, CD
should be changed to (something like):
movab inittbl, r1
bicl byte_off, r1
addl3 #rsppkt-inttbl, r1, rd
addl3 #cmdpkt-inttbl, r1, cd
movab cmdpkt, r5
This preserves the relative addresses of the different parts of the
UDA communications area within the space mapped onto the UNIBUS.
This was found, in fact, when I tried to write a boot block for UNIX
System V (Rel. 1) that mapped itself down to 0x50000, mapped the
Restart Parameter Block (RPB, size 0x110) down to 0x50200, then mapped
the UDA50 boot driver to 0x50310. My temporary solution was to
declare that the RPB has size 0x180, and so amp the driver down to
0x50380. (The boot block grew while being debugged; the above
addresses are now, respectively, 0x50400 and 0x50580. Same problems,
same !temporary! solution. I hope DEC fixes this.)
I am not a subscriber to this newsgroup, so would appreciate if any
responses to this also get forwarded to me either by Email (below) or
in any other way.
Joseph S. D. Yao hadron!jsdy@seismo.{ARPA,UUCP}
Information Technology Division
Hadron, Inc.
9990 Lee Highway
Fairfax VA 22030 (703) 359-6163