Date: Tue, 21 May 1996 20:26: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: <199605220326.UAA03065@phaeton.artisoft.com> In-Reply-To: <199605220308.UAA14803@uruk.org> from "erich@uruk.org" at May 21, 96 08:08:42 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. Duplicated disks using 'dd'? I would think "last mounted" might be enough. I guess only a strange person would do this -- maybe why they are called "degenerate" cases? ;-). > 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. I Think they do it by knowing that there will be in the BIOS chain some place and providing a directed reference for the entry so they can replace the thing wholesale without distrubing anything that refers to it. > 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. Yeah; worst case is identical controllers with zeroed identical disks with probe order the reverse of POST order. But then, do you really care which disk you get? 8-). > > 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. 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. > > 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. Well, I was thinking of using partition contents as secondary indicators for which drive is which. For all the normal FS's, there's an incept date in the first 512 bytes of data on the drive. > > 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. I'm not sure; unless you hard-coded ll of the non-linear transaltions into the geometry detection from BIOS. I don't think the WD1007 (a popular controller, so it's a good example) has been sufficiently documented to predictively spare the same way using a protected mode driver. 8-(. > > 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. Yep. > 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. This assumes (I think) that you will run "dedicated" disks, right? > > 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) !! Well, at least that way, you fail up front... unless you guess wrong and start writing your BSD partition into the middle of the DOS partition somewhere when you boot from the BSD boot disk. You would probably need to write the boot disk as two stage instead of one stage, as well... that *might* do it for an up-front fail. > > 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. 8-). 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?199605220326.UAA03065>