Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!wupost!news.utdallas.edu!convex!convex!news.oc.com!eff!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!agate!tfs.com!tfs.com!julian
From: julian@tfs.com (Julian Elischer)
Subject: Re: DOS and 386BSD (and NT and OS2)
Message-ID: <1992Oct17.075833.18570@tfs.com>
Organization: TRW Financial Systems
References: <1992Oct15.171833.25427@fcom.cc.utah.edu> <1992Oct16.043347.3567@tfs.com> <1992Oct16.175743.19250@fcom.cc.utah.edu>
Date: Sat, 17 Oct 1992 07:58:33 GMT
Lines: 207
first, I'd like to say that if we assume that IDE drives do the translation
in SOFTWARE then some of what I said before is false.
If however some IDE drives do translation then some of what I'm GOING
to say is going to be false, (or at least a waste of time.
I guess we need to experment to settle this without doubts.
In article <1992Oct16.175743.19250@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>In article <1992Oct16.043347.3567@tfs.com> julian@tfs.com (Julian Elischer) writes:
>
>>
>>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.
>
>>
>
>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.
>
Ok I'll agree to that.
>>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?
No, now everything I say now is assumong SOFT translation
but here goes..
for each BIOS partition, there are THREE (3) separate descriptions
of a block.
(1) there is the longword blocknumber of the first block of the partition.
(2) there is the broken down description of the same block. The description
is made as a track/head/sector triplet, and the calculations
to break it down must be made using TRANSLATED geometry
figures, because they will be used by the level0 booter
using the BIOS.
(3) there is the broken down description of the LAST block of the partition.
NOTHING reads this information except the wd driver, which
uses it to find out what the geometry of the drive is. The assumption
it makes is that the last block of a partition is also the last block
of a cylinder, and therefore, the sector# is the number of sectors
and the head# is the number of the last head.
The wd driver uses the geometry deduced from (3) to translate the number in (1)
to the track#, head#, and sector# needed to feed into the controller.
This information is used to read the disklabel, after which (hopefully)
the real information is known and things can proceed as normal.
The code below reads in the (3) information and sets it into
the disklabel for temproary use in reading the real disklabel:
/* update disklabel with details */
lp->d_partitions[0].p_size = dp->dp_size;
lp->d_partitions[0].p_offset = dp->dp_start;
lp->d_ntracks = dp->dp_ehd + 1;
lp->d_nsectors = DPSECT(dp->dp_esect);
lp->d_subtype |= (lp->d_subtype & 3) + i | DSTYPE_INDOSPART;
lp->d_secpercyl = lp->d_ntracks * lp->d_nsectors;
For a drive with < 64 sectors per track, then to make it calculate out
the correct NON-TRANSLATED set of figures for loading the kernel
we need only put the correct non-translated number of heads in dp->dp_ehd
and the non-translated number of sectors in dp->dp_esect.
The trouble comes with >63 sectors, because the macro DPSECT() is actually
an AND with 63. Many translated drives have > 63 sectors per track.
For these machines, I think that 386bsd must have a partition
that starts in the first track.
With the new bootblocks, it is possible to start the 386bsd partition
at block 1 and still have a BIOS bootblock at block 0.
>
>>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.
just ask the user what the figures are.. my fdisk I just posted can do this.
>
>2) It would have to go into "untranslated mode"
>
run the program again, this time giving untranslated values
>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.
>
I already have done this.. steps 1 and 2 are enough
>4) Other partitions could be made accessable to the 386BSD partition,
> as long as each had it's own "shadow".
no, only the BOOT partition has problems, because once the disklabel is
loaded, there are no unknown factors.
>
>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.
>
the old bootcode already has the facility
to do this,.. it is #ifdef'd out, but there is code to pass the
disk info to the kernel on the stack.
This doesn't help though for the second disk.
>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).
as I said, there is support for this in the old bootcode, pasing it
on the stack, but the boot code doesn't know about the 2nd drive.. and
what about the third/fourth?
>
>>>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?
>
yes.. the one I posted is slightly better than the one I sent you to look at..
>
> 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
>-------------------------------------------------------------------------------
+----------------------------------+ ______ _ __
| __--_|\ 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