Date: Tue, 21 May 1996 20:08:42 -0700 From: erich@uruk.org To: Terry Lambert <terry@lambert.org> Cc: freebsd-hackers@freebsd.org Subject: Re: BIOS Disk setup (was -> Re: Glitch in install procedure.) Message-ID: <199605220308.UAA14803@uruk.org> In-Reply-To: Your message of "Tue, 21 May 1996 19:10:44 PDT." <199605220210.TAA02885@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert <terry@lambert.org> writes: > > 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). Hmmm... I think we're generally in violent agreement, then. > > 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. I agree that statistically, this is highly likely to work. I'm worried about the degenerate cases. > > 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. Yes, yes. I'm aware of this stuff... that's why I had the idea in the following section. You didn't really respond about the same topic, though. I was curious about how the manufacturers figure out which BIOS drive number corresponds to their own disk with their higher-performance/functionality drivers when transparently replacing the BIOS service without disturbing the other drives. I think this is also somewhat relevant to the next section. > > 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. Well, at least if it works, it would be a known mechanism. The statistical probe strikes me as a kind of shot in the dark, since you really can have duplicated disks, for example... or zeroed disks. You'd have to allow for failure of the 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). In general, I agree this is the Right Thing (tm) to do, whatever probe mechanism one uses to determine the which drives are OK to use. > > > > 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-(. I was simply referring to the fact that this is how you can identify IDE devices. SCSI still needs the more general-purpose solution we're haggling over above. > 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. Huh? You never need to work with the "INT 21" stuff (isn't this also installed by DOS... I'm talking about raw BIOS services). AFAIK it is completely determinable from the physical raw interface (INT 13 -based) plus knowing partition tables. > > > 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. Well, if you know how the controller will/would treat the disk, you're done. > 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. This is simply all part of synchronizing your tables. I don't see any real problem here other than education and debugging. Frankly, worrying about the "C:H:S" numbers isn't really necessary for booting an OS you have control over. There are ways around it (my bootloader gets around it, for example). The main problem is addressable area. > There are also issues like linear translation (sector c*H*S + h*S + s > is abosolute sector AS), Any controller/partitioning scheme that works with DOS uses the "standard" linear translation. DOS's boot sector does, and so does any controller that has to switch to linear mode when a fancy driver takes over. Only the single-block first stage/MBR blocks even use C:H:S addressing in "raw" form. All the rest translate to linear already (in my bootloader, I simply do it at all stages, thereby getting rid of the nagging issue of the particular geometry in question). This pretty much proves that if it's scrambled using the BIOS interface, it'll be scrambled in the same way with any other interface (since they *must* track each other) !! > 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.. I think we all agree that the OnTrack folks should be shot. There really is no solution is general to this kind of thing. -- 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?199605220308.UAA14803>