Date: Mon, 28 Aug 1995 00:43:28 -0500 From: Jon Loeliger <jdl@chrome.onramp.net> To: freebsd-hackers@freebsd.org Subject: ATAPI Message-ID: <199508280543.AAA00248@chrome.onramp.net>
next in thread | raw e-mail | index | archive | help
OK, So where can I get a copy of the ATAPI spec? Does anyone
on this list have (or know where to find) one on line?
(Any vague chance of finding one specifically for the NEC 260?)
Specifically, I guess I'd like to be able to interpret the
command buffers, and know what the handshakes and protocols
are supposed to be.
As Joerg pointed out, the entire buffer from the probe attempt
does appear to need to be byte-swapped. This fixes both the
ident string problem and the devtype == AT_TYPE_CDROM problem.
I've permuted an endless set of byte swapping on all the insw()
and outsw() operations I can find in atapi.c, but I've clearly
not yet stumbled onto the magic incantation.
Also, as Steve Schwarz pointed out earlier, I too have this problem:
> [4] Yet again, in the atapi.c file, I am having problems that I don't
> know even a brutal hack for. (Help!) Here is what occurs.
> wcdattach() calls atapi_request_immediate() with an ATAPI_MODE_SENSE
> command. The latter makes it as far as the second call of atapi_io()
> in this fragment:
--------------------------------------------------------------------
if (atapi_start_cmd (ata, ac) >= 0 && atapi_wait_cmd (ata, ac) >= 0) {
/* Send packet command. */
atapi_send_cmd (ata, ac);
/* Do all needed i/o. */
while (atapi_io (ata, ac))
/* Wait for DRQ deassert. */
for (cnt=2000; cnt>0; --cnt)
if (! (inb (ata->port + AR_STATUS) & ARS_DRQ))
break;
}
------------------------------------------------------------------------
> The first call of atapi_io() thinks it is in PHASE_CMDOUT, so it ends
> up calling atapi_send_cmd() again. (I can't really tell if that is
> right or wrong.) The second call of atapi_io() fails, because the
> atapi_wait() call at the top fails with "controller not ready". And
> that, unfortunately, is it. (I tried increasing the time that
> atapi_wait() waits, but this did not help.) I can make the full (i.e.
> DEBUG defined) output of the atapi driver available to anyone who
> thinks it could help them figure out what is happening.
I went so far as to comment out the atapi_send_cmd() here in
atapi_request_immediate() and let it happen as a course of action in
atapi_io(). This *appears* to correctly issue the command only once now.
I'm not the least bit convinced that this is the *right* atapi_send_cmd()
to allow to happen. Ie, do we sort of get into an out-of-sync situation
in the phase state machine?
However, I still see atapi_io() failing due to the atapi_wait() call
returning error. The reason for this is apparently that the desired
ARS_DRQ bit is never asserted during atapi_wait(). (These bits are
wanted because the ac->count > 0.)
I *think* all this might be translated into English as:
In an effort to determine the capailities of the drive, the
MODE_SENSE command is issued and expects 24 bytes in response
from the drive. When the drive responds with the 24 bytes,
I think the PHASE state machine doesn't recognize that it's
getting a response to the command back and tries to send the
command again.
Serge are you out there? Can you help us out some please?
Feh. Maybe it's bedtime for a bit...
jdl
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508280543.AAA00248>