Date: Wed, 8 Nov 1995 22:45:16 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: markem@primenet.com (Mark Monninger) Cc: julian@ref.tfs.com, questions@FreeBSD.org Subject: Re: IDE HD > 1Gb Message-ID: <199511090545.WAA28019@phaeton.artisoft.com> In-Reply-To: <199511090142.SAA03932@usr5.primenet.com> from "Mark Monninger" at Nov 8, 95 06:42:10 pm
next in thread | previous in thread | raw e-mail | index | archive | help
[ A long trieste on booting in general follows] > I'm sure this is the case. The drive (a Maxtor) handles LBA and looks like > it has fewer than 1024 cyl instead of the 2448 it actually has...instead of > 2448 cyl and 16 heads, it is remapped to appear to have 612 cyl and 64 > heads. Since FreeBSD uses the geometry from the disk (2448x16x63) instead of > from the BIOS table (612x64x63), it gets confused. By "the BIOS table", you mean "the DOS partition table"? If so, sorry, but the DOS partition table does not contain the geometry of the disk as one of its contents. If you mean "the same as the BIOS", the answer is that FreeBSD can't make the INT 13 AH=0x08, AL=<ID> call to get the BIOS apparent geometry because you can't make BIOS calls from protected mode. If you could make BIOS calls from protected mode, there's still the problem of mapping <ID> to a device node, since the DOS BIOS drive ID <ID> is based on the INT 13 chaining order, which is in turn based on the POST initialization order of the controller cards for those cards that trap INT 13 (those that don't are either built into the BIOS on the machine or they are unsupported as boot devices). The BSD device nodes are based on controller and driver (and potentially, LUN) probe order, which is kernel specific and is based on the definition and probe order, which has nothing to do with BIOS POST initialization order. > However, I still don't understand why the install floppies won't boot > (I can boot DOS or Win95 or OS/2 floppies), These all use BIOS to load the OS and BIOS or DCB based/aware protected mode drivers to do their I/O (which means they have the standard 8G drive limit -- BSD doesn't). > nor do I understand why I can't boot FreeBSD from a second, non-remapped > drive (it was installed there before I got the 1.2G drive/EIDE > controller and worked just fine). It has to be mapped. The first drive's "boot selector" or MBR loads the OS specific second stage boot from the OS's partition. Some can load from drives other than the first drive. But since a "boot selector" or MBR uses BIOS to load the second stage boot, then you can only boot from drives that you can get at via the INT 13 interface (ie: BIOS). This is complicated by the fact that the second stage boot (the OS specific boot code in BSD) *also* uses BIOS to load the actual kernel, which (because BIOS manufacturers other than IBM are stupid, and IBM used to be) can't itself call BIOS I/O routines from protected mode. The BSD second stage boot thus requires that the BSD disklabel, the BSD "slice 'a'", and any replacement sectors be below cylinder 1023 so BIOS can find them. > The controller is a DTC 2278E, which replaced a DTC 2278VL. Very > frustrating and disappointing. As these drives become more common > I'm sure there will be pressure to make FreeBSD handle them. FreeBSD "handles" them the same way most protected mode OS's that rely on BIOS based boot code (ie: boot code for Intel machines) "handle" them: by requiring that the code to be loaded by the BIOS calls resides in the range addressable by BIOS (ie: below cylinder 1024 because of the 10 bit limitation). > I believe Linux already does. Linux understands LBA. The difference is that some EIDE controllers support LBA, or what the rest of the world has called absolute sector addressing, at least since it was invented. Typically, drives for these controllers come with OnTrack 6.x or better installed on them. When booted, these drives install a TSR of up to 32k of your precious 640k DOS memory, subtract the 64 sectors off of the front of the drive, and load the MBR (if any) at the new drive offset 0 via INT 13 (which the TSR has redirected to itself). The TSR takes translated geometry requests in C/H/S at the INT 13 interface and makes LBA calls to the controller. The reason for the OnTrack INT 13 hook is that EIDE interfaces are usually too cheaply built and their ROMs are too stupid to do the translation without help. Either way, you end up with boot problems for things that don't used the BIOS. Like Linux, FreeBSD, UnixWAre, etc. The two ways to fix this are: 1) Assume the same geometry that the TSR provides. BSD almost does this, but screws up on install because when you boot from a floppy, the TSR isn't loaded and BSD doesn't properly account for that when setting up the partition table entries for the BSD or writing the boot manager (which is just an MBR replacement). 2) Assume the same geometry that the TSR provides for the install, but use LBA to actually do the I/O in the boot code. Linux does this, and correctly sees the OnTrack stuff. The Linux method complicates the boot manager and complicates the OS specific boot blocks, but lets you boot from locations past physical cylinder 1023. In either case, you'd be screwed if you tried to install in the last 1G of a 9G drive because BIOS is stupid. > If I had time, I'd try the hack myself...if I had a system to do it > on. Oh well...I probably shoulda spent the money on a SCSI drive and > controller. There are limits to the size of code you can put in the second stage boot, and there are limit on the "boot selector" replacements for the DOS MBR which both conspire against you being able to fix this problem in BSD by using LBA. Probably the easiest thing to do is to adjust the install to allow the INT 13 redirector to be loaded before the boot manager is loaded and then have the second stage boot and the kernel itself recognize this kind of drive. Note that LBA can't really be coded directly, since it's hard to identify wd drives that support it without locking up some older controllers (RLL controllers are particularly likely to lock up), and besides, no one will ever code above the least common denominator, so it's not expected that LBA disk access will be in wide use anywhere other than specially constructed boot code before NT takes over the world and you don't need it any more. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511090545.WAA28019>