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>
index | next in thread | raw e-mail
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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508252319.SAA21812>