Date: Tue, 21 May 1996 19:10:44 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: erich@uruk.org Cc: terry@lambert.org, freebsd-hackers@freebsd.org Subject: Re: BIOS Disk setup (was -> Re: Glitch in install procedure.) Message-ID: <199605220210.TAA02885@phaeton.artisoft.com> In-Reply-To: <199605220136.SAA14623@uruk.org> from "erich@uruk.org" at May 21, 96 06:36:04 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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? No, actually, I think the kernel should use the BIOS until it has all the information it needs to put its drivers in place of INT 13 based drivers and still reliably get the INT 13 information. This is slightly different. I know that I couldn't possible expect the Adaptec BIOS to operate after we overwrite the Adaptec supplied microcode (for instance). > > 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). If you get all of the disks, and compare them for uniqueness so that you have a fully populated interference graph, then you can. This might take some time to do if you have identical data on a lot of select blocks on a lot of disks. But it *is* doable. > 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. They chain the INT 13 during POST after asking anyone in front of them (ie: anyone who POSTed first) what BIOS drives are there. If you install a second disk on controller 1, you move ID's 0x81 and so on up one ID. The chain knows that 0x82 was supplied by this controller, and so it acts accordingly. This (and the broken IFSMgr_SendEvent) is the reason you have to reboot Win95 after partitioning... logical drive numbers (at the INT 21 interface) are treated the same way based on partition table decoding. > 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). That's a bit evil. Better to load all the information to identify all INT 13 physical drives uniquely (a set of sector offset/value tuples is sufficient). Then you can probe controllers you recognize, grab the physical devices, and then anything that doesn't map, you know it's on a controller you couldn't probe. Because of that, you know it's safe to use VM86()-based BIOS calls to communicate with those devices (assuming you can). For a completely modular kernel, this would be all drives during install, and during the boot stage until controller-specific drivers have been dynamically loaded (booting is a single-threaded sequence of events anyway). > > > 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?). Clever. But dies in the face of SCSI + IDE in the same machine. 8-(. You could use the INT 21 raw read and a knowledge of partition tables coupled with INT 13 physical raw reads to identify which logical drives are on which disks, etc.. This is basically what Win95 does during its switch to protected mode. > > 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 ? Nope; unfortunately, you have to have VM86() to call EISA BIOS to get the amount of per slot CMOS for a card -- it's not standardized. Then you have to know how the card uses the CMOS. In general, this is done by hard-coding the knowledge in the driver, since the CFG files can't be used by a jernel to decode the information (the CFG files are themselves only internally consistent with the driver, and not standard otherwise, as far as decoding what resources are in use). > Well... the BugLogic is still predictable, in general. 8-). > > 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"... You have to know the BIOS geometry to be able to create legal partitions; for instance, the OS/2 boot manager is picky about cylinder boundries. You also need to make sure the BIOS-based boot blocks will get the same real sector for the start of the BSD partition as BSD has in the disktab, so the offset can be interpreted, first by the BIOS-based second stage boot to load the kernel, and second, to calculate the real sector offset in BSD for the C/H/S value in the partition table, which must be interpreted by protected mode code. There are also issues like linear translation (sector c*H*S + h*S + s is abosolute sector AS), offset linear translation (OnTrack LBA MBR's offsets all addresses through INT 13 by -64 sectors; other LBA MBR's offset by 1 Cylinder, or whatever, etc.), and non-linear translation (sector sparing in the BIOS, such that DOS partitions are unusable, like WD1007 controllers with J8 J14). Etc.. > 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. Assuming the query works on all old hardware. ;-). (AFAIK, it does). 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?199605220210.TAA02885>