OSDev.org

I have a couple more questions on ATA. I would've posted them in the topic about it returning 0xFF, but I had already hijacked that topic enough and thought it might go better in a new topic. My questions are:
1) The ATA spec mentions several protocols (DMA, DMA Queued, Execute Device Diagnostic, ...) that it doesn't cover. The ATA/ATAPI through DMA article on the wiki answers the DMA protocol question (very good article, by the way), but what are the others? Is it worth supporting any of them in my kernel and if so, what document(s) should I purchase/read to learn about them?
And finally, 2) All of the commands that take "count" as an "argument" to them indicate that 0000h is 256 sectors (for LBA28) and 65536 sectors (for LBA48), and that "count" indicates how many sectors to "<insert action here>". Is a "sector" in this instance an actual LBA, and if so, would I just read 256*count words on the data port?
Edit: to clarify, the protocols I'm specifically asking about are:

• Execute device diagnostic
• Non-data
• DMA queued

I would ask about the Packet and Device Reset protocols, however Packet and Device Reset are obsolete in ATA8 ACS, at least the standard I have a copy of. I would assume that Non-data means "no IO", just transmission of parameters, and I already know that PIO data in and PIO data out are just inw/outw instructions.
Edit 2: fixed typo and changed "FPDMA" to "DMA queued".

Ethin wrote:1) The ATA spec mentions several protocols (DMA, DMA Queued, Execute Device Diagnostic, ...) that it doesn't cover. The ATA/ATAPI through DMA article on the wiki answers the DMA protocol question (very good article, by the way), but what are the others? Is it worth supporting any of them in my kernel and if so, what document(s) should I purchase/read to learn about them?

First of all, you shouldn't be buying any of these documents. The drafts available for free are more than good enough.

Now, I know you already found a good explanation of DMA, but if you're looking for actual specifications, you want the PCI IDE Controller Specification and the Programming Interface for Bus Master IDE Controller. (Well, there's also ISA DMA, but hardware for that is both obsolete and extremely rare.) PCI DMA is very fast, so you should be using it whenever possible.

The DMA Queued protocol is used for SATA NCQ, which (as far as I know) you can't implement in your ATA driver. Worry about it in your AHCI driver instead.

Non-data means what it says: you transfer no data. Instead, the drive updates its registers to indicate the result. You still have to wait for the drive to become ready before you can read the result.

Execute Device Diagnostic is a special case of Non-data, where the error register is redefined to store a numeric error code in the low 7 bits, instead of the usual definition.

Ethin wrote:And finally, 2) All of the commands that take "count" as an "argument" to them indicate that 0000h is 256 sectors (for LBA28) and 65536 sectors (for LBA48), and that "count" indicates how many sectors to "<insert action here>". Is a "sector" in this instance an actual LBA, and if so, would I just read 256*count words on the data port?

You'll wait for the drive to report that it's ready, then read (or write) one sector. Repeat these two steps for however many sectors you've told the drive you're going to read (or write). The sectors will be sequential, starting from the LBA you indicated when you sent the command. Don't assume that sectors will always be 256 words, it's 2020 now and drives with 4kB sectors (2048 words) are common.

The latest command set (ATA8-ACS4) has marked it obsolete, but prior versions describe the READ MULTIPLE and WRITE MULTIPLE commands, which allow PIO transfers of more than one sector each time the drive reports it's ready. They're useful for speeding up PIO transfers when DMA is not available.

Octocontrabass wrote:

Ethin wrote:1) The ATA spec mentions several protocols (DMA, DMA Queued, Execute Device Diagnostic, ...) that it doesn't cover. The ATA/ATAPI through DMA article on the wiki answers the DMA protocol question (very good article, by the way), but what are the others? Is it worth supporting any of them in my kernel and if so, what document(s) should I purchase/read to learn about them?

First of all, you shouldn't be buying any of these documents. The drafts available for free are more than good enough.

Thanks, I'll probably check out the drafts for now. I can't seem to find any "revision" documents that describe changes to any of these, which is weird; SATA has a revsion section but this doesn't seem to have any that I can find.
Edit: OK, so the draft apparently has a revision document. But the released version, I don't think, has it. Strange.

Octocontrabass wrote:Now, I know you already found a good explanation of DMA, but if you're looking for actual specifications, you want the PCI IDE Controller Specification and the Programming Interface for Bus Master IDE Controller. (Well, there's also ISA DMA, but hardware for that is both obsolete and extremely rare.) PCI DMA is very fast, so you should be using it whenever possible.

The DMA Queued protocol is used for SATA NCQ, which (as far as I know) you can't implement in your ATA driver. Worry about it in your AHCI driver instead.

Non-data means what it says: you transfer no data. Instead, the drive updates its registers to indicate the result. You still have to wait for the drive to become ready before you can read the result.

Execute Device Diagnostic is a special case of Non-data, where the error register is redefined to store a numeric error code in the low 7 bits, instead of the usual definition.

Thanks. Could you link me to the latest drafts of those specifications? I definitely can't buy any of the PCI specs (the hardcopies are something ridiculous like 5 grand,if they're both by PCI-SIG).

Octocontrabass wrote:

Ethin wrote:And finally, 2) All of the commands that take "count" as an "argument" to them indicate that 0000h is 256 sectors (for LBA28) and 65536 sectors (for LBA48), and that "count" indicates how many sectors to "<insert action here>". Is a "sector" in this instance an actual LBA, and if so, would I just read 256*count words on the data port?

You'll wait for the drive to report that it's ready, then read (or write) one sector. Repeat these two steps for however many sectors you've told the drive you're going to read (or write). The sectors will be sequential, starting from the LBA you indicated when you sent the command. Don't assume that sectors will always be 256 words, it's 2020 now and drives with 4kB sectors (2048 words) are common.

The latest command set (ATA8-ACS4) has marked it obsolete, but prior versions describe the READ MULTIPLE and WRITE MULTIPLE commands, which allow PIO transfers of more than one sector each time the drive reports it's ready. They're useful for speeding up PIO transfers when DMA is not available.

Again, thanks. And I know that not all drives are 256 words in length per sector, but that's what my QEMU HDD is; I'm working on making my code more flexible. So I would do sector size in words * count field inw/outw instructions, for example?
I suspect that read multiple and write multiple was removed because the DMA mode made things so fast that read/write multiple just became redundant. I wonder if it also might've made things slower when you were using ridiculously fast PCI DMA already? I mean, if your using Read/Write Sector(s) Ext DMA, you can simply wait for the disk to be done returning data to you, which presumably didn't take long, and then you could just gather all of it and go on your way.
Edit: removed my question on drafts and purchased docs.

Ethin wrote:Thanks. Could you link me to the latest drafts of those specifications? I definitely can't buy any of the PCI specs (the hardcopies are something ridiculous like 5 grand,if they're both by PCI-SIG).

Here is a PDF of the PCI IDE Controller Specification and here is a PDF of the Programming Interface for Bus Master IDE Controller.

Ethin wrote:So I would do sector size in words * count field inw/outw instructions, for example?

Only if the count is small enough to fit within the current multi-sector transfer size. If it's bigger, you have to treat it like you're transferring very big sectors, each one being sector size * multi-sector transfer size. If the count doesn't evenly divide into the multi-sector transfer size, the last transfer will be smaller than the others.

In order to use the READ/WRITE MULTIPLE commands, you first have to ensure they're available and enabled through IDENTIFY DEVICE words 47 and 59. If necessary, you can enable it or change the transfer size using the SET MULTIPLE MODE command. Only powers of 2 are allowed for the transfer size.

Thanks for those. Final question: if I'm reading or writing a file that's not <sector size> words, how would I set the count field? Would I just set it to the next word value (for example, if the file is 8.2 words, would I just set the count to 9) and then pad the rest with NULLs, or would FS structures take care of that? Lets assume that I've decided to use read/write sector(s) ext (in either PIO or DMA mode) (since I have interrupts off) for this example.

You probably want your disk driver to handle only whole sectors, and let the filesystem driver figure how to turn sectors into files. IDE lends itself pretty well to manipulating the data while it's being read, but other block storage interfaces do not. If you support it in your IDE driver, you'll have to support it in your other block storage drivers too.

You probably also want to use interrupts. Polling the disk wastes a lot of time.