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