OSDev.org

Hi!

I'm currently implementing an AHCI driver. I've got IDENTIFY working in QEMU, so I decided to try out real hardware. Unfortunately, I've found numerous discrepancies between hardware implementations. On one of my machines, I can't run commands because the BSY flag is set immediately after the connection with the device is established. In turn, the CR flag never gets set and so the command engine never starts.

I've sent a COMRESET to that port and that resets the BSY flag temporarily, but it quickly gets reset by the controller once the connection with the drive is re-established. Has anyone else encountered a problem like this? I've read the specs, and AFAICT, the BSY flag shouldn't be set at least until a command is executed. Does anyone know why this is happening?

Thanks in advance.

I'm encountering the same problem with my board.
I see all registers is ok with one exception: GHC. In that register AE field (bit 31) is = not 1 as I expect.
In many other boards I found that bit setted, as I set Sata as AHCI in BIOS options.
Furthermore it's impossible to set GHC.AE when BSY equals 1.
What do you say about GHC register in your application? Is the same?
Have you found any solutions?

I recently had the same problem. I found a small note in the specs that seemed to indicate that you need to clear the PxSERR (port x SATA error) register for the HBA to update the PxTFD register with new values. I cannot find that note right now, after looking briefly again. But I had the exact same problem: AHCI driver worked perfectly in emulators, but not at all on real hardware. I added a bit of code to clear the PxSERR register at certain points, and then it worked on real hardware.

Since I cannot find that part of the specs, I don't know if this is just something that gets around the problem or not. Perhaps someone with more knowledge of AHCI can confirm or deny this?

-dB