Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 26 Sep 2002 10:46:43 +0100
From:      Bruce M Simpson <bms@spc.org>
To:        Larry Rosenman <ler@lerctr.org>
Cc:        freebsd-mobile@freebsd.org
Subject:   Re: DMI Multi-Flash (USB)
Message-ID:  <20020926094642.GR26280@spc.org>
In-Reply-To: <1033030248.391.0.camel@lerlaptop.lerctr.org>
References:  <1032971644.441.17.camel@lerlaptop.iadfw.net> <20020925164121.GP26280@spc.org> <1033030248.391.0.camel@lerlaptop.lerctr.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 26, 2002 at 03:50:45AM -0500, Larry Rosenman wrote:
> On Wed, 2002-09-25 at 11:41, Bruce M Simpson wrote:
> > On Wed, Sep 25, 2002 at 11:34:03AM -0500, Larry Rosenman wrote:
> > > Anyone tried to figure out how to get one of these to work?  It's a USB
> > > Flash memory reader, that supports 4 units, SmartMedia, SD/MMC,
> > > CompactFlash, and MemoryStick.  When I add it to the port I get:
> > 
> > Please run the udesc_dump(1) utility *without* loading the umass.ko
> > kernel module, and send us the output.
> > 
> Here it is:
[snip]
> Standard Device Descriptor:
[snip]
>   idVendor           0c0b
>   idProduct          001c
>   bcdDevice          0100
[snip]
> 
> Configuration 0:
[snip]
> 	Standard Interface Descriptor:
> 	  bLength            9
> 	  bDescriptorType    04
> 	  bInterfaceNumber   0
> 	  bAlternateSetting  0
> 	  bNumEndpoints      3
> 	  bInterfaceClass    08
> 	  bInterfaceSubClass 06
> 	  bInterfaceProtocol 50
> 	  iInterface         0
[snip]
> 	  bmAttributes     02 (Bulk)
[snip]
> 	  bmAttributes     02 (Bulk)
[snip]
> 	  bmAttributes     03 (Interrupt)
[snip]

So this would appear to be a Command/Block/Interrupt (CBI) device, 
UCLASS_MASS, USUBCLASS_SCSI, but the protocol 0x50 isn't something 
handled by the USB code in -STABLE. Linux seems to think of it as
US_PR_BULK.  According to the OpenBSD tree, 0x0C0B has the meaning
USB_VENDOR_DMI and also USB_VENDOR_AGATE.

It's possible this device could be supported with some hacks to the
umass driver, but without having access to such a device, I can't say for
sure; some protocol analysis of the behaviour of the Windows driver using
a tool such as USB Snoopy would be necessary; it smells like a USB-ATA
device, though, and these are problematic to support.

Although the USB-ATA solutions seem to be cheaper than anything else, but
horrendous to write a driver for. I fought with a PNY CF/Smartmedia USB
reader for a while, then gave in and bought a SanDisk (because the
controller isn't braindead on such devices).

BMS

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-mobile" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020926094642.GR26280>