Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!uunet!zaphod.mps.ohio-state.edu!rpi!greg
From: greg@ecse.rpi.edu (Greg)
Subject: 386bsd-0.1: primary bootstrap (wdbootblk.c) problem & fix.
Message-ID: <greg.712111605@hibp1.ecse.rpi.edu>
Summary: I have solved a timing dependent boot problem by adding a delay.
Keywords: 386bsd boot bootstrap wdbootblk.c
Nntp-Posting-Host: hibp0.ecse.rpi.edu
Date: Sun, 26 Jul 1992 00:46:45 GMT
Lines: 60
In a recent post I described a booting problem I was having: I could only
boot about 20% of the time in high speed mode. I tried all the latest patches,
but the problem persisted. By putting a printf at the top of boot.c, I determined that it was not making it out of wdbootblk.c.
I managed to learn enough 386 assembly language from reading the source, to
enable me to write directly to the video buffer. By placing video writes
throughout the bootstrap, I was able to figure out where it was getting hung up.
from wdbootblk.c:
readblk:
movl $ IO_WD1+wd_status,%edx
NOP
inb %dx,%al
testb $ WDCS_BUSY,%al
jnz readblk
It would get stuck in this loop, thinking that the controller was busy.
my code:
readblk:
# beware, ugly hack ahead!!
# it is safe to clobber ax, cx here
movl $0xff,%ecx
blink: movw $0x0f30,%ax
movw %ax, VIDEO
movw $0x0f5c,%ax
movw %ax, VIDEO+160
movw $0x0f21,%ax
movw %ax, VIDEO+160
movw $0x0f2f,%ax
movw %ax, VIDEO+160
movw $0x0f5f,%ax
movw %ax, VIDEO+160
decl %ecx
movl %ecx,%eax
jnz blink
# end of ugly hack
movl $ IO_WD1+wd_status,%edx
NOP
inb %dx,%al
testb $ WDCS_BUSY,%al
jnz readblk
After adding this, I was able to successfully boot 30 consecutive times at
full speed. I appologize if its ugly, as my knowledge of 386 assembly
language is entirely based on reading wdbootblk.c. I appeal to someone who
actually knows 386 assembler to write a proper delay loop. My version works
fine, but I am sure it can be more compactly coded. Also, in a final version
the video writes would be removed.
If someone could help me recode this into a more "publishable" form,
it can be made available as a patch and a patched binary. I don't think
(at least I hope), that this will "break" the bootstrap with respect
to machines other than mine. Also, I wonder if anyone has any insight as to the
cause of this problem. Perhaps there is a better fix for it.
Happily booting and rebooting,
Greg - greg@megas.ecse.rpi.edu