Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!sgiblab!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: DOS and 386BSD (and NT and OS2)
Message-ID: <1992Oct16.175743.19250@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1992Oct15.081904.20697@ntuix.ntu.ac.sg> <1992Oct15.171833.25427@fcom.cc.utah.edu> <1992Oct16.043347.3567@tfs.com>
Date: Fri, 16 Oct 92 17:57:43 GMT
Lines: 165
In article <1992Oct16.043347.3567@tfs.com> julian@tfs.com (Julian Elischer) writes:
>In article <1992Oct15.171833.25427@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>>
>>The translation is done by the disk BIOS *on* the controller, or it may be
>>done by the drive itself. You don't use the BIOS for access, you don't
>>get translation.
>
>Actually, I think the translation is performed on the controller.
>The disk driver in 386bsd actually resets the controller to use the
>figures in the disklabel, but before it can get the disklabel it
>has to guess at what translation the controller is set to.
>It does this by assuming that the last block in a partition is also
>the last block in a (translated) cylinder and from that, it can deduce
>the number of heads etc. with that information it can load the
>disklabel and then it resets the controller again to use whatever
>geometry is in the disklabel.
I can definitively say that the IDE on AT&T 386SX WGS and Compaq Deskpro
486/33M boxes use *soft* translation... that is, the translation is done
in software as a result of using the BIOS. I can also say that the
Maxtor ESDI drive on my WD1007 uses hardware translation, independant of
the use of the BIOS.
>>There is a probe request (which not all controllers support!) that is done
>>to ask the controller the disk's geometry. This is because the raw driver
>>used in 386BSD doesn't use the BIOS (for reasons which should be obvious)
>>and talks to the controller directly -- thus there is no such thing as a
>>translated geometry as far as 386BSD (or any other non-BIOS OS) is
>>concerned.
>
>As I said above, the first access that the kernel does actually be in
>translated mode. If you put translated parameters into your disklabel
>it should continue to run in translation mode for all your work and
>no-one would be the wiser (may be a bit slower). I think that in a
>translating controller, the translation is done whether or not it's the
>BIOS that is making the requests. Non translation is often only a case
>of 1:1 translation.
This is true for ESDI and SCSI, but not for the IDE I have played with
so far. The biggest problem here, of course, is that IDE "controllers"
are pretty much stuck on the disk drive, and the "controller card" you
put in the DOS box is more of a bus interface than anything else. This
is why IDE controllers are so cheap compared to SCSI. In plain English
(yuck! 8-)), this means it's possible for this to vary between hardware
and software for different IDE drives. The wonderful thing here is that
using two different drives with soft translation turned off basically
requires two CMOS entries where only one is possible.
>well I don't think this is correct.. as I said before, the very first seek
>the kernel does is in translated mode and it has to read the bootblock to
>work out what the translated geometry is, so it can find the disklabel.
I hate to disagree here, because I'm not on as firm a ground as I would
normally like -- especially given your rewriting of the boot blocks;
however, I think the first kernel I/O for the "booted" 386BSD is after
the controller has been queried for the real geometry. The use of the
routines to read the disk failing on disklabel access would seem to
support this.
>>*soft* ... DOS still works is it only uses the BIOS to access the disk.
>
>No, iI think the translation is on the disk, (IDE.. controller = *nop* )
>
>If the translation were in the BIOS then the first read to find the
>disklabel would always fail, because the read to find the disklabel is
>made using translated parameters.... hmmm I have ESDI,
>I wonder if that is why I'm disagreeing with you.. has anybody been
>able to get a translated IDE to work, if so, then the translation
>must be in the hardware, (the same as the ESDI).
This isn't a really valid test. I would ammend it to "get a translated
IDE to work for 386BSD with DOS partitioning active on the disk"... even
then, I'd hate to buy off on it, as I have suggested two ways of doing
this, and you have suggested a third (below) with the translation on
for DOS but off for 386BSD.
>In any case, if the translation WERE in the BIOS then the new bootblocks
>would still be ok, but the kernel would have to load REAL geometry
>from the end of teh BIOS partition entry (I guess that's ok, nothing
>else uses that information)
This shouldn't be possible; the boot information is located by the DOS
master boot by looking at the partition information, isn't it?
>One way would be to make two partitions pointing at the same block,
>one in translated mode, and one in real, then the boot code could be
>changed to look for a different OS_id so it would use a different
>set of figures from the kernel (yuk)
Actually, this is brilliant, in that it avoids the "voodoo" necessary
with my two suggestions for doing it (assuming a program can set this
up for you without blowing up). Let's look at what the program would
have to do:
1) It would have to use BIOS calls to find out the disk geometry,
as translated, to create the untranslated 386BSD partition from
which the DOS MBR will load the boot.
2) It would have to go into "untranslated mode"
3) It would have to create a "shadow" partition with the physical
location (untranslated) partition offset. This could be difficult,
since there is no way to ask the controller what physical address
is represented by a translated address, or vice versa. The best
bet would be the calculation of a sector offset based on the
geometry in both configurations. This makes a (bad) assumption,
primarily that of "most significant multiplier" -- that is, is
the head number or the cylinder number multiplied first to find the
offset? This might be overcome by writing a full sector or 10 with
a "magic" pattern, and "scanning" the disk to find it.
4) Other partitions could be made accessable to the 386BSD partition,
as long as each had it's own "shadow".
5) A potentially better soloution would be to blow data tables in the
boot code, which are loaded at a known location, and then referenced
by the kernel as part of initialization. If the kernel knew it's
base address, this would be fairly simple; use above 1M to store
the tables if the kernel loads at 0, and 0 if the kernel loads
at or above 1Meg.
6) Calculation of these offsets would still require the "scan" to
insure the location of the 386SD partition; hopefully, this
location information, and the fact that we wrote more than one
sector with sequential "magic cookies" based on the translated
head/cylinder/sector offsets would allow us to determine the
translation algorithm and directly calculate the non-386BSD
offsets without having to save the first 'n' sectors of each
partition, blow magic cookies to them, and scan for all partitions,
and, on finding them, blow their original contents back and save
the locations for reference by 386BSD.
7) An approach requiring calculation of the translation algorithm
is superior, in that it does not halve the number of non-shadow
partitions available for other OS's.
8) An approach also involving blowing the data to memory for use by the
kernel is also useful, in that it eliminates the one "shadow" in
the paritition table; thus you still have all 8 for OS's or for
extended DOS partitions. This is a modification of your original
"shawod" idea, and could be used with #7 at the same time to allow
things like "mtools" to work without problems on the "translated"
storage sections of the drive (since all the FAT offsets for DOS,
for instance, are as translated values).
>>Once we get this hammered out, we should have a "the way things work"
>>document that will be useful to everyone.
>
>with the new fdisk program I just posted, we should be able to
>test it easily.
You got the OK from CMU, I take 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
-------------------------------------------------------------------------------