No subject

[Barry Bouwsma]

<pete at altadena.net>
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