hgm@beta.UUCP (Harry McGavran) (05/06/87)
The bootblok routine places the stack pointer at the top of the
vector region (0000:0400). When bootblok runs to load the balance of
the system, the stack pointer results in clobbering vectors 0xFF and down
for some number of vectors. The WD 1002A-WX1 ( and other hard disk
controllers) use these vectors. The range from 0000:0400 to 0000:0500
is used for the bios data area. When rebooting, the bios sets up the
vectors and puts tables and flags in the data area. The WD controller
when it gets its turn stores things in the top few vectors.
The result is, that when you run fsck on the hard disk, even though
fsck uses the bios, the stuff bios has set up for the hard disk
has been destroyed by bootblok, so fsck fails.
One fix is the move the stack segment
from zero up to some higher number.
My solution was to move the relocation point from just below 192K
for bootblok, to somewhat lower, and make the stack point 1K above
the highest point of the relocated bootblok. Now fsck is ok.
I also put in some code to set the keyboard reset flag that results
in a reboot without a memory check. Some PCs I have, have a reset
button. I use that to re-boot because I notice flakiness (described
in the book) if I use CTRL-ALT-DEL. (For reasons I would like to
understand better, but haven't had the time to look into.) Without
the flag set, the reset button results on a LONG memory check on my
slow PC.
Below are the diffs for "bootblok.s". Copy the source for the original
bootblok.s to some system with the latest version of "patch" on it.
Cut the portion below out into a file named bootblok.pat.
Then type "patch -l bootblok.s <bootblok.pat".
You will get a new bootblok.s with the fixes. Reassemble
bootblok and run build to make a new bootable floppy (as per
the instructions in the book.)
These changes are for the MINIX version of bootblok.s ONLY.
I make no claims as to the suitability of these changes for anything.
Perhaps it will allow you to get around fsck problems though.
It should be noted, that according to the IBM Technical Reference Manual
(1502237) page 2-9, mucking around with things below 0000:0500
can result in bios troubles, so I don't know why the stack was put
on top of bios vectors, when fsck needs bios to work.
----------------------------Cut here------------------------------------
*** bootblok.s Wed May 6 09:41:40 1987
--- bootblok.new Wed May 6 12:24:31 1987
***************
*** 22,29 ****
LOADSEG = 0x0060 | here the boot block will start loading
BIOSSEG = 0x07C0 | here the boot block itself is loaded
! BOOTSEG = 0x2FE0 | here it will copy itself (192K-512b)
DSKBASE = 120 | 120 = 4 * 0x1E = ptr to disk parameters
final = 504
fsck_ds = 506
--- 22,32 ----
LOADSEG = 0x0060 | here the boot block will start loading
BIOSSEG = 0x07C0 | here the boot block itself is loaded
! BOOTSEG = 0x2F90 | here it will copy itself (192K-51asdf2b-1024b-256b)
! BOOTSTK = 0x2FB0 | here is the boot stack segment
DSKBASE = 120 | 120 = 4 * 0x1E = ptr to disk parameters
+ WRMBTBS = 0x0472 | here is where the warm reboot flag goes
+ WRMBOOT = 0x1234 | warm reboot flag
final = 504
fsck_ds = 506
***************
*** 59,66 ****
mov ds,dx | set ds to cs
xor ax,ax
mov es,ax | set es to 0
! mov ss,ax | set ss to 0
! mov sp,#1024 | initialize sp (top of vector table)
| initialize disk parameters
mov ax,#atpar | tenatively assume 1.2M diskette
--- 62,75 ----
mov ds,dx | set ds to cs
xor ax,ax
mov es,ax | set es to 0
! mov ax,#BOOTSTK
! mov ss,ax | set ss to BOOTSTK
! mov sp,#1024 | initialize sp
!
! | set the warm boot flag
! mov ax,#WRMBOOT
! seg es
! mov WRMBTBS,ax
| initialize disk parameters
mov ax,#atpar | tenatively assume 1.2M diskette
--------------------------------Cut here----------------------------------
Harry McGavran
hgm@LANL.GOV
Los Alamos National Laboratory
MS-B294, Group C-8
Los Alamos, New Mexico 87545
505/667-4050hgm@beta.UUCP (Harry McGavran) (05/07/87)
One additional note to the item I posted earlier about the bootblok stack causing problems. It has been mentioned in this news group that some conrtollers with configurable tables place the tables in the vector space. That is true, but some of these controllers and others as well, place other things there too. My problems with fsck occurred even though I was not using configurable tables. I was using hardwired tables, in C800:xxxx. Other parameters put below 0000:0500 by the controller for use later by its bios were being clobbered as well. So, depending on your controller, independently of whether the disk tables are configurable, fsck may fail because of the stack problem. Harry McGavran hgm@LANL.GOV Los Alamos National Laboratory MS-B294, Group C-8 Los Alamos, New Mexico 87545 505/667-4050