[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: bios - Re: GRUB problem (long, description of BOOT)

Alvin Oga wrote:
hi ya mike

Hi yourself. Glad to meet you.

I hope this message doesn't seem pugnacious. It isn't intended
to be. But your response seems to me to contain some factual
and comprehensional errors. Since this is a technical forum,
I don't feel comfortable allowing what I percieve to be the technical failings to go unnoted.

No personal criticism is intended in any way. I appreciate
your attempt to clarify my message. You are obviously smart
and intelligent, but you weren't THERE. I was.

On Tue, 27 Sep 2005, Mike McCarty wrote:

the "tracking info" is dependant on the filesystem

It is not.

i beg to differ ... different fs has different disk
structure to tune itself for various things to make
it better or worst than other fs

It is used by the uController on the disc itself
to servo.

the disk controller on the disk does its magic too
but that is 1 level lower than the track info needed
by the fs

Precisely my point. I guess I didn't make myself clear enough. I was
talking about a low-level format, not a file system thing.

the disk controller also does all the bad-block remapping
so that the fs thinks it has a clean 100GB of disks
even if its using 110GB of actual physical space

No longer done by the disc controller. With the advent of
Advanced Technology attachment (ATA) (incorrectly referred to by
many as Integrated Drive Electronics [IDE]) drives, the intelligence
is no longer on the controller board, but rather on the disc
itself. Modern "controller" boards are just I/O expansion
ports. The controller logic is now on the disc itself.

A FS format should not disturb the low level

no it doesne't, but it uses that info in conjunction
with what it needs to be faster/better

Anyone who redoes the low level format is taking
his figurative life into his own hands.

those are the folks that insist on using "dd"

No, dd cannot disturb the low-level format. That requires
talking to the uC on the disc itself (usually), using
proprietary commands.

[snip due to talking at cross-purposes]

maybe there is a difference in what you call track info
and what i'm calling track info ..
	servo data vs meta-data vs ??-data

	servo data is on one platter as yu say,
	OR interspersed amongst each track ( not on one platter )

Yes, I'm talking about servo data, which cannot be seen
by dd or any other normal (or even driver level) accesses.

	meta-data is for the ext3, xfs, jfs, dos, etc

I'm afraid that dd cannot see that information, nor
can it destroy it.

sure it can ... try it ... the servo data is gone that track-1234 head-6 sector-47 is not longer
marked as bad block because dd overwrote it

Certainly it can write to the "reserved" areas of the
disc (I mean reserved by the file system). But it cannot
write to the servo area (which is used by the uC on the
disc to ensure proper head alignment).

if the bad block is marked at the disk controller,
than yes, dd cannot change those badblocks and servo info

bad blocks is part of servo data ?? and is managed
in various wys

Bad blocks and bad track info are used by different levels
of the system. The bad blocks are a file level thing, and
can be modified or obliterated by dd, as you note. The bad
track info and sector remapping is a low level construct,
and cannot be modified by dd.

The bad block information stored in the File Allocation Table
(FAT) was/is separate from the low-level bad track marking
used by a low-level format. You may be confusing this information
(not stored in a FAT for for non-FAT FS, naturally) used by the file
system with the low-level bad track remapping.

You are using the word "servo" in a way I don't recognize.
I quote from Funk & Wagnalls New Comprehensive


servo- /combining form/ In technical use, auxiliary: servomechanism
[<L servus a slave].

servomechanism n. Any of various relay devices which can be
actuated by comparatively weak force in the automatic control
of a complex machine, instrument, operation, or process, as
artillery fire, the course of an airplane or ship, etc.


The servo tracks are used to supply the "weak force" used in
automatic control of the head movement mechanism.

The older MFM and RLL drives used stepper motors and a wound
band of steel to move the heads. This resulted in gradual creep
of the tracks as formatted on the disc with temperature. We used
to have to warm up the discs to operating temperature before
low-level formatting them (laying down tracks and sectors).
Over time, the tracks would also creep due to various changes
in the movement mechanism, requiring periodic (like every few
months) redoing of the low level format. Eventually, the
head movement mechanism would develop hysteresis, leading to
an unusable disc. (I have a few of those around :-)

When the newer "voice coil" technology came
out, we all regretted the loss of one entire disc surface, but
we all heaved a great sigh of relief at not having to do
low-level formats any more (no more running debug, no more
-g=c800:0 commands, no more having to do bad track marking...)
and no longer having to park the heads before moving the


Voice coil
From Wikipedia, the free encyclopedia.

Voice coil originally described the coil of copper wire mounted to the moving cone of a loudspeaker. By applying a voltage to the voice coil, a


Other uses for the term

Nowadays the term has been generalized and refers to any coiled wire that is used to move an object back-and-forth within a magnetic field. In particular, it is commonly used to refer to the coil of wire that moves the read-write disk heads in a moving-head disk drive. In this application, a very light weight coil of wires is mounted within a very strong magnetic field produced by rare earth permanent magnets. By means of a servomechanism driving the voice coil, the heads of the disk drive can be positioned very quickly and accurately.



Note the proper use of the term "servomechanism" in this article.
The servo tracks are used by the servomechanism for head positioning.

There is only one MBR per physical disc. Each partition has
a BR, not an MBR.

okay ... i'll bite with the mbr vs br


	each partition has its own MBR allowing it to be bootable

I'm afraid you have some misconceptions yourself.

just a difference of vocabulary of mbr or br per your correction

I've been formatting hard discs since 1984 when each level was
visible to the user (the low-level format was performed
by a program in ROM on the controller, the second-level format
was/is performed by FDISK, and the third and [optional] fourth
level formats were/are performed by FORMAT). I've never heard the
BR on a volume referred to as an MBR. I suggest you look at the
wikipedia entry.

From the wikipedia


Master boot record
From Wikipedia, the free encyclopedia.
(Redirected from MBR)

In the IBM PC architecture the master boot record (MBR), or partition sector, is the 512-byte (1/2 kibibyte [sic]) boot sector, i.e. the sector on the logical beginning of a hard disk that contains the sequence of commands necessary for booting the operating system(s) (OSes).

[snip for space' sake]

Layout of Master Boot Record

| First 446 bytes: Code Area  |
|16 byte partition table entry|
|16 byte partition table entry|
|16 byte partition table entry|
|16 byte partition table entry|
|2 byte MBR signature (0xAA55)|


The boot record (aka boot sector) is contained on each volume.
It contains the BIOS Parameter Block (BPB).

Again, I quote the wikipedia


BIOS parameter block
From Wikipedia, the free encyclopedia.

BIOS parameter block (BPB) is a description of the physical medium (hard disk or floppy) that might be stored in a filesystem's Volume Boot Record. Filesystems with a BIOS parameter block include FAT16, FAT32, and NTFS.


Note the distinction between BR and MBR. A disc has at most one MBR.
It may have as many BRs as there are Volumes. (Not all OS use a BR.)
Apparently, the term VBR is coming into use. I haven't seen the term
"volume boot record" used, only "boot record" (aka boot sector).

There has been in past some confusion of the terms BR, BPB, MBR, and PT.
Originally, we only used floppies, and BRs. When hard discs first
became available for small computers, they also had "boot records"
on them. But when we needed to paritition them, then we got
"master boot records", which in a manner of speaking are also
"boot records". Eventually the term "master boot record" changed
meaning. The word "master" became, not an adjective any more, but
a part of a single noun, the MBR, and BR became a term reserved
for the boot record contained in a volume. The MBR is not part of
any volume.

important to note that its active, but is NOT required to boot

Depends on what boot program one is using. Since the current
context is Windows, that is the context I used.

yup... i'm using lilo/grub context... nto sure if loadlin needs the active boot flag

Well, I repeatedly used in my message the word "traditionally", which
was *supposed* to be a hint that there are other ways of doing things.
BUT, this guy has a problem with a Windows MBR on his disc not
recognizing/using the boot procedure he wants. I felt that the
message was *already* getting too long and dense for easy comprehension
without burdening it with descriptions of alternate methods of boot.

the boot sequence is configurable in the BIOS setting

It may or may not be configurable in the ROM boot program

sure it is ... always have been since 1979 ...

Sir, the IBM PC wasn't *around* in 1979. In 1979 the common machines
used 8080, 8085, or Z80 processors, were built on S-100 boards, and
ran CP/M. I recall doing significant real-time embedded development on
computers with 8085 processors on S-100 boards using CP/M and 8 inch
floppy discs. When the IBM PC was introduced it had two methods of
boot, not selectable in the BIOS...

It first looked for a floppy disc, and if that failed it looked
for BASIC in ROM. If that failed, it gave the infamous message...

Initially, floppies for the PC were 90K single-sided single-density 5 1/4 inches. The first hard drives were 5 Megabytes, and we thought we were in hog heaven with that much room.

From Wikipedia


From Wikipedia, the free encyclopedia.
IBM PC (IBM 5150) with keyboard and green screen monochrome monitor (IBM 5151).

IBM PC (tm) (Personal Computer), is a trademark of IBM. The predecessor of the current personal computers and progenitor of the IBM PC compatible hardware platform, it was introduced in August 1981. The original model was designated the IBM 5150. It was created by a team of 12 engineers and designers under the direction of Don Estridge of the IBM Entry Systems Division. The introduction of the PC changed the world of IBM in 1981.


The BIOS on the PC and XT did not store *any* configurable but
non-volatile data. Not even time of day (*). Only with the advent of
the IBM PC/AT ("advanced technology") series using the 80286 did
we get a configurable BIOS. The AT had a clock chip (the Motorola
MC146818 Real Time Clock [RTC]) with some battery backed up RAM.
This was not configurable by using the on-ROM programs at the time,
but rather required a special boot floppy (the so-called "diagnostics
disc") containing the configuration program, which stored the data in
the RTC RAM (not part of the normal memory address space, but accessed
using 'point and shoot' via I/O ports 0x70 and 0x71).


Again, I replied only because this is a technical forum, and I
intend only to address what I percieve to be technical or factual
errors. No personal criticism is intended.

(*) Third-party add-on boards added an RTC, usually using the
National Semiconductor MM58167 chip. An example of this type of
board is the "Six Pack" which added expansion RAM, RTC, and a
serial port or two. But these boards had no non-volatile RAM,
and certainly did not upgrade the ROM BIOS to have configuration
parameters. I have in my hands at the moment one of these types
of boards manufactured by TECMAR.

This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

Reply to: