Date: Tue, 21 May 1996 18:36:04 -0700 From: erich@uruk.org To: Terry Lambert <terry@lambert.org> Cc: freebsd-hackers@freebsd.org Subject: BIOS Disk setup (was -> Re: Glitch in install procedure.) Message-ID: <199605220136.SAA14623@uruk.org> In-Reply-To: Your message of "Tue, 21 May 1996 16:48:33 PDT." <199605212348.QAA02519@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert <terry@lambert.org> 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): <erich@uruk.org>
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605220136.SAA14623>