Date: Thu, 16 Oct 1997 19:12:19 -0700 (PDT) From: David Filo <filo@yahoo.com> To: mike@smith.net.au Cc: freebsd-hackers@freebsd.org Subject: Re: biosboot/start.S needs fix for Intel AL440LX motherboard Message-ID: <199710170212.TAA22643@ns2.yahoo.com> In-Reply-To: <199710170011.JAA02473@word.smith.net.au> (message from Mike Smith on Fri, 17 Oct 1997 09:41:09 %2B0930)
next in thread | previous in thread | raw e-mail | index | archive | help
> > > The latest BIOS from Intel for their AL440LX board does not pass the > > drive number in %dl as biosboot/start.S assumes (instead %dl is set to > > 0). The end result is that you cannot boot from a harddrive if you're > > not using slices (a "Read error" occurs after the BIOS hands over > > control). Booting from floppy works fine and using slices with bteasy > > works as well. > > Unpleasant. How are you supposed to differentiate between booting from > a harddisk (0x8?) and a floppy (0x0?) ? > you know you're booting from harddisk because that's where the code comes from. the mbr on harddisk assumes it's a harddisk boot. the mbr on floppy assumes it's a floppy boot. > > Forcing %dl to $0x80 (which is what bteasy appears to do) solves the > > problem for me. I assume the real solution is a bit more complex than > > this. I suppose this could be due to some weird BIOS setting, but I > > think I pretty much tried everything. This board will be popular, so > > would be nice to get this fixed. > > Unless Intel are angling for compatability with some other standard, I > think the correct fix will be a BIOS upgrade. If they are, it'd be > handy to know which one, so that we can detect and support it. > > Forcing %dl to 0x80 obviously breaks using the same start.s for both > harddisk and floppy booting. > yep. but doesn't seem like that big a deal to have separate versions. btw, bteasy can deal with %dl not properly set. the first thing it does is check for (%dl == 0x81). if this fails it sets %dl to 0x80. should this solution be used in startup.S as well? in our setup i don't think 0x81 is even possible (how would you get a boot1 from any disk other than scsi id 0?). so doesn't seem too bad to have boot1 on sd0 forced to 0x80. david
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710170212.TAA22643>