Date: Mon, 28 Aug 1995 17:25:51 -0500 From: Jon Loeliger <jdl@chrome.onramp.net> To: freebsd-hackers@freebsd.org Subject: ATAPI CDROM 1.3 update Message-ID: <199508282225.RAA03354@chrome.onramp.net>
next in thread | raw e-mail | index | archive | help
Thanks for the update to the ATAPI code. I've applied the 1.3 update,
and it seems to be a good partial solution so far.
It looks like it fixes the byte-swap for the ident string, allows it
to be treated like a CD ROM, but doesn't get much further than that.
Notice that this is still essentially the same problem with the
double-command that we'd seen before too:
wdc0 at 0x1f0-0x1f7 irq 14 on isa
wdc0: unit 0 (wd0): <WDC AC31000H>
wd0: 1033MB (2116800 sectors), 2100 cyls, 16 heads, 63 S/T, 512 B/S
atapi0.1 at 0x1f0: attach called
wdc0: unit 1 (atapi): <NEC CD-ROM DRIVE:260>, removable, cmd16
wcd0: info 85-80-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-20-20-20-20-20-20-20-20-20-20-20-20-20-20-20-20-20-20-20-20-0-0-0-0-0-0-2e-34-33-32-20-20-20-20-4e-45-43-20-20-20-20-20-20-20-20-20-20-20-20-20-20-20-20-20-43-44-2d-52-4f-4d-20-44-52-49-56-45-3a-32-36-30-0-0-0-0-0-0-0-0-a-0-0-0-3-0-0-0-0-3-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-b4-0-b4-0-0-0-0-0-0-0-0-0-0-0
atapi0.1: req im 5a-0-2a-0-0-0-0-0-18-0-0-0-0-0-0-0 len=24
atapi0.1: start
atapi0.1: send cmd 5a-0-2a-0-0-0-0-0-18-0-0-0-0-0-0-0
atapi0.1: intr ireason=0x1, len=24, status=48<ready,drq>, error=0
atapi0.1: send cmd 5a-0-2a-0-0-0-0-0-18-0-0-0-0-0-0-0
atapi0.1: intr ireason=0x3, len=24, status=41<ready,check>, error=64<abort>
I sent some mail to Scott Snyder, SNYDER@D0SB10.FNAL.GOV, asking
about the lovely NEC 260. (He appears to be the Linuxian who wrote
the ATAPI for the other camp.) He said:
> Well, you can look at my linux atapi driver (drivers/block/ide-cd.c),
> which works with the 260. The flags no_playaudio12, old_readcd, and
> msf_as_bcd get set for the 260.
Yep, watch that last one: MSF needs to be encoded as, get this, BCD!
I couldn't find the old_readcd or msf_as_bcd flags anywhere.
The no_playaudio12 was an "i've been here before and it didn't work
then either" detection to force the msf_as_bcd behaviour.
OK, I can hack that in if needed. Serge, do you know if this is already
done? The code from the other camp had:
cdrom_play_lba_range (ide_dev_t *dev, int lba_start, int lba_end)
{
/* This is rather annoying.
My NEC-260 won't recognize group 5 commands such as PLAYAUDIO12;
the only way to get it to play more than 64k of blocks at once
seems to be the PLAYAUDIO_MSF command. However, the parameters
the NEC 260 wants for the PLAYMSF command are incompatible with
the new version of the spec.
So what i'll try is this. First try for PLAYAUDIO12. If it works,
great. Otherwise, if the drive reports an illegal command code,
try PLAYAUDIO_MSF using the NEC 260-style bcd parameters. */
if (CDROM_FLAGS (dev)->no_playaudio12)
return cdrom_play_lba_range_msf (dev, lba_start, lba_end);
else
{
int stat, stat2;
struct atapi_request_sense reqbuf;
stat = cdrom_play_lba_range_play12 (dev, lba_start, lba_end);
if (stat == 0) return 0;
/* It failed. Try to find out why. */
stat2 = cdrom_request_sense (dev, &reqbuf);
if (stat2) return stat;
if (reqbuf.sense_key == 0x05 && reqbuf.asc == 0x20)
{
/* The drive didn't recognize the command.
Retry with the MSF variant. */
printk ("%s: Drive does not support PLAYAUDIO12; "
"trying PLAYAUDIO_MSF\n", dev->name);
CDROM_FLAGS (dev)->no_playaudio12 = 1;
return cdrom_play_lba_range_msf (dev, lba_start, lba_end);
}
/* Failed for some other reason. Give up. */
return stat;
}
}
static int
cdrom_play_lba_range_msf (ide_dev_t *dev, int lba_start, int lba_end)
{
struct packet_command pc;
memset (&pc, 0, sizeof (pc));
pc.c[0] = SCMD_PLAYAUDIO_MSF;
lba_to_msf (lba_start, &pc.c[3], &pc.c[4], &pc.c[5]);
lba_to_msf (lba_end-1, &pc.c[6], &pc.c[7], &pc.c[8]);
pc.c[3] = bin2bcd (pc.c[3]);
pc.c[4] = bin2bcd (pc.c[4]);
pc.c[5] = bin2bcd (pc.c[5]);
pc.c[6] = bin2bcd (pc.c[6]);
pc.c[7] = bin2bcd (pc.c[7]);
pc.c[8] = bin2bcd (pc.c[8]);
return cdrom_queue_packet_command (dev, &pc);
}
However, i'm willing to bet we're not anywhere near this code yet... :-)
It still looks like it might be a variant on which flags are set
and what the floating state of the status register is.
I can compile this with much more detailed debug tracing if needed...
jdl
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508282225.RAA03354>