Return to BSD News archive
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!think.com!ames!biosci!ucselx!crash!fpm
From: fpm@crash.cts.com (Frank Maclachlan)
Newsgroups: comp.unix.bsd
Subject: Re: Finding untranslated params for IDE drives (w/ pgm)
Summary: Some thoughts on IDE drives, translation mode
Keywords: IDE 386BSD
Message-ID: <1992Oct21.144326.27644@crash>
Date: 21 Oct 92 21:43:25 GMT
References: <1992Oct18.153007.28120@crash> <1992Oct19.053131.11296@tfs.com> <1992Oct19.173418.10490@fcom.cc.utah.edu>
Organization: CTS Network Services (crash, ctsnet), El Cajon, CA
Lines: 166
In article <1992Oct19.053131.11296@tfs.com> julian@tfs.com (Julian Elischer) writes:
>In article <1992Oct18.153007.28120@crash> fpm@crash.cts.com (Frank Maclachlan) writes:
>
> [ ...discussion deleted... ]
>
>>Also, data transfers from this drive averaged about 300 kb/sec when
>>the drive was set up in translated mode and about 660 kb/sec when
>>set up in its "default" mode. This was probably partially caused
>>by the use of 17 secs/trk rather than the native 33 secs/trk; the
>>80C31 microprocessor has to work harder to translate addresses.
>
>is the 'default' the figure the BIOS reborts?
This discussion should perhaps be in comp.sys.ibm.pc.hardware,
but here goes...
The BIOS sets up interrupt vectors to point to 16 byte drive
parameter structures for up to two drives. The far pointer at
interrupt vector 0x41 (0x0:0x104) points to the drive parameter
structure for hard disk 0 ("C:" in the DOS world) and interrupt
vector 0x46 (0x0:0x118) points to the drive parameter structure
for drive 1 ("D:"). There is no provision for more than two hard
disks in the BIOS. In any case, these drive parameter structures
reflect the drive geometries selected when the user sets up his
(or her) CMOS configuration and have no necessary relation to the
'default' values as reported by the drive. 'Soft' configurations,
such as the AMI BIOS type 47 user configurable drive types, are
stored in RAM; 'hard' configurations (types 1..46), are in an array
of structures in the BIOS itself and are indexed by the CMOS drive
type (-1).
Many ESDI and RLL hard disk controllers which have on board EPROMs
also have on-board RAM where 'soft' drive parameter structures can
be stored; during initialization, the on-board EPROM code queries
the drive, builds the required drive parameter structures, and then
changes the interrupt vectors to point to the new structures. The
Western Digital WD1007[AV] ESDI controllers, for example, do this.
>
> [ ...discussion deleted... ]
>
>
>julian
>
>+----------------------------------+ ______ _ __
>| __--_|\ Julian Elischer | \ U \/ / On assignment
>| / \ julian@tfs.com +------>x USA \ in a very strange
>| ( OZ ) 2118 Milvia st. Berkeley CA. \___ ___ | country !
>+- X_.---._/ USA+(510) 704-3137(wk) \_/ \\
> v
What does OZ stand for (as opposed to 'au')? Just curious.
In article Message-ID: <1992Oct19.173418.10490@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>I guess this then raises the question: why the heck are the 0xec/0x91's
>used at all? Turning off translation makes no sense, then, since the only
>apparent effect is to screw up installation for 2/3's of the people with
>IDE drives. Why does the WD driver screw with it?
The real killer is the controller/drive reset in wdprobe(). This
causes the drive to revert to its 'default' translation. The 0x91
(Initialize Drive Params) is used to restore the translation once the
disklabel has been read and the drive's geometry is extracted, but
since the translation has changed, we can't read the disklabel if it
isn't at cylinder 0! 0xec (Identify Drive) is used *only* to get the
controller/drive ID string printed in angle brackets during the probe
phase.
One solution would be to *not* reset the drive/controller in wdprobe().
This would preserve the drive's translation mode. Remember that the
drive/controller was already reset and tested by the BIOS, so resetting
it and testing it again is probably unnecessary. I'll hack a copy of
the patchkit wd.c and send it to Terry to try out (a few other things
have to change in wd.c if the reset is removed, so don't just remove the
reset and expect it to work).
>
> [ ...more discussion deleted... ]
>
>>>Also, data transfers from this drive averaged about 300 kb/sec when
>>>the drive was set up in translated mode and about 660 kb/sec when
>>>set up in its "default" mode. This was probably partially caused
>>>by the use of 17 secs/trk rather than the native 33 secs/trk; the
>>>80C31 microprocessor has to work harder to translate addresses.
>
>Ah, here's the rub! If you don't turn off translation, your performance
>is halved (at least for this drive). Well, I knew it was disgusting to
>install DOS on my drives, but I didn't know it was *that* bad! ;-). I
>think we will have to just eat this if DOS partitioning is on the drive,
>just like we may have to eat a loss of space on MFM and RLL drives
>because we can't determine from the controller if it's IDE or not (if we
>have to make pessimistic assumptions for IDE, like leaving translation
>on to avoid buggering it, then we will lose the benefits of knowing the
>real geometry on other drive types that are software indistinguishable from
>IDE).
I suspect that it may not be so bad on the newer IDE drives which can
have a lot of cache memory, can read ahead, and in some cases, also write
behind. The Fujitsu IDE drive used in my tests is a generation or two
out of date. I personally like to use *no* translation.
>
> [ ...stuff deleted... ]
>
>
>I disagree that we should be turning translation off at all, unless, as
>detailed above, we can turn it back on or we aren't using DOS partitioning.
>
>
>Any ideas on how to turn translation back on so I can provide an ioctl()
>interface and modified probe routine for the wd driver to get the drive
>set up from user space and set/unset translation?
>
To establish a new translation:
1. Output the desired number of sectors/track to the sector count
register (0x1f2).
2. Select the drive and highest numbered desired head (number of heads
- 1) w/ the SDH register (0x1f6). This register has several bit
fields.
3. Give the drive time to go BUSY, then wait for it to be not BUSY.
This status can be tested w/ either register 0x1f7 or 0x3f6.
It probably won't go BUSY, but I think a few drives/controllers do.
4. Issue a 0x91 command to the command register.
5. Give the drive time to go BUSY, then wait for it to be not BUSY.
This status can be tested w/ either register 0x1f7 or 0x3f6.
6. Test for errors w/ register 0x1f7.
>Also: What about the two IDE problem, when you only have one drive type 47
>available? It would seem to me that translation wouldn't want to be on on
>an all-386BSD drive, and that the first drive is more likely to boot both
>DOS (or some other OS) and 386BSD. It's be a shame to pay half the disk
>performance and part of the disk space if we didn't have to.
I tested my AMI BIOS and it supports *two* distinct type 47 configurations.
For those folks w/ IDE drives who don't have a user configurable drive
type, I've heard that NCL makes an IDE controller w/ an on-board BIOS
which allows user configuration (I think). Costs about $50.
>I think we are coming close to something that can work every time for
>everybody, which is what I feel this whole thing has been about anyway...
>a few more hammer blows, and we should have it.
>
> Terry Lambert
> terry@icarus.weber.edu
> terry_lambert@novell.com
>---
>Any opinions in this posting are my own and not those of my present
>or previous employers.
>--
>-------------------------------------------------------------------------------
> "I have an 8 user poetic license" - me
> Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
>-------------------------------------------------------------------------------
I hope so.
Frank
--
UUCP: {hplabs!hp-sdd ucsd nosc}!crash!fpm
ARPA: crash!fpm@nosc.mil
INET: fpm@crash.cts.com