external eSata enclosure drive recognition?

[Bill in Co.]

AIUI, theorectically you could boot the device as long as the BIOS can
load
and jump into the first sector. Practically, "basic disk" Windows MBR boot
code
requires the device to be recognised by the 0x13 interrupts. IOW, Windows
MBR code
uses int 0x13 to load the volume boot sector of the boot device.

So what is the process again? I'm still confused. Let's see what I am
missing:

When you initially boot the computer, the *system* BIOS 1) enumerates
devices, and 2) if it detects BIOS on the added in PCI controller card, the
CPU executes an INT 13H CALL instruction, which then tells it to go out and
read a sector on the MBR of a HD?

 

[Bill Blanton]

So what is the process again? I'm still confused. Let's see what I am missing:

When you initially boot the computer, the *system* BIOS 1) enumerates devices, and 2) if it detects BIOS on the added in PCI
controller card, the CPU executes an INT 13H CALL instruction, which then tells it to go out and read a sector on the MBR of a
HD?

Not sure Bill, but I believe that the cards on board "BIOS" would have to
add the storage devices to the system BIOS data area which is then
accessed by int 13h. It may also modify the int 13h code in some way.
(Int 13h is not a hardware interrupt, but a software interrupt and can be
modified. "Drive managers/overlays" do this.)

The BIOS code may or may not use the int 13h disk services to access/load a
boot device. An example of that would be a network boot, which Paul brought
up, which uses a different software int.

When the system BIOS is done with all its initializations, enumerations, etc. ,
all the BIOS needs to worry about is loading the selected "boot" device into
memory and then jumping to that code. After that, it is up to that loaded
code to continue the boot process, however it wants to accomplish the task.

As far as how a PCI device interacts with the BIOS on boot up, I don't really
know the details, but one thing I am positive of is the fact that the boot code
in the Win MBR uses int 13h to load the volume boot sector. If a storage device,
(at that stage), can't be seen by int 13h, then it cannot boot using that standard
MBR code. (might not apply for the newer EFI specification). Again however,
that int 13h code can be modified. And so can the standard MBR boot code.

 

[Paul]

Not sure Bill, but I believe that the cards on board "BIOS" would have to
add the storage devices to the system BIOS data area which is then
accessed by int 13h. It may also modify the int 13h code in some way.
(Int 13h is not a hardware interrupt, but a software interrupt and can be
modified. "Drive managers/overlays" do this.)

The BIOS code may or may not use the int 13h disk services to access/load a
boot device. An example of that would be a network boot, which Paul brought
up, which uses a different software int.

When the system BIOS is done with all its initializations, enumerations, etc. ,
all the BIOS needs to worry about is loading the selected "boot" device into
memory and then jumping to that code. After that, it is up to that loaded
code to continue the boot process, however it wants to accomplish the task.

As far as how a PCI device interacts with the BIOS on boot up, I don't really
know the details, but one thing I am positive of is the fact that the boot code
in the Win MBR uses int 13h to load the volume boot sector. If a storage device,
(at that stage), can't be seen by int 13h, then it cannot boot using that standard
MBR code. (might not apply for the newer EFI specification). Again however,
that int 13h code can be modified. And so can the standard MBR boot code.

There is a casual description here, of some of this stuff.

http://en.wikipedia.org/wiki/Option_ROM

http://en.wikipedia.org/wiki/INT_13

http://en.wikipedia.org/wiki/Booting ("Boot sequence on standard PC")

http://www.microsoft.com/technet/prodtechnol/Windows2000Pro/reskit/part7/proch32.mspx?mfr=true

Even after looking at a few of these articles, it is unclear how the
OS carries out the loading from disk. The articles give the impression
that the OS routines do the loading from disk. But if that were the case,
then why would storage drivers ever be needed once the desktop appears ?
I'm still looking for an article that addresses what is handling
disk I/O, all the way until the desktop appears. I had the impression
that a lot of drivers run their initialization code, just before the desktop
appears. Now, maybe the storage drivers are loaded first, and are running
much earlier than the rest. But that isn't a very satisfying answer.

Paul

 

[Bill Blanton]

There is a casual description here, of some of this stuff.

http://en.wikipedia.org/wiki/Option_ROM

http://en.wikipedia.org/wiki/INT_13

http://en.wikipedia.org/wiki/Booting ("Boot sequence on standard PC")

http://www.microsoft.com/technet/prodtechnol/Windows2000Pro/reskit/part7/proch32.mspx?mfr=true

Even after looking at a few of these articles, it is unclear how the
OS carries out the loading from disk. The articles give the impression
that the OS routines do the loading from disk. But if that were the case,
then why would storage drivers ever be needed once the desktop appears ?
I'm still looking for an article that addresses what is handling
disk I/O, all the way until the desktop appears. I had the impression
that a lot of drivers run their initialization code, just before the desktop
appears. Now, maybe the storage drivers are loaded first, and are running
much earlier than the rest. But that isn't a very satisfying answer.

Here's the Win2k MBR boot code disassembled. The int 13 loads are near the
bottom of the code section.

http://mirror.href.com/thestarman/asm/mbr/Win2kmbr.htm

Once the OS boot sector is loaded, I believe it uses int 13h initially (it's still
the only thing available at that point), to load the loader, but eventually does
load more specific drivers. I have no idea either, when that occurs exactly.


In some instances the OS will contiinue using the hard disk
services that are in place at boot (could be, but not necessarily the BIOS
interrupts). Win9x DOS compatibility mode is an example. I don't think
XP/NT has a similar mechanism?

 

[Bill Blanton]

Here's the Win2k MBR boot code disassembled. The int 13 loads are near the
bottom of the code section.

http://mirror.href.com/thestarman/asm/mbr/Win2kmbr.htm

Once the OS boot sector is loaded, I believe it uses int 13h initially (it's still
the only thing available at that point), to load the loader, but eventually does
load more specific drivers. I have no idea either, when that occurs exactly.


In some instances the OS will contiinue using the hard disk
services that are in place at boot (could be, but not necessarily the BIOS
interrupts). Win9x DOS compatibility mode is an example. I don't think
XP/NT has a similar mechanism?

Here's another good link;
http://en.wikipedia.org/wiki/Windows_NT_startup_process
Sounds authoritive anyway. Relative quote:

<quote>
For the purposes of booting, a driver is either a "Boot" driver that is loaded by NTLDR or IA64ldr prior to starting the kernel and
started before system drivers by the kernel, a "System" driver, which is loaded and started by ntoskrnl.exe after the boot drivers
or an "Automatic" driver which is loaded much later when the GUI already has been started. "Boot" drivers are almost exclusively
drivers for hard-drive controllers and file systems (ATA, SCSI, file system filter manager, etc.); in other words, they are the
absolute minimum that ntoskrnl.exe will need to get started with loading other drivers, and the rest of the operating system.
"System" drivers cover a wider range of core functionality, including the display driver, CD-ROM support, and the TCP/IP stack.
</quote>

 

[Paul]

Here's another good link;
http://en.wikipedia.org/wiki/Windows_NT_startup_process
Sounds authoritive anyway. Relative quote:

<quote>
For the purposes of booting, a driver is either a "Boot" driver that is loaded by NTLDR
or IA64ldr prior to starting the kernel and started before system drivers by the kernel,
a "System" driver, which is loaded and started by ntoskrnl.exe after the boot drivers
or an "Automatic" driver which is loaded much later when the GUI already has been started.
"Boot" drivers are almost exclusively drivers for hard-drive controllers and file systems
(ATA, SCSI, file system filter manager, etc.); in other words, they are the absolute minimum
that ntoskrnl.exe will need to get started with loading other drivers, and the rest of the
operating system. "System" drivers cover a wider range of core functionality, including
the display driver, CD-ROM support, and the TCP/IP stack.
</quote>

Thanks for that. So the INT 0x13 doesn't sound like it is used for very long.
I've been wondering about that for a while.

Paul