views:

399

answers:

2

RESOLVED

After much confusion and frustration, I finally got my hard disk to interrupt. :D It basically came down to the fact that I kept reading the status register instead of the alternate status register. A few other things were messed up to boot, but the point is my hard disk driver is finally starting to take shape. Now, for others I will leave the original post.

P.S. For further clarification, I didn't need to issue any sort of reset command. All I did was the following:

  1. Select the device (didn't want to kill the Solaris OS on the other disk)
  2. clear the nIEN bit in the DEVICE CONTROL register
  3. issue an IDENTIFY DEVICE command***

Actually, I am not sure if the IDENTIFY DEVICE command is need because I left the lab happy before I could test the code without issuing the command. However, the main point is that I needed to be sure to read the alternate status register and have the nIEN bit cleared without the need for a reset. The BIOS apparently takes care of most stuff.


I am currently trying to write a disk driver for a hobby OS being developed at my school. I currently have routines to read/write data in the PCI configuration space and assembly routines to do port IO with the various registers defined by ATA/ATAPI-7. Now, my question is, specifically how will I get an IDE hard drive to start generating interrupts? I have been looking through all this documentation and is hasn't become clear to me what I am doing wrong.

Can someone explain exactly what causes an IDE hard drive to start generating interrupts? I already have an interrupts service routine ready to test, but am having difficulty getting the interrupts in the first place. Can this be accomplished through the ATA SOFT RESET?

Thanks!

UPDATE: Ok, I was able to get the secondary channel, an ATAPI CDROM to generate interrupts by setting the SRST bit in the DEVICE CONTROL register for a soft reset. This does not work for the hard disk on the primary channel. What I have noticed so far is that when I set the SRST bit for the HDD, it sets the BSY bit and leaves it set. From there I don't know what to do.

+1  A: 

if this is just a hobby OS, why not use the BIOS interrupt (int 13h)? admittedly not as fast as direct disk access but safer for your hard drive (I've put a read head through a plate before messing with disk I/O).

Scott Herbert
I was thinking about that at first, but wanted to be able to access the disk in protected mode.
TURBOxSPOOL
It is poss. to call int 13h from protected mode, I think you have to play-a-round a bit... This may be wrong, but I think you run your int 13h call in ring0 and call that from your ring3 IIRC this is what M$ does with the HAL.
Scott Herbert
+3  A: 

This reference should help you a fair bit: Kenos description of programming ATA/ATAPI.

The basic mechanism to enable interrupts is to clear nIEN in the DCR (Device Control Register):

nIEN: Drive Interrupt Enable bit. The enable bit for the drive interrupt to the host. When nIEN is 0 or the drive is selected the host interrupt signal INTRQ is enabled through a tri state buffer to the host. When nIEN is 1 or the drive is not selected the host interrupt signal INTRQ is in a high impedance state regardless of the presence or absence of a pending interrupt.

This www.ata-atapi.com is a good jumping-off point to find way more info about ATA/PATA/SATA/ATAPI than you want to know... Note that the official ATA-6/7/etc specs cost $$ from T13, though you can download current drafts of ATA-8 from them.

This link describes a few of the many ways ATA devices vary from the specs. (I used to write SCSI and ATA/ATAPI drivers for Commodore/Amiga, way back when, as well as help with qualifying drives - or more accurately, figuring out what idiocies drive makers had done.)

jesup
Thanks for the great post! Even though I think my problem came down to reading the status register (which clears interrupts) instead of the alt. status.
TURBOxSPOOL
Yup, you need to be careful with those reads. Glad it helped
jesup
Yea, thats for sure!. I must say this disk driver project is easily the most rewarding and complex project I've worked on in college. It's easy to realize why we started programming a simple serial device last quarter, as something like this is much, much more complex.
TURBOxSPOOL