OSDev.org

I was confused by the IDE Controller Registers in ICH5(82801EB) and the traditional IDE I/O port, such as 0x1F7,0x3F6,etc. these days.
I can read some sectors data from the IDE disk through the I/O port R/W operation. Than's no problem.
But now, I read the ICH5 datasheet, I found a IDE Controller Registers is integrated into the ICH5 as a PCI device(device:31,function:1), in its configuration space, there are some registers such as :Primary Command Block Base Address,Primary Control Block Base Address, etc.
So my question is: if I want to write a IDE disk drivers in a PC which has a ICH5 in its mother board, then which kind of method I should use to operate upon the IDE disk, through the traditional I/O port or through the pci mechanism?
Also I don't know what's relation between the pci IDE controller registers and the I/O port, and if I want to use the pci IDE controller registers to read a sector from the disk, then which register can be used to put the sector address(C/H/S) parameter?
I am completely confused by these questions? HELP ME!!
Thanks

As I understand it when you boot up you'll have to poll the PCI bus to determine the I/O ports that each bus uses. You can also get other information like does the drive run with LBA or CHS. You can determient he transfer speeds and set a few others attributes as well. So:

First) poll PCI for the class and sub-class of the device.

Second) Check to see if it is your device (or a generic, or other) is there.

Third) Get the information for the device from the PCI so that you may use it.

Foruth) Initialize your code to use the device.

Fifth) Use it...

I realize this is top level, but I think this is what you were asking?

I think you can always R/W a Hard Disk with the standard IDE interface in your system through the standard I/O port such as 0x1F0, 0x1F1...
But currently I don't know whether we can touch the same HD through the IDE Controller registers inside the ICH5, if that, then that menas we can operate the same HD with 2 methods, one is I/O port, one is pci-related mechanism, right?
I understand what you said, you mean that we can get the Command/Control block base address and other info from the pci configuration, then use the [base address + port offset] as the final I/O space address to access the real HW. I think maybe you are right, but now I am not sure about that.

BTW: IDE controller registers in ICH5 tell us that there are 8 consecutive I/O locations based on the Command block base address, I think from offset 0 to offset 7 are the I/O space corresponding to the I/O port from 0x1F0 to 0x1F7, but how about the 4 consecutive I/O locations based on the Control block base address, what are they?

Are there more hints here?

cxsnew wrote:
But currently I don't know whether we can touch the same HD through the IDE Controller registers inside the ICH5, if that, then that menas we can operate the same HD with 2 methods, one is I/O port, one is pci-related mechanism, right?

...but how about the 4 consecutive I/O locations based on the Control block base address, what are they?

Are there more hints here?

I looked up ATA-6 specification today, I find it's not a problem about the offset address of Command registers and Control registers within the corresponding ICH5 pci IDE Command registers base address and Control registers base address.
But the same confusion is still there: Can we access the same Hard disk through the pci-related mechanism?
In Linux box which have a ICH5 chip, I found that the I/O space range of pci IDE device is 0xfc00~0xfc0f, so does that mean the I/O space address of data register in ATA specification is 0xfc00?

From what I understand, in the PCI specs the HD can be in 2 modes native mode i.e. the usual ports or in PCI mode. in PCI mode the ports can be relocated. There should be no confusion, its still the same HD just that in PCI mode the ports can be relocated (or mapped etc)
Thats my understanding.

humm ... surprisingly enough, when i google for 82801EB, i hit a AC97-related chip datasheet ...

now, that being said, you can indeed always use the ATA-defined standard ports to access the ATA disks. The PCI device reports those ports only to keep consistent. In extenso, your disk controller *is* a PCI device that behaves like the good old disk controller, and if it's assigned non-standard ports, probably you should better flash your BIOS ...

If you wish to use Ultra-DMA transfers, however, you *need* the help of the PCI device as it will have to act as a PCI bus-master during the transfer (which the 'controller' itself cannot do, as ATA ignores the fact you're operating from a PCI bus)

HTH.

... oops. ignore the above thing about AC-97. looks like i was wrongly reading document 25275101 instead of 29860004

, Oh my, Code Slasher's answer just make me have a bit understanding, but Pype's comments make me confusion again!
especaily for the following highlight line:

Pype.Clicker wrote:
The PCI device reports those ports only to keep consistent. In extenso, your disk controller *is* a PCI device that behaves like the good old disk controller, and if it's assigned non-standard ports, probably you should better flash your BIOS ...

If you wish to use Ultra-DMA transfers, however, you *need* the help of the PCI device as it will have to act as a PCI bus-master during the transfer (which the 'controller' itself cannot do, as ATA ignores the fact you're operating from a PCI bus)

It seems that you think one purpose of the IDE controller in ICH5 is just used to double check sanity of HD's I/O port.
In my pci enumeration codes, I read the Primary Command block base address registers and Control block base address registers, I got the value 0x01 for both above registers. That means BIOS doesn't allocate the I/O space for these register, but in Linux, I found the I/O space range is 0xfc00~0xfc0f by reading the /proc/pci.
And also, for the DMA operation of HD, I remeber that we can still use the DMA mode even not use the pci-related mechanism.
You guys(include me) had better to try operate the HD in your system by using the IDE controller in ICH5

sorry for the confusion. I had not found the correct datasheet while typing. After having check it (quickly, i have to admit), things looks more or less like what CodeSlasher described.

Your chipset has a 'IDE controller' part that can be controlled through the IDE function of the PCI device.

- in legacy mode: the chipset reacts to standard ATA ports (1F0-1F7, 3F6, IRQ14 and 170-177 376 IRQ15)
- in native mode, the address of the different blocks is controlled by the Base Address Registers of the PCI device/function.

If Native PCI operation is desired, each device can be independently enabled into this mode of operation by writing a 1 into its associated mode enable bit in the Programming Interface PCI configuration register.

It seems that the programming interface register (config space, byte at offset 9) of the device:function can be switched between 0x0a (legacy mode -- default at boot) and 0x0f (native mode). As the device was in legacy mode while PCI bios performed IO space assignment, it ignored the device ... if you turn it in native mode afterwards, *you*'ll be the one to give it addresses.

btw, my own chipset VT82C586B http://www.2ka.mipt.ru/~alexp/docs/hw/c ... a/586b.pdf seems to behave the same way

Thank you for your answer, and after these discussion, I think I get more details about the IDE operation in PC.
So the final conclusion is:
In modern PC with a IDE controller intergrated into the ICH chip, we can operate upon the IDE use 2 methods:
1)Legacy-PCI mode
2)Native-PCI mode

Some information from the ICH4(82801DB):
...
Programming Interface Register (IDE?D31:F1)
...
bit 1: POP_MODE_CAP ? RO. This read-only bit is a 1 to indicate that the primary controller supports
both legacy and native modes.
bit 0: POP_MODE_SEL ? R/W. This read/write bit determines the mode that the primary IDE channel is operating in.
0 = Legacy-PCI mode (default)
1 = Native-PCI mode