OSDev.org

Hi dudez. I just thought it could interrest some of you. I'm actually doing researchs on how Ultra DMA (fast access to IDE disks without the intervention of the CPU for transferring bytes from the disk to the memory or vice-versa :p ) works and how it can be enabled.

Here's are my results so far:

• whether UDMA is supported or not, and which mode (thus which speed) is supported is defined in the "ATA Indentify" block you get in response of command 0xEC, at the word #88 if it was valid in extensions list word (#53) .
  Information on the ATA identify can be found at
  T13 AT-Attachment working group. You can get ready-to-use ATA identify structure at Clicker CVS (ata.h) or on Mobius CVS (ata.c).
• The IDE controller itself can't control the Ultra DMA transfer: it requires the assistance of the IDE BusMaster component, which is a part of your chipset (PIIX4 chip, according to the informations i own), and actually appears as a separate PCI device. So in order to enable Ultra DMA, you first need a PCI enumeration feature. A tutorial about PCI enumeration is available in Clicker's teacups, written by S.Rajeev
• Once the enumeration is available, you will scan for class code 01(storage):01(ide):80(busmaster) in your devices tree. In the pci configuration function of this device, you have some interresting registers like the BusMaster Interface Base Address (at offset 0x20), which allows you to set up in which I/O location you'll access the Busmater. How the IO location is chosen is still under research.
• Another interresting register is UDMA-enable register (offset 0x48 in configuration space) which has one bit per hdd. I hope src/linux/drivers/ide/ide-dma.c will tell me a bit more about this ...
• Once you get your busmaster activated and gave it a base address, you have at that base address 8 I/O ports for each controller (xxx0 - xxx7 is for primary, xxx8 - xxxf for secondary). The structure of each block is:
  [table]
  [tr][td]0[/td][td]8bits[/td][td]command byte[/td][/tr]
  [tr][td]2[/td][td]8bits[/td][td]status byte[/td][/tr]
  [tr][td]4[/td][td]32bits[/td][td]descriptor table base address[/td][/tr]
  [/table]
  DMA operation is programmed by writing direction and start bits in the command byte. (thus outb(udma_base,1) for a read and outb(udma_base,9) for a write.
• The place in memory where the DMA transfer is performed is described by the Descriptor Table. The physical address of that table must be loaded in udma_base+4 before the transfer begins. The structure of that table is unknown by your humble servant so far.

Hope it helps More info to come when i'll be done.
Oh, btw, so far, i have the feeling that BOCHS doesn't support UDMA operations, so it will be for my |<r@$|-| machine to test

hmmm ... from reverse-engineering of linux "ide-dma.c", it appears that the 'descriptor table' is made of 2x32bits entries. The first dword in each entry is the dma address of the chunk and the second dword is actually used on 16bits only and is the size (highest bit of the size is the termination bit). Note that chunks may not cross a 64Kb barrier (as far as i know) and may not be larger than 64KB either. A 0x0000 size is usually representing a full 64KB size, but some controllers misinterprete this as a 0 size, so linux split all 64K chunks in 2 32K chunks on the fly.

-- update --
intel Chipset datasheet confirms the Physical Region Descriptor Format.


I have trouble finding out how one actually access the PCI configuration space. i know I/O ports 0xCF0..0xCFF are involved, but i don't know neither how nor which one exactly ... What is usually presented as memory-mapping configuration space looks like not being mapped at all ??...

Tim or anybody else that has worked on PCI already, if you have some docs reference ...

-- update --
this article seems to hold good info about how to access the PCI configuration space.

okay. so obviously, access to PCI configuration space is made by writing the configuration address (made of bus, device, function numbers plus offset for that function -- see above proposed PDF link) to port 0xCF8 and then reading/writing the data from port 0xCFC (watch out sideeffects like security holes in ozone layer :p )