*BSD News Article 10232


Return to BSD News archive

Received: by minnie.vk1xwt.ampr.org with NNTP
	id AA7512 ; Fri, 22 Jan 93 14:00:11 EST
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!gatech!news.byu.edu!ux1!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: [386BSD] boot disk does absolutely nothing on gateway 4dx33v
Message-ID: <1993Jan21.221451.10039@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University  (Ogden, UT)
References: <1jkdpeINNkeg@cat.cis.Brown.EDU>
Date: Thu, 21 Jan 93 22:14:51 GMT
Lines: 85

In article <1jkdpeINNkeg@cat.cis.Brown.EDU> tim@news.Brown.EDU (Timothy Miller) writes:
>I have acquired the boot disk image for 386bsd, and no matter what I try,
>when my system starts up, it displays all the bios messages, and then hangs
>with the floppy drive light on. I have tried waiting for half an hour (just
>to be on the safe side), I've tried keeping the keyboard unplugged during
>reboot and also only unplugging it when it gets to the hang stage (because of
>reading about gateway keyboard problems), I've tried disabling in nvram/eeprom
>everything I can get my hands on, including setting IDE speed to slow,
>cpu speed to slow, internal & external caching off, bios shadowing disabled,
>ide block mode disabled, turning the ATI's memory aperture off, etc. I've
>tried booting off of fixit as well as dist, and as well as the debug versions
>of the bootables.  I know I'm installing the disk image correctly because
>doing the same thing with the linux disk images works perfectly (in fact linux
>successfully installs and runs fine, without my even needing to turn anything
>off (except gcc dies unless I turn external caching off)).
>
>I've examined the source to the boot blocks for both linux and 386bsd (and
>confirmed that they matched the binaries), and as far as I can tell both
>are doing about the same things, with the exception that the 386bsd goes
>directly to the floppy ports where linux uses the bios interrupts, and 
>linux loads itself into 0x90000 where 386bsd uses 0x98000. However, linux later
>writes directly to the floppy ports and that works fine, and linux uses the
>same port locations as 386bsd. Since I don't hear any disk access after the
>light turns on, I would guess that the hang is coming before the point where
>the boot block loads in anything else, but that's only a guess; I don't know
>if I'd necessarily hear it loading in the 15 sectors if that doesn't require
>moving the heads, for instance.

This is the "Compaq boot problem".  You can get the patch from the file
~/terry/patch.bootblock.fdboot.c on ref.tfs.com, download a Compaq
dist.fs or fixit,fs, or go to a news archive and get the article
"Message-ID: <1992Dec08.132820.29435@crash>".

The problem is insidious, and it's a wonder anyone can boot at all; from
the referenced article:

] Also, Akihiro Higashi, in article
] <1992Sep11.051554.29192@mlab.nttdocomo.co.jp>, reported that he
] had to change 3rd & 4th "NOP"s to "JMP .+2"s on his COMPAQ 486/50L.
] 'NOP' is a delay macro which alters the AL register.  The specific
] ange 3rd & 4th "NOP"s to "JMP .+2"s on his COMPAQ 486/50L.
] 'NOP' is a delay macro which alters the AL register.  The specific
] instances mentioned involve code resetting the DMA controller's first/last
] flip-flop and then programming the DMA controller's mode register.
] The initialization byte for the mode register is clobbered by a NOP
] (I am amazed that the boot works on most systems!).  This can be fixed
] by rearranging the code slightly.

And for brave, brave souls:

] Fortunately, these changes do not shift the boot code, so a binary patch
] is possible.  The changes to the first sector on the disk (fixit.fs or
] dist.fs) are given below:
] 
] Offset    Old    New
] ------    ----   ----
] 0x00e1    0x07   0xbf
] 0x00f2    0xb0   0xee
] 0x00f3    0x46   0xe4
] 0x00f4    0xee   0x84
] 0x00f5    0xe4   0x4a
] 0x00f6    0x84   0xb0
] 0x00f7    0x4a   0x46

I believe the pattern "b0 46 ee e4 84 4a" would exist even on altered boot
disks, since this portion of the boot would be unchanged, even if not at
the same offset.  Work back by -15 (decimal) to fix the e1 offset value.


Using either a binary patch or Compaq boot disks should alleviate the
need to have a working system to build a disk to have a working system...



					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
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
-------------------------------------------------------------------------------