disk Read Error with PIO method

[LIC]

Hi, I am currently trying to make my OS read disk sectors from the boot drive with I/O ports method. However there is something blocking me when running the Identify command.

To use the IDENTIFY command, select a target drive by sending 0xA0 for the master drive, or 0xB0 for the slave, to the "drive select" IO port. On the Primary bus, this would be port 0x1F6. Then set the Sectorcount, LBAlo, LBAmid, and LBAhi IO ports to 0 (port 0x1F2 to 0x1F5). Then send the IDENTIFY command (0xEC) to the Command IO port (0x1F7). Then read the Status port (0x1F7) again. If the value read is 0, the drive does not exist. For any other value: poll the Status port (0x1F7) until bit 7 (BSY, value = 0x80) clears. Because of some ATAPI drives that do not follow spec, at this point you need to check the LBAmid and LBAhi ports (0x1F4 and 0x1F5) to see if they are non-zero. If so, the drive is not ATA, and you should stop polling. Otherwise, continue polling one of the Status ports until bit 3 (DRQ, value = sets, or until bit 0 (ERR, value = 1) sets.

(from: https://wiki.osdev.org/ATA_PIO_Mode#Det ... ialization)

As said, after sending the identify command to port 0x1f7, I need to check ports 0x1f4 and 0x1f5 to see if they are still 0x00, if not then the drive is not ATA.
This works fine in Qemu (I am getting 0x00 on ports 0x1f4 and 0x1f5) and I am able to read disk sectors. However when I run my OS on a real machine this is what I get:

At first:
0x1f7: 0xd0
0x1f4: 0xd0
0x1f5: 0xd0

then after a slight delay (and forever):
0x1f7: 0x51
0x1f4: 0x14
0x1f5: 0xeb

I have non-zero values on ports 0x1f4 and 0x1f5, according to the wiki page that means that the disk is not ATA and that I should stop polling the 0x1f7 port. What does it actually mean that the drive is not ATA? What should I do next if I stop polling? What should I do to read disk sectors?

Note: After sending the identify command to port 0x1f7, I get interrupt 0x2e (irq 0x14).

Thanks in advance for your help, regards

[K3achas]

It most likely means that the drive is an ATAPI drive, not an ATA one. What media storage devices do you have in your testing computer? How are they connected to the computer?

[LIC]

Thanks for your reply.

It tested with a Hard Disk Drive connected to a SATA port on the computer and with a USB Drive connected to a 2.0 USB port and I get the same result with both.

[K3achas]

Your drive probably is an AHCI drive that doesn't support ATA. You'll need to write an AHCI driver (it uses the same commands as IDE based ATA, but has many more registers and a system that enables sending multiple commands at once. USB will use the USB mass storage protocol, but I don't know that one as well.

[Octocontrabass]

It tested with a Hard Disk Drive connected to a SATA port on the computer and with a USB Drive connected to a 2.0 USB port and I get the same result with both.

That's because you're not accessing the hard drive or the USB drive - you're accessing the CD drive.

You must write other drivers for SATA and USB. In order to write those drivers, you'll need a PCI driver so you can find the SATA/USB controller.

[LIC]

Okay, thank you for your replies. I hopped I could avoid this step (at least at that point of OS developing) but it seems like I have no choice haha

Regards

[BenLunt]

However when I run my OS on a real machine this is what I get:
then after a slight delay (and forever):
0x1f7: 0x51
0x1f4: 0x14
0x1f5: 0xeb

The 0xEB and 0x14 are the expected values for an ATAPI device. Also, if the BUSY bit is set, reading these registers will return undefined results (0xD0 being a common value read).

As mentioned, you have an ATAPI device attached to that port's controller.

Also, as mentioned, you might have an AHCI controller as well. To be backward compatible, the AHCI might start out as a standard ATA(PI) controller, only moving to the AHCI interface when a bit is set in one of the registers (GHC.AE), either by your driver or by the BIOS/Firmware. However, not all AHCI's have this feature, though most will.

One more thing, sending the IDENTIFY command to an ATAPI device will purposely fail so that you will then try the IDENTIFY_ATAPI command. Some ATAPI devices might fail if you don't send both in that order.

Ben
- http://www.fysnet.net/osdesign_book_series.htm

[LIC]

Okay, I'll try to check that as well. Thank you for your reply!