From owner-freebsd-hackers Tue May 21 18:36:05 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA23976 for hackers-outgoing; Tue, 21 May 1996 18:36:05 -0700 (PDT) Received: from uruk.org (uruk.org [198.145.95.253]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA23841 for ; Tue, 21 May 1996 18:35:49 -0700 (PDT) From: erich@uruk.org Received: from loopback (loopback [127.0.0.1]) by uruk.org (8.7.4/8.7.3) with SMTP id SAA14623; Tue, 21 May 1996 18:36:04 -0700 (PDT) Message-Id: <199605220136.SAA14623@uruk.org> X-Authentication-Warning: uruk.org: Host loopback [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: freebsd-hackers@freebsd.org Subject: BIOS Disk setup (was -> Re: Glitch in install procedure.) In-reply-to: Your message of "Tue, 21 May 1996 16:48:33 PDT." <199605212348.QAA02519@phaeton.artisoft.com> Date: Tue, 21 May 1996 18:36:04 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert writes: > > > This will let you map the 0x8x ID's to BSD devices, and therefore > > > map the geometries, known by ID's, to the BSD devices. > > > > > > This solves all the problems. > > > > INT 13 reads might not work, since even the probe might ruin the BIOS > > setup with the controller. > > If this happens, it's broken. I must admit to being no expert on the interaction of BIOS and other drivers, but I generally haven't heard that a disk controller's BIOS is very happy about having the controller stolen out from under it (or for that matter, having a disk driver be unloadable in DOS). So, you're claiming the BIOS interface should work even after poking and playing with the hardware directly? > I know all you would need to do is preread all BIOS devices to get unique > sector/byte identifiers. There isn't enough room in the second stage > boot to do this before the probe. If the kernel could make vm86() > calls, it could do it before the probe, though. I agree on this point... but in general you can't really be sure that each disk is unique. (OK, the probability is VERY high that you will be able to tell the difference). Hmmm... it makes me wonder how the various manufacturers do it in DOS, but they probably have a way to ask their own BIOS interfaces which controller it is really on. That gives me a crazy thought. If you find a real disk controller... use a VM86-mode handler (i.e. one with enforced protection!) to try to make a BIOS call. If it works correctly, and the hardware driver says the device was "untouched", then you know that it wasn't the one probed. If it hangs past some timeout, or some other such thing, then you know which BIOS device it is (was). > > Well, we do know: > > > > 1) The order of IDE controller initialization. > > ??? I don't know how to figure that one... Easy. If the controller is using interrupt 14, it's the first one. You then count through the drives (the "master" drive of course being first on each controller). Admittedly, this would break if someone was running an IDE controller at a different interrupt than 14 or 15, but I have yet to see a controller which lets you do this (I agree one should be sure of this one first, but if it is an invariant, why not take advantage of it?). > > 2) Each SCSI adapter driver knows it's BIOS translation, right? > > (or what it's capable of... the newer BusLogic controllers, > > for example, adapt to the BIOS translation it finds in the > > MBR of each hard drive if you have it set up right) > > No. Adaptec 1742 controllers (for instance) have two possible > translation modes, based on an EISA config setting. The BusLogic > "autodetection" is scary. So, is the EISA config setting not interpretable in general for the 1742 ? Well... the BugLogic is still predictable, in general. > In any case, you have to ask the controller using BIOS (INT 13, AH=0x08) > to get the BIOS answer. 8-(. What do you mean here? You haven't provided a "why" for the "in any case"... ...[on the topic of reading past the 8GB limits imposed by the standard INT 13h C:H:S interfaces]... > > > Have you looked at the VFAT32 code? They change both the partition > > > table data and the msdos.dos/io.dos (the replacements for io.sys and > > > msdos.sys for DOS 7.x). The add additional INT 13 entry points for > > > doing all this, and they make the system recognize them. > > > > Well, the "standard" BIOS LBA calls might just work if I use them, though > > there are still a few issues to resolve. > > Yeah, like whether or not they are there when you boot off the floppy > to boot BSD. They aren't, if they are provided by ONTrack or similar > software and you didn't boot off the hard drive. 8-(. The BIOS LBA calls have a "query to see if I exist" call. That plus knowing you can't use them for floppies seems reasonable. As it is I only use the "BIOS geometry" call when booting off of a hard disk, because it doesn't work on some machines... and it certainly doesn't return the right values for floppies of different sizes than the normal drive setup (like a 720K floppy in a 1.44MB drive). I perform a probe to figure out the disk size on those. -- Erich Stefan Boleyn \_ E-mail (preferred): Mad Genius wanna-be, CyberMuffin \__ (finger me for other stats) Web: http://www.uruk.org/~erich/ Motto: "I'll live forever or die trying" This is my home system, so I'm speaking only for myself, not for Intel.