INT13/SCSI Boot Questions

NTDEV
1

Hello,

Please accept my apology in advance if this is not the appropriate place to
post this.

I’m trying to understand how SCSI devices boot via the use of INT13 in a
windows environment and am pretty much banging my head against the wall. I
looked at the aha154x driver in the DDK, but did not find anything that
helped me in my search. As a background, my SCSI knowledge is very limited
as I’m a networking type. Can anyone point me to somewhere that describes
(from a SCSI miniport point of view) what needs to be done, if anything
specific, within my driver to support boot. I’ve read several MSDN articles
that describe boot.ini requirement to specify where the boot image resides,
but nothing about actually implementing INT13 processing in my ROM image.

Thanks,

Chris

2

xxxxx@lists.osr.com wrote on 03/28/2005 03:27:45 PM:

Hello,

Please accept my apology in advance if this is not the appropriate place
to
post this.

I’m trying to understand how SCSI devices boot via the use of INT13 in a
windows environment and am pretty much banging my head against the wall.
I
looked at the aha154x driver in the DDK, but did not find anything that
helped me in my search. As a background, my SCSI knowledge is very
limited
as I’m a networking type. Can anyone point me to somewhere that
describes
(from a SCSI miniport point of view) what needs to be done, if anything
specific, within my driver to support boot. I’ve read several MSDN
articles
that describe boot.ini requirement to specify where the boot image
resides,
but nothing about actually implementing INT13 processing in my ROM
image.

SCSI devices don’t boot. They start and stop. (OK, they do boot, but you
don’t see that unless you are attached to a diagnostic port, and they sure
don’t use INT 13h to boot themselves.)

Software or firmware boots from a variety of media, including SCSI
devices. Perhaps you meant to ask something like “How does Windows boot
from a SCSI device using INT 13h?” Good question. But the answer
requires a bit of background. The following description is generally
correct, though I know of some exceptions, such as some alternative boot
loaders that do things differently.

The BIOS in any modern system already has an INT 13h handler for the
onboard HBA, whether it’s ATA or SCSI. When the POST is completed, the
BIOS loads the MBR (LBA zero) from the designated boot device, and then
jumps into the code in that sector. That sector needs to load any data it
requires to continue booting, but how? Normally it’s done through the INT
13h interface. The boot code reads the MBR to see which partition is
active, then loads the boot sector from that partition. That boot sector
then reads the FS enough to continue the process, loading the kernel,
registry hive, boot drivers, and some other gunk. Once NTLDR has all the
necessary stuff in memory, it jumps into the kernel, which then starts the
drivers, including the HBA driver. Once NTLDR jumps into the kernel, INT
13h isn’t used anymore, AFAIK. The most current edition of “Inside
Windows ???” by Russinovich and Solomon has an excellent description of
this process.

I’ve never seen the code for an INT 13h handler, so I’m not exactly sure
what you need to know. Are you trying to write an INT 13h handler for a
SCSI HBA? Perhaps it would be more productive for you to give more detail
about the specific problem you are trying to solve?

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

3

Phil,

Thanks for the information. I’m still working on getting my terminology
right.

The problem I’m investigating is iSCSI related and I’m trying to first
determine how SCSI works and extrapolate that to iSCSI. Would it be fair to
say (and I know this leaves out a lot of details) that at the point in your
description below where, after “NTLDR has all the necessary stuff in memory,
it jumps into the kernel, which starts the drivers…”, an iSCSI driver
(which is implemented as a SCSI miniport) could be one of the ones started?

Like I said, I know this leaves out a lot of details (mainly because I don’t
have them yet).

Chris

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Monday, March 28, 2005 6:42 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] INT13/SCSI Boot Questions

xxxxx@lists.osr.com wrote on 03/28/2005 03:27:45 PM:

Hello,

Please accept my apology in advance if this is not the appropriate place
to
post this.

I’m trying to understand how SCSI devices boot via the use of INT13 in a
windows environment and am pretty much banging my head against the wall.
I
looked at the aha154x driver in the DDK, but did not find anything that
helped me in my search. As a background, my SCSI knowledge is very
limited
as I’m a networking type. Can anyone point me to somewhere that describes
(from a SCSI miniport point of view) what needs to be done, if anything
specific, within my driver to support boot. I’ve read several MSDN
articles
that describe boot.ini requirement to specify where the boot image
resides,
but nothing about actually implementing INT13 processing in my ROM image.

SCSI devices don’t boot. They start and stop. (OK, they do boot, but you
don’t see that unless you are attached to a diagnostic port, and they sure
don’t use INT 13h to boot themselves.)

Software or firmware boots from a variety of media, including SCSI devices.
Perhaps you meant to ask something like “How does Windows boot from a SCSI
device using INT 13h?” Good question. But the answer requires a bit of
background. The following description is generally correct, though I know
of some exceptions, such as some alternative boot loaders that do things
differently.

The BIOS in any modern system already has an INT 13h handler for the onboard
HBA, whether it’s ATA or SCSI. When the POST is completed, the BIOS loads
the MBR (LBA zero) from the designated boot device, and then jumps into the
code in that sector. That sector needs to load any data it requires to
continue booting, but how? Normally it’s done through the INT 13h
interface. The boot code reads the MBR to see which partition is active,
then loads the boot sector from that partition. That boot sector then reads
the FS enough to continue the process, loading the kernel, registry hive,
boot drivers, and some other gunk. Once NTLDR has all the necessary stuff
in memory, it jumps into the kernel, which then starts the drivers,
including the HBA driver. Once NTLDR jumps into the kernel, INT 13h isn’t
used anymore, AFAIK. The most current edition of “Inside Windows ???” by
Russinovich and Solomon has an excellent description of this process.

I’ve never seen the code for an INT 13h handler, so I’m not exactly sure
what you need to know. Are you trying to write an INT 13h handler for a
SCSI HBA? Perhaps it would be more productive for you to give more detail
about the specific problem you are trying to solve?

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842 — Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 You are currently subscribed to
ntdev as: xxxxx@alacritech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com

4

The problem will be getting the network up early enough. I recommend looking at Adaptecs iSCSI controllers. They allow you to boot from an iSCSI device.

Jamey

----- Original Message -----
From: Chris Harrer
To: Windows System Software Devs Interest List
Sent: Tuesday, March 29, 2005 2:06 PM
Subject: RE: [ntdev] INT13/SCSI Boot Questions

Phil,

Thanks for the information. I’m still working on getting my terminology right.

The problem I’m investigating is iSCSI related and I’m trying to first determine how SCSI works and extrapolate that to iSCSI. Would it be fair to say (and I know this leaves out a lot of details) that at the point in your description below where, after “NTLDR has all the necessary stuff in memory, it jumps into the kernel, which starts the drivers…”, an iSCSI driver (which is implemented as a SCSI miniport) could be one of the ones started?

Like I said, I know this leaves out a lot of details (mainly because I don’t have them yet).

Chris

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@seagate.com
Sent: Monday, March 28, 2005 6:42 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] INT13/SCSI Boot Questions

xxxxx@lists.osr.com wrote on 03/28/2005 03:27:45 PM:

Hello,
>
> Please accept my apology in advance if this is not the appropriate place to
> post this.
>
> I’m trying to understand how SCSI devices boot via the use of INT13 in a
> windows environment and am pretty much banging my head against the wall. I
> looked at the aha154x driver in the DDK, but did not find anything that
> helped me in my search. As a background, my SCSI knowledge is very limited
> as I’m a networking type. Can anyone point me to somewhere that describes
> (from a SCSI miniport point of view) what needs to be done, if anything
> specific, within my driver to support boot. I’ve read several MSDN articles
> that describe boot.ini requirement to specify where the boot image resides,
> but nothing about actually implementing INT13 processing in my ROM image.

SCSI devices don’t boot. They start and stop. (OK, they do boot, but you don’t see that unless you are attached to a diagnostic port, and they sure don’t use INT 13h to boot themselves.)

Software or firmware boots from a variety of media, including SCSI devices. Perhaps you meant to ask something like “How does Windows boot from a SCSI device using INT 13h?” Good question. But the answer requires a bit of background. The following description is generally correct, though I know of some exceptions, such as some alternative boot loaders that do things differently.

The BIOS in any modern system already has an INT 13h handler for the onboard HBA, whether it’s ATA or SCSI. When the POST is completed, the BIOS loads the MBR (LBA zero) from the designated boot device, and then jumps into the code in that sector. That sector needs to load any data it requires to continue booting, but how? Normally it’s done through the INT 13h interface. The boot code reads the MBR to see which partition is active, then loads the boot sector from that partition. That boot sector then reads the FS enough to continue the process, loading the kernel, registry hive, boot drivers, and some other gunk. Once NTLDR has all the necessary stuff in memory, it jumps into the kernel, which then starts the drivers, including the HBA driver. Once NTLDR jumps into the kernel, INT 13h isn’t used anymore, AFAIK. The most current edition of “Inside Windows ???” by Russinovich and Solomon has an excellent description of this process.

I’ve never seen the code for an INT 13h handler, so I’m not exactly sure what you need to know. Are you trying to write an INT 13h handler for a SCSI HBA? Perhaps it would be more productive for you to give more detail about the specific problem you are trying to solve?

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842 — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: xxxxx@alacritech.com To unsubscribe send a blank email to xxxxx@lists.osr.com —
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

If you want to boot off of an iSCSI remote disk you have to have bios
support for something that looks like an INT13 disk device but is in fact
your remote iSCSI disk. This is possible if you have a hardware iSCSI
solution, but I think it is not possible if you have a software iSCSI
solution.

The INT13 interface is used to load the entire OS off of the BOOT DISK
whatever that happens to be, and that INT13 boot disk is used as the OS goes
through its initialization process. That very same BOOT DISK had better be
the same media used when the OS switches from using the INT13 interface to
the internal HBA miniport drivers.

=====================
Mark Roddy

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Chris Harrer
Sent: Tuesday, March 29, 2005 5:06 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] INT13/SCSI Boot Questions

Phil,

Thanks for the information. I’m still working on getting my terminology
right.

The problem I’m investigating is iSCSI related and I’m trying to first
determine how SCSI works and extrapolate that to iSCSI. Would it be fair to
say (and I know this leaves out a lot of details) that at the point in your
description below where, after “NTLDR has all the necessary stuff in memory,
it jumps into the kernel, which starts the drivers…”, an iSCSI driver
(which is implemented as a SCSI miniport) could be one of the ones started?

Like I said, I know this leaves out a lot of details (mainly because I don’t
have them yet).

Chris

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Monday, March 28, 2005 6:42 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] INT13/SCSI Boot Questions

xxxxx@lists.osr.com wrote on 03/28/2005 03:27:45 PM:

Hello,

Please accept my apology in advance if this is not the appropriate place
to
post this.

I’m trying to understand how SCSI devices boot via the use of INT13 in a
windows environment and am pretty much banging my head against the wall.
I
looked at the aha154x driver in the DDK, but did not find anything that
helped me in my search. As a background, my SCSI knowledge is very
limited
as I’m a networking type. Can anyone point me to somewhere that describes
(from a SCSI miniport point of view) what needs to be done, if anything
specific, within my driver to support boot. I’ve read several MSDN
articles
that describe boot.ini requirement to specify where the boot image
resides,
but nothing about actually implementing INT13 processing in my ROM image.

SCSI devices don’t boot. They start and stop. (OK, they do boot, but you
don’t see that unless you are attached to a diagnostic port, and they sure
don’t use INT 13h to boot themselves.)

Software or firmware boots from a variety of media, including SCSI devices.
Perhaps you meant to ask something like “How does Windows boot from a SCSI
device using INT 13h?” Good question. But the answer requires a bit of
background. The following description is generally correct, though I know
of some exceptions, such as some alternative boot loaders that do things
differently.

The BIOS in any modern system already has an INT 13h handler for the onboard
HBA, whether it’s ATA or SCSI. When the POST is completed, the BIOS loads
the MBR (LBA zero) from the designated boot device, and then jumps into the
code in that sector. That sector needs to load any data it requires to
continue booting, but how? Normally it’s done through the INT 13h
interface. The boot code reads the MBR to see which partition is active,
then loads the boot sector from that partition. That boot sector then reads
the FS enough to continue the process, loading the kernel, registry hive,
boot drivers, and some other gunk. Once NTLDR has all the necessary stuff
in memory, it jumps into the kernel, which then starts the drivers,
including the HBA driver. Once NTLDR jumps into the kernel, INT 13h isn’t
used anymore, AFAIK. The most current edition of “Inside Windows ???” by
Russinovich and Solomon has an excellent description of this process.

I’ve never seen the code for an INT 13h handler, so I’m not exactly sure
what you need to know. Are you trying to write an INT 13h handler for a
SCSI HBA? Perhaps it would be more productive for you to give more detail
about the specific problem you are trying to solve?

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842 — Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 You are currently subscribed to
ntdev as: xxxxx@alacritech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com —
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

Chris,

The TCPIP stack is not one of the drivers normally loaded by NTLDR, it is
loaded later in the system. As such it is unavailable when the storage
stack is initialised during kernel start.

Having said that, last year there was an attempted project that did
something similar to what you seem to be looking at, involving PXE on the
NIC, a SCSI miniport and a vast munging of the Windows load order and boot
sequence.

Firstly, because it requires a SCSI miniport it will not conform to the
Microsoft iSCSI framework and as such the chances of getting such a driver
signed are approximately nil.

Secondly, the munging of the Windows load order that is required to make
this work makes Windows unstable on many systems. So unstable in fact that
at the time Microsoft refused to support any system which used this
method. If you follow this method then you must be prepared to provide all
Windows support for all the customers you sell the product to. Also, it is
unlikely that you will get any help from Microsoft during the development
due to the nature of what you are trying to do to Windows.

As an exercise, what you are looking at is quite interesting to do. As a
product, it will probably never be able to fly.

Mark.

At 11:06 PM 3/29/2005, Chris Harrer wrote:

Phil,

Thanks for the information. I’m still working on getting my terminology
right.

The problem I’m investigating is iSCSI related and I’m trying to first
determine how SCSI works and extrapolate that to iSCSI. Would it be fair
to say (and I know this leaves out a lot of details) that at the point in
your description below where, after “NTLDR has all the necessary stuff in
memory, it jumps into the kernel, which starts the drivers…”, an iSCSI
driver (which is implemented as a SCSI miniport) could be one of the ones
started?

Like I said, I know this leaves out a lot of details (mainly because I
don’t have them yet).

Chris

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Monday, March 28, 2005 6:42 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] INT13/SCSI Boot Questions

xxxxx@lists.osr.com wrote on 03/28/2005 03:27:45 PM:

> Hello,
>
> Please accept my apology in advance if this is not the appropriate place to
> post this.
>
> I’m trying to understand how SCSI devices boot via the use of INT13 in a
> windows environment and am pretty much banging my head against the wall. I
> looked at the aha154x driver in the DDK, but did not find anything that
> helped me in my search. As a background, my SCSI knowledge is very limited
> as I’m a networking type. Can anyone point me to somewhere that describes
> (from a SCSI miniport point of view) what needs to be done, if anything
> specific, within my driver to support boot. I’ve read several MSDN
articles
> that describe boot.ini requirement to specify where the boot image resides,
> but nothing about actually implementing INT13 processing in my ROM image.

SCSI devices don’t boot. They start and stop. (OK, they do boot, but you
don’t see that unless you are attached to a diagnostic port, and they sure
don’t use INT 13h to boot themselves.)

Software or firmware boots from a variety of media, including SCSI
devices. Perhaps you meant to ask something like “How does Windows boot
from a SCSI device using INT 13h?” Good question. But the answer
requires a bit of background. The following description is generally
correct, though I know of some exceptions, such as some alternative boot
loaders that do things differently.

The BIOS in any modern system already has an INT 13h handler for the
onboard HBA, whether it’s ATA or SCSI. When the POST is completed, the
BIOS loads the MBR (LBA zero) from the designated boot device, and then
jumps into the code in that sector. That sector needs to load any data it
requires to continue booting, but how? Normally it’s done through the INT
13h interface. The boot code reads the MBR to see which partition is
active, then loads the boot sector from that partition. That boot sector
then reads the FS enough to continue the process, loading the kernel,
registry hive, boot drivers, and some other gunk. Once NTLDR has all the
necessary stuff in memory, it jumps into the kernel, which then starts the
drivers, including the HBA driver. Once NTLDR jumps into the kernel, INT
13h isn’t used anymore, AFAIK. The most current edition of “Inside
Windows ???” by Russinovich and Solomon has an excellent description of
this process.

I’ve never seen the code for an INT 13h handler, so I’m not exactly sure
what you need to know. Are you trying to write an INT 13h handler for a
SCSI HBA? Perhaps it would be more productive for you to give more detail
about the specific problem you are trying to solve?

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842 — Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 You are currently subscribed
to ntdev as: xxxxx@alacritech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com —
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

7

Check out the session at the upcoming Driver Devcon 2005.

iSCSI Network Boot Architecture
http://www.microsoft.com/whdc/driverdevcon/ddctracks2005/d05tracks.mspx
http:>

However, it is not clear if it is either “Network boot using the MS
iscsi initiator” or “Network boot over 3rd party iscsi initiator”
Either way, the session should be useful.

-g

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark S. Edwards
Sent: Wednesday, March 30, 2005 12:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] INT13/SCSI Boot Questions

Chris,

The TCPIP stack is not one of the drivers normally loaded by
NTLDR, it is loaded later in the system. As such it is unavailable when
the storage stack is initialised during kernel start.

Having said that, last year there was an attempted project that
did something similar to what you seem to be looking at, involving PXE
on the NIC, a SCSI miniport and a vast munging of the Windows load order
and boot sequence.

Firstly, because it requires a SCSI miniport it will not conform
to the Microsoft iSCSI framework and as such the chances of getting such
a driver signed are approximately nil.

Secondly, the munging of the Windows load order that is required
to make this work makes Windows unstable on many systems. So unstable
in fact that at the time Microsoft refused to support any system which
used this method. If you follow this method then you must be prepared
to provide all Windows support for all the customers you sell the
product to. Also, it is unlikely that you will get any help from
Microsoft during the development due to the nature of what you are
trying to do to Windows.

As an exercise, what you are looking at is quite interesting to
do. As a product, it will probably never be able to fly.

Mark.

At 11:06 PM 3/29/2005, Chris Harrer wrote:

Phil,

Thanks for the information. I’m still working on
getting my terminology right.

The problem I’m investigating is iSCSI related and I’m
trying to first determine how SCSI works and extrapolate that to iSCSI.
Would it be fair to say (and I know this leaves out a lot of details)
that at the point in your description below where, after “NTLDR has all
the necessary stuff in memory, it jumps into the kernel, which starts
the drivers…”, an iSCSI driver (which is implemented as a SCSI
miniport) could be one of the ones started?

Like I said, I know this leaves out a lot of details
(mainly because I don’t have them yet).

Chris

________________________________

From: xxxxx@lists.osr.com [
mailto:xxxxx@lists.osr.com
mailto:xxxxx] On Behalf Of
xxxxx@seagate.com
Sent: Monday, March 28, 2005 6:42 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] INT13/SCSI Boot Questions

xxxxx@lists.osr.com wrote on 03/28/2005
03:27:45 PM:

> Hello,
>
> Please accept my apology in advance if this is not the
appropriate place to
> post this.
>
> I’m trying to understand how SCSI devices boot via the
use of INT13 in a
> windows environment and am pretty much banging my head
against the wall. I
> looked at the aha154x driver in the DDK, but did not
find anything that
> helped me in my search. As a background, my SCSI
knowledge is very limited
> as I’m a networking type. Can anyone point me to
somewhere that describes
> (from a SCSI miniport point of view) what needs to be
done, if anything
> specific, within my driver to support boot. I’ve read
several MSDN articles
> that describe boot.ini requirement to specify where
the boot image resides,
> but nothing about actually implementing INT13
processing in my ROM image.

SCSI devices don’t boot. They start and stop. (OK,
they do boot, but you don’t see that unless you are attached to a
diagnostic port, and they sure don’t use INT 13h to boot themselves.)

Software or firmware boots from a variety of media,
including SCSI devices. Perhaps you meant to ask something like “How
does Windows boot from a SCSI device using INT 13h?” Good question.
But the answer requires a bit of background. The following description
is generally correct, though I know of some exceptions, such as some
alternative boot loaders that do things differently.

The BIOS in any modern system already has an INT 13h
handler for the onboard HBA, whether it’s ATA or SCSI. When the POST is
completed, the BIOS loads the MBR (LBA zero) from the designated boot
device, and then jumps into the code in that sector. That sector needs
to load any data it requires to continue booting, but how? Normally
it’s done through the INT 13h interface. The boot code reads the MBR to
see which partition is active, then loads the boot sector from that
partition. That boot sector then reads the FS enough to continue the
process, loading the kernel, registry hive, boot drivers, and some other
gunk. Once NTLDR has all the necessary stuff in memory, it jumps into
the kernel, which then starts the drivers, including the HBA driver.
Once NTLDR jumps into the kernel, INT 13h isn’t used anymore, AFAIK.
The most current edition of “Inside Windows ???” by Russinovich and
Solomon has an excellent description of this process.

I’ve never seen the code for an INT 13h handler, so I’m
not exactly sure what you need to know. Are you trying to write an INT
13h handler for a SCSI HBA? Perhaps it would be more productive for you
to give more detail about the specific problem you are trying to solve?

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842 — Questions? First check the Kernel
Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are
currently subscribed to ntdev as: xxxxx@alacritech.com To unsubscribe
send a blank email to xxxxx@lists.osr.com —
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown
lmsubst tag argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@wipro.com
To unsubscribe send a blank email to
xxxxx@lists.osr.com</mailto:xxxxx></http:>

8

iSCSI requires TCP/IP to be started in fact.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Chris Harrer
To: Windows System Software Devs Interest List
Sent: Wednesday, March 30, 2005 2:06 AM
Subject: RE: [ntdev] INT13/SCSI Boot Questions

Phil,

Thanks for the information. I’m still working on getting my terminology right.

The problem I’m investigating is iSCSI related and I’m trying to first determine how SCSI works and extrapolate that to iSCSI. Would it be fair to say (and I know this leaves out a lot of details) that at the point in your description below where, after “NTLDR has all the necessary stuff in memory, it jumps into the kernel, which starts the drivers…”, an iSCSI driver (which is implemented as a SCSI miniport) could be one of the ones started?

Like I said, I know this leaves out a lot of details (mainly because I don’t have them yet).

Chris

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@seagate.com
Sent: Monday, March 28, 2005 6:42 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] INT13/SCSI Boot Questions

xxxxx@lists.osr.com wrote on 03/28/2005 03:27:45 PM:

Hello,
>
> Please accept my apology in advance if this is not the appropriate place to
> post this.
>
> I’m trying to understand how SCSI devices boot via the use of INT13 in a
> windows environment and am pretty much banging my head against the wall. I
> looked at the aha154x driver in the DDK, but did not find anything that
> helped me in my search. As a background, my SCSI knowledge is very limited
> as I’m a networking type. Can anyone point me to somewhere that describes
> (from a SCSI miniport point of view) what needs to be done, if anything
> specific, within my driver to support boot. I’ve read several MSDN articles
> that describe boot.ini requirement to specify where the boot image resides,
> but nothing about actually implementing INT13 processing in my ROM image.

SCSI devices don’t boot. They start and stop. (OK, they do boot, but you don’t see that unless you are attached to a diagnostic port, and they sure don’t use INT 13h to boot themselves.)

Software or firmware boots from a variety of media, including SCSI devices. Perhaps you meant to ask something like “How does Windows boot from a SCSI device using INT 13h?” Good question. But the answer requires a bit of background. The following description is generally correct, though I know of some exceptions, such as some alternative boot loaders that do things differently.

The BIOS in any modern system already has an INT 13h handler for the onboard HBA, whether it’s ATA or SCSI. When the POST is completed, the BIOS loads the MBR (LBA zero) from the designated boot device, and then jumps into the code in that sector. That sector needs to load any data it requires to continue booting, but how? Normally it’s done through the INT 13h interface. The boot code reads the MBR to see which partition is active, then loads the boot sector from that partition. That boot sector then reads the FS enough to continue the process, loading the kernel, registry hive, boot drivers, and some other gunk. Once NTLDR has all the necessary stuff in memory, it jumps into the kernel, which then starts the drivers, including the HBA driver. Once NTLDR jumps into the kernel, INT 13h isn’t used anymore, AFAIK. The most current edition of “Inside Windows ???” by Russinovich and Solomon has an excellent description of this process.

I’ve never seen the code for an INT 13h handler, so I’m not exactly sure what you need to know. Are you trying to write an INT 13h handler for a SCSI HBA? Perhaps it would be more productive for you to give more detail about the specific problem you are trying to solve?

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842 — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: xxxxx@alacritech.com To unsubscribe send a blank email to xxxxx@lists.osr.com —
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

9

Mark,

I’m familiar with the project you reference below. It’s different from what
I’m discussing. What I’m discussing is not a software solution dependent
upon MS TCP/IP or NDIS. In my mind, what I’m thinking is described as an
HBA. It would be a SCSI miniport on the top end that talks to it’s hardware
(as opposed to TDI) on the bottom end. It contains its own TCP/IP, etc.

So, to go back to my previous question, the driver for this devive could be
marked as one of the drivers required for Boot and subsequently started
right after the ntldr, kernel and such loads, right?

Chris

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark S. Edwards
Sent: Wednesday, March 30, 2005 2:00 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] INT13/SCSI Boot Questions

Chris,

The TCPIP stack is not one of the drivers normally loaded by NTLDR, it is
loaded later in the system. As such it is unavailable when the storage
stack is initialised during kernel start.

Having said that, last year there was an attempted project that did
something similar to what you seem to be looking at, involving PXE on the
NIC, a SCSI miniport and a vast munging of the Windows load order and boot
sequence.

Firstly, because it requires a SCSI miniport it will not conform to the
Microsoft iSCSI framework and as such the chances of getting such a driver
signed are approximately nil.

Secondly, the munging of the Windows load order that is required to make
this work makes Windows unstable on many systems. So unstable in fact that
at the time Microsoft refused to support any system which used this method.
If you follow this method then you must be prepared to provide all Windows
support for all the customers you sell the product to. Also, it is unlikely
that you will get any help from Microsoft during the development due to the
nature of what you are trying to do to Windows.

As an exercise, what you are looking at is quite interesting to do. As a
product, it will probably never be able to fly.

Mark.

At 11:06 PM 3/29/2005, Chris Harrer wrote:

Phil,

Thanks for the information. I’m still working on getting my terminology
right.

The problem I’m investigating is iSCSI related and I’m trying to first
determine how SCSI works and extrapolate that to iSCSI. Would it be fair to
say (and I know this leaves out a lot of details) that at the point in your
description below where, after “NTLDR has all the necessary stuff in memory,
it jumps into the kernel, which starts the drivers…”, an iSCSI driver
(which is implemented as a SCSI miniport) could be one of the ones started?

Like I said, I know this leaves out a lot of details (mainly because I don’t
have them yet).

Chris

From: xxxxx@lists.osr.com [
mailto:xxxxx
mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Monday, March 28, 2005 6:42 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] INT13/SCSI Boot Questions

xxxxx@lists.osr.com wrote on 03/28/2005 03:27:45 PM:

> Hello,
>
> Please accept my apology in advance if this is not the appropriate place
to
> post this.
>
> I’m trying to understand how SCSI devices boot via the use of INT13 in a
> windows environment and am pretty much banging my head against the wall.
I
> looked at the aha154x driver in the DDK, but did not find anything that
> helped me in my search. As a background, my SCSI knowledge is very
limited
> as I’m a networking type. Can anyone point me to somewhere that describes
> (from a SCSI miniport point of view) what needs to be done, if anything
> specific, within my driver to support boot. I’ve read several MSDN
articles
> that describe boot.ini requirement to specify where the boot image
resides,
> but nothing about actually implementing INT13 processing in my ROM image.

SCSI devices don’t boot. They start and stop. (OK, they do boot, but you
don’t see that unless you are attached to a diagnostic port, and they sure
don’t use INT 13h to boot themselves.)

Software or firmware boots from a variety of media, including SCSI devices.
Perhaps you meant to ask something like “How does Windows boot from a SCSI
device using INT 13h?” Good question. But the answer requires a bit of
background. The following description is generally correct, though I know
of some exceptions, such as some alternative boot loaders that do things
differently.

The BIOS in any modern system already has an INT 13h handler for the onboard
HBA, whether it’s ATA or SCSI. When the POST is completed, the BIOS loads
the MBR (LBA zero) from the designated boot device, and then jumps into the
code in that sector. That sector needs to load any data it requires to
continue booting, but how? Normally it’s done through the INT 13h
interface. The boot code reads the MBR to see which partition is active,
then loads the boot sector from that partition. That boot sector then reads
the FS enough to continue the process, loading the kernel, registry hive,
boot drivers, and some other gunk. Once NTLDR has all the necessary stuff
in memory, it jumps into the kernel, which then starts the drivers,
including the HBA driver. Once NTLDR jumps into the kernel, INT 13h isn’t
used anymore, AFAIK. The most current edition of “Inside Windows ???” by
Russinovich and Solomon has an excellent description of this process.

I’ve never seen the code for an INT 13h handler, so I’m not exactly sure
what you need to know. Are you trying to write an INT 13h handler for a
SCSI HBA? Perhaps it would be more productive for you to give more detail
about the specific problem you are trying to solve?

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842 — Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 You are currently subscribed to
ntdev as: xxxxx@alacritech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com —
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@alacritech.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx>

10

Chris,

you have iSCSI HBA. TCP stack and iSCSI stack are running on card’s own
processor. Your card
has EEPROM with a real-mode int 13h BIOS. On boot main machine BIOS would
call your ROM
BIOS extension module (as you’ll be the only boot capable device - you’d
pick the request up). You’ll
have the code to map int 13h requests to read/write particular sector with
your card private API calls
(could be even PIO or something really dumb and easy - performance is not
critical at this point).

NTLDR would switch machine to protected mode (until this point it would read
whole loadable images
thru the int 13h). It would load your card .sys driver and starting from
this point you’ll have all of the
requests routed thru your card .sys driver. That’s all :slight_smile:

You do not need system network stack so you don’t care when it load or would
it load at all. And also
you have a very wide choice of storage driver model as you deal with pure
hardware only.

That’s the way to solve your problem. There’s one other way to do it but it
does require hardware and
not software redesign and I don’t think I want to describe it in the public
group :slight_smile:

Regards,
Anton Kolomyeytsev

CEO, Rocket Division Software

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Chris Harrer
Sent: Wednesday, March 30, 2005 3:51 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] INT13/SCSI Boot Questions

Mark,

I’m familiar with the project you reference below. It’s different from what
I’m discussing. What I’m discussing is not a software solution dependent
upon MS TCP/IP or NDIS. In my mind, what I’m thinking is described as an
HBA. It would be a SCSI miniport on the top end that talks to it’s hardware
(as opposed to TDI) on the bottom end. It contains its own TCP/IP, etc.

So, to go back to my previous question, the driver for this devive could be
marked as one of the drivers required for Boot and subsequently started
right after the ntldr, kernel and such loads, right?

Chris

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark S. Edwards
Sent: Wednesday, March 30, 2005 2:00 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] INT13/SCSI Boot Questions

Chris,

The TCPIP stack is not one of the drivers normally loaded by NTLDR, it is
loaded later in the system. As such it is unavailable when the storage
stack is initialised during kernel start.

Having said that, last year there was an attempted project that did
something similar to what you seem to be looking at, involving PXE on the
NIC, a SCSI miniport and a vast munging of the Windows load order and boot
sequence.

Firstly, because it requires a SCSI miniport it will not conform to the
Microsoft iSCSI framework and as such the chances of getting such a driver
signed are approximately nil.

Secondly, the munging of the Windows load order that is required to make
this work makes Windows unstable on many systems. So unstable in fact that
at the time Microsoft refused to support any system which used this method.
If you follow this method then you must be prepared to provide all Windows
support for all the customers you sell the product to. Also, it is unlikely
that you will get any help from Microsoft during the development due to the
nature of what you are trying to do to Windows.

As an exercise, what you are looking at is quite interesting to do. As a
product, it will probably never be able to fly.

Mark.

At 11:06 PM 3/29/2005, Chris Harrer wrote:

Phil,

Thanks for the information. I’m still working on getting my terminology
right.

The problem I’m investigating is iSCSI related and I’m trying to first
determine how SCSI works and extrapolate that to iSCSI. Would it be fair to
say (and I know this leaves out a lot of details) that at the point in your
description below where, after “NTLDR has all the necessary stuff in memory,
it jumps into the kernel, which starts the drivers…”, an iSCSI driver
(which is implemented as a SCSI miniport) could be one of the ones started?

Like I said, I know this leaves out a lot of details (mainly because I don’t
have them yet).

Chris

From: xxxxx@lists.osr.com [
mailto:xxxxx
mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Monday, March 28, 2005 6:42 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] INT13/SCSI Boot Questions

xxxxx@lists.osr.com wrote on 03/28/2005 03:27:45 PM:

> Hello,
>
> Please accept my apology in advance if this is not the appropriate place
to
> post this.
>
> I’m trying to understand how SCSI devices boot via the use of INT13 in a
> windows environment and am pretty much banging my head against the wall.
I
> looked at the aha154x driver in the DDK, but did not find anything that
> helped me in my search. As a background, my SCSI knowledge is very
limited
> as I’m a networking type. Can anyone point me to somewhere that describes
> (from a SCSI miniport point of view) what needs to be done, if anything
> specific, within my driver to support boot. I’ve read several MSDN
articles
> that describe boot.ini requirement to specify where the boot image
resides,
> but nothing about actually implementing INT13 processing in my ROM image.

SCSI devices don’t boot. They start and stop. (OK, they do boot, but you
don’t see that unless you are attached to a diagnostic port, and they sure
don’t use INT 13h to boot themselves.)

Software or firmware boots from a variety of media, including SCSI devices.
Perhaps you meant to ask something like “How does Windows boot from a SCSI
device using INT 13h?” Good question. But the answer requires a bit of
background. The following description is generally correct, though I know
of some exceptions, such as some alternative boot loaders that do things
differently.

The BIOS in any modern system already has an INT 13h handler for the onboard
HBA, whether it’s ATA or SCSI. When the POST is completed, the BIOS loads
the MBR (LBA zero) from the designated boot device, and then jumps into the
code in that sector. That sector needs to load any data it requires to
continue booting, but how? Normally it’s done through the INT 13h
interface. The boot code reads the MBR to see which partition is active,
then loads the boot sector from that partition. That boot sector then reads
the FS enough to continue the process, loading the kernel, registry hive,
boot drivers, and some other gunk. Once NTLDR has all the necessary stuff
in memory, it jumps into the kernel, which then starts the drivers,
including the HBA driver. Once NTLDR jumps into the kernel, INT 13h isn’t
used anymore, AFAIK. The most current edition of “Inside Windows ???” by
Russinovich and Solomon has an excellent description of this process.

I’ve never seen the code for an INT 13h handler, so I’m not exactly sure
what you need to know. Are you trying to write an INT 13h handler for a
SCSI HBA? Perhaps it would be more productive for you to give more detail
about the specific problem you are trying to solve?

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842 — Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 You are currently subscribed to
ntdev as: xxxxx@alacritech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com —
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@alacritech.com
To unsubscribe send a blank email to xxxxx@lists.osr.com —
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx>

11

iSCSI and TOE have been implemented on a single silicon-:slight_smile:

Calvin Guan??? Software Engineer??
ATI Technologies Inc. www.ati.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: March 30, 2005 5:00 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] INT13/SCSI Boot Questions

??? iSCSI requires TCP/IP to be started in fact.
?
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

12

Yes, that would work.

Jamey
----- Original Message -----
From: Chris Harrer
To: Windows System Software Devs Interest List
Sent: Wednesday, March 30, 2005 4:51 AM
Subject: RE: [ntdev] INT13/SCSI Boot Questions

Mark,

I'm familiar with the project you reference below. It's different from what I'm discussing. What I'm discussing is not a software solution dependent upon MS TCP/IP or NDIS. In my mind, what I'm thinking is described as an HBA. It would be a SCSI miniport on the top end that talks to it's hardware (as opposed to TDI) on the bottom end. It contains its own TCP/IP, etc.

So, to go back to my previous question, the driver for this devive could be marked as one of the drivers required for Boot and subsequently started right after the ntldr, kernel and such loads, right?

Chris

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark S. Edwards
Sent: Wednesday, March 30, 2005 2:00 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] INT13/SCSI Boot Questions

Chris,

The TCPIP stack is not one of the drivers normally loaded by NTLDR, it is loaded later in the system. As such it is unavailable when the storage stack is initialised during kernel start.

Having said that, last year there was an attempted project that did something similar to what you seem to be looking at, involving PXE on the NIC, a SCSI miniport and a vast munging of the Windows load order and boot sequence.

Firstly, because it requires a SCSI miniport it will not conform to the Microsoft iSCSI framework and as such the chances of getting such a driver signed are approximately nil.

Secondly, the munging of the Windows load order that is required to make this work makes Windows unstable on many systems. So unstable in fact that at the time Microsoft refused to support any system which used this method. If you follow this method then you must be prepared to provide all Windows support for all the customers you sell the product to. Also, it is unlikely that you will get any help from Microsoft during the development due to the nature of what you are trying to do to Windows.

As an exercise, what you are looking at is quite interesting to do. As a product, it will probably never be able to fly.

Mark.

At 11:06 PM 3/29/2005, Chris Harrer wrote:

Phil,

Thanks for the information. I'm still working on getting my terminology right.

The problem I'm investigating is iSCSI related and I'm trying to first determine how SCSI works and extrapolate that to iSCSI. Would it be fair to say (and I know this leaves out a lot of details) that at the point in your description below where, after "NTLDR has all the necessary stuff in memory, it jumps into the kernel, which starts the drivers...", an iSCSI driver (which is implemented as a SCSI miniport) could be one of the ones started?

Like I said, I know this leaves out a lot of details (mainly because I don't have them yet).

Chris

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@seagate.com
Sent: Monday, March 28, 2005 6:42 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] INT13/SCSI Boot Questions

xxxxx@lists.osr.com wrote on 03/28/2005 03:27:45 PM:

Hello,
>
> Please accept my apology in advance if this is not the appropriate place to
> post this.
>
> I'm trying to understand how SCSI devices boot via the use of INT13 in a
> windows environment and am pretty much banging my head against the wall. I
> looked at the aha154x driver in the DDK, but did not find anything that
> helped me in my search. As a background, my SCSI knowledge is very limited
> as I'm a networking type. Can anyone point me to somewhere that describes
> (from a SCSI miniport point of view) what needs to be done, if anything
> specific, within my driver to support boot. I've read several MSDN articles
> that describe boot.ini requirement to specify where the boot image resides,
> but nothing about actually implementing INT13 processing in my ROM image.

SCSI devices don't boot. They start and stop. (OK, they do boot, but you don't see that unless you are attached to a diagnostic port, and they sure don't use INT 13h to boot themselves.)

Software or firmware boots from a variety of media, including SCSI devices. Perhaps you meant to ask something like "How does Windows boot from a SCSI device using INT 13h?" Good question. But the answer requires a bit of background. The following description is generally correct, though I know of some exceptions, such as some alternative boot loaders that do things differently.

The BIOS in any modern system already has an INT 13h handler for the onboard HBA, whether it's ATA or SCSI. When the POST is completed, the BIOS loads the MBR (LBA zero) from the designated boot device, and then jumps into the code in that sector. That sector needs to load any data it requires to continue booting, but how? Normally it's done through the INT 13h interface. The boot code reads the MBR to see which partition is active, then loads the boot sector from that partition. That boot sector then reads the FS enough to continue the process, loading the kernel, registry hive, boot drivers, and some other gunk. Once NTLDR has all the necessary stuff in memory, it jumps into the kernel, which then starts the drivers, including the HBA driver. Once NTLDR jumps into the kernel, INT 13h isn't used anymore, AFAIK. The most current edition of "Inside Windows ????" by Russinovich and Solomon has an excellent description of this process.

I've never seen the code for an INT 13h handler, so I'm not exactly sure what you need to know. Are you trying to write an INT 13h handler for a SCSI HBA? Perhaps it would be more productive for you to give more detail about the specific problem you are trying to solve?

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842 --- Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: xxxxx@alacritech.com To unsubscribe send a blank email to xxxxx@lists.osr.com ---
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ''
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@alacritech.com
To unsubscribe send a blank email to xxxxx@lists.osr.com ---
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ''
To unsubscribe send a blank email to xxxxx@lists.osr.com