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.