Date: Sun, 30 Oct 2005 21:17:04 -0600 From: Jason Harmening <jason.harmening@gmail.com> To: =?iso-8859-1?q?S=F8ren_Schmidt?= <sos@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Native ATAPI MO driver Message-ID: <200510302117.04602.Jason.Harmening@gmail.com> In-Reply-To: <08AD1F28-AE42-4C36-B5E0-3E909130BDB8@FreeBSD.org> References: <200510232049.16352.Jason.Harmening@gmail.com> <08AD1F28-AE42-4C36-B5E0-3E909130BDB8@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 24 October 2005 11:27, S=F8ren Schmidt wrote: > On 24/10/2005, at 3:49, Jason Harmening wrote: > > Hi, > > > > I have a 2.3G Fujitsu MO drive, and I've gotten tired of using > > atapicam to > > access it. I'm thinking of writing a native ATAPI driver that > > could be added > > to the kernel through a configuration line like: > > > > device atapimo > > > > I've been doing a little work to see how feasible this is--the > > kernel already > > defines the ATA_ATAPI_TYPE_OPTICAL device type that is received > > from my drive > > during probing. But ATA_ATAPI_TYPE_OPTICAL isn't actually used > > anywhere, and > > there is no driver that can actually recognize and attach to an > > ATAPI MO > > drive. > > > > I modified the atapifd driver (src/sys/dev/ata/atapi-fd.c) to also > > recognize > > ATA_ATAPI_TYPE_OPTICAL, and my drive was actually recognized during > > probing > > as afd0, but afd_attach returned an error. It looks as if afd_sense > > () was > > failing, which I'm guessing is because ATAPI MO drives (or mine, at > > least) > > use a different capabilities page code and/or capabilities page > > structure > > than ATAPI floppies. The atapi-fd driver uses 0x5 for its > > "Capabilities and > > Mechanical Status" page code, while everything else (atapi-cd, > > atapi-tape) > > uses 0x2a. All three drivers have distinctly different structures > > for this > > page. > > > > So I'm wondering: do ATAPI MO drives use a capabilities page code/ > > structure > > more like CD/DVD drives, or do they have their own unique ATAPI page > > structure? If so, where can I find a document outlining the > > structure? > > > > I've found loads of documents detailing the page structure for CD/ > > DVD drives, > > but nothing for MO drives (or floppies or tape drives for that > > matter). > > > > Also, beyond the capabilities page, are there any other special > > considerations > > I'd need to make for an MO driver? > > I did plan to write such a driver back when, but HW seemed to have > disappeared from all the vendors I've asked so it was pu ton the > backburner. > Anyhow I should have the docs somewhere so it should be possible to > get this working... > > S=F8ren Schmidt > sos@FreeBSD.org I finally managed to find some documentation from Fujitsu, and it turns out= my=20 drive (and older Fujitsu MO drives as well) use exactly the same capabiliti= es=20 page and page code that are already defined in atapi-fd.h. The reason my=20 drive was failing afd_sense() was that by default it returns an 8-byte bloc= k=20 descriptor between the header and the actual page. But there's a Disable=20 Block Descriptor bit at byte1, bit3 of the MODE SENSE command that will=20 prevent it from doing this if set. It looks like the ATAPI floppies and=20 earlier MO drives just ignored this bit and never returned the block=20 descriptor. So I just changed the second character in the command array in= =20 afd_sense() from 0 to 8, added ATA_ATAPI_TYPE_OPTICAL to afd_probe(), and t= he=20 drive now works as afd0. =46rom what I've seen, the DBD bit seems to be a standard part of the MODE = SENSE=20 command block, so I don't think having it set will mess with any of the oth= er=20 drives supported by atapifd. =20 Reading, writing, deleting, prevent/allow eject, and newfs (UFS2) all work= =20 with the drive as afd0--haven't tried anything else yet. =20 Jason Harmening
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200510302117.04602.Jason.Harmening>