Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: [ata] wait_for_bsy vs. wait_for_rdy: ATA spec interpretation

[ata] wait_for_bsy vs. wait_for_rdy: ATA spec interpretation

From: Jonas Wielicki <j.wielicki_at_sotecware.net>
Date: Mon, 07 May 2012 18:21:06 +0200

Hi folks,

(heh, I hope this won't be too long, but its essentially just a short
question with a „bit“ of context)

I'm still messing with ATA code to debug further SSD issues. Now I
stumbled across what rockbox code does before command issuing. Basically
its like this:

(1) Select the device
(2) wait_for_rdy
(2a) wait_for_bsy (or return with error)
(2a.i) wait until STATUS_BSY is cleared (or timeout)
(2a) wait until STATUS_RDY is set (or timeout)
(3) Setup parameters and issue the command

(see firmware/ata.c, searching for ATA_SELECT for reference, its done at
several places)

However, ATA spec draft 5 (section 9.3, its at page 236 in the version I
have) has the following state graph for the bus idle mode (i.e. before a
command is being executed):

Check_Status:
    BSY = 0 & DRQ = 0 & wrong device selected
      => Device_Select
    BSY = 0 & DRQ = 0 & correct device selected
      => Write_parameters
    BSY = 1 or DRQ = 1
      => Check_Status
Device_Select:
    Device selected
      => Check_Status
Write_parameters:
    ... do command setup etc.

So the spec makes no statement about the RDY bit in the status register,
so we could be timing out here indefinetly under circumstances where the
RDY bit has *not* been set before or am I getting something wrong here?

The reason I'm looking so closely right now is that I get weird timeouts
which I tracked down to wait_for_rdy to fail after device selection.

So I'm just asking back because it seems like this should have lead to
issues before, except if my drive behaves significantly different from
all other drives used in rockbox players. I'm currently testing with
just waiting for BSY to clear, which does not give me issues until now
(however, thats no safe indicator, as the issues I have seem a bit racey).

Summarized:
(1) are we missing a subtle point in the ATA spec here?
(2) if so, why does it not cause errors with most (all) drives?
(2a) maybe due to numerous reset attempts which give RDY bits?
(2a.i) if so, why do these fail on my drive?

cheers,
Jonas
Received on 2012-05-07


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa