Date: Fri, 25 Aug 1995 18:19:39 -0500 From: Jon Loeliger <jdl@chrome.onramp.net> To: freebsd-current@freebsd.org Subject: That IDE CD ROM thang again... Message-ID: <199508252319.SAA21812@chrome.onramp.net>
next in thread | raw e-mail | index | archive | help
Well, I was never able to get my wdc1 controller recognized at all.
Don't know why yet.
However, with some cable re-routing, I placed the CD ROM on wdc0
as the slave device and I got:
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
wdc0: ATAPI hard disks not supported
Turns out, I *did* have to byte-pair shuffle the ID string in order
to get real "english"here.
Naturally though, it's not a hard disk. Apparently the "type" of
device is returned from an insw() call, vaguely like:
char tb [DEV_BSIZE];
/* Obtain parameters. */
insw (port + AR_DATA, tb, sizeof(tb) / sizeof(short));
ap = malloc (sizeof *ap, M_TEMP, M_NOWAIT);
bcopy (tb, ap, sizeof *ap);
return (ap);
Just after that we use ap->devtype, expecting it to be AT_TYPE_DIRECT
(hard disk) or AT_TYPE_CDROM.
Where can I find the description of what should be coming back from
the insw() call to determine why it's not a CDROM drive? Sure I see:
struct atapi_params {
unsigned devtype : 5; /* packet command size */
#define AT_TYPE_DIRECT 0 /* direct-access (magnetic disk) */
#define AT_TYPE_TAPE 1 /* streaming tape (QIC-121 model) */
#define AT_TYPE_CDROM 5 /* CD-ROM device */
#define AT_TYPE_OPTICAL 7 /* optical disk */
}
But it looks like the insw() causes the devtype to be a lie somehow...
The obvious serious hack is to slam ap->devtype to be AT_TYPE_CDROM at
some point, but that doesn't strike me as being reliable or long term.
Anyone fix this or get further?
Thanks,
jdl
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508252319.SAA21812>