From owner-freebsd-scsi Sat Feb 20 14:52:59 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id C9A1F119C0 for ; Sat, 20 Feb 1999 14:52:51 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.2/8.8.5) id PAA14683; Sat, 20 Feb 1999 15:52:48 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199902202252.PAA14683@panzer.plutotech.com> Subject: Re: IOCTL question In-Reply-To: from David Miller at "Feb 20, 1999 4:18:15 pm" To: dmiller@search.sparks.net (David Miller) Date: Sat, 20 Feb 1999 15:52:48 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David Miller wrote... > On Sat, 20 Feb 1999, Kenneth D. Merry wrote: > > > David Miller wrote... > > > Hello all:) > > > > > > I'm struggling to bring up a scsi based mpeg2 decoder on 2.2.7. Right now > > > I'm trying to kick start it with the "scsi" command. In order to write to > > > it I'm using: > > > > > > alex# dd if=test.mpg bs=64k count=1 | ./scsi -f /dev/uk0 -c "2A 0 0 0 80 > > > 0" -o 65536 "-" > > > 1+0 records in > > > 1+0 records out > > > 65536 bytes transferred in 0.008196 secs (7996099 bytes/sec) > > > SCIOCCOMMAND ioctl: Input/output error > > > > > > > > > Since I certainly can talk to the board (identification inquiry, color > > > bars, soft reset) this is not a general communications problem. > > > > > > Is this a case of ioctl not wanting to issue this command to uk0? If so, > > > how do I tweak uk() so as to write to it? If not, what is it telling me? > > > > There are several things wrong with the above command. > > > > - the CDB length is wrong > > Bingo! I saw that while reading the doc's for the tenth time this > morning:) I mistakenly changed the 0a to 2a without adding the other > fields in the CDB:( Oops. > > - you either have not specified the length of the command, or if the '80' > > above is part of the length, it doesn't match up with the length you gave > > to the scsi command on the command line. > > The 80 is correct in this case. Length is specified for this device as the > number of 512 byte blocks. Not that there was any way for you to know an > idiosynchrasy (sp) like this:) Yeah, I wouldn't have guessed. :) > > Try something like: > > > > ./scsi -f /dev/uk0 -c "2A 0 0 0 0 0 0 ff ff 0" -o 65535 "-" > > > > That will hopefully write 65535 bytes at address 0. > > > > What kind of device is this, any way? I mean, what device type does it > > probe as? > > It's a Vela Research scsi-2 mpeg-2 decoder, and probes as device type 12. 12?? That's the code for a storage array! I would expect it perhaps to be 10 or 11 or something, but probably not 12. Unless you mean 0x12, and then that's a 'reserved' device type, according to the SCSI 2 and SCSI 3 specs. > Any words of wisdom on how to create a device type vl (as opposed to st, > uk, pt, etc:) ? I'd like to clean things up a little. > > OTOH, I should probably do this under 3.1Stable, and the scsi system is > all changed. Is it easier/harder under CAM? I would suggest doing it under CAM. I'll at least be able to give you some advice/help if you use CAM. I don't know nearly as much about the old SCSI layer, though, so you'd be dependent on other folks to help out. It should be pretty easy to do a peripheral driver for it under CAM. You'll probably want to give it a read-write interface. That would probably make things go a lot easier. My guess is that that thing has a fairly non-standard interface. So in the probe routine for the peripheral driver you'll want to make sure that it only attaches to that particular device. (You'd look at the device type number, as well as the inquiry data.) If you don't want to write a driver for it, you can do the same tricks with camcontrol(8) that you're doing with scsi(8) now. Or you can write a userland application that uses the pass(4) driver to talk to the device. Depending on the interface, though, I think it would be easier to just write a driver, so you can read and write to the thing. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message