From owner-freebsd-usb@FreeBSD.ORG Sat Jan 29 02:11:48 2005 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C313716A4CF; Sat, 29 Jan 2005 02:11:48 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (84-72-24-62.dclient.hispeed.ch [84.72.24.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27E0343D39; Sat, 29 Jan 2005 02:11:45 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [IPv6:2002:5448:183e:0:206:28ff:fed8:8dcf]) (8.13.2/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id j0T29OJq002277NO); Sat, 29 Jan 2005 03:09:32 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.13.2/FNORD) id j0T29N5F002276; Sat, 29 Jan 2005 03:09:23 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Sat, 29 Jan 2005 03:09:23 +0100 (CET) Message-Id: <200501290209.j0T29N5F002276@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma References: <20050103205820.GA74545@users.altadena.net> <20050103214607.GB64429@cicely12.cicely.de> To: Pete Carah Mail-Followup-To: freebsd-usb@freebsd.org, hardware@freebsd.org, Pete@FreeBSD.ORG, Carah@FreeBSD.ORG cc: hardware@freebsd.org cc: freebsd-usb@freebsd.org cc: Bernd Walter Subject: X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Barry Bouwsma List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2005 02:11:49 -0000 Subject: Re: Adaptec USB2Xchange [moved from current@ over to usb@ which seems more appropriate, left in hardware@ also ] > > I have reason to use a USB to SCSI adapter under FBSD. I have a USB2Xchange > > from Adaptec, but (as usual for adaptec) it requires a firmware load, which > > appears harder in usb than in PCI. Does anyone know how to do this? (Should > > Kernel attach message is: > > ugen0: Adaptec product 0x2002, rev 2.00/1.00, addr 2 > As far as I know the Adaptec parts can do multiple addreses, which is > not part of umass specification. > They may use a vendor extended umass or completely different protocol. > Whatever it is - the device doesn't offer itself as beeing umass. > With vendor specs it should be simple to teach our umass driver about > this special device, even if it really isn't umass. > Also firmware uploading in USB is very simple if you have vendor specs. Has anyone gotten any further with this? If not, I'll tell you what I've managed to do so far: Thanks to that post made to a Linux list which I referred to some weeks ago, and to the NetBSD uyap driver, I was able to get somewhere. First, from the posted message, I took the firmware includes file and hacked it to match the format of the ezload.c utility used by NetBSD's uyap. (No guarantee I got that right.) Then I modified NetBSD's uyap.c and called it uadaptec.c, to port it to FreeBSD 4.x and change a few things to match with the mailing list posting. I also ported ezload.c for FBSD 4.x. The list posting indicated that a special sequence needed to be sent after firmware load, or something. I tried adding that to ezload or uadaptec.c, but it wasn't quite successful. I suspect I need to send those as part of a umass.c quirk. Anyway, in my latest tests, building uadaptec.c as a module, I'm able to download the firmware, whereupon the device detaches from the bus, and then gets snagged again by ugen.ko, as it's not as pure a umass device as the code expects. When I add an entry to umass to grab the device (its product ID changes from 0x2002 before firmware load, to 0x2003 after), then it attaches to umass, and creates luns up to pass7, all of which have oddball zero-size geometry. The following two times I tried this, I got panics (divide by zero), so maybe I was lucky the first time, or else what I'm seeing is a result of not sending those missing commands. After the firmware load, here's what the device shows with `usbctl': DEVICE addr 3 DEVICE descriptor: bLength=18 bDescriptorType=device(1) bcdUSB=2.00 bDeviceClass=0 bDeviceSubClass=0 bDeviceProtocol=0 bMaxPacketSize=64 idVendor=0x03f3 idProduct=0x2003 bcdDevice=100 iManufacturer=1(Adaptec, Inc.) iProduct=2(Adaptec USB2-Xchange Adapter) iSerialNumber=3(020000008348) bNumConfigurations=1 CONFIGURATION descriptor 0: bLength=9 bDescriptorType=config(2) wTotalLength=32 bNumInterface=1 bConfigurationValue=1 iConfiguration=4(USB2.0 to SCSI) bmAttributes=80 bMaxPower=500 mA INTERFACE descriptor 0: bLength=9 bDescriptorType=interface(4) bInterfaceNumber=0 bAlternateSetting=0 bNumEndpoints=2 bInterfaceClass=255 bInterfaceSubClass=0 bInterfaceProtocol=255 iInterface=5(USB Mass Storage, Bulk Only) ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=2-out bmAttributes=bulk wMaxPacketSize=64 bInterval=0 ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=6-in bmAttributes=bulk wMaxPacketSize=64 bInterval=0 current configuration 1 ---------- This is quite different from its power-up state, which hasn't been posted yet. I don't have any devices to attach to this adapter to see if that makes a difference. According to the Linux list post, the device is a well-behaved umass device after firmware load. Seeing that I have no idea what I'm doing, it's possible that I've botched the firmware include file. Or I could have maybe botched the ezload.c or uadaptec.c file, getting an address wrong or something. Or it could be that I need to add those missing resets to umass.c -- or that I wasn't doing them right in uadaptec.c. Or plenty of other things I could have screwed up. I've done all this for my hacked FreeBSD 4.x USB stack, but it should be pretty trivial to get this working with 5.x and -current for anyone who wants to give it a try. My umass.c is snarfed from an older -current, to get functioning multi-card-readers, which may be related to the problems with the luns of the adapter. The files I hacked upon can be found at https://NOSPAM.dyndns.dk/hacks/adaptec/ and you should be able to build from these just like most other modules. At the moment I'm missing a umass.c hack, and I'll put that up after sleeping on it or something. Without this hack, you probably won't panic your machine the way I did, but after uadaptec.ko grabs the adapter and stuffs it with code, it should then appear with the different product ID and different appearance with `usbctl' and such. If you snag it with umass.ko, the LED on the adapter will come on as well. These aren't the files I built, but after trying to clean them up (my hacks are easy to find searching XXX and/or HACK), so I may have broken them, but I'll sleep on it first before needing to think clearly. Feel free to take my work, erm, hacks, and do as you see fit with them, or make them work properly, or if you know more than I do, fix ezload.c to be a general-purpose loader handling both this adapter as well as the uyap for which it was written, and anything else that may need to use EZ-USB. So close, but yet so far... thanks barry bouwsma