public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Phillip Susi <psusi@cfl.rr.com>
To: "linux-os (Dick Johnson)" <linux-os@analogic.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Seewer Philippe <philippe.seewer@bfh.ch>,
	Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: RFC: disk geometry via sysfs
Date: Wed, 15 Feb 2006 17:43:54 -0500	[thread overview]
Message-ID: <43F3AEAA.4080309@cfl.rr.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0602151606540.10924@chaos.analogic.com>

linux-os (Dick Johnson) wrote:
> Heads start at 0. Sectors start at 1. Cylinders start at 0.
> A "lower head" than allowed would be 0xff so the BIOS wouldn't
> know it was "lower". The BIOS doesn't look at the MBR for
> normal read/write access! Only while booting does it
> read the first sector of the master boot record (MBR) into
> the appropriate physical place (0x7c00). Then it checks to see
> if there is an 0xaa55 as the last word in the sector. If so,
> it executes code starting at offset zero. Modern BIOS don't
> even check the "boot flag" because it may be wrong, preventing
> a boot.
> 

I'm talking about the geometry of the disk.  If the disk has 16 sectors 
and 8 heads, then the maximum value allowed for any valid address is 16 
in the sector field and 7 in the heads field.  This influences the 
translation to/from LBA.  A sector with LBA of 1234 would have a CHS 
address using this geometry of 9/5/3.  If the disk reports a geometry of 
x/8/16 but the bios is using a geometry of x/255/63, then when you pass 
9/5/3 to int 13 it will fetch LBA 144902 which is clearly not going to 
give you what you wanted.

This is why you must use the same geometry that the bios exposes, NOT 
what the disk reports in its inquiry command.  It is quite typical for a 
disk to report that it uses 8 heads and has a number of cylinders that 
is > 1024.  The bios will typically present a view of the disk with 255 
heads ( though it very well may use a smaller value ).  If you generate 
CHS addresses when you write the MBR using 8 heads, they will be wrong 
when you try to pass them to the bios.

> Now, during the boot sequence, the BIOS via INT 0x13 or 0x40
> will be called upon to read data into memory from various
> offsets on the media. If the offsets are calculated in the
> same way that they were calculated when the disk was initialized
> as a boot disk, then everything is okay. The calculations of
> offsets do not require the same C/H/S phony variables! One

Yes, they do require the same geometry, see above.

> only has to follow the correct rules. The rules are that
> heads increment from 0, as do cylinders, and sectors start
> at 1. Also "sectors" must be 512-byte intervals even though
> the physical media may have 16 kilobyte sectors. Given
> these rules, there are zillions of ways for one to arrive
> at the correct offset. The interpretation will be correct
> IFF the number of cylinders are extracted first, then the
> number of heads (tracks), then the number of sectors, always
> using the largest number that will fit into the BIOS
> registers used to make that access.
> 

The bios will not accept values that are larger than it's idea of the 
disk's geometry.  If the bios thinks the disk only has 8 heads, you 
can't ask it to fetch a sector on head 17.

> In the case of "large media" access, the cylinders are
> set to 0xffff. This triggers additional logic that invents
> a new virtual sector length to accommodate.
> 
> The following is the __entire__ boot code for an IBM/PC
> compatible BIOS! Constant "DISKS" is 0x13.
> 

<snip>

Not sure why you pasted the example bios code, maybe you could explain?



  reply	other threads:[~2006-02-15 22:44 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-10 13:06 RFC: disk geometry via sysfs Seewer Philippe
2006-02-13  9:56 ` Bartlomiej Zolnierkiewicz
2006-02-15  7:57   ` Seewer Philippe
2006-02-13 16:32 ` Phillip Susi
2006-02-13 19:02   ` Seewer Philippe
2006-02-13 19:22     ` linux-os (Dick Johnson)
2006-02-13 19:36       ` Phillip Susi
2006-02-14 16:35         ` Seewer Philippe
2006-02-13 19:34     ` Phillip Susi
     [not found]       ` <43F206E7.70601@bfh.ch>
2006-02-14 18:19         ` Phillip Susi
2006-02-15  8:39           ` Seewer Philippe
2006-02-15  8:51             ` Bartlomiej Zolnierkiewicz
2006-02-15  9:01               ` Seewer Philippe
2006-02-15 14:06                 ` Alan Cox
2006-02-15 14:11                   ` Seewer Philippe
2006-02-15 15:15                     ` Alan Cox
2006-02-15 15:29                       ` Phillip Susi
2006-02-16  8:12                         ` Seewer Philippe
2006-02-16 15:36                           ` Phillip Susi
2006-02-16 15:41                             ` Seewer Philippe
2006-02-16 16:15                               ` Phillip Susi
2006-02-15 15:20                   ` Phillip Susi
2006-02-15 16:06                     ` Alan Cox
2006-02-15 16:20                       ` Phillip Susi
2006-02-15 17:32                         ` Alan Cox
2006-02-15 18:43                           ` Phillip Susi
2006-02-15 19:23                             ` linux-os (Dick Johnson)
2006-02-15 20:54                               ` Phillip Susi
2006-02-15 21:41                                 ` linux-os (Dick Johnson)
2006-02-15 22:43                                   ` Phillip Susi [this message]
2006-02-16 12:33                                     ` linux-os (Dick Johnson)
2006-02-16 15:26                                       ` Phillip Susi
2006-02-16 16:15                                         ` Seewer Philippe
2006-02-16 17:01                                           ` Phillip Susi
2006-02-16 16:39                                         ` linux-os (Dick Johnson)
2006-02-16 17:09                                           ` Phillip Susi
2006-02-16 19:01                                             ` linux-os (Dick Johnson)
2006-02-16 19:55                                               ` Phillip Susi
2006-02-16  8:18                           ` Seewer Philippe
2006-02-16 18:14                       ` Matt Domsch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43F3AEAA.4080309@cfl.rr.com \
    --to=psusi@cfl.rr.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=bzolnier@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-os@analogic.com \
    --cc=philippe.seewer@bfh.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox