Logical view of IDE, ATA, and Bus Master DMA

[dmatlack]

Since this is my first post, I'll give a quick run down of where I'm at in my project. I am in the process of writing a 32-bit, protected mode, kernel for the x86 architecture. The kernel is monolithic and so far I have implemented exception handling, IRQ handling, PIT, physical memory frame allocator, virtual memory (still in the works, lower-half kernel), kernel heap manager, basic console driver, PCI bus scanning, and basic ATA support (IDENTIFY DEVICE, SET FEATURES). I have written the ATA part of DMA but not the Bus Master part or interrupt handling (or really any of the hard stuff ) yet.

So I'm having trouble understanding how a few of the pieces fit together. I will try to describe things as I see them and see if it makes sense.

An ATA drive is a physical disk like a hard drive or CD-ROM. ATA drives are (always?) paired in a master-slave configuration. They both share the same IRQ and I/O ports. Each ATA drive has its own on-board controller. When we send commands to one of the drives, we select a drive using the DEVICE register as detailed in the ATA spec. My guess here is that the commands get sent to both drives but will be ignored by the not-selected drive. Can I refer these two ATA drives as being connected by an ATA bus?

So ATA buses also seem to come in pairs, and are referred to as primary and secondary. The primary and secondary buses do not (never?) share IRQs or I/O ports. Now when I do I a PCI scan, these two buses show up together as a single IDE Controller device (00:01.01 Intel 82371SB IDE Controller). This confuses my because I though IDE was just another name for "ATA-1"? What actually is this IDE controller? What does it do?

Last is Bus Master DMA. Who is actually doing the Bus Master DMA? Is it this IDE Controller? I know that I am reading the bus master base address out of BAR4 of my IDE PCI device configuration space (so it seems to be tied to the IDE controller), but is it unique to the IDE Controller? Is Bus Master DMA a property of IDE or PCI or what (it doesn't seem to be a part of ATA because the ATA spec only provides a way to get a drive ready for a DMA transfer, but not actually do it)? My guess is IDE because there are primary and secondary bus master I/O registers which matches setup of the ATA buses.

I guess most of my confusion comes from the uses of the terms "IDE Controller", "ATA", "ATA Controller", etc. (Intel's http://www.srcf.ucam.org/piipkernel/git ... r_spec.pdf says that "ATA Controller" means "Bus Master IDE Controller" ... what?).

Thanks for your help .

[Owen]

Since this is my first post, I'll give a quick run down of where I'm at in my project. I am in the process of writing a 32-bit, protected mode, kernel for the x86 architecture. The kernel is monolithic and so far I have implemented exception handling, IRQ handling, PIT, physical memory frame allocator, virtual memory (still in the works, lower-half kernel), kernel heap manager, basic console driver, PCI bus scanning, and basic ATA support (IDENTIFY DEVICE, SET FEATURES). I have written the ATA part of DMA but not the Bus Master part or interrupt handling (or really any of the hard stuff ) yet.

So I'm having trouble understanding how a few of the pieces fit together. I will try to describe things as I see them and see if it makes sense.

An ATA drive is a physical disk like a hard drive or CD-ROM. ATA drives are (always?) paired in a master-slave configuration. They both share the same IRQ and I/O ports. Each ATA drive has its own on-board controller. When we send commands to one of the drives, we select a drive using the DEVICE register as detailed in the ATA spec. My guess here is that the commands get sent to both drives but will be ignored by the not-selected drive. Can I refer these two ATA drives as being connected by an ATA bus?

Pretty much. The first ATA implementations (in the IBM PC/AT) were essentially just the ISA bus ran out onto a ribbon cable. It advanced a bit since then.

"Master" and "slave" are incorrect but unfortunately common nomenclature. Just think of it as a pair of devices on one cable

The thing to keep in mind is that before ATA (that is, for HDDs plugged into original PC and PC XT machines), the drive electronics were separate (on an addon card) and connected by a bunch of cabling to one or two drives. The integrated device electronics, in the ATA case, were made to match this interface for compatibility.

So ATA buses also seem to come in pairs, and are referred to as primary and secondary. The primary and secondary buses do not (never?) share IRQs or I/O ports. Now when I do I a PCI scan, these two buses show up together as a single IDE Controller device (00:01.01 Intel 82371SB IDE Controller). This confuses my because I though IDE was just another name for "ATA-1"? What actually is this IDE controller? What does it do?

The terms IDE and ATA get confused a lot because at the time of its' introduction ATA (AT Attachment) was by far the most common implementation of IDE (Integrated Device Electronics) (Another being SCSI).

The terms (in this context) are roughly interchangeable

Last is Bus Master DMA. Who is actually doing the Bus Master DMA? Is it this IDE Controller? I know that I am reading the bus master base address out of BAR4 of my IDE PCI device configuration space (so it seems to be tied to the IDE controller), but is it unique to the IDE Controller? Is Bus Master DMA a property of IDE or PCI or what (it doesn't seem to be a part of ATA because the ATA spec only provides a way to get a drive ready for a DMA transfer, but not actually do it)? My guess is IDE because there are primary and secondary bus master I/O registers which matches setup of the ATA buses.

Bus master DMA is a property of the bus - that is, yes, PCI in this case. Contrast things like ISA, which have a separate DMA controller chip which manages the DMA on behalf of the device.

Indeed, back in the days when ATA was connected to the ISA bus, you would setup the ISA DMA controller for a transfer, then issue the same commands to the device to get it ready for DMA transfer, and then the ISA DMA controller would go and do the transfer for you. PCI doesn't have a designated DMA controller (because they're limited and problematic), so in the case of an ATA controller it sits in the middle, mediating transfers from the drive to memory.

Be aware that most SATA controllers these days are configured in (legacy incompatible) AHCI mode, which provides extra features at the cost of extra complexity. On the plus side, AHCI is a common standard all SATA controllers use (unless they're operating in legacy ATA compatibility mode, in which case they're pretending to be an older parallel ATA controller).

[dmatlack]

Thank you!

[rdos]

I wouldn't put down a lot of time on the now more or less obsolete ATA interface, and would do the transfer with PIO instead, simplifying the process a lot. Then I would implement the real thing (bus mastering) for AHCI instead.

Also, PCI ATA discs doesn't need to use the legacy addresses, or the primary-secondary scheme. Rather, you discover their base-addresses and IRQs through PCI instead.

[dmatlack]

I've decided to get multitasking working before trying to implement a dma/blockio layer.

Also, PCI ATA discs doesn't need to use the legacy addresses, or the primary-secondary scheme. Rather, you discover their base-addresses and IRQs through PCI instead.

The Intel PIIX IDE controller wasn't reporting IRQs through PCI (only bus master base address via BAR4), but assuming the conventional IRQs (14&15) was working during my time on ATA.

Thanks for the tip on AHCI. I'll be sure to look into it once I'm ready to start talking to disks (and reading long specifications) again!