Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!spool.mu.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: [386bsd] strange solutions revisited
Message-ID: <1992Sep21.050906.23988@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1992Sep20.185358.2092@drycas.club.cc.cmu.edu>
Date: Mon, 21 Sep 92 05:09:06 GMT
Lines: 120
In article <1992Sep20.185358.2092@drycas.club.cc.cmu.edu> ghod@drycas.club.cc.cmu.edu writes:
>Greetings again...
>
>This is directed to Lynne Jolitz, who responded to my first post.
>
>It seems there's another way I can get the dist.fs floppy to boot that doesn't
>involve the 'bait and switch' trick I described previously. I discovered that
>if I press a key on the keyboard (any key) while the system boots, the
>bootstrap code doesn't hang. Also, the problem persists even now that
>I installed the binaries on my hard disk: what happens is that the boostrap
>code is read from the hard disk, then the floppy drive light comes on and
>the system locks up again. Both the 'bait and switch' and holding down a key
>on the keyboard will permit me to boot from the hard disk properly. Obviously,
>there must be something funny going on with my disk controller, however my
>controller circuit appears to be part of the motherboard so I'm afraid there's
>not much I can tell you about it.
You may want to try Hans Nasten's boot fix from (pretty ancient) 0.0 aritcle
<1992Apr21.163753.15468@everyware.se>. In it, he says:
>The floppy bootstrap in 386BSD uses the interrupt controller in a somewhat
>unorthodox manner. Chipsets with a less than perfect emulation of the 8259
>interrupt controller will get into trouble. ( at least the WD chipset on
>my WD LPX motherboard ).
>
>This is the offending code in the floppy boot module :
>
>/* watch the icu looking for an interrupt signalling completion */
>
> xorl %edx,%edx
> movb $0x20,%dl
>2: movb $0xc,%al
> outb %al,%dx
> NOP
> inb %dx,%al
> NOP
> andb $0x7f,%al
> cmpb $6,%al
> jne 2b
>
>
>Replacing the "jne 2b" instruction with 2 nop's made my SX boot the "0.0newer"
>distribution. Without this patch it never got past the initial bootstrap.
Additioanlly, Julian has posted BIOS-based boot blocks.
There is also a suggested modification (a delay) around the keyboard reset in
article <1992Sep09.135513.18978@crash> (from Frank Maclachlan):
>I encountered the BOOT009 bug (buglist 2) when I replaced the mother-
>board in my 386BSD 0.1 system with an OPTi chipset based clone 386/40
>clone board. The copyright notice appeared and the system hung w/
>no further activity.
>
>I fixed the problem by adding a delay in the probe routine in
>'/sys/i386/isa/pccons.c' just before the keyboard controller is reset.
>Apparently the keyboard controller reset was falling through the cracks
>because of insufficient delay between the output to KBOUTP and the call
>to kbd_cmd() on the next line and the test for an ack from the keyboard
>controller was looping endlessly. I am enclosing a context diff of the
>changes I made.
>
>
>*** pccons.c.ORIG Tue Aug 11 17:08:53 1992
>--- pccons.c Sat Aug 22 14:16:26 1992
>***************
>*** 173,182 ****
>--- 173,184 ----
> outb(KBOUTP, CMDBYTE);
>
> /* Start keyboard stuff RESET */
>+ DELAY(1000);
> kbd_cmd(KBC_RESET);
> while((c = inb(KBDATAP)) != KBR_ACK) {
> if ((c == KBR_RESEND) || (c == KBR_OVERRUN)) {
> if(!again)printf("KEYBOARD disconnected: RECONNECT \n");
>+ DELAY(1000); /* just in case */
> kbd_cmd(KBC_RESET);
> again = 1;
> }
>
Finally, in article <peter.713629934@hilly>, Peter Galbavy suggests:
>Subject: Re: 386BSD 0.1 keyboard problems on laptop...
[ ... ]
>Found the solution !!!
>
>I took the kbdreset() function from i386/stand/kbd.c and replaced the
>code that resets the keyboard in pccons.c (pcprobe() ?), and all
>is now OK. The extra lines to "defeat gate a20" seem to make the differnce.
Out of these, I find Peter's patch more esthetically pleasing; unfortunately,
it's simply a description, and the problem doesn't repeat for me.
Additionally, the idea of a "coerce to known mode" appeals to me more than
a reset, which is going to be done by the BIOS as part of the pre-boot
reset anyway... so reading for an ACK seems like a waste to me, as does the
idea of a full reset.
Unfortuantely, I don't have a patch for this that I can simply distribute
as a working example. Try one of these to get around the problem if you
have already tried using Julian's BIOS-based bootstrap code (in case Lynne's
idea that the floppy controller is in a weird mode is correct).
Good luck!
Terry Lambert
terry_lambert@gateway.novell.com
terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------