external eSata enclosure drive recognition?

"Bill in Co." <not_really_here.RemoveThis@earthlink.net> wrote in message news:%233EYoOa9IHA.5568@TK2MSFTNGP04.phx.gbl...
> Bill Blanton wrote:
>> "Bill in Co." <not_really_here.RemoveThis@earthlink.net> wrote in message
>> news:%23Gvwd7T9IHA.1208@TK2MSFTNGP05.phx.gbl...
>>> Paul wrote:
>>>> Bill in Co. wrote:
>>>>
>>>>>> OK. When the BIOS starts, it enumerates the add-on cards. It visits them
>>>>>> one at a time, and reads the configuration info from the main chip.
>>>>>
>>>>> From the "main chip" on the add-on card, I presume that means. (Not sure
>>>>> what the "main chip" is, but I guess that depends on the nature of the card).
>>>>
>>>> The chip connected to the bus present in that expansion slot. The SIL3132
>>>> chip has a PCI Express x1 interface on it, and it connects to the slot.
>>>> Probes by the BIOS, to the configuration space of the SIL3132, will
>>>> uncover it is a storage controller card. If a BIOS chip is detected,
>>>> then the next step would be to load code from the BIOS_chip.
>>>>
>>>> SIL3132 ------ BIOS_chip
>>>> |
>>>> | (Enumerates via bus)
>>>> |
>>>> PCI_Express_x1_slot
>>>>
>>>> If the above BIOS chip, has INT 0x13 code present, then that storage card
>>>> could contribute a drive to the boot list.
>>>
>>> I wonder if it does (or how many actually do). Interesting.
>>>
>>>> If the card is designed like this, then a disk drive connected to the
>>>> SIL3132 cannot be used to boot the computer.
>>>
>>> Cannot? And yet it would appear in the boot list. I don't understand
>>> why if the system reads the BIOS on the card it's not able to boot the
>>> computer (not that I want that, anyways). It seems you are saying above
>>> that if the BIOS on the card is read, that it can't be used for booting? OR
>>> that this is somehow tied into the INT 0 x 13 thing you mentioned, and THAT
>>> is what creates that limitation?
>>
>> 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?

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.

Bill Blanton wrote:
> "Bill in Co." <not_really_here.DeleteThis@earthlink.net> wrote in message news:%233EYoOa9IHA.5568@TK2MSFTNGP04.phx.gbl...
>> Bill Blanton wrote:
>>> "Bill in Co." <not_really_here.DeleteThis@earthlink.net> wrote in message
>>> news:%23Gvwd7T9IHA.1208@TK2MSFTNGP05.phx.gbl...
>>>> Paul wrote:
>>>>> Bill in Co. wrote:
>>>>>
>>>>>>> OK. When the BIOS starts, it enumerates the add-on cards. It visits them
>>>>>>> one at a time, and reads the configuration info from the main chip.
>>>>>> From the "main chip" on the add-on card, I presume that means. (Not sure
>>>>>> what the "main chip" is, but I guess that depends on the nature of the card).
>>>>> The chip connected to the bus present in that expansion slot. The SIL3132
>>>>> chip has a PCI Express x1 interface on it, and it connects to the slot.
>>>>> Probes by the BIOS, to the configuration space of the SIL3132, will
>>>>> uncover it is a storage controller card. If a BIOS chip is detected,
>>>>> then the next step would be to load code from the BIOS_chip.
>>>>>
>>>>> SIL3132 ------ BIOS_chip
>>>>> |
>>>>> | (Enumerates via bus)
>>>>> |
>>>>> PCI_Express_x1_slot
>>>>>
>>>>> If the above BIOS chip, has INT 0x13 code present, then that storage card
>>>>> could contribute a drive to the boot list.
>>>> I wonder if it does (or how many actually do). Interesting.
>>>>
>>>>> If the card is designed like this, then a disk drive connected to the
>>>>> SIL3132 cannot be used to boot the computer.
>>>> Cannot? And yet it would appear in the boot list. I don't understand
>>>> why if the system reads the BIOS on the card it's not able to boot the
>>>> computer (not that I want that, anyways). It seems you are saying above
>>>> that if the BIOS on the card is read, that it can't be used for booting? OR
>>>> that this is somehow tied into the INT 0 x 13 thing you mentioned, and THAT
>>>> is what creates that limitation?
>>> 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?
>
> 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/par...proch32

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

"Paul" <nospam.TakeThisOut@needed.com> wrote in message news:g75qs0$mr7$1@aioe.org...
> Bill Blanton wrote:
>> "Bill in Co." <not_really_here.TakeThisOut@earthlink.net> wrote in message news:%233EYoOa9IHA.5568@TK2MSFTNGP04.phx.gbl...
>>> Bill Blanton wrote:
>>>> "Bill in Co." <not_really_here.TakeThisOut@earthlink.net> wrote in message
>>>> news:%23Gvwd7T9IHA.1208@TK2MSFTNGP05.phx.gbl...
>>>>> Paul wrote:
>>>>>> Bill in Co. wrote:
>>>>>>
>>>>>>>> OK. When the BIOS starts, it enumerates the add-on cards. It visits them
>>>>>>>> one at a time, and reads the configuration info from the main chip.
>>>>>>> From the "main chip" on the add-on card, I presume that means. (Not sure
>>>>>>> what the "main chip" is, but I guess that depends on the nature of the card).
>>>>>> The chip connected to the bus present in that expansion slot. The SIL3132
>>>>>> chip has a PCI Express x1 interface on it, and it connects to the slot.
>>>>>> Probes by the BIOS, to the configuration space of the SIL3132, will
>>>>>> uncover it is a storage controller card. If a BIOS chip is detected,
>>>>>> then the next step would be to load code from the BIOS_chip.
>>>>>>
>>>>>> SIL3132 ------ BIOS_chip
>>>>>> |
>>>>>> | (Enumerates via bus)
>>>>>> |
>>>>>> PCI_Express_x1_slot
>>>>>>
>>>>>> If the above BIOS chip, has INT 0x13 code present, then that storage card
>>>>>> could contribute a drive to the boot list.
>>>>> I wonder if it does (or how many actually do). Interesting.
>>>>>
>>>>>> If the card is designed like this, then a disk drive connected to the
>>>>>> SIL3132 cannot be used to boot the computer.
>>>>> Cannot? And yet it would appear in the boot list. I don't understand
>>>>> why if the system reads the BIOS on the card it's not able to boot the
>>>>> computer (not that I want that, anyways). It seems you are saying above
>>>>> that if the BIOS on the card is read, that it can't be used for booting? OR
>>>>> that this is somehow tied into the INT 0 x 13 thing you mentioned, and THAT
>>>>> is what creates that limitation?
>>>> 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?
>>
>> 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/par...proch32
>
> 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" <bblanton RemoveThis @REMOVEmagicnet.net> wrote in message news:OJL$F$i9IHA.3648@TK2MSFTNGP03.phx.gbl...
> "Paul" <nospam RemoveThis @needed.com> wrote in message news:g75qs0$mr7$1@aioe.org...
>> Bill Blanton wrote:
>>> "Bill in Co." <not_really_here RemoveThis @earthlink.net> wrote in message news:%233EYoOa9IHA.5568@TK2MSFTNGP04.phx.gbl...
>>>> Bill Blanton wrote:
>>>>> "Bill in Co." <not_really_here RemoveThis @earthlink.net> wrote in message
>>>>> news:%23Gvwd7T9IHA.1208@TK2MSFTNGP05.phx.gbl...
>>>>>> Paul wrote:
>>>>>>> Bill in Co. wrote:
>>>>>>>
>>>>>>>>> OK. When the BIOS starts, it enumerates the add-on cards. It visits them
>>>>>>>>> one at a time, and reads the configuration info from the main chip.
>>>>>>>> From the "main chip" on the add-on card, I presume that means. (Not sure
>>>>>>>> what the "main chip" is, but I guess that depends on the nature of the card).
>>>>>>> The chip connected to the bus present in that expansion slot. The SIL3132
>>>>>>> chip has a PCI Express x1 interface on it, and it connects to the slot.
>>>>>>> Probes by the BIOS, to the configuration space of the SIL3132, will
>>>>>>> uncover it is a storage controller card. If a BIOS chip is detected,
>>>>>>> then the next step would be to load code from the BIOS_chip.
>>>>>>>
>>>>>>> SIL3132 ------ BIOS_chip
>>>>>>> |
>>>>>>> | (Enumerates via bus)
>>>>>>> |
>>>>>>> PCI_Express_x1_slot
>>>>>>>
>>>>>>> If the above BIOS chip, has INT 0x13 code present, then that storage card
>>>>>>> could contribute a drive to the boot list.
>>>>>> I wonder if it does (or how many actually do). Interesting.
>>>>>>
>>>>>>> If the card is designed like this, then a disk drive connected to the
>>>>>>> SIL3132 cannot be used to boot the computer.
>>>>>> Cannot? And yet it would appear in the boot list. I don't understand
>>>>>> why if the system reads the BIOS on the card it's not able to boot the
>>>>>> computer (not that I want that, anyways). It seems you are saying above
>>>>>> that if the BIOS on the card is read, that it can't be used for booting? OR
>>>>>> that this is somehow tied into the INT 0 x 13 thing you mentioned, and THAT
>>>>>> is what creates that limitation?
>>>>> 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?
>>>
>>> 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/par...proch32
>>
>> 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?


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>

Bill Blanton wrote:

>
>
> 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