Date: Fri, 15 Sep 1995 18:15:22 -0500 From: Jon Loeliger <jdl@chrome.onramp.net> To: Josh Littlefield <josh@American.COM> Cc: current@freebsd.org Subject: More ATAPI CD issues, and some old ones too! Message-ID: <199509152315.SAA08077@chrome.onramp.net> In-Reply-To: Your message of "Fri, 15 Sep 1995 18:37:04 EDT." <199509152237.SAA19750@mozart.american.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Apparently, Josh Littlefield scribbled:
> > Hmm. Not sure I agree here. My POS NEC 260 fails this test badly.
> > Not sure why. I (w)hacked it out to get even vague functionality...
>
> Wow. Writable byte count registers are pretty much mandatory for atapi to
> work at all, since they are the way of communicating ATAPI packet sizes and
> data lengths.
Yea, I believe it is writable, but...
> The best explanation I can think of is that this is not really a good test.
Right.
> I'm not sure there is really any guarantee that this register will read the
> same as its written. For ATAPI, one writes it to indicate the size of data
> desired to be read or written. One reads it AFTER SENDING A PACKET COMMAND,
> and when BSY is gone to find out about the subsequent device needs for data
> transfer. Even the length of time the register is supposed to contain info
> the device has generated is only until the first data register access.
>
> Other parts of the spec indicate that the device should place its "signature"
>
> (0xEB14) in the cnt_hi/lo registers and maintain it until the first ATAPI
> command is recieved, which might explain the need to generalize this test to
> checking for != 0xFF after the write. All in all, sounds like a bogus "test"
>.
And in hackers, Bruce added to the fray:
> jdl wrote:
> >So who can tell me any details about that lovely weak check for R/W
> >registers that appears to be failing for me? Simple things like:
>
> > - Is this a valid register for a CDROM drive too? Ie, is this check
> > tacitly assuming a hard disk beneath it?
> > - Is it subject to timing problems?
> > - It *claims* to be "too weak", however it appears to be too strong!
>
> It's too weak for ST506...EIDE controllers with normal drives attached.
> These all have read/write registers, so the inb() should return what
> was written. That used to be tested for, but someone weakened the
> test without documenting why. I don't know what happens for CDROM
> drives.
>
> The point of the test is to attempt to limit the damage if there is
> a device other than an ST506...EIDE controller behind the port. It
> is far too weak for that (if 0xff wasn't so magic, then the test
> would have much less than a 1/256 chance of detecting conflicts).
> Even if it tested for `== 0xa5', then any device with a read/write
> port at the probed address would pass the test.
>
> The test is very sloppy. It should do something like:
>
> int
> is_rw_port(port)
> u_int_port;
> {
> u_char in1, in2, was;
>
> DELAY(5);
> was = inb(port);
> DELAY(5);
> outb(port, 0xa5);
> DELAY(5);
> (void)inb(0x20); /* attempt to eliminate bus echoes */
> DELAY(5);
> in1 = inb(port);
> DELAY(5);
> outb(port, 0x5a);
> DELAY(5);
> (void)inb(0x20);
> DELAY(5);
> in2 = inb(port);
> DELAY(5);
> outb(port, was);
> DELAY(5);
> return (in1 == 0xa5 && in2 == 0x5a);
> }
> ...
> if (!is_rw_port(du->dk_port + wd_cyl_lo))
> goto nodevice;
>
> Then the test would be stronger and your CDROM would be sure to fail :-).
Leave it Bruce to be succinct on that final point... :-)
So, I'm not sure what to do there yet... If this suddenly clears up,
feel free to let me know!
Also, it appears that the NEC-260 might have been available before the
spec gelled, so I'm apt to expect it to be a tad out of spec with respect
to the ATAPI spec.
> > Hmm.. You may need Serge's latest and greates patch that I alude to above.
> > With minor work, I could dredge this up for you if you don't have it.
>
> I don't have this, and it doesn't appear that -current does either. Could
> you send it?
Check. Sent separately to only Josh. If this should be commited, we need
to find a committer for it.... Serge may have it wrapped and ready to go too.
Dunno.
> >From some behavior I've noticed where the drive gets stuck in an aborted
> command state (and stays there across a reboot),
Ick. Maybe that's part of the reason for the "reset test"?
jdl
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509152315.SAA08077>