From owner-freebsd-hackers Mon Aug 28 15:26:23 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id PAA02470 for hackers-outgoing; Mon, 28 Aug 1995 15:26:23 -0700 Received: from chrome.onramp.net (chrome.onramp.net [199.1.166.202]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id PAA02461 for ; Mon, 28 Aug 1995 15:26:08 -0700 Received: from localhost.jdl.com (localhost.jdl.com [127.0.0.1]) by chrome.onramp.net (8.6.11/8.6.9) with SMTP id RAA03354 for ; Mon, 28 Aug 1995 17:25:52 -0500 Message-Id: <199508282225.RAA03354@chrome.onramp.net> X-Authentication-Warning: chrome.onramp.net: Host localhost.jdl.com didn't use HELO protocol To: freebsd-hackers@freebsd.org Subject: ATAPI CDROM 1.3 update Reply-To: jdl@chromatic.com Date: Mon, 28 Aug 1995 17:25:51 -0500 From: Jon Loeliger Sender: hackers-owner@freebsd.org Precedence: bulk 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): wd0: 1033MB (2116800 sectors), 2100 cyls, 16 heads, 63 S/T, 512 B/S atapi0.1 at 0x1f0: attach called wdc0: unit 1 (atapi): , 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, 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, error=64 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