Re: maximum hard drive size in Latitude cpi

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.


Peter
.

Relevant Pages

  • Re: BIOS
    ... > I guess that coding assembly in Linux is different because ... > What is I only use the BIOS functions? ... the machine acts like "real mode" but is also in "protected mode" at ... Unfortunately, unlike the BIOS, no "standard" was ever agreed...device ...
    (alt.lang.asm)
  • 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: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
    ... When the kernel calls into the BIOS, it has to do a grotesque dance that involves jumping through a chain of several segments of different flavors, thus gradually shutting down the multi-tiered address translation mechanism. ... Then, if the BIOS is actually operating in protected mode, it has to perform the inverse process, do the requested work, then go back into real mode to return to the kernel. ... f) Switching from protected mode to real mode (or in some cases, V86 mode instead, which requires an additional Task State Segment dance to set the IO permission mask) ...
    (Linux-Kernel)
  • Re: maximum hard drive size in Latitude cpi
    ... >>> to bios are a well known problem ... >>in real mode (I don't know why ... ... >>how big the disk is, then carries that info over to the multitasking o/s ...
    (comp.sys.laptops)