Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!uunet!charon.amdahl.com!pacbell.com!ames!agate!tfs.com!tfs.com!julian
From: julian@tfs.com (Julian Elischer)
Subject: HOW IDE DRIVES (and others) boot,
Message-ID: <1992Sep24.055056.7234@tfs.com>
Organization: TRW Financial Systems
References: <1992Sep23.212547.15460@fcom.cc.utah.edu> <19r0h6INNp42@aludra.usc.edu> <1992Sep24.022400.19483@fcom.cc.utah.edu>
Date: Thu, 24 Sep 1992 05:50:56 GMT
Lines: 215
I just saw the original of this article go past and all my
comments were missing !!?!?!?!
damned news poster sent the article I was responding to
rather than my response. luckily I saved it for future reference
so, here it is again.
>Newsgroups: comp.unix.bsd
>Subject: Re: 386BSD and IDE drives
>Summary:
>Expires:
>Sender:
>Followup-To:
>Distribution:
>Organization: TRW Financial Systems
>Keywords:
In article <1992Sep24.022400.19483@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>The only time it acts "funny" is if the translation is used at one time
>but not another -- for instance, 386BSD.
>
>The inital program load (IPL) code is from ROM and uses BIOS -- so the
>geometry translation is in effect. Later, the "real" boot loader loads
>the kernel using BIOS -- still no problem. Then the kernel takes over
The Bios is not responsible for loading the kernel in the normal boot blocks
as they do it all themselves. The following sumarises the steps used loading
386BSD using an ESDI or IDE drive:
1/ The BIOS loads block 0 which May be the boot1 block or maybe a
DOS boot block (e.g. os-bs). (if boot1 skip step 2)
2/ If it's a DOS bootblock, it looks in the table within itself (see
structure below) and uses the entries marked !**! to ask the BIOS
to load the boot1 code.
struct dos_partition {
unsigned char dp_flag; /* bootstrap flags */
unsigned char dp_shd; /* starting head */ !**!
unsigned char dp_ssect; /* starting sector */ !**!
unsigned char dp_scyl; /* starting cylinder */ !**!
unsigned char dp_typ; /* partition type */
#define DOSPTYP_386BSD 0xa5 /* 386BSD partition type */
unsigned char dp_ehd; /* end head */ !++!
unsigned char dp_esect; /* end sector */ !++!
unsigned char dp_ecyl; /* end cylinder */
unsigned long dp_start; /* absolute starting sector */ !xx!
unsigned long dp_size; /* partition size in sectors */ !xx!
} dos_partitions[NDOSPART];
3/ The first level bootstrap just loads the next 15 sectors from
wherever the controller is already set up for (where it
itself was read from presumably). It has hardwired into it to
read from sector 2 of whatever track it is presently on.
(it was on sector 1 itself). THIS IS WHY 386BSD PARTITIONS MUST
START ON A TRACK BOUNDARY (for wd drives). NOTE: this is a
track boundary from the BIOS's point of view, which may be
different from the REAL point of view, due to translation.
4/ The second level bootstrap (boot2) has within it the disklabel
and thus the REAL characteristics. It will therefore be able to set
the controller into REAL mode. It then uses the disklabel to find
the start of the a partition and thus the kernel.
5/ The kernel runs but has no idea of how the controller is set up
but needs that information to get to the disklabel.
It solves this problem by re-reading block 0 and reading the
entries marked !++! to work out what the geometry of the disk
is, assuming that the last block of the partition is in the
last sector of the last head. If there was no step 2 then the disklabel
is in cylinder0, head0 sector2 so we don;t need the dos partition
information (which is just as well because it isn't there).
6/ The kernel reads the disklabel and finally knows what's going on.
It uses the entries marked !xx! to find the start of the 386BSD
partition. and is working in REAL mode. THESE ARE ABSOLUTE REAL
SECTOR NUMBERS
>From this we can work out:
A/ The entries marked !**! must be calculated using the BIOS's idea
of what the disk looks like. (because of "2")
B/ The entries marked !++! must give the number of sector and heads the
controller reverts to after it has been reset by the wdattach()
code (because of "5"). I dont run IDE drives in translated mode,
so I don't know whether this should be real or translated geometry.
My guess is REAL.
C/ At all other times The disklabel information is sufficient and should
reflect REAL geometry.
D/ The 386BSD partition must start on a (translated) track boundary.
E/ The entries marked !xx! must be correct from REAL mode, (in fact
it would be difficult for them to not be so).
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
In the NEW bootblocks the flow is similar but different.
1/ BIOS is used for all read steps, and the hardwired '2' in step 3 is
no longer present. (therefore partitions need not be on a track
boundary, though I would recommend for simplicity that they are.)
2/ The new boot1 code is ALSO a valid DOS boot block, so even if
the 386BSD partition starts at 0, there is a valid DOS boot
block, (which is hard wired to specify that the 386BSD
partition starts at 0). It is therefore possible to later
add other partitions without having to move the 386BSD
partitions (if you have or can make room for them)
(of course booting to them would be harder, but you could
adjust the 386bsd partition to start at sector 1 now )
3/ both the boot1 and boot2 code read sector 0 again for the
table in it, even if boot1 IS sector 0. This is more important
in the case of boot2, because it may have been directed to read
the sector 0 from ANOTHER DISK.
4/ boot2 goes on to read the disklabel again (even though it may have
one embedded within it, once again because it may have been asked
to read it from another disk.
5/ If reading from a second disk, the second disk must have a valid
DOS boot block. (the new boot1 will do). (this may be fixed later).
>in protected mode -- problem. Because the kernel has a driver which
>probably ignores translation (which is generally a function of the BIOS,
>although not in every case, ie: the Maxtor SCSI drive), the location
>for paging and so on is not the load location. In addition, you may find
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I'm sorry terry but you've lost me on this one (!?)
>that during install from a floppy that the boot information could be
>written to a location on the hard disk that happened to cause it to boot...
>but that the translated boot information locates to somewhere in the middle
>of the untranslated disk. You will run fine until you accidently overwrite
>your boot information and it "mysteriously" quits booting.
When setting up a wd disk for the first time:
If at the time of configuration there is no valid DOS block, or one that
does not follow rule 'B', then the disk is left set up in either the
wrong or the default (also wrong) condition after the first open.
HOWEVER
The new disklabel is read into the kernel before it is written to the disk,
so the in-core copy of the disklabel in the kernel should be correct.
Whenever the kernel disklabel is updated the controller is re-initialised
to the new figures. The following write of this information is therefore
writen to the correct place on the disk.
On the next boot however, since the starting figures to read the disklabel
in in the first place come from the !++! figures, it will probably be
unable to FIND that disklabel, because since a dos program was used
to create TRANSLATED values in the DOS boot block, those figures
are probably wrong, because they are describing the last block of a REAL
partition, couched in TRANSLATED terms. I would hazard a guess that
THAT would probably lead to a wrong geometry being loaded in to the
controller for finding the DISKLABEL.. *BANG* cannot mount root *BANG*.
This is made complicated because the figures marked !**! must be The translated
description of a translated track boundary and the figures markes !++!
must be the REAL description of a REAL boundary (minus 1) (probably(see
conclusion C)).(on the otherhand might also need to be a translated version
of a translated geometry which may be different to the translated address of
the last block (just as wrong)).
The simplest answer would be to ALWAYS RUN IDE DRIVES IN TRANSLATED MODE
even in 386BSD. Then if everybody agreed about what to call
any particular block, there would be no problem.
(or don't run translation anywhere)
>
>A lot of this can be alleviated by picking the user defined drive type and
>entering the correct geometry as part of the CMOS setup. You of course
>have to be able to *find* this information out, however.
>
>The other common problem is when you try to "partition" the drive. Since
>the master boot record and partition table are at the front of the disk,
>giving 386BSD the whole disk works (because sector 0 cylinder 0 usually
>translates to the same location as it's untranslated value), but partitioning
>doesn't work (because the translated address of the partition is not the
>same as the untranslated address because it occurs at an offset greater than
>0). This is also fixed by the "user defined drive type" fix.
>
>The problem with the "user defined drive type" fix is that you probably
>wouldn't be doing geometry translation unless you needed it... which means
>more than 1024 physical cylinders on a drive (anyone ever wonder why MFM
>disks can only have up to ~130M on them? No geometry translation to let
>them pretend that they have 1024 or less cylinders).
>
>Geometry translation is DOS's way of breaking the 1024 cylinder boundry...
>beware of large drives that let DOS use the whole disk!
>
>Since DOS can't access cylinders past 1024, this means a DOS partition
>would have to be before that -- thus either reducing the usable disk space,
>or making the 386BSD partition the second one rather than the first. A
>problem in asboot.c means that not having the 386BSD partition first can
>mean it won't work.
>
well, you can always use my bootblocks 8-)
Maybe this should be added to the FAQ answer list?
+----------------------------------+ ______ _ __
| __--_|\ 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