Trailing-Edge
-
PDP-10 Archives
-
bb-lw55a-bm
-
7-documentation/boot.tco
There are 25 other files named boot.tco in the archive. Click here to see a list.
TCO-number: 7.1001
Written-by: PRATT Creation-date: 28-May-87 15:34:43
Edit-checked: Yes Document: No TCO-tested: Yes
Maintenance-release: No Hardware-related: No
Program: BOOT
Problem:
EDDT cannot find individual module symbol tables at BOOT
time when certain monitors are loaded. The command "name<esc>:"
will "beep U". This sometimes prevents these monitors from being
debugged at startup.
Diagnosis:
To find the individual symbol tables for each module, EDDT
traces thru the symbol table backwards. Each module contains a
two word entry which has a radix 50 name of the module and a
-count,,value. The minus count is used to get to the next symbol
table. When stepping thru the table, EDDT encountered a 0 entry
where the MDDT symbol table entry should have been. Since EDDT
didn't find the module the user wanted, it "beep'd U".
When the monitor is loaded by BOOT, the symbol table is
located in section 0 where EDDT has access to it. MDDT's 0 entry
was caused by page 600 being zeroed by BOOT. BOOT wiped out page
600 because there was an entry in the .EXE file's directory
which called for a zero page at page 1600. BOOT treats any page
in the .EXE that is over 777 as physical memory. Unfortunately,
BOOT incorrectly BLT'd page 600 to zero because it tried to
reference page 1600 as virtual and not physical.
Solution:
Re-write the G.DIR4 routine to correctly handle all zero
pages when they must be created beyond BOOT address space. Do
this by temporarily mapping the physical page requested to a
page mapped by BOOT and then BLT the page to zero.
In addition, do some minor fix up on the debugging code.
[End of TCO 7.1001]
TCO-number: 7.1224
Written-by: GSCOTT Creation-date: 12-Feb-88 09:20:02
Edited-by: GSCOTT Edit-date: 12-Feb-88 10:18:49
Edit-checked: No Document: No TCO-tested: No
Maintenance-release: No Hardware-related: No
Program: BOOT
Problem:
Monitor can't tell when it is supposed to prompt for "Why Reload" and
"Run CHECKD".
Diagnosis:
Currently BOOT doesn't tell the monitor if it has been an no-prompt reload
(e.g. after a BUGHLT) or if some friendly person just ran KLI and booted
the system.
Solution:
Write the flags sent to BOOT from KLI into BOOTFL (in the boot communications
area). Now BOOTFL will take on the following values:
If BOOTFL is zero the monitor should do whatever it used to (no prompt if 20F
has the date and time). If BOOTFL is -ive then it was an auto reload (no
prompt like after a BUGHLT). If it is +ive then the monitor should prompt for
why reload and run CHECKD. Note that BOOTFL will be zero when older versions
of BOOT have loaded the monitor.
[End of TCO 7.1224]
TCO-number: 7.1228
Written-by: GSCOTT Creation-date: 16-Feb-88 15:13:48
Edited-by: GSCOTT Edit-date: 19-Feb-88 10:21:22
Edit-checked: No Document: No TCO-tested: No
Maintenance-release: No Hardware-related: No
Program: BOOT
Problem:
Problems dumping to RP07s including SWC, LWC, overruns.
Diagnosis:
Boot version 11 attempts to write the dump in large contiguous sections that
are up to 1 cylinder in length. Unfortunately there are some math problems
when it tries to compute the contiguous sectors for RP07s. Also the transfers
for RP07s are so large that they cause overruns.
Solution:
Fix the math problems by setting IDXADR to only include the useful parts of a
disk address (3,,777777). Also set the maximum pages to dump to be 95 (one cyl
on an RP06) which will prevent overruns in most cases on RP07s. To prevent all
overruns on RP07s only 8 pages at a time could be dumped. More work should be
done to try to recover from overruns while dumping and should be done in a
later development edit to BOOT.
[End of TCO 7.1228]
TCO-number: 7.1229
Written-by: GSCOTT Creation-date: 16-Feb-88 15:24:46
Edit-checked: No Document: No TCO-tested: No
Maintenance-release: No Hardware-related: No
Program: BOOT
Problem:
BOOT's CTL file is a mess.
Diagnosis:
Sloppy edits.
Solution:
Clean up BOOT.CTL.
[End of TCO 7.1229]