Question about Bus Mastering DMA - ATA/ATAPI

[Isaac D. Cohen]

Hi,

I'm trying to find out how to read from a drive using PCI Bus Mastering DMA. I've come across some pages on the OS Dev wiki, this specification http://www.bswd.com/idems100.pdf and the Brokenthorn tutorial on DMA (http://www.brokenthorn.com/Resources/OSDev21.html). Now I a bit confused. The Brokenthorn tutorial is about ISA DMA, not PCI Bus Mastering DMA, so is any of it applicable?

Also, that specification I referred to above, talks about the Physical Region Descriptor (PRD) table and two registers: A command register and a status register both of which, it says, are in port I/O space. But it does not say how to find out where in in port I/O space they are. Also, in that whole specification, the letters "LBA" are not mentioned once; which means the specification left out a very important detail: How to tell the controller which sectors to load from the disk.

One of the pages that I came across on the OS Dev wiki has example code showing how to load from a disk. Here is a link to the page: http://wiki.osdev.org/ATA_read/write_sectors

One of the things the example code does is send the drive number to port 0x1F6. What it does not say, is how to find out the number of the drive we are reading from.

So as you can see, I'm a little confused. Can somebody please help me out here?

[Johann Klammer]

The ISA dma is a third party dma mechanism in which the chipset periodically outputs
control signals onto the bus to transfer words from address A to B...
Whereas the PCI `DMA' is really just the PCI device doing writes to your main memory
all by itself.

The blackthorn tutorial deals with ISA only. Ignore it if you ATA ctrlr is PCI.
See if you can find a datasheet with register map for your device, look up
the base address in the devices' BAR and program the registers yourself....
(alot of things that can go wrong...)

[Rod Pemberton]

On Thu, 12 Nov 2015 11:56:23 -0500, Isaac D. Cohen <8switch...@gmail.com> wrote:

> I'm trying to find out how to read from a drive using PCI Bus Mastering DMA.

Is this specification of interest to you?

"PCI-ATA-DMA" v1.0, Phoenix, May 24,1995
http://rbsfm.org/Downloads/APPNOTE/IDE/PCICAG.PDF

> I've come across some pages on the OS Dev wiki, this specification
> http://www.bswd.com/idems100.pdf
> and the Brokenthorn tutorial on DMA
> (http://www.brokenthorn.com/Resources/OSDev21.html).
> Now I a bit confused. The Brokenthorn tutorial is about ISA DMA,
> not PCI Bus Mastering DMA, so is any of it applicable?
>
> Also, that specification I referred to above, talks about the
> Physical Region Descriptor (PRD) table and two registers:
> A command register and a status register both of which, it
> says, are in port I/O space. But it does not say how to find
> out where in in port I/O space they are. Also, in that whole
> specification, the letters "LBA" are not mentioned once;
> which means the specification left out a very important detail:
> How to tell the controller which sectors to load from the disk.

LBA is described in the later ATA/ATAPI specifications, of
which there are 7 or 8 or more versions.

> One of the pages that I came across on the OS Dev wiki has
> example code showing how to load from a disk. Here is a
> link to the page: http://wiki.osdev.org/ATA_read/write_sectors
>
> One of the things the example code does is send the drive number
> to port 0x1F6. What it does not say, is how to find out the number
> of the drive we are reading from.

This is the port I/O method for IDE drives (ATA devices). ATAPI is
for packet devices like CD-ROMs. The various early ATA and later
ATA/ATAPI combination specifications support PIO (port I/O),
DMAs (singleword), DMAm (multiword), and UDMA (ultra). 28-bit LBA
was introduced with ATA-2, 48-bit LBA with ATA/ATAPI-6, and SATA
drives with ATA/ATAPI-7.


(start info from old post of mine, slightly updated for you)
You'll want to obtain copies of the ATA/ATAPI standards. The last draft
prior to standardization is usually available. The standard version could
have some changes made after the draft version... The titles I have for the
final drafts which you can search for. They should be available as .pdf's.
I'd recommend at least version 3,5, and either 6 or 7. That would cover the
older, middle, and newest command sets without needing to locate all of
them.

"Information technology - AT Attachment Interface for Disk Drives"
"Information technology - AT Attachment Interface with Extensions (ATA-2)"
"Information technology - AT Attachment-3 Interface (ATA-3)"
"Information Technology - AT Attachment with Packet Interface Extension
(ATA/ATAPI-4)"
"Information Technology - AT Attachment with Packet Interface - 5
(ATA/ATAPI-5)"
"Information technology - AT Attachment Interface with Packet Interface - 6
(ATA/ATAPI 6)"
"Information technology - AT Attachment Interface with Packet Interface - 7"
"Information technology - AT Attachment 8 - ATA/ATAPI Command Set (ATA8-ACS)"

That's a partial title for ATAPI 7 since it has multiple volumes.

I posted an ATAPI 1,2,3,6,7 command summary. Unfortunately, I didn't have
the ATAPI 4,5,8 commands at the time. Link:

http://groups.google.com/group/alt.os.development/msg/d0da8699eb4d33bf?hl=en
Usenet MSG-ID <ea37kp$hs3$1...@nntp.aioe.org>

I missed command E7h:
E7h FLUSH CACHE ----, ----, ----,
ATA6, ATA7
(end old post info)


I've looked at the other standards since. There are a few minor changes
inbetween for the other standards, e.g., new commands, end-of-life for
some commands. I've not posted the updated info. I haven't followed
the ATA/ATAPI specifications since version 7. I know there is at least
a version 8, and probably some more now.

Also, IIRC, the ATA and ATA/ATAPI specifications don't tell you which
ports to program for IDE drives. Hence, your question. So, ...


(from another old post of mine)
My understanding is that these are the historical IDE ports
and interrupts:

IDE 0x1f0 thru 0x1f7, 0x3f6, 0x3f7, IRQ 14
IDE 0x170 thru 0x177, 0x376, 0x377, IRQ 15 (or alt. IRQ 10)
IDE 0x1e8 thru 0x1ef, 0x3ee, 0x3ef, IRQ 11 (or alt. IRQ 12)
IDE 0x168 thru 0x16f, 0x36e, 0x36f, IRQ 10 (or alt. IRQ 9)

The alternate (alt.) IRQs conflict with standard IRQs, but
might've been used on some machines or add-on cards.

Some versions of Linux support these also:

IDE 0x1e0 thru 0x1e7, 0x3e6, 0x3e7, IRQ 8
IDE 0x160 thru 0x167, 0x366, 0x367, IRQ 12
(/end old post info)


Note that SATA drives are not programmable in this way, unless the
machine is emulating the boot drive as an IDE device.


HTH,


Rod Pemberton


--
When El Chapo is the most beloved man in Mexico and Trump is the most hated,
it shows that Mexico is truly fouled up.

[Benjamin David Lunt]

"Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
news:op.x70bd9k6yfako5@localhost...

>
>
> Note that SATA drives are not programmable in this way, unless the
> machine is emulating the boot drive as an IDE device.
>

Rod,

Just a correction, the above statement isn't 100% accurate,
though it isn't wrong either.

Some SATA drives are not programmable in this way, as you
have noted, however, some are.

There is a flag within the SATA's operational registers that
indicates whether the drive interface supports AHCI only,
or AHCI and IDE.

If the SAM bit in the capabilities register is clear *and*
the EA bit is clear, the drive will behave just as an IDE
drive. If the EA bit is set, then the SATA drive will not
be programmable in this way, as you noted above.

Ben

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Forever Young Software
http://www.fysnet.net/index.htm
http://www.fysnet.net/osdesign_book_series.htm
To reply by email, please remove the zzzzzz's

Batteries not included, some Assembly required.

[Benjamin David Lunt]

"Isaac D. Cohen" <8switch...@gmail.com> wrote in message
news:96eae8c3-88d0-4ea9...@googlegroups.com...

[ I have cut the quoted part since some times my news reader
doesn't add the '>' to the beginning. However, Isaac is asking
about the PCI's bus mastering interface ]

Isaac,

When you tell the drive to read or write, you must have a
buffer ready for the read data, or a buffer that is filled
with data ready to be written to the drive, as you probably
already know.

Now you need to be able to tell the controller where this
buffer is located.

Since a buffer in 4096-byte pages is highly desired, the
bus mastering allows you to specify multiple 4096-byte
pages that may or may not be consecutive in memory.

This is where the Bus Mastering Descriptor table comes in
to play. You point the Bus Master's registers to a small
buffer holding a list of pages.

This is explained in detail in Volume 3 of my series,
"Media Storage Devices"
http://www.fysnet.net/media_storage_devices.htm

Chapter 9, starting with page 6 defines DMA transfers
on the PCI bus, using an IDE controller.

Here is a link to the section in the book.
http://www.fysnet.net/incoming/vol3_chap9_dma_xs.pdf

I have made this section a freely downloadable .pdf, and
will keep it up for a week or so, or maybe longer.

Note also that you must use a different command for reading
sectors using DMA. The command to read sectors using PIO
is different than the command to read sectors using DMA.

As with this and all of the other sections within the book,
it shows each step to setting up the PCI's DMA and then
sending the commands.

Might I also mention that Chapter 4 shows how do use the
DMA on an ISA bus.

Also, if you have an SATA drive in AHCI mode, you will
need to do a different sequence of DMA setup, which is
also explained within the latter parts of the book.

As with the other books in the series, if you show proof
of purchase, I will send you the CD-ROM to that book which
has source code to do what is shown in the book.

Please note that a quote from Chapter 9 is no longer
acceptable as proof of purchase :-)

Hope this helps,

[Benjamin David Lunt]

"Benjamin David Lunt" <zf...@fysnet.net> wrote in message
news:n23rnn$fb1$1...@speranza.aioe.org...

>
> "Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
> news:op.x70bd9k6yfako5@localhost...
>>
>>
>> Note that SATA drives are not programmable in this way, unless the
>> machine is emulating the boot drive as an IDE device.
>>
>
> Rod,
>
> Just a correction, the above statement isn't 100% accurate,
> though it isn't wrong either.
>
> Some SATA drives are not programmable in this way, as you
> have noted, however, some are.
>
> There is a flag within the SATA's operational registers that
> indicates whether the drive interface supports AHCI only,
> or AHCI and IDE.
>
> If the SAM bit in the capabilities register is clear *and*
> the EA bit is clear, the drive will behave just as an IDE
> drive. If the EA bit is set, then the SATA drive will not
> be programmable in this way, as you noted above.
>
> Ben

P.S. It has been a while since I have posted, and after reading
what I posted it may sound like I am bashing you a little :-)
That is not my intention, I am just making a correction.

I hope to be able to post more frequently in the near future.

Thanks,
Ben

[wolfgang kern]

Benjamin David Lunt said:

>>> Note that SATA drives are not programmable in this way, unless the
>>> machine is emulating the boot drive as an IDE device.

>> Rod,
>>
>> Just a correction, the above statement isn't 100% accurate,
>> though it isn't wrong either.
>>
>> Some SATA drives are not programmable in this way, as you
>> have noted, however, some are.
>>
>> There is a flag within the SATA's operational registers that
>> indicates whether the drive interface supports AHCI only,
>> or AHCI and IDE.
>>
>> If the SAM bit in the capabilities register is clear *and*
>> the EA bit is clear, the drive will behave just as an IDE
>> drive. If the EA bit is set, then the SATA drive will not
>> be programmable in this way, as you noted above.
>>
>> Ben
>
> P.S. It has been a while since I have posted, and after reading
> what I posted it may sound like I am bashing you a little :-)
> That is not my intention, I am just making a correction.
>
> I hope to be able to post more frequently in the near future.

Either way you told the truth, but I see two PCI-config spaces,
one for IDE and another for native SATA ports.
So UDMA seem to use the ports [01f0..1f6 and other base] the
same way as all IDE [LBA28 and LBA48] beside the PRD setup.
__
wolfgang

[Rod Pemberton]

On Fri, 13 Nov 2015 00:18:53 -0500, Benjamin David Lunt <zf...@fysnet.net> wrote:
> "Benjamin David Lunt" <zf...@fysnet.net> wrote in message
> news:n23rnn$fb1$1...@speranza.aioe.org...
>> "Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
>> news:op.x70bd9k6yfako5@localhost...

>>> Note that SATA drives are not programmable in this way, unless the
>>> machine is emulating the boot drive as an IDE device.
>>>
>>

>> Just a correction, the above statement isn't 100% accurate,
>> though it isn't wrong either.
>>
>> Some SATA drives are not programmable in this way, as you
>> have noted, however, some are.
>>
>> There is a flag within the SATA's operational registers that
>> indicates whether the drive interface supports AHCI only,
>> or AHCI and IDE.
>>
>> If the SAM bit in the capabilities register is clear *and*
>> the EA bit is clear, the drive will behave just as an IDE
>> drive. If the EA bit is set, then the SATA drive will not
>> be programmable in this way, as you noted above.
>>

I didn't know that. Thanks.

I abandoned my plans to develop IDE code after SATA became more
common, but, IIUC, that would allow some SATA drives to work with
the same code. Do you happen to have a rough idea about what
percentage of drives do and don't support that? Or, a guess?
Was is just early SATA? Just one of the four _HCI's?

Do you think a util to set these registers would help support
SATA on DOS for the non-boot drives? ...

> P.S. It has been a while since I have posted, and after reading
> what I posted it may sound like I am bashing you a little :-)
> That is not my intention, I am just making a correction.
>
> I hope to be able to post more frequently in the near future.
>

No, it didn't.

As the guy who literally wrote the book on the four _HCIs,
you're our resident expert! If you don't correct us, who
will?

[Benjamin David Lunt]

"wolfgang kern" <now...@never.at> wrote in message
news:n25a2k$lg8$1...@speranza.aioe.org...

>
> Either way you told the truth, but I see two PCI-config spaces, one for
> IDE and another for native SATA ports.

That is correct.

> So UDMA seem to use the ports [01f0..1f6 and other base] the same way as
> all IDE [LBA28 and LBA48] beside the PRD setup.

If using non-PCI IDE drives or PCI IDE drives in compatibility
mode, then yes, they use 0x01F0...6. If a PCI EDI drive and the
controller supports native mode, then you may specify the
port values.

However, the IRQ's of 14 and 15 are still hard-coded into the
drive. Go figure.

Ben

[Benjamin David Lunt]

"Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message

news:op.x7163xnvyfako5@localhost...

I have not done much research on this specifically, but from
what I understand is that almost all SATA controllers support the
legacy IDE interface. This interface also has a few extra
registers at BAR5 for status. If your code is not SATA aware,
then these will have no effect on your code. However, if your
code is SATA aware, you can use these registers for status
on the drives.

Please note that in this legacy IDE interface, you cannot
use more than four (4) drives even though the SATA spec's
specify many more.

Now, it is my understanding that the recent SATA interface
cards, recent meaning the last 5 or 6 years, support AHCI.
AHCI, not to be confused with USB's four _HCI's, is Intel's
and other's form of interface to allow up to 32 attached drives.

Also, the SATA drive itself does not know the difference
between the legacy IDE interface and the AHCI interface. The
same type and form of data is sent to the drive no matter
the interface used.

The legacy IDE interface allows up to 4 drives. The AHCI
interface allows up to 32 drives and may support things like
hot-plug notification, power management, etc.

> Do you think a util to set these registers would help support
> SATA on DOS for the non-boot drives? ...

Yes, though any non-AHCI SATA controller should already be
compatible where as an AHCI SATA controller should have a BIOS
(CMOS) option to change to legacy. However, a utility could
be written to check all AHCI compatible devices to check for
legacy support and set them to legacy if allowed.

>> P.S. It has been a while since I have posted, and after reading
>> what I posted it may sound like I am bashing you a little :-)
>> That is not my intention, I am just making a correction.
>>
>> I hope to be able to post more frequently in the near future.
>>
>
> No, it didn't.
>
> As the guy who literally wrote the book on the four _HCIs,
> you're our resident expert! If you don't correct us, who
> will?

:-)

Thanks,
Ben

[Rod Pemberton]

On Sat, 14 Nov 2015 15:03:06 -0500, Benjamin David Lunt <zf...@fysnet.net> wrote:
> "Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
> news:op.x7163xnvyfako5@localhost...
>> On Fri, 13 Nov 2015 00:18:53 -0500, Benjamin David Lunt <zf...@fysnet.net>
>> wrote:
>>> "Benjamin David Lunt" <zf...@fysnet.net> wrote in message
>>> news:n23rnn$fb1$1...@speranza.aioe.org...
>>>> "Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
>>>> news:op.x70bd9k6yfako5@localhost...

>>>> There is a flag within the SATA's operational registers that
>>>> indicates whether the drive interface supports AHCI only,
>>>> or AHCI and IDE.
>>>>
>>>> If the SAM bit in the capabilities register is clear *and*
>>>> the EA bit is clear, the drive will behave just as an IDE
>>>> drive. If the EA bit is set, then the SATA drive will not
>>>> be programmable in this way, as you noted above.
>>>>
>>

>> Do you happen to have a rough idea about what
>> percentage of drives do and don't support that? Or, a guess?
>> Was is just early SATA? Just one of the four _HCI's?
>
> I have not done much research on this specifically, but from
> what I understand is that almost all SATA controllers support the
> legacy IDE interface. This interface also has a few extra
> registers at BAR5 for status. If your code is not SATA aware,
> then these will have no effect on your code. However, if your
> code is SATA aware, you can use these registers for status
> on the drives.
>
> Please note that in this legacy IDE interface, you cannot
> use more than four (4) drives even though the SATA spec's
> specify many more.
>
> Now, it is my understanding that the recent SATA interface
> cards, recent meaning the last 5 or 6 years, support AHCI.

Supposedly, it was added to chipsets starting in 2004.
I'm not sure how long it took for complete penetration.

> AHCI, not to be confused with USB's four _HCI's, is Intel's
> and other's form of interface to allow up to 32 attached drives.

"not to be confused with USB's four _HCI's"

Subtle. Oops. Yeah, I'm not up to date anymore ... :-)

Does that mean I get to retract my resident expert comment? ;-)

> Yes, though any non-AHCI SATA controller should already be
> compatible where as an AHCI SATA controller should have a BIOS
> (CMOS) option to change to legacy. However, a utility could
> be written to check all AHCI compatible devices to check for
> legacy support and set them to legacy if allowed.

This BIOS has "Native IDE", "RAID", and "AHCI". It was set to
"Native IDE". Switching it to AHCI, it adds an additional
"AHCI Init" where it finds all my installed drives (all SATA),
except floppy. It boots both Linux and DOS with the setting,
as before with "Native IDE". Is there a reason to preference
"AHCI" over "Native IDE"? The drives seem to all be recognized
as AHCI compatible. So far, I see no difference. Is there a
way to tell if the drive is in "Native IDE" or "AHCI" mode?
How do I know if I selected AHCI in the BIOS, that the BIOS
didn't fall back to using IDE? Also, hopefully, switching
modes doesn't mess up anything. Let me know if it does.

[Rod Pemberton]

On Sat, 14 Nov 2015 18:48:32 -0500, Rod Pemberton <b...@fasdfrewar.cdm> wrote:

> Is there a way to tell if the drive is in "Native IDE" or
> "AHCI" mode?

With a bit of GIYF, this always shows a line with
"ahci" for Linux:

grep -inr IO-APIC-fasteoi /proc/interrupts

However, for Linux, this indicates whether
SATA is in IDE mode or AHCI mode:

lspci | grep SATA

The reported mode "IDE mode" or "ACHI mode" for the SATA
controller matches my BIOS setting of "Native IDE" or "ACHI".

I'm not sure how to check DOS for fall back ...


RP

[Benjamin David Lunt]

"Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message

news:op.x736260hyfako5@localhost...

> On Sat, 14 Nov 2015 15:03:06 -0500, Benjamin David Lunt
> <zf...@fysnet.net> wrote:

>> Now, it is my understanding that the recent SATA interface
>> cards, recent meaning the last 5 or 6 years, support AHCI.
>
> Supposedly, it was added to chipsets starting in 2004.
> I'm not sure how long it took for complete penetration.

A little while later. I found it to be around 2009-10.

>> AHCI, not to be confused with USB's four _HCI's, is Intel's
>> and other's form of interface to allow up to 32 attached drives.
>
> "not to be confused with USB's four _HCI's"
>
> Subtle. Oops. Yeah, I'm not up to date anymore ... :-)
>
> Does that mean I get to retract my resident expert comment? ;-)

What, I am not the resident expert anymore :-)

AHCI stands for Advanced Host Controller Interface.

>> Yes, though any non-AHCI SATA controller should already be
>> compatible where as an AHCI SATA controller should have a BIOS
>> (CMOS) option to change to legacy. However, a utility could
>> be written to check all AHCI compatible devices to check for
>> legacy support and set them to legacy if allowed.
>
> This BIOS has "Native IDE", "RAID", and "AHCI". It was set to
> "Native IDE". Switching it to AHCI, it adds an additional
> "AHCI Init" where it finds all my installed drives (all SATA),
> except floppy. It boots both Linux and DOS with the setting,
> as before with "Native IDE". Is there a reason to preference
> "AHCI" over "Native IDE"?

IMO, only if you have more than four drives attached to the same
controller, would like to be notified if one is detached or a
new one is attached, disable one of the drives, or something along
these lines.

> The drives seem to all be recognized
> as AHCI compatible. So far, I see no difference. Is there a
> way to tell if the drive is in "Native IDE" or "AHCI" mode?

Again, the drive itself knows no difference between the two
modes. It is the controller that is the difference. The controller
will either be in Native IDE mode or AHCI mode.

> How do I know if I selected AHCI in the BIOS, that the BIOS
> didn't fall back to using IDE?

That I don't know. I have yet to investigate the builtin BIOS
settings and options.

> Also, hopefully, switching
> modes doesn't mess up anything. Let me know if it does.

DOS does not know anything about AHCI and I doubt anyone has
written a driver for it for use within DOS. I am quite sure
the controller must be in Native IDE mode for DOS to use
the drive. If the controller is in AHCI mode, then DOS won't
even recognize a controller/disk(s) exist.

Remember, the (SATA) drive itself knows no difference between
the two. SATA and AHCI are two different specifications,
neither relying upon the other, other than AHCI states that
it will send data to the drive (across the wire) conforming
to the SATA standards.

On a side note, the AHCI actually allows for more than 32
drives if you use the Enclosure mechanism. You may have
a number of SATA drives housed in an "enclosure", and this
enclosure only needs a single SATA cable connected to the
AHCI controller. It is then up to the driver to keep track
of the number and current drive being used on that enclosure.
However, minus the enclosure mechanism, AHCI allows no more
than 32.

A later version might specify a flag and state that the
32-bit "container" DWORD is now a 64-bit QWORD and allow
64 drives. Of course other things would have to be modified
too, but just a thought...

Ben

[wolfgang kern]

Benjamin David Lunt wrote:

>> Either way you told the truth, but I see two PCI-config spaces,
>> one for IDE and another for native SATA ports.

> That is correct.

>> So UDMA seem to use the ports [01f0..1f6 and other base] the same
>> way as all IDE [LBA28 and LBA48] beside the PRD setup.

> If using non-PCI IDE drives or PCI IDE drives in compatibility
> mode, then yes, they use 0x01F0...6. If a PCI EDI drive and the
> controller supports native mode, then you may specify the
> port values.

I never tried to alter the port address here ...

> However, the IRQ's of 14 and 15 are still hard-coded into the
> drive. Go figure.

For my SATA-drives I use the I/O-port-pairs reported in the PCI-
config BAR0..3 and see (as PCI tells) IRQ 10 happen for them.
Only IDE connected drives seem to be hardwired to IRQ 14/15.
__
wolfgang

[Rod Pemberton]

On Sat, 14 Nov 2015 19:19:29 -0500, Rod Pemberton <b...@fasdfrewar.cdm> wrote:

> On Sat, 14 Nov 2015 18:48:32 -0500, Rod Pemberton <b...@fasdfrewar.cdm> wrote:

>> Is there a way to tell if the drive is in "Native IDE" or
>> "AHCI" mode?
>
> With a bit of GIYF, this always shows a line with
> "ahci" for Linux:
>
> grep -inr IO-APIC-fasteoi /proc/interrupts
>
> However, for Linux, this indicates whether
> SATA is in IDE mode or AHCI mode:
>
> lspci | grep SATA
>
> The reported mode "IDE mode" or "ACHI mode" for the SATA
> controller matches my BIOS setting of "Native IDE" or "ACHI".
>
> I'm not sure how to check DOS for fall back ...
>

FYI, update.

Well, I've been using AHCI for Linux and MS-DOS without issue
for about a month now. Linux *seems* to operate much more
reliably, i.e., less thrashing, memory usage for ramdisk. This
may just be a "placebo" effect. MS-DOS doesn't seem to have any
problems either. But, as you may recall, I had no way to determine
if the drive was actually booted with AHCI mode for DOS. I don't
start Windows 98/SE much anymore after moving to Linux, but I just
attempted to do so. Windows 98/SE won't start with the drive in
AHCI mode. It complains of either a kernel error or and IOS driver
error. The latter is the OS driver for the hard drive. I.e.,
I think this confirms that the drive boots into DOS with AHCI mode
and uses it just fine. MS-DOS is likely using BIOS drive calls
which support AHCI, at least for this machine, whereas Windows 98/SE
is probably attempting to program the hard drive as an IDE device
and not AHCI.


Rod Pemberton


--
How to kill Facebook. Tell a bunch of fourth graders that
only old people use Facebook. Wait eight years.

[Benjamin David Lunt]

"Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message

news:op.x87ap9vryfako5@localhost...

Hi Rod,

Your assumptions are correct. Since MS-DOS uses the BIOS to access
the drive, the drive can be in either mode as long as the BIOS
supports either mode. MS-DOS knows no difference.

In a previous post to this thread, I said:
[

DOS does not know anything about AHCI and I doubt anyone has
written a driver for it for use within DOS. I am quite sure
the controller must be in Native IDE mode for DOS to use
the drive. If the controller is in AHCI mode, then DOS won't
even recognize a controller/disk(s) exist.

]

I need to correct myself there. Since DOS uses the BIOS, the
BIOS is what accesses the drive. DOS could use the drive in
any interface as long as the BIOS understood the interface.

It has been a long time since I have used the BIOS to
access anything, I was still in the frame of mind of
direct hardware access :-)

Anyway, your assumptions are correct. DOS will boot just fine
since the BIOS handles the AHCI interface. However, Win98/SE
uses direct hardware access, therefore will not be able to
access the drive in AHCI mode. Linux does support AHCI mode.

Just confirming your findings. Thanks,