Re: maximum hard drive size in Latitude cpi

Barry OGrady wrote:

> On Mon, 7 Nov 2005 12:09:29 +0100, "Peter T. Breuer" <ptb@xxxxxxxxxxxxxxx>
> wrote:
>
>>John Doue <notwobe@xxxxxxxxx> wrote:
>>> You have been clear enough. I am not sure I follow Peter (I recognize my
>>> technical limitations in this area) but recognized size limitations due
>>> to bios are a well known problem (see the second link at end of post)
>>
>>No they AREN'T. Please stop letting vague concepts step in front of your
>>frontal cortex! If you don't grok "bios is not used in disk i/o" you
>>are at a serious disadvantage from the get-go and you need to work on
>>assimilating that idea first. The bios can do no "limiting", since it is
>>not used.
>>
>>What I daresay is happening is that the win o/s starts up with the cpu
>>in real mode (I don't know why ... to emulate dos?) and asks the bios
>>how big the disk is, then carries that info over to the multitasking o/s
>>that takes over in virtual 386 mode. A multitasking o/s cannot run in
>>real mode. Bios can only be used in real mode. You need to appreciate
>>those two facts to understand why the idea of the bios playing any
>>part in disk i/o is preposterous, not to mention fact three: "it would
>>be ridiculously slow" (it would be a kind of programmed i/o mode, but
>>since it's got to be done in real mode anyway, everything is dead).
>>
>>The o/s can perfectly well ask the disk how big it is without asking
>>the bios anything. To illustrate, here's a query directed at my disk
>>from my TP:
>>
>>% sudo hdparm -I /dev/hda
>>
>>/dev/hda:
>>
>>non-removable ATA device, with non-removable media
>> Model Number: IC25N030ATCS04-0
>>
>> Serial Number: CSH305DADKY0NB
>> Firmware Revision: CA3OA71A
>>Standards:
>> Used: reserved
>> Supported: 2 3 4 5
>> Likely used: 5
>>Configuration:
>> Logical max current
>> cylinders 16383 16383
>> heads 15 15
>> sectors/track 63 63
>> bytes/track: 0 (obsolete)
>> bytes/sector: 0 (obsolete)
>> current sector capacity: 15481935
>> LBA user addressable sectors = 58605120
>>
>>(the LBA addressing mode is the one that even the bios would be asked
>>to use by the o/s, if it asked the bios to do anything!)
>>
>>Capabilities:
>> LBA, IORDY(can be disabled)
>> Buffer size: 1768.0kB ECC bytes: 4 Queue depth: 1
>> Standby timer values: spec'd by Vendor, no device specific
>>minimum
>> r/w multiple sector transfer: Max = 16 Current = 16
>> Advanced power management level: 16512
>> DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
>> Cycle time: min=120ns recommended=120ns
>>
>>(these are the standard methods of talking to the disk for i/o).
>>
>>
>> PIO: pio0 pio1 pio2 pio3 pio4
>> Cycle time: no flow control=240ns IORDY flow
>>
>>(this is slow "programmed i/o" - the bios is likely to use that, but
>>since one would have to go to real mode to use the bios, uh, uh, no
>>way).
>>
>>control=120ns
>>Commands/features:
>> Enabled Supported:
>> * NOP cmd
>> * READ BUFFER cmd
>> * WRITE BUFFER cmd
>> * Host Protected Area feature set
>> * look-ahead
>> * write cache
>> * Power Management feature set
>> Security Mode feature set
>> * SMART feature set
>> SET MAX security extension
>> Address offset used (large drive)
>> Power-Up In Standby feature set
>> * Advanced Power Management feature set
>>Security:
>> Master password revision code = 65534
>> supported
>> not enabled
>> not locked
>> not frozen
>> not expired: security count
>> not supported: enhanced erase
>> 34min for SECURITY ERASE UNIT.
>>HW reset results:
>> CBLID- above Vih
>> Device num = 0 determined by the jumper
>>Checksum: correct
>>%
>>
>>> and I am surprised Peter seems to dispute this fact (but may be I
>>> misunderstand him).
>>
>>Quite probably. My typing at you seems to be wasted! Please try and
>>understand - the "overlay" nomenclature probably comes from MSDOS and is
>>probably either a bios extension (which could only be used by msdos,
>>since bios is only available in real mode), or a hook of some interrupt
>>vector (which could again only be used by msdos, since interrupts hooks
>>are rewritten to pass interrupts to the o/s by anything more recent
>>than msdos!). Either way, it's simply either "not used" or "not there"
>>by the time a more modern o/s gets running.
>>
>>The only chance the extra boot code has to do something is while the
>>cpu is still in real mode, before the o/s gets going. It could
>>conceivably diddle the size parameters for the disk kept in the bios.
>>That's trivial. One ne then have to suppose that the windows o/s,
>>while still in the "loader" phase, running in real mode, grabs the
>>bios data and makes it available in some memory location or register
>>for its later incarnation as a modern o/s running in 386 virtual mode.
>>
>>But when up and running, the o/s would have no reason not to query the
>>disk directly as to what it knows abut itself, as I just did! So the
>>design of windows must be perverse in that respect.
>
> You are completely out of your depth on this one.
> The limitation is the number of bits used to count the sectors. EG. 16
> bits allows for 65,535 sectors. As hard drives get bigger more bits are
> needed, hence the 48 bits needed for drives over 137 gigs.
> What the overlay does is to take over the disk I/O with more bits so it
> can address larger hard drives. My K6/2/500 system has a bios limitation
> of 32 gigs but I had a 120 gig and a 60 gig running in it. I set a link on
> one drive and sent a command to the other so the bios would see them as 32
> gigs, then used an overlay on each so that windows could see the full
> size.

You are confusing a number of issues. There's a good rundown on this at
<http://web.inter.nl.net/hcc/J.Steunebrink/bioslim.htm> with links for more
details.

The only time that the number of bits used to count the sectors was an issue
was with the 128GB barrier. Prior to that the limit was related to the
cylinders/heads/sectors addressing scheme.

The overlays in general enable logical block addressing on machines whose
BIOS doesn't support it directly. They do _not_ fix the 128 GB limit,
which needs 48-bit support in the host adapter.

Any current OS should have no trouble querying the disk directly for its
parameters once it has gotten its own drivers loaded--actually getting it
to that stage is the problem and this had been handled in various ways by
various systems, as until the kernel and disk driver are loaded the machine
is still running on the BIOS boot code.

>>Peter
>
> Barry
> =====
> Home page
> http://members.iinet.net.au/~barry.og

--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)
.

Relevant Pages

  • Re: Option ROM - Real Mode - PCI BAR
    ... I have a disk emulator called MEMDISK, which stashes the virtual disk in ... The problem here is that some software may expect the BIOS and option ... ROMs to contain "real mode only" code, and might use the GDT and/or ... if your option ROM attempts to use protected mode then the OS is ...
    (comp.lang.asm.x86)
  • Re: maximum hard drive size in Latitude cpi
    ... >>>you want to use the full size of a disk and if the bios recognizes only ... > like it or not are using Windows, ... Designing an o/s ...
    (comp.sys.laptops)
  • Re: maximum hard drive size in Latitude cpi
    ... Unless you use an overlay the bios will limit how much ... An o/s would just query the disk directly ... Hard drives are addressed by controllers, ide controllers, ...
    (comp.sys.laptops)
  • Re: maximum hard drive size in Latitude cpi
    ... If you don't grok "bios is not used in disk i/o" you ... What I daresay is happening is that the win o/s starts up with the cpu ... in real mode (I don't know why ... ...
    (comp.sys.laptops)
  • Re: maximum hard drive size in Latitude cpi
    ... I just don't want to invest in a 80gig drive only to find ... The bios is only responsible for booting a couple ... After the bios has booted an o/s, the o/s does the disk i/o via linear ...
    (comp.sys.laptops)
Loading